Probably the best link is:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-December/050954.html

(others can be found by googling "greenberg gpl  
site:lists.squeakfoundation.org").

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?
	- etc.
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.

Josh


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.
>
> Paolo
>
>