Squeak and LGPL

Hi, as a result of the recent discussion about the license issues of GNU St and Squeak, I've sent a mail to the FSF license help.

Maybe you've seen this, but the GNU Smalltalk site has some
information on applying the licenses...

>From the FAQ...
========
"Does copyright restrict the use of GNU Smalltalk?

It does, but in general you don't need to worry much about the
licensing of your Smalltalk programs.

The class library is licensed under the GNU LGPL. Thus, it permits
using the library together with non-free programs.

The virtual machine and the bindings to external libraries are
licensed under the GNU GPL, with a special exception that allows
Smalltalk programs to be linked with the functions exported by the
virtual machine and said bindings."
========

And the user manual has quite a bit more information...

http://www.gnu.org/software/smalltalk/manual/gst.html#Legal-concerns

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:

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),

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

On Feb 1, 2008 9:22 AM, Paolo Bonzini <[hidden email]> wrote:
> 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.

I'm confused on how this settles the matter (comments below).

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

Since Squeak doesn't have namespaces (by default anyway) and afaik the
Squeak package systems aren't compatible with other Smalltalks
directly, that leaves file in/out, no?  Is that enough of a "clear
separation"?

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

Below the "rest of the code" is defined as the entire package.  It
sounds like if I make a package that depends on LGPL code then my code
would in fact be tainted right?

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

> Also, this only applies if someone wants to avoid altogether the FSF
> copyright, which is only true for code that goes into SqueakCore.

Why is it only true in that case?  It's only *absolutely required* in that case.

> > 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. [...]

So as mentioned above, you wont taint the whole image but you will
taint your own library.

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

I haven't seen much intersection between law and common sense. :)  As
I mentioned in a previous email, it doesn't matter how much good will
there is today.  Boards can change, new owners come along, situations
come along.  At that point it doesn't matter how anyone felt once upon
a time.  It matters what's in writing.

I started to write a reply, but...

> As
> I mentioned in a previous email, it doesn't matter how much good will
> there is today.  Boards can change, new owners come along, situations
> come along.  At that point it doesn't matter how anyone felt once upon
> a time.  It matters what's in writing.

... this shows it would be pointless anyway.

Paolo

so this means that we could port a lot of new code to GNU without  
problem.
This is an excellent news.
        Seaside
        SystemChangeNotifier
        Monticello?
        Traits???

I donwloded 3.0.1 and it is nice to see all these test running......
(I had to do ^C on int... I sent you the log).
May GNU is the way to go :)


Stef

On Feb 2, 2008, at 10:52 AM, Paolo Bonzini wrote:

>>>>> "stephane" == stephane ducasse <[hidden email]> writes:

stephane> so this means that we could port a lot of new code to GNU without  problem.

*to* GNU.  Certainly.  But nothing I've seen at all changes
my original concern, because nothing new has been added *in* writing.

In summary, my original concern, which still apparently stands, is that you
*cannot* look at LGPL material and copy or adapt it into the Squeak core,
because anything derived from LGPL code must remain under the LGPL (unless
*relicensed* by the original author), and the resulting LGPL would then apply
to *all* of Squeak, which some of us consider unacceptable, and possibly not
even possible given the current license hassles anyway.

Paolo - stop confusing the issue.  The issue is only what I just stated.  I'm
*not* talking about stuff in squeaksource or other distributions methods.  I'm
not talking about dual-licensed stuff because the authors added a
Squeak-compatible license.  I'm only talking about people working on stuff
that may eventually want to be included in the Squeak core, because this isn't
separated enough to allow an independent license, even with the clarification
you gave.

If you can get FSF to grant *in writing* an exception to the license to allow
the above, then I will withdraw my concern.  However, given the commitment of
the FSF to the LGPL (and GPL), it'll be pretty unlikely.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

On 02/02/2008, Randal L. Schwartz <[hidden email]> wrote:
> ....  I'm only talking about people working on stuff
> that may eventually want to be included in the Squeak core, because this isn't
> separated enough to allow an independent license, even with the clarification
> you gave.

Which of the things that Stephane mentioned are in "Squeak core"?

He mentioned:

       Seaside
       SystemChangeNotifier
       Monticello?
       Traits

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

>>>>> "Bruce" == Bruce Badger <[hidden email]> writes:

Bruce> Which of the things that Stephane mentioned are in "Squeak core"?

I was not responding to Stephane, except indirectly, because he said
"to GST".

My statement is directed at the larger Squeak devel community.

Bruce> He mentioned:

Bruce>        Seaside
Bruce>        SystemChangeNotifier
Bruce>        Monticello?
Bruce>        Traits

All but Seaside.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

On Sat, 2008-02-02 at 17:13 -0800, Randal L. Schwartz wrote: Actually, the reality is that, unless I'm mistaken no release so far has
actually included a 'core' image.  IIRC the long term plan is to have
three images, a core, a basic, and a kitchensink/full.  The cleaning so
far has not progressed to the point where any release team has been
ready to try to produce a true Core image.  Other than perhaps Traits, I
don't think any of these would be part of a Core image.  Although
perhaps Monticello since it has been part of the core update mechanism
in recent versions, whether that will continue is far from clear.

Ken

> In summary, my original concern, which still apparently stands, is that you
> *cannot* look at LGPL material and copy or adapt it into the Squeak core,

This is exactly what the FSF did *not* say.  They said:

