w/o relicensing, can LGPL code be legally added to an MPL licensed file under the terms of the LGPL and MPL? (Implication: the person intending to merge them is not the owner of the MPL code/file and the LGPL code/file, otherwise the person could treat the owned code as owned and relicense, which is beyond the scope of the question.) netbeans.org http://www.netbeans.org/contrib-modules.html point 7. Decide on a license for your code and properly mark all your source files - if you have no objections to it, you can use the Sun Public License which NetBeans code uses and which is functionally very similar to the Mozilla license. If you prefer to use another license such as GPL, or LGPL, that is your decision to make. Note that a module under the GPL can not be distributed with other NetBeans modules or the NetBeans core, it can only ever be distributed as a standalone unit. The same is (probably) true of a module under the LGPL. See http://www.gnu.org/philosophy/license-list.html for a listing and description of licenses. You might want to ask for opinions on the mailing list if you are not sure. it can't be and two other individuals seemed too come to that conclusion (mozGlade, Curl). 2.c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. <ot> According to 2.d an LGPL spell checker must function w/o a dictionary.</ot> These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. This seems to force an application/package that includes LGPL to _be_ LGPL. 5. ... However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. ... If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. <comment>this portion might be interesting in its application to the bug which necesitated this request.</comment> ... It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. --end interesting snippets from http://www.gnu.org/copyleft/lesser.html "GNU Lesser General Public License". References from groups.google http://groups.google.com/groups?q=lgpl+mpl&num=100&hl=en&group=netscape.public. mozilla.*&safe=off&rnum=4&ic=1&selm=37435D87.CC2EE75F%40mozilla.org Mitchell Baker (firstname.lastname@example.org) Re: LGPL versus MPL http://groups.google.com/groups?q=lgpl+mpl&num=100&hl=en&group=netscape.public. mozilla.*&safe=off&rnum=45&ic=1&selm=376EFAC8.36821A7C%40netscape.com Daniel Veditz (email@example.com) Subject: Re: Including Mozilla in GPL/LGPL'ed project from dveditz's article and my reading i think it would be possible to have mpl files which reference/rely on lgpl files, but i don't think you could mix code from the two licenses in a single file. results drawn from http://groups.google.com/groups?q=lgpl+mpl&hl=en&safe=off&meta=site%3Dgroups%26 group%3Dnetscape.public.mozilla.* Searched Groups for lgpl mpl in netscape.public.mozilla.* Results 1 - 85 of about 91. Search took 1.71 seconds. (groups.google beta, i see no way to find articles 86-91) fwiw, gropus.google's archive of netbeans.* seems broken (probably based on news.netbeans.com). the relevant news servers are news.mozilla.org and news.netbeans.org
Just to clarify, is the question specifically concerning the effects of combining MPLed code and LGPLed code in a single source file? If that is the question, then IMO that would cause problems unless you secured appropriate permissions from one of the two parties that originally licensed the code. For example, suppose you took a sequence of source code lines licensed under the MPL, and added a second sequence of source code lines licensed under the LGPL to create a single resulting source file. According to the MPL the new source file would be considered a Modification of the MPLed code, since per MPL 1.9(b) it would be a "new file that contains [a] part of the Original Code". As a Modification, the new source file would be considered Covered Code, since by MPL 1.3 "'Covered Code' means the Original Code or Modifications ..." And as Covered Code the new source file would have to be licensed under the MPL, since per MPL 3.1 "The Source Code version of Covered Code may be distributed only under the terms of this License or a future version of this License ..." According the LGPL the new source file would also be considered "a work based on the Library", since by LGPL 0 it would be a "a work containing the Library or a portion of it". And as a work based on the Library the new source file must be licensed under the LGPL, since per LGPL 2(b) "You must cause the whole of the work [based on the Library] to be licensed at no charge to all third parties under the terms of this License." So we have the result that the new source file must be licensed in its entirety under both the MPL and the LGPL. But IMO this would require the permissions of the original licensors, since the LGPL grants rights that are not granted by the MPL and are not inferable from it, and vice versa. To take but one example, LGPL 3 allows the licensee to relicense code under the GPL, a right which is not explicitly granted by the MPL and which is not inferable from the rights that the MPL does grant. So in this case of combining the two types of code in a single source file either the copyright holder for the MPLed code must grant permission for it to be used under LGPL terms or the copyright holder for the LGPLed code must grant permission for it to be used under MPL terms. Note that this case is very similar to the case discussed in bug 53518, which involved mixing MPLed code and NPLed code in a single file. Both are instances of the general problem of combining code under different copyleft licenses.
The FSF has specifically said MPL is not compatible with (L)GPL because it imposes "additional restrictions" which are forbidden by the GPL/LGPL. When Frank says you need to "[secure] appropriate permissions from one of the two parties that originally licensed the code" he means you have to get them to give you a copy of the code under a different license. That's an option the original question specifically precludes. There would be no problem linking an MPL project with an LGPL *library* (as long as you follow the LGPL rules for such linking), but there's no practical way to combine random source code taken from that library with code under the MPL license, or to add MPL code into the library. The LGPL was specifically created to allow distinct chunks of basically GPL code to be able to link with non-GPL code. It's a compromise on the principles of the GPL, just as the MPL is a different compromise between pure copyleft and BSD-like freedom.
here are two examples in the tree to support the claims made in this discussion: http://lxr.mozilla.org/seamonkey/source/gfx/src/xlibrgb/xlibrgb.c http://lxr.mozilla.org/seamonkey/source/extensions/ctl/src/pangoLite/shape.c
The two examples given are both "dual licensed", or as RMS prefers a "disjoint" license. For Mozilla purposes we use the file under the MPL and ignore the fact that it could also be used under the LGPL. The file can be copied under one set of terms or the other, not both at once. These cases sidestep the issue raised by this bug, which starts with the assumption "w/o relicensing".
you are right - going back to the original question this is about distribution "w/o relicensing". However, the examples I've included refer directly to Frank's comment - "this case of combining the two types of code in a single source file either the copyright holder for the MPLed code must grant permission for it to be used under LGPL terms or the copyright holder for the LGPLed code must grant permission for it to be used under MPL terms." Seems like for practical purposes (i.e. for bug 16489), it would suffice to contact the copyright holder and relicense under MPL or simply use another secure hash implementation as suggested by timeless.
*** Bug 91360 has been marked as a duplicate of this bug. ***
I can't see any further value in this bug. Gerv
Again, I stand by my comments above; this bug is closed as far as I'm concerned.