beware GNU Smalltalk if you want to contribute to squeak

13 year olds dont normally get sued :)

i just dont get it.

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

Paolo> The licenses were discussed at great length with rms, and he agreed
Paolo> that this particular combination was the best option to keep GNU
Paolo> Smalltalk: 1) free, 2) competitive with other Smalltalks in terms of
Paolo> what the user can do, 3) competitive with other scripting languages in
Paolo> terms of what the user can do.

However, that means my initial admonition still applies.

Until and unless GNU Smalltalk's libraries are relicensed, anyone contributing
anything to *Squeak's* core (something we would call a 3.n or 4.n release, for
example) *must* steer clear of looking at the source code of GNU Smalltalk.

This is not FUD.  This is a plain and simple suggestion to keep people out of
hot water, and the Squeak distro under its current (already confusing :)
licensing situation.

Please note that I am *not* saying anything about the relative merits of GPL
or BSD-family licenses.  Please stop dragging that into the issue.  That has
nothing to do with it. It's just that the GPL (and even LGPL) licenses are
incompatible with the core of Squeak.  Simple, OK?

So, you can choose to be either a Squeak core contributor, or someone who has
been looking at (and contributing to) the GNU Smalltalk project.  But you'll
never be both.

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

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

Janko> To conclude: we should stay away from staring in-fight and press down
Janko> one Smalltalk just because someone don't like its license! We need to
Janko> encourage a cooperation between Smalltalks instead.

Yes, but to do this, either the Squeak core distro license will have
to be changed (again!) (not likely), or the creators of GNU Smalltalk
will have to dual-license their code (unknown how likely).

Until then, there's not much cooperation *legally* possible.  Sad if
that's the case, but that's the choices we've collectively made.

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

>>>>> "David" == David Zmick <[hidden email]> writes:

David> if you really want to be "open", you should except anything from anywhere,
David> and licenses shouldn't matter,  at least thats how i see it.

David> what are the major differences in the two licenses?

BSD-family licenses are all variants on "do whatever you want with this code,
as long as we get some credit".  You can use Squeak in a turneky commercial
application.  You can make changes and distribute binaries.  Pretty much
whatever you want.

The GPL license requires full source code disclosure of any modifications
if you also "distribute" the code.

So, for example, let's say someone wanted a Squeak-powered cell phone.
Under the current license, it's perfectly fine to embed Squeak into the
cell phone, even making some interesting clever modification to the
VM to get it to work nicely in the embedded environment, and that
nifty modification is *private* to the creator.

Under the GPL, that would not be possible.  All modifications would have to be
available, at least on a website somewhere.

This is an overview, so excuse me if it's oversimplifies.

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

Hi fellas!

Ahhh, some refreshing license discussions - nothing better to fire up
2008 with a BANG! :)

But on a more serious note - AFAIK Randal is in fact quite right. And
please do not downplay the importance of this. Andrew Greenberg (lawyer
and specialist in this area) long time ago warned us from mixing
licenses and creating a totally MESS of the legal situation. And he also
explained that the interpretation of GPL (and LGPL I think) in the
context of a reflective image based language/system like Squeak is
definitely not clear.

And yes, it is already quite complex - we definitely need to make sure
any contributions to "core Squeak" - being the images we distribute from
squeak.org and maintain cooperatively (discluding addon packages on
SqueakMap etc) - should stick to... (ehum, what is our last
recommendation here btw?).

And why does it matter? Well, let me tell you for one thing - it matters
a DAMN lot to OLPC for example.

regards, Göran

Hi again! (this post is a Molotov cocktail)

I noticed how some people entered these discussions with a... well, let
us call it refreshingly naive attitude (nothing negative implied). I
mean, how complicated can this "license thingy" really be, right?
....muuahahhahaaaa!!!

Let me Count The Ways...

First everyone should review: http://squeak.org/SqueakLicense

I mean, yes, Squeak v1.1 is available as of today under 3 licenses:
SqueakL (the original license as displayed), APSL 2.0 and Apache license
2.0. But that is just a tiiiiny bit of the current Squeak codebase!
Still of course a nice thing - and you could take Squeak v1.1 and run
from there and have a clean BSDish base to build on (Apache v2 is
BSDish).

Then a quite large percentage of Squeak (IIRC right after Disney about
80% of the Squeak-at-the-time was in fact new code added at Disney) was
written at Disney and AFAIK that codebase is still only available under
SqueakL. There have been different opinions about the ownership of that
codebase - is it Disney's or Alan's team? If Alan is right and it is all
owned by them - then there is no problem. But... is he right?