(back to your message)
> Paolo - stop confusing the issue.  The issue is only what I just stated.  I'm
> *not* talking about stuff in squeaksource or other distributions methods.  I'm
> not talking about dual-licensed stuff because the authors added a
> Squeak-compatible license.

Yes, dual licensing is what the FSF explained to Diego, not to me.  His
were separate questions, with separate answers.

> I'm only talking about people working on stuff
> that may eventually want to be included in the Squeak core, because this isn't
> separated enough to allow an independent license, even with the clarification
> you gave.

I said exactly that you *need* a rewrite to include stuff into
SqueakCore.  But I also said that the FSF does not see any problem in
not doing cleean-room reverse engineering to do such a rewrite.

This is my last message in the thread, I don't believe anything else I
could say would add and we are clearly boring/confusing some squeakers.

Paolo

>>>>> "Paolo" == Paolo Bonzini <[hidden email]> writes:

Paolo> This is exactly what the FSF did *not* say.  They said:

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

And where is the formal document amending the LGPL to permit this?

"derived work" is a broad term, and the FSF must specifically waive its rights
to that.  If I *look* at GNU code, then write something similar, that is
arguably "derived work", and therefore subject to GNU licensing.

I don't see that anything has changed, except that we have an "understanding"
that is not legally binding.

Let's make it legally binding, and then (only then!) has something changed.

Until then, *DO NOT LOOK AT GST*.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Randal L. Schwartz wrote:

Randal, please! First, why the heck we as Smalltalkers need to obey by
the word that damn licenses if even FSF hinted clear enough, that it
should be treated LGPL by the spirit, that is by intent and meaning of
the license. And this one is clear enough for me from the FSF answers.
So, Randal, if you'd like help us Smalltalkers, what I believe is your
honest intent, better let us help cooperate without such bloody lawyer's
obstacles.


Janko



--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Janko,

You can want to not worry about licenses all you want - but when a  
lawyer comes knocking at your door with a lawsuit, you might feel  
differently.  I'm not going to pretend to understand all the issues  
surrounding the GPL and the LGPL; I don't.  However, I can tell you  
that corporate entities take license issues very, very seriously.

Deciding to ignore a license could easily cost you a sale.

On Feb 3, 2008, at 12:09 PM, Janko Mivšek wrote:

>>>>> "Janko" == Janko Mivšek <[hidden email]> writes:

Janko> Randal, please! First, why the heck we as Smalltalkers need to obey by
Janko> the word that damn licenses if even FSF hinted clear enough, that it
Janko> should be treated LGPL by the spirit, that is by intent and meaning of
Janko> the license.

Precisely because it's *only* a "hint", and not legally binding.

What will matter in court some day is the letter of the license, not what some
random person may "hint" about it indirectly.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Jim,

James Robertson wrote:

> You can want to not worry about licenses all you want - but when a
> lawyer comes knocking at your door with a lawsuit, you might feel
> differently.  I'm not going to pretend to understand all the issues
> surrounding the GPL and the LGPL; I don't.  However, I can tell you that
> corporate entities take license issues very, very seriously.
>
> Deciding to ignore a license could easily cost you a sale.

I didn't say to ignore license issues, no, I just said to listen to FSF
  responses which are clearly more competent than most of us and to
treat their opinion by spirit, not by letter.

And just for intermezzo, not whole world has the same judiciary
practice, many parts have much more up-to-the-ground way to solve such
disputes and for those parts the FSF answer is more than adequate, IMO.

Janko



--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Laurence Rozier wrote:

As a next step I would then propose that we as Smalltalk community ask
FSF for official statement for our case. Such a statement will be then a
guard for our future work and specially the cooperation among Smalltalks.

Janko



--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Randal L. Schwartz wrote:
This is not a random person volunteering to answer [hidden email]
e-mails.  It is the FSF "licensing clerk" that answered me.

I'm impressed (negatively), more than by a protective attitude which I
find after all understandable, by the way people manage to read only the
downside of what was written.  For example, Laurence wrote:

> What they said was that they "don't have teeth" which allows them
> to find teeth in the future.

The way I read this is that *unlike some proprietary licenses* the LGPL
doesn't have such teeth.  And anyway, the LGPL *as is now* doesn't have
teeth, and licensing changes for GPL and LGPL are *not* retroactive.
What is now distributed under LGPLv2 or v3 will *never* gain such teeth.

(I said this last point only to clarify a common misunderstanding on the
"or any later version" clause used in licensing under the GPL.  It is
not about the Squeak vs. GNU Smalltalk debate).

Paolo

Thank you, Paolo and Diego, for following up with the FSF.

Clearly, the most recent communications with the FSF are positive.  
There is no way to construe them as hostile toward the Squeak  
community; quite the opposite.

Nevertheless, I think that the continuing cautious attitude is  
justified.  As others have said, the letter of the license is what  
will be interpreted in court.  For example, I don't see any basis for  
the claim that the "LGPL has no teeth" (although I can see how the FSF  
might feel that way, compared to the GPL).  "Clean-room engineering"  
is an established practice precisely because courts have ruled that  
viewing copyrighted code and then writing your own version can  
constitute a copyright violation.  I fail to see how the LGPL differs  
from a proprietary license in that respect.

The FSF have a vested interest in marketing their licenses as  
acceptable to as broad an audience as possible.  There is nothing  
wrong with this, but as always the adage "buyer beware" is applicable.

Cheers,
Josh


On Feb 3, 2008, at 10:14 AM, Paolo Bonzini wrote: