Re: Proposed policy change: permit use of LGPLed libraries

On 5/24/2012 3:00 AM, Gervase Markham wrote:
> On 23/05/12 15:21, [email protected] wrote:
>> We have an enterprise list that *I think* is used for ESR [1]. It may
>> make sense to run this proposal by that list to ensure it's getting
>> out to those eyes.
>
> This has no legal ramifications for _using_ Mozilla software, or even
> for changing it and distributing those changes within your organization.
> So I'm not sure the occupants of the ESR list will have much to say
> about it. But I will ask for them to be notified.
>
> Gerv

(I apologize for replying mid-thread; the mirroring to NNTP appears to 
be broken and I can't find the thread starting post.)

Will the LGPL code be limited to be outside of libxul?  Because libxul 
is special in that it's the only binary with access to 
MOZILLA_INTERNAL_API, plus being the bulk of the code it is the most 
likely to be changed (for example, Joost used to have patches for the 
chrome protocol handler to only accept signed jars, I think, with their 
actual crypto code in separate not-released files).  If Mozilla ends up 
needing LGPL code, and that code gets shipped in libxul, it ends up 
meaning libxul itself is LGPL (as far as I understand how LGPL is 
intended to work).  Of course, if the LGPL code is limited strictly to 
separate binaries this would not be a problem, except for the snappy 
people (since that was part of the motivation behind having a giant 
library in the first place, as I understand it).

Ideally, of course, we'd get a tier-one tinderbox for MPL-only builds to 
make sure that doesn't break, but given releng resources I've seen that 
seems unlikely ;)

Note: I'm looking at this from the point of view of a _desktop_ 
application developer; whether existing android builds require GPL/LGPL 
code is irrelevant.  From an Android/B2G point of view that would be 
much different.  And I suspect once LGPL code starts being accepted for 
B2G, it'd be so much more tempting to use it for non-B2G as well...

-- 
Mook