[Pkg-mono-devel] Moonlight Package Licensing

Sun Apr 26 11:09:21 UTC 2009

On Sat, 2009-04-25 at 21:41 -0400,
saulgoode at flashingtwelve.brickfilms.com wrote:
> Quoting Jo Shields <directhex at apebox.org>:
> 
> > Why am I only hearing about licensing concerns regarding a package I
> > maintain when reading about it on a personal attack website? I'd usually
> > think that a package's maintainer should be included in such
> > discussions, assuming you're interested in their input.
> >
> > Please remember that debian-legal is an advice forum, and in no way has
> > a formal role regarding license compliance - that role belongs to
> > ftp-master.
> 
> I was not aware that debian-legal was a personal attack website. :)

It's not. But BoycottNovell is, and the first I heard about your posting
to debian-legal was there - as opposed to being CC'd in as the package's
maintainer.

> But seriously, I welcome your input and appreciate your response.  
> You've addressed many of the concerns I raised and it would seem I had  
> indeed garnered some misconceptions from the Debianwiki Project page.  
> No animosity was intended in my pointing out inaccuracies on that  
> page, nor did I consider them to be overly disconcerting. More than  
> anything, the Project wiki was presented as the basis for my  
> understanding of the codebase (but in time the page should be amended).
> 
> Regarding Cairo components and the Mozilla Public License:
> > The license has zero role in the package - but rules state that licenses
> > need to be disclosed in debian/copyright for ALL source in a given
> > source tarball, whether that code is used in final binary packages or
> > not. The embedded copies of cairo and pixman are NOT used in the binary
> > packages. Nor is any Ms-PL source.
> Apparently I have been misinformed on the components constituting the  
> Debian binary package and much of my concern over that misapprehended.  
> If one may ask, why is there code in the source tarball that does not  
> get included in the binary? Is their exclusion handled by configure  
> switches? The Project wiki provided an admirable description of the  
> role FFMPEG played in the package; perhaps a similar description could  
> be provided for code licensed under the MPL, LGPLv2.1, and Ms-PL.

Upstream recommends that their own copy of Cairo be used - I ignore
this, basically because I hate duplication of libraries (as do
ftp-master), and there doesn't seem to be any actual changes to the
bundled copy that would necessitate giving it its own unique copy. It's
controlled by the --with-cairo flag - the package uses
--with-cairo=system to use Debian's Cairo.

The Ms-PL stuff consists of two places - some Javascript files (which
are never compiled anyway, and are used as part of the test harness),
and Microsoft's Silverlight Controls (which would be enabled using
--with-managed=yes, default is no). This stuff isn't compiled basically
because Moonlight 1.0 isn't usable as a Managed (Silverlight
2.0-compatible) plugin. When it eventually IS compiled in future
packages, then it'll be as distinct libraries - i.e. the moon source
package isn't producing one enormous .so mixing all its constituent
libraries, the Ms-PL section of the source will be compiled into its
own .dll with no mingling of other incompatibly-licensed source. And I
think we can agree that using a library with one license on a runtime
with another license is fine (Just ask the libc folks)

> >> As a final comment, and one more hypothetical in nature, the Ms-PL
> >> makes no distinction between derived and collective works and offers no
> >> exemption for "mere aggregation" (as does the General Public License).
> >> In lieu of such an exception, we are left with relying upon the
> >> interpretation of the courts as to what constitutes a derived or
> >> collected work of joint authorship under copyright law. Should a
> >> Ms-PL-licensed package be included with a Debian distribution, it may
> >> very well be argued that the entire distribution (a collective work)
> >> must be offered under licensing which "complies with" the Ms-PL -- any
> >> inclusion of code for which there is no patent grant could be construed
> >> as infringement of the copyrights of Ms-PLed code's author.
> >
> > How likely does that REALLY seem to you? codeplex.com contains a lot of
> > Ms-PL source, and a lot of other licenses (including some non-Free
> > licenses). How likely does it seem that a "mere aggregation" like a code
> > website is actually licensing everything under one of its constituent
> > licenses, by accident?
> 
> Let me clarify that when I stated my comment was "more hypothetical",  
> it was precisely owing to the fact that the Moonlight packages are in  
> a third-party repository and that "a code website" should probably not  
> be considered under copyright law definitions as a ?joint work? ("...  
> a work prepared by two or more authors with the intention that their  
> contributions be merged into inseparable or interdependent parts of a  
> unitary whole" - USC Title 17 § 101). The argument that a Debian  
> distribution might be a "joint work", however, is not quite so  
> tenuous. Even though one can separate out *copies* of the individual  
> components, the distro itself is an instance of a "unitary whole".

Okay, another example then. If some Ms-PL libs or tools are used in
Visual Studio, then is Visual Studio Ms-PL? And I mean Ms-PL, not
"dual-licensed Ms-PL|Proprietary"

> > See also: Hanlon's Razor.
> 
> If by this you are suggesting that my concern is attributable to my  
> considering the author of the Microsoft Public License to be  
> "malicious", such is not the case. Whether a combination of code  
> contributions under disparate licenses should be considered to result  
> in a collective or derived work is not a matter to be decided by the  
> license authors (unless there is language in the license explicitly  
> addressing this), but by the holders of the code's copyrights (in that  
> they may choose whether or not to pursue the matter) and, ultimately,  
> by the courts.

You could ask Microsoft's Open Source people for clarification. But you
seem to be asserting not that Ms-PL + non-Ms-PL source -> Ms-PL, but
that compiled Ms-PL + internet -> Ms-PL. Which seems to me to be
something that could never be intentional if it WERE the case, and could
never hold up in court whether or not it were intentional. Again, you
could always ask for clarification from the people behind the license.

> The terms and conditions of the Ms-PL need to be examined for what  
> they actually say; not what we want them to say, nor what we expect  
> them to say. The lack of a "mere aggregation" exemption is, in my  
> opinion, extremely problematic for Free Software providers -- imagine  
> the ramifications to Linux-based distros if the GPL didn't provide  
> such an exemption -- and the unorthodox requirement that one license  
> "complies with" another places conditions on combining contributions  
> far stricter than a requirement of "does not contradict" (as in the  
> AFL 3.0). The intention of the license's author is of little  
> significance once the license is written; what matters is how the  
> courts will apply the code of law to the copyrights covered by the  
> license.

I agree that "does not contradict" would have been better wording. Where
were you at the OSI approval process? :p

You could propose your changes to Microsoft. They might well accept
them. Whilst applications in general would need to be relicensed by
their authors under Ms-PL2 (since the license has no GPL-like
or-later-version provision), the specific bits here (Silverlight.js and
the Silverlight Controls) are © Microsoft anyway, so they'd be in a
position to do so.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-mono-devel/attachments/20090426/b6114e61/attachment.pgp>