Re: mono and moonlight distribution method make me worried.

2009-06-03 Thread saulgoode

Quoting Bradley M. Kuhn bk...@ebb.org:


Steve Langasek wrote at 19:58 (EDT) on Sunday:


we don't consider the existence of a software patent claim to be a
sufficient reason to remove software from main.


Well said.  There are so many USA patents, if you tried to remove every
piece of software from main that might be judged to practice the
teachings of some patent, you'd do a *lot* of removing.

Nevertheless, possible patents on Mono and what Novell/Microsoft's
strategy is with regard to releasing this software is something to watch
and be concerned about.


The Mono Project assures us that Microsoft holds patents that cover  
the ECMA 334/335 technology; they even go so far as to identify one of  
the inventors[1]. The Mono Project does not state that they practice  
those patents, but they also do not suggest in any way that those  
patents are either invalid or that their practice is avoided in the  
Mono implementation of the ECMA standards.


Instead the Mono Project asserts that a royalty-free, reasonable, and  
non-discriminatory patent grant has been provided by Microsoft. Both  
Microsoft and Hewlett-Packard have complied with ECMA requirements[2]  
in promising to offer their patents covering ECMA 334/335 under RAND  
terms[3]; and an archived email from the aforementioned inventor is  
cited by the Mono Project as further promising that the RAND licensing  
would be offered royalty-free[4].


However, if one examines the details of the patent declaration,  
Microsoft states that the RAND licensing is available to any party  
requesting it. The royalty-free addendum by Jim Miller does not  
relieve this requirement to actually request the license from  
Microsoft. In addition, the patent declaration ensures its validity  
only for the duration of the ECMA standard.


Not to conflate the issues of patent licensing with copyright  
licensing, but if it is indeed required that the patent indemnity be  
requested then from a patent license perspective, the Mono  
implementation should fail Debian Legal's Desert Island and  
Dissident tests for DFSG compliance[5] because upstream must be  
contacted and the licensees identified. Furthermore, the limitation of  
the validity of the patent declaration to the duration of the ECMA  
standard should fail the DFSG's Tentacles of Evil test.


Now I would certainly agree that patent claims of persons or companies  
not involved in the development of a Free Software project should not  
be sufficient cause for exclusion of that software from Debian Main;  
however, it seems that when it is the Free Software project itself  
asserting the claims, and relies upon the licensing from the patent  
holder as justification for practicing those patents, it is  
appropriate to consider the actual terms of that licensing.


[1] http://www.mono-project.com/FAQ:_Licensing
  The core of the .NET Framework, and what has been patented by Microsoft
  falls under the ECMA/ISO submission. Jim Miller at Microsoft has made a
  statement on the patents covering ISO/ECMA, (he is one of the inventors
  listed in the patent): here[3]
[2] http://www.ecma-international.org/memento/codeofconduct.htm
[3] (PDF)  
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma%20PATENT/ECMA-334%20%20335/2001ga-123%20%202002ga-003.pdf


[4]  
http://web.archive.org/web/20030424174805/http://mailserver.di.unipi.it/pipermail/dotnet-sscli/msg00218.html

[5] http://en.wikipedia.org/wiki/DFSG#debian-legal_tests_for_DFSG_compliance





--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



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.



Moonlight Package Licensing

2009-04-24 Thread saulgoode
I would raise a few questions about the licensing terms of the  
Moonlight Project's source and binary packages.


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


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).


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.


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.


The essentially MIT with patent grants claim ignores the Ms-PL's  
lack of permissiveness, its requirements of reciprocity, and its viral  
nature. At issue is not whether these characteristics are good or bad,  
but that they are as essential to the nature of the Ms-PL license as  
its patents grants, and that their terms and conditions are  
dramatically different from corresponding terms (or lack of them) in  
the MIT license.


The preceding was mainly covering the tedious bookkeeping aspects of  
licensing and can be either addressed through modification of the  
appropriate documentation or, if deemed appropriate, even ignored.


===

The more salient point of this post is to address the incorporation of  
code licensed under the Microsoft Public License into Debian binary  
packages. (For reference, the text of the Ms-PL can be viewed at  
http://www.microsoft.com/resources/sharedsource/silverlightcontrolslicense.mspx)


First, I would point out that the Ms-PL inheres acceptance of the  
license by mere usage (If you use the software, you accept this  
license). Since acceptance of the license entails the sacrifice of  
certain rights with regard to bringing patent lawsuits against the  
copyright holders, it would seem incumbent that the package installer  
provide an opportunity to reject the license and not install the  
software or, alternately, the first-run of the software should provide  
a similar approval dialog.


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?


Section 3(D) of the Ms-PL specifies that the following condition  
should be met by the Debian binary package licensing: If you  
distribute any portion of the software in compiled or object code  
form, you may only do so under a license that complies with this  
license.


Since the license for the Debian package must comply with the Ms-PL,  
its license should necessarily offer the patent grants required in  
Section 2(B). Assuming that a license which complies with the Ms-PL is  
used -- or indeed that the Ms-PL itself used -- the question is thus  
raised, how are patent grants being provided for the MIT/X11-licensed  
components of the Debian binary package? Without providing such a  
grant, the package licensing would not meet the terms and conditions  
of Section 2(B) and fail to comply with the Ms-PL. Providing such a  
grant should demand extra measure be taken with regard to the  
MIT/X11-licensed code because the authors of that code were not  
obligated by its licensing to provide such a grant.


As a final comment, and one more hypothetical in nature, the Ms-PL  
makes no distinction between derived and collective works and offers  
no