If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Research MPL / LGPL license compatibility

RESOLVED WORKSFORME

Status

mozilla.org
Licensing
--
critical
RESOLVED WORKSFORME
16 years ago
12 years ago

People

(Reporter: timeless, Assigned: Frank Hecker)

Tracking

Details

(Reporter)

Description

16 years ago
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 (mitchell@mozilla.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 (dveditz@netscape.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

Comment 1

16 years ago
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.
(Reporter)

Updated

16 years ago
Blocks: 16489
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
(Reporter)

Comment 4

16 years ago
filed bug 91596 to research 'javascript libraries' and lgpl...
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.
(Reporter)

Comment 7

16 years ago
*** Bug 91360 has been marked as a duplicate of this bug. ***
--> Licensing
Assignee: mitchell → hecker
Component: Miscellaneous → Licensing
QA Contact: mitchell → gerv
I can't see any further value in this bug.

Gerv
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 10

12 years ago
Again, I stand by my comments above; this bug is closed as far as I'm concerned.
You need to log in before you can comment on or make changes to this bug.