I have also written to the FSF and got some information.  Together with 
the e-mail Diego forwarded, I think this should be enough to settle the 
matter.

The message to Diego is very informative from the point of view of 
someone who wants to contribute to both Squeak and GNU Smalltalk.  In 
particular, this is a very useful thing to know:

> As long as there is a package system and/or clear namespace separation,
> it is always possible to see where a program ends and a library starts,
> even if they ultimately end up in the same VM or runtime.

And this idea was remarked also in the answer that the FSF gave to me:

> The whole purpose of the LGPL is that it states our policy for
> sharing.   :)   And like I said, it's quite possible [for Squeak to
> use] GNU Smalltalk libraries without "tainting" the rest of the code.

This paragraph is also interesting in general, though in the particular 
case of Squeak/GST it is probably overkill:

> If you are the copyright holder of the package, you can distribute it
> under several different licenses concurrently. We call this
> "dual-licensing". For instance, MySQL AB release their software under
> both a free license and a proprietary license. So technically speaking,
> there is nothing stopping you from contributing your package to
> different projects under different licenses.

I say it is overkill because new Squeak code is licensed mostly under 
MIT license and that is compatible with the LGPL.  The FSF would not 
need a copyright assignment, and there would not be any specific need 
for dual licensing.  Of course, if your code is under a different 
license (Squeak License or, until GNU Smalltalk is upgraded to the 
LGPLv3, Apache License), it is better to dual license.

I had asked the FSF about a different issue, namely whether (and if so, 
how) cross-pollination between Squeak and GNU Smalltalk can happen.  Of 
course, this is somewhat unfair for Squeak: MIT license is more liberal 
and GNU Smalltalk could include Squeak's code at will, but the converse 
is not true.  But, the FSF's stance is relatively open:

> we see no problem with people
> studying LGPLed code in order to write a different implementation that
> does the same thing.  We give people the source, enabling them to study
> it, without requiring them to accept any license.  The LGPL doesn't have
> any requirements for people writing an independent implementation, and
> that's because it has no teeth it could use to enforce such those
> requirements.
>
> So if anything, I think if you want to write a new implementation of
> LGPLed code, the best way to do it would be to study the original code
> as much as possible, to make sure that your own implementation is as
> different as possible from the original.

Also, this only applies if someone wants to avoid altogether the FSF 
copyright, which is only true for code that goes into SqueakCore.  For 
other code (for example code released in SqueakSource or SqueakMap),

> there's very fertile ground for sharing here. [...]
> The MIT license (assuming you're referring to one of the free
> ones listed at <http://www.fsf.org/licensing/licenses/>) and the Apache
> License 2.0 are both compatible with LGPLv3.  You can take code under
> those licenses and put them in GNU Smalltalk without any problems at
> all.  And while it's true you can't take code under LGPLv3 and release
> it under one of those other licenses, there should be absolutely no
> problem with the other Smalltalk developers taking some libraries from
> GNU Smalltalk and putting them in Squeak.  Developers who used those
> libraries would need to follow the terms of the LGPL when doing so, but
> the rest of Squeak could remain under the MIT/Apache licenses without
> any problem, assuming there are no licenses on any of the older code
> that would conflict with it. [...] [I'm]
> a little distressed to see a situation where there's so much tension
> between developers, even though there's nothing in the licenses
> themselves that should cause it.

When using LGPL conflicts with project policies, as is the case for code 
going into SqueakCore, the FSF said it's *not* a problem if a previous 
version of the code was released outside SqueakCore:

> This [using FSF-copyrighted code] doesn't even have to be a permanent solution --
> they can use the LGPLed Smalltalk libraries until they write their own
> implementations.

Having said this, I also have to warn you.  The above says that, if you 
read the licenses, take into account license compatibility, and apply 
common sense adequately, "it's okay to study our LGPLed code to write 
your own independent implementation".  But it's *not* an official 
statement saying so.

An official statement would probably have to be written in lawyerese, 
would surely cover a lot of cases one by one (I don't think it's 
possible to establish hard and fast rules), and would likely be the 
least satisfying solution for everyone.  Also, it would apply in a 
relatively small number of cases, i.e. those where releasing under LGPL 
on SqueakSource is not an option, so it is may not even be worth the 
trouble.

It is best, and I'd very much like to see it happen, if the involved 
people collaborate as fruitfully as possible.  If for now it's only 
going to be sharing ideas, because you need further evidence that Squeak 
has nothing to fear from collaboration with GNU Smalltalk, so be it. 
Still, I hope this is enough.

Paolo