Then we have all the contributions being made during the years. These
are all considered to be under SqueakL and now - there is a great effort
by VPRI to get all contributors (or at least a majority of us) to sign
that all our contributions are also available under the MIT license -
which is one of the dead simplest most open licenses available.

So... yes, the smallest of cores (v1.1) is available under Apache
license 2.0 which is more or less a BSD license (though incompatible
with GPL - see http://www.oss-watch.ac.uk/resources/apache2.xml). And
then a large part - probably the majority - of all individiually
contributed parts are available under MIT - nuff said.

This still leaves us with the large part of Disney-SqueakL-code. And
well, I should not even say this but parts of the VM support code base
is available under yet other variations IIRC (I may be wrong here, Ian
may have changed that - and it is not at all as unclear since we are
then in the realm of C-linking etc and the rules are relatively easy to
understand).

Ok, I am rambling - but unless the Disney-issue is cleared I still can't
see that we have Squeak under anything else than SqueakL as a whole. And
don't get me wrong - SqueakL is a quite nice license - it just happens
to fail the OSI validation and the DFSG guidelines (Debian). :)

Over and out - let the carnage begin. ;) ;)

regards, Göran

David Zmick wrote:
> if you really want to be "open", you should except anything from
> anywhere, and licenses shouldn't matter,  at least thats how i see it.
>
> what are the major differences in the two licenses?

Philosophies of compelled sharing verses voluntary sharing.

GPL and its kin, require sharing if you modify source code and you
distribute the modified source code based software.

BSD, MIT, and their kin, give credit where credit is due, don't blame us
if something goes wrong, and do whatsoever you want should you decide to
distribute modified source code based software.

Two philosophical camps.

Most people who prefer the BSD, et al, licenses often share just as much
as the GPL people, simply because they believe in sharing, not because
they are being compelled to.

Many in the GPL camp believe that compelling the sharing is necessary in
order to keep open source software from being a part of proprietary
software.

BSD, MIT, don't care.

I am a big BSD, MIT fan myself, as are many/most on the Squeak list. I
believe that the most compelling aspect of open source is the freedoms
it gives. I don't believe that most who contribute to open source
require being compelled. I believe that most who have to be compelled
don't do open source.

SQLite, PostgreSQL, etc. compete quite well in there arenas and have
Public Domain and BSD licensing respectively. There are many extremely
successful BSD, MIT and similarly licensed projects. Demonstrating that
voluntary sharing can be quite successful. Yes there are many GPL
successful projects, but that doesn't mean that they wouldn't be
successful with a BSD, MIT license. That there contributors only
contribute because they have to.

Oh well. Enough philosophical ranting.

But this is the conflict between BSD and kin vs. GPL and kin when
introducing GPL and kin into a BSD-like licensed project. It makes
requirements upon the project that didn't previously exist. Going the
other direction makes no such requirements.

Hope this helps.

Jimmie

On 9-Jan-08, at 3:02 PM, [hidden email] wrote:
> I mean, yes, Squeak v1.1 is available as of today under 3 licenses:
> SqueakL (the original license as displayed), APSL 2.0 and Apache  
> license
> 2.0. But that is just a tiiiiny bit of the current Squeak codebase!
> Still of course a nice thing - and you could take Squeak v1.1 and run
> from there and have a clean BSDish base to build on (Apache v2 is
> BSDish).

Correct.
Probably not, unfortunately. And that is a big problem in the board's  
discussions with the SFLC lawyers.

>
>
> Then we have all the contributions being made during the years. These
> are all considered to be under SqueakL and now - there is a great  
> effort
> by VPRI to get all contributors (or at least a majority of us) to sign
> that all our contributions are also available under the MIT license -
> which is one of the dead simplest most open licenses available.

It has to be *every* person that authored *any* part of the code in  
the image. *Any* version up to and including the version in the image.  
Which means that yes, we  will need to contact the families of several  
deceased contributors.
According to SFLC a majority is not enough, nor is it just authors of  
current versions. Basically "every bit is sacred".

I don't claim to understand the full logic of this but they are paid  
to be experts so I don't have to.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Nihil curo de ista tua stulta superstitione =  
I'm not interested in your dopey religious cult.

> Please note that I am *not* saying anything about the relative merits of GPL
> or BSD-family licenses.  Please stop dragging that into the issue.

I didn't try to do that.  OTOH, "damn GPL" seems a pretty clear
statement on these relative merits.

> So, you can choose to be either a Squeak core contributor, or someone who has
> been looking at (and contributing to) the GNU Smalltalk project.  But you'll
> never be both.

So a changeset from me to SqueakCore would never be accepted?  (My GNU
Smalltalk code is copyrighted FSF, so I cannot in principle relicense it).

I think there are two other issues to consider:

