On Thu, 13 Sep 2001, Ben Bucksch wrote:
>
> Did the thread started in .general? Can you give a short summary?

Someone mentioned that all the worlds problems would be solved if we used
the LGPL instead of the MPL. I said, in reply:

The LGPL would also prevent anyone from building Mozilla using MSVC++,
since the MSVC++ redistributables license disallows reverse engineering,
and the LGPL requires that that be allowed.

I see no advantage of licensing Mozilla using the LGPL that isn't also
covered by dual licensing Mozilla using the MPL/GPL. I do, however, see
disadvantages, including the Patent issue that the MPL covers.

And before anyone suggests it, licensing MPL/LGPL would be pointless,
since the MPL allows everything the LGPL allows and more -- MPL/LGPL would
merely be a nuissance to those who want to use it as GPL (since LGPL
allows you to assume the license is the GPL, but requires that you
change every file in the tree to say so).

See also: http://www.fsf.org/licenses/why-not-lgpl.html


> Gervase Markham wrote:
> 
>> I think Hixie's saying that if you want to combine with GPL code, you 
>> have to change all the notices, as section 3 requires, before you can 
>> do so. This is inconvenient (and may make returning changes to the 
>> original codebase more complex.)
> 
> That's a problem, but not that bad that it were the reason to 
> dual-license under GPL instead of LGPL.

So, what are the advantages of using the LGPL?


> There are quite a number of LGPL problems, and Mozilla code 
> dual-licensed under the GPL could not be used in those projects, 
> assuming they want to keep the ability to be used under LGPL terms.

Any project using the LGPL should be equally happy with an MPL/GPL dual
license, since when the LGPL code is linked with proprietary code, it can
be linked with the MPL code, and when the LGPL code is linked with GPL
code (changing it to GPL in the process) it can be linked with Mozilla's
GPL code.

The only case where I can see a problem is where a specific LGPL library
wishes to use Mozilla's code directly (i.e., not linking to it). Is there
really such a case?


> Note that this problem is (again!) a problem inherent with the LGPL
> and not limited to the dual license. If you want to use LGPL-"native"
> code in GPL projects, you have the same problem. It is unclear, how it
> works, if I don't directly incorporate/import the code into the GPL
> project, but just use it (e.g. linking, extracting mozilla tarballs
> etc.).

The GPL is pretty clear about it. Do you have any specific examples of
where you think it is unclear?


(IANAL. These are merely my opinions. I should also point out that my
overall opinion on this issue is that we should be pure GPL, but that I
accept the MPL is a necessity for Netscape to be able to ship Mozilla with
the AIM code, which AOL do not want to open. The LGPL would not help
Netscape here, since it requires that the user be allowed to reverse
engineer all the product, including, in this case, the proprietary AOL
code. I personally do not want to promote either the MPL or the LGPL since
neither are strong copyleft.)

-- 
Ian Hickson                                     )\     _. - ._.)       fL
                                               /. `- '  (  `--'
                                               `- , ) -  > ) \
irc.mozilla.org:Hixie _________________________  (.' \) (.' -' __________

Reply via email to