beware GNU Smalltalk if you want to contribute to squeak
schwa at fastmail.us
Fri Jan 11 06:01:49 UTC 2008
Probably the best link is:
(others can be found by googling "greenberg gpl
I misremembered slightly... Andrew's considered legal opinion was
about the GPL, not the LGPL. Nevertheless, he is not sanguine about
the suitability of LGPL for image code. Other posts in the thread
give good examples of confusing situations. If you add a LGPL class
to the system, what happens when you:
- make a subclass of the class?
- add a method to the class?
The legal interpretations are unclear, to say the least.
FWIW, I can understand the FSF's reticence to clarify the situation.
If they offered a permissive enough interpretation to be useful for
Squeak, they might be opening up undesired loopholes that might remove
some of the LGPL's teeth in other cases.
On Jan 10, 2008, at 2:47 PM, Paolo Bonzini wrote:
>> LGPL code is completely unacceptable for inclusion in the main
>> Squeak distribution, and doubly so if it is code that the FSF holds
>> the copyright to. RMS was unwilling to elaborate on the
>> interpretation of the LGPL for image-based systems such as Squeak.
>> In his view, including a single LGPL class makes the entire image
>> into a "derived work" that can only be redistributed subject to the
>> restrictions of the LGPL.
> Do you have a pointer? I believe this is true for the GPL, but not
> for the LGPL. I can tell you that it was pretty hard to convince
> him to adopt the LGPL because he wanted to understand the ins and
> outs -- because there *is* a difference: if it were as you said, GPL
> or LGPL would be completely the same. It's been a few years ago
> though, so neither of us has those e-mails.
> Anyway LGPL code is not compatible with MIT, so it is completely
> unacceptable for inclusion in Squeak core independent of who is the
> copyright holder.
More information about the Squeak-dev