1) Size of "Squeak core".  I believe that most of GNU Smalltalk's code
would not fit into Squeak core (which I would like to become smaller and
smaller).  If anybody wants to port it to Squeak, most of the time they
would release it on SqueakSource under LGPL and be done.

Some other parts would (these might include for example the
continuation-based implementation of generators, which spurred a sibling
thread on comp.lang.smalltalk AFAIU) but they are probably more fun to
reimplement from scratch, and not so easy to port anyway.

2) Right now, the opposite would also be true.  The licensing situation
of Squeak is such a mess that GNU Smalltalk contributors should also
steer clear.  It's not possible to look at a random method and
understand what license it is distributed under.

So it's mainly an issue of being willing to cooperate.  I think all GNU
Smalltalk people (almost all?) are and it's also true at least for some
Squeak people.  If somebody took a package (several thousands lines of
code, etc.) wholesale, ported it to Squeak, and licensed it under MIT on
SqueakMap that would be copyright violation.  But everything can be done
"cum grano salis".  Nobody is going to sue you if you copy an interface
from GNU Smalltalk, reimplement in Squeak (for fun!), but you did look
at the method comments in GNU Smalltalk -- and OMG maybe you got a
glimpse of the source code just below!  Copyright does not protect
having similar implementations (patenting would, and GNU Smalltalk has a
clear patent license as part of the GPL/LGPL -- does Squeak have one?).

I think we're all for interoperability and for exchange of opinions
within the communities.  Asking questions instead of making statements
in three different places, and using a more moderate tone than "beware
GNU Smalltalk" (*) is a good way to start.

Paolo

(*) not to mention the "GNU Smalltalk sucks" subliminal messages that
some people including you keep sending on #squeak.  We all know that all
computer programs suck.

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

Paolo> (*) not to mention the "GNU Smalltalk sucks" subliminal messages that
Paolo> some people including you keep sending on #squeak.  We all know that
Paolo> all computer programs suck.

You know, I wasn't going to respond until you said that. I *absolutely* do not
believe that. I *do* hope you're either joking (in which case, it's a poor
joke), or you have specific information that backs up your claim that I have
said things that imply that I have a distaste for GNU Smalltalk.

In fact, it's quite impressive.  And I had started to paw through some of the
things, *especially* the Generator class, and was thinking about suggesting
this for 3.10.  And *that's* what caused me to think about licenses, and
*start* this whole thread.

My *single* *sole* purpose of this thread is the warning of incompatible
licenses.  OK, I had the subtext of "GPL sucks" on *one* message.  But let's
set that aside for now, and return to the same focus.

I *want* to have some of the things from GNU Smalltalk in Squeak.  I guess for
now, it'll have to be limited to the things that people reimplement in a clean
room, or leave unbundled in SM/SS/Universes (but then I have to worry about
accidentally using those packages in my commercial applications).

If GNU Smalltalk "sucked", as you suggest that I claim, I would *not* have
bothered with *any* of this discussion.  Think about that for a moment, and
you see it's the only logical conclusion.

--
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 10/01/2008, Randal L. Schwartz <[hidden email]> wrote:
> I *want* to have some of the things from GNU Smalltalk in Squeak.  I guess for
> now, it'll have to be limited to the things that people reimplement in a clean
> room, or leave unbundled in SM/SS/Universes (but then I have to worry about
> accidentally using those packages in my commercial applications).

Only if it is "Squeak core" if I understand the points made earlier in
this thread.

But what is "Squeak core"  where is it defined?

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

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

Bruce> Only if it is "Squeak core" if I understand the points made earlier in
Bruce> this thread.

Bruce> But what is "Squeak core"  where is it defined?

I'm talking about what I download that is called "3.9-final" for my
production work, and "3.10-gamma" for development.

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

> You know, I wasn't going to respond until you said that. I *absolutely* do not
> believe that. I *do* hope you're either joking (in which case, it's a poor
> joke), or you have specific information that backs up your claim that I have
> said things that imply that I have a distaste for GNU Smalltalk.

http://tunes.org/~nef/logs/squeak/07.11.26

16:18:16 <iamtravis> i have gnu smalltalk installed.. a person on #linux
mentioned this room, so I came in :)
16:18:26 <Randal> iamtravis - get squeak
16:18:32 <Randal> far more mature than gnu smalltalk
16:18:39 <Randal> and a lot more fun, I must say
16:18:52 <Randal> and industrial strength
16:18:57 <Randal> gnu smalltalk still has a ways for that

How can a community build up if you discourage people this way?

> And *that's* what caused me to think about licenses, and
> *start* this whole thread.

My problem is that you didn't start a thread.  You posted your own
conclusions and that happened to spark a thread.

