Re: Moonlight Package Licensing

2009-04-26 Thread Jo Shields
On Sat, 2009-04-25 at 21:41 -0400,
saulgo...@flashingtwelve.brickfilms.com wrote:
 Quoting Jo Shields direct...@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  
 

Re: Moonlight Package Licensing

2009-04-25 Thread Jo Shields
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.

Firstly, there seems to be some inaccuracies on the Project's
Debianwiki page
(http://wiki.debian.org/Teams/DebianMonoGroup/Moonlight).

This page isn't guaranteed to be up to date or accurate - it was used
largely for discussion and collaboration whilst the package was being
prepared. The Debian Mono Group uses wiki pages for collaboration a fair
bit.

The Moonlight licensing is described as consisting of MIT/X11, Ms-PL,
and LGPL2.0-only; yet there are Cairo components in the source tree
which are licensed under the dual licenses of the Mozilla Public
License and the LGPLv2.1-only. There is no real conflict here (to my
understanding), however, offering this code under any of the MIT/X11,
Ms-PL, or LGPL2.0-only licenses relies upon the fact that the *MPL*
permits re-licensing under more restrictive terms (the LGPLv2.1
licensing of the Cairo code serves no purpose towards this end -- you
can't re-license LGPLv2.1-only software except as GPL). The project
page, as well as all of the appropriate sources' COPYING files, should
reflect the nature of this re-licensing (the moonlight-mozilla-plugin
provides the text of the Mozilla Public License but does not indicate
the license's role in the package).

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.

Moonlight 1.0 is a combination made by compiling LGPL2, GPL2 (ffmpeg),
and MIT/X11 together. The result is unambiguously GPL2. However, dumb as
it may seem, debian/copyright doesn't reveal a package's final compiled
binary license (only the source tree).

Also in the same section, the Ms-PL is characterized as a DFSG-free
GPL3-compatible license from Microsoft which is essentially MIT with
patent grants.

The GPL3 compatibility claim contradicts the description given on
GNU.org (http://www.gnu.org/philosophy/license-list.html) wherein it is
stated, This is a free software license; it has a copyleft that is not
strong, but incompatible with the GNU GPL.

The description of Ms-PL from the FSF changed between when that wiki
page was written and now, with no obvious discussion involved. At the
time the page was written, it was marked as GPL3-compatible.

I would neither contradict nor corroborate the DFSG-free claim for the
Ms-PL, but note that there is no mention of the Ms-PL on Debianwiki's
DFSG Licenses page (http://wiki.debian.org/DFSGLicenses). If I have
missed wherein the discussion occurred over the compatibility of the
Ms-PL with the Debian Free Software Guidelines, I should welcome the
opportunity to read it.

I believe the first Ms-PL licensed source code in the archive was
IronPython - please refer to its packager and possibly the appropriate
ftpmaster (and the ITP bug, and so on) to read about it.

More importantly, it seems rather inescapable that a Debian binary
package is a collective work of the software that is included in that
package. The licensing of that collective work must not conflict with
the terms and conditions of the individual licenses of components of
that package. The question is thus raised, what is the licensing for
the Debian binary package of Moonlight?

GPL2. See above.

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? See also: Hanlon's Razor.

Regards.

--Jo Shields


signature.asc
Description: This is a digitally signed message part


Re: Moonlight Package Licensing

2009-04-25 Thread saulgoode

Quoting Jo Shields direct...@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. :)

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.



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.



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.


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.