LGPL and SqueakMap
Nevin Pratt
nevin at smalltalkpro.com
Mon Dec 23 06:26:39 UTC 2002
Daniel Joyce wrote:
>I would say the changesets that impliment said code.
>
>A LGPL library can call Kernel functions on a NON-GPL OS. That does not
>require that the source of the OS has to be released too. ( Gnu C libs
>on Solaris )
>
>Likewise, LGPL classes can call code in non-Gpl classes, that does not
>require the source to those non- LGPL classes be released either.
>
>Likewise, a propietary library can call functions in LGPL libraries too
>w/o being LGPL.
>
>So non-LGPL classes can call GPL classes.
>
>The only REAL muddy place I see is the case where someone subclasses a
>LGPL class. Would the subclass fall under the LGPL too, or since it's
>still just calling a LGPL class, and so technically is not a LGPL class
>too.
>
>-Daniel
>
>
There's more muddy places than that. What about moving a portion of such code out of one change set into another? The second change set will now contain some LGPL code-- does the entire second change set now need to be LGPL'd? Probably.
And I don't think this covers all the issues either.
In short, I think Andrew is entirely correct in raising flags.
But none-the-less, I think the statement on SqueakMap that LGPL is only good for VM plugins is a bit overreaching, and an overreaction. Thus, I still strongly disagree with what it says.
Nevin
More information about the Squeak-dev
mailing list
|