On 27/05/12 02:52, Mook wrote: > Will the LGPL code be limited to be outside of libxul?
I guess I had assumed that "clearly-demarcated 3rd-party LGPLed libraries" meant that the library had to be a standalone lib which was dynamically linked in, such that LGPLness did not affect any non-LGPLed code. But in hindsight, perhaps that wasn't clear. I'm sure it's true that a requirement for LGPLed code to be in its own library (or perhaps we have one for all LGPLed code, I don't know) would have effects on our build system and perhaps on performance. Those would need to be taken into account when considering whether to use the LGPLed code. > 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). Clarification: it would mean we'd need to obey the terms of the LGPL in terms of the particular ways one makes source available etc. for all code inside libxul. It wouldn't mean we'd need to change the licence of the source code or their headers, because MPL2 is upwardly compatible with LGPL. But I agree, we don't want to be in that place. > 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 ;) I don't anticipate there being "MPL-only" builds; if we decided to accept LGPLed code under this new policy, it would be fine for it to be a required part of building e.g. Firefox. Gerv _______________________________________________ legal mailing list [email protected] https://lists.mozilla.org/listinfo/legal
