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