LGPL and SqueakMap

Andrew C. Greenberg werdna at mucow.com
Mon Dec 23 03:49:25 UTC 2002


On Sunday, December 22, 2002, at 06:31 PM, Nevin Pratt wrote:

> The key phrase here is Andrew's admission that "I have not given any 
> thought to LGPL Smalltalk code distributed outside the image".

Don't read too much into it.  While it is true that I haven't carefully 
opined, this is not because I am optimistic about obtaining a different 
result -- this is simply because nobody has seriously insisted on LGPL 
for any meaningful Squeak asset.  I doubt that LGPL would work 
effectively with a monolithic image in practice, but I am game to look 
at the question if there is serious interest.

> GLORP also has an attorney retained to investigate such issues.  At 
> some point an "official" opinion might be solicited from that attorney 
> (with, of course, his usual fees to investigate the issue sufficiently 
> to render an "official" opinion).  However, for now, it isn't 
> considered to be a high enough priority.  Thus, for now, a simpler 
> approach to quelch all uncertainties might be to get an "official" 
> opinion rendered directly by the FSF concerning LGPL (just as it 
> appears Andrew did for GPL), since they are the creators of the LGPL 
> license.

FSF has been remarkably hostile to Squeak and Squeak-L, and has no 
interest in catering to monolithic images.  Indeed, FSF is hostile to 
use of LGPL for the most part.  Their view is that the world should be 
GPL'd.

> At some point (hopefully soon) I plan on attempting to do just that.

The culture of Squeak is a bit "freer" than LGPL.  We are used to 
freely manipulating code in the image, refactoring, subclassing, 
copying and so forth, without being concerned about compliance with 
licenses.  The Squeak-L makes it possible to do just about anything, 
and all is well -- the resulting image can be used commercially for 
many purposes, and for just about any non-commercial purpose.  This is 
not the case for LGPL code -- and any code infected thereby.   The 
practical application of LGPL for plugins is that folks don't tend to 
freely reuse plugin code in apps as widely -- don't get the idea that 
we Squeakers widely sanction LGPL for plugins, its just that there have 
been a few applications that couldn't be made available any other way 
(however, virtually ALWAYS with respect to any code that got into the 
image, we have gotten, at least, a Squeak-L/LGPL dual license).

Be certain to ask the right questions.  The issues are complex.  What 
is the LGPL status of subclasses of the LGPL code?  of various patterns 
that do not use inheritance?

All of a sudden, commercial uses of Squeak will require complex 
compliance memoranda by attorneys, depending on the specific classes 
used and not used.

> But in any case, it certainly *is* the current opinion of many that 
> LGPL is certainly good for more than "just VM plugins".  I am one of 
> those people.  I strongly disagree with the statement on SqueakMap 
> that states it that way (though I personally completely agree with 
> Andrew's statement about GPL code).

Many?  How many is that?  How many have seriously considered LGPL in 
monolithic images for widely distributed open source Smalltalks?




More information about the Squeak-dev mailing list