> I *want* to have some of the things from GNU Smalltalk in Squeak.  I guess for
> now, it'll have to be limited to the things that people reimplement in a clean
> room, or leave unbundled in SM/SS/Universes (but then I have to worry about
> accidentally using those packages in my commercial applications).

I don't think so.  First of all because you don't have to worry about
accidentally using LGPL packages.

As to crossbreeding, I'm all for it!  Make a list of things you'd like;
if they are GPL some could be relicensed to LGPL.  Unfortunately, I must
say that BSD/MIT/Apache is not on the radar.

> If GNU Smalltalk "sucked", as you suggest that I claim, I would *not* have
> bothered with *any* of this discussion.  Think about that for a moment, and
> you see it's the only logical conclusion.

You have a point.

Paolo

On 10-Jan-08, at 2:20 AM, Paolo Bonzini wrote:
>
> As to crossbreeding, I'm all for it!  Make a list of things you'd  
> like; if they are GPL some could be relicensed to LGPL.  
> Unfortunately, I must say that BSD/MIT/Apache is not on the radar.

Basically it appears that we will have to insist on anything intended  
to be put in the base image (leave aside discussions of what exactly  
that means for now, please) is licensed as MIT. That's my current  
understanding of the situation anyway.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Starbucks are, of course, run by the Caffia

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

Paolo> 16:18:16 <iamtravis> i have gnu smalltalk installed.. a person on #linux
Paolo> mentioned this room, so I came in :)
Paolo> 16:18:26 <Randal> iamtravis - get squeak
Paolo> 16:18:32 <Randal> far more mature than gnu smalltalk
Paolo> 16:18:39 <Randal> and a lot more fun, I must say
Paolo> 16:18:52 <Randal> and industrial strength
Paolo> 16:18:57 <Randal> gnu smalltalk still has a ways for that

Paolo> How can a community build up if you discourage people this way?

Yes, I see that I was saying that Squeak is far more mature (28 years and
counting), more fun (all the Morphs and EToys and existing packages), and
industrial strength (dabbledb, etc), and that GNU Smalltalk has a ways to go
for that.

All of that is the truth.

None of that says "GNU Smalltalk Sucks".  If that's your strongest evidence,
I'll suggest now that you read into my actions a hostility that I will now
explicitly disclaim.  Thank you for confirming that.

--
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 Jan 10, 2008, at 2:20 AM, Paolo Bonzini wrote:
As Goran said, Andrew Greenberg (a Squeaker and IP lawyer) extensively  
analyzed the LGPL situation with respect to Squeak.  I'll restate it  
more strongly than Goran did:

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.  This is not the opinion of some random guy on the internet,  
this is the official position of the organization that:
        - is the copyright holder of GNU Smalltalk (as with other GNU  
projects, the FSF requires that copyright of contributions be assigned  
to them)
        - has litigated against more GPL/LGPL violators than anyone else

Does looking at LGPLed Smalltalk code mean that you can't write  
similar code and contribute it to Squeak?  The issue hasn't been  
tested in court, so we don't know the answer for sure.  It seems  
better to avoid having an issue to test in the first place.

Judging by this thread, at least some people were unaware of the  
issues involved.  Randal's warning provided a valuable service by  
raising awareness of the potential pitfalls.  I hope that it doesn't  
dampen the buzz around GNU Smalltalk 3.10, but if it does it should be  
viewed as an unfortunate but predictable side-effect of choosing the  
LGPL.  It doesn't appear to me that Randal has a vendetta against GNU  
Smalltalk (maybe against the "damn GPL" though :-) ).  On the  
contrary, he is careful to state that it is (probably) OK to look and  
use the protocol and documentation of GNU Smalltalk, just not to look  
at the source code.

Just my opinion,
Josh

Thanks for the wonderful summary.  I wouldn't have replied, except this gem of
a slip deserves an underline:

>>>>> "Joshua" == Joshua Gargus <[hidden email]> writes:

Joshua> [...] I hope that it doesn't dampen the buzz around GNU Smalltalk
Joshua> 3.10, [...]

Heh.  GNU Smalltalk 3.10. :)

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

tim Rowledge a écrit :

>
> I don't claim to understand the full logic of this but they are paid to
> be experts so I don't have to.
>
> tim

And with such rules they are defending, they are certain to be paid for
years and years...

Nicolas

On 10-Jan-08, at 11:53 AM, nicolas cellier wrote:

> tim Rowledge a écrit :
>
>> I don't claim to understand the full logic of this but they are  
>> paid to be experts so I don't have to.
>> tim
>
> And with such rules they are defending, they are certain to be paid  
> for years and years...
Well yes, that is the entire point of the legal system :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
when people are free to do as they please, they usually imitate each  
other

> 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