Squeak and LGPL
Paolo Bonzini
bonzini at gnu.org
Fri Feb 1 08:22:44 UTC 2008
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
More information about the Squeak-dev
mailing list
|