91596 - Investigate License ramifications of 'Linking' LGPL and MPL Javascript to be run by an MPL JS Engine as part of Mozilla

Status: RESOLVED DUPLICATE of bug 225189

(mozilla.org :: Miscellaneous, task)

Description

[timeless]

Welcome to MPL-LGPL question 2.

Question 1 was bug 91384 based on an MPL-LGPL patch for bug 16489.

This bug is based on [e-mail]:
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.

Question focus:
What determines an application? What determines a library? How do they interact 
when the questionable 'code' is JavaScript under LGPL and the interpretter is 
the MPL js runtime where the specific `application` would be a mozilla 
seamonkey relative/derivative.

Assertion:
The person intending to use LGPL w/ MPL in Question 2 is not the owner of the 
MPL code/file(s) or the LGPL code/file(s), otherwise the person could treat the 
owned code as owned and relicense, which is beyond the scope of the question.

Question 2:
w/o relicensing, can LGPL javascript code be legally referenced by an MPL 
licensed xul file and used by MPL licensed javascript (either in an MPL js file 
or an MPL xul file) under the terms of the LGPL and MPL? Corollary, can the 
LGPL file be included w/ Mozilla and under what conditions?

Assumption:
The MPL code would not be particularly functional w/o the LGPL code which is 
why the LGPL code is being included.

According to my reading of LGPL 2.d an LGPL spell checker must function w/o a 
dictionary. -- An interesting question would be, if the LGPL spell checker 
functions w/o a dictionary, does function for MPL code work if it uses try {} 
and manages to NOOP (identity function f(a){return a}) if the LGPL code is 
missing)

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

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&rn
um=45&ic=1&selm=376EFAC8.36821A7C%40netscape.com

Daniel Veditz ([e-mail]) 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.

Frank Hecker:
This question is specifically concerning the effects of combining MPLed script 
code and LGPLed script code in a package where the script interpretter is under 
MPL and the package was expected to be MPL. 

bug 53518
1. Put the code in separate files. Note that IMO you could actually use the 
preprocessor to #include one file in the other. This may be bending the 
spirit MPL and NPL a little, but I personally don't think it's out of bounds.

Comment 1

[Daniel Wang]

duping to Timeless's more recent bug :-)

*** This bug has been marked as a duplicate of 225189 ***