If GPL does not prevent users from using Seaside in GST, then using Seaside in GST - if ported - can be meaningful. In fact I'm very curious on the Seaside performance(of my application) in GST(with JIT).
Importing GST's code to Seaside will be problematic because it can cause License conflict problem. But I'm not sure on every part/usage of GST is GPL; it might be similar case of GLibC...
----- Original Message ----- From: "Randal L. Schwartz" merlyn@stonehenge.com To: squeak-dev@lists.squeakfoundation.org Sent: 08-01-09 07:34:07 Subject: beware GNU Smalltalk if you want to contribute to squeak
Basically, keep in mind that GNU Smalltalk is GPL, and therefore, incompatible with Squeak's license. Oops. Don't look inside. Keep a safe "clean-room" distance from any code in GST.
Also posted on http://methodsandmessages.vox.com/library/post/beware-gnu-smalltalk-if-you-work-on-squeak.html.
"chunsj" == chunsj chunsj@embian.com writes:
chunsj> Importing GST's code to Seaside will be problematic because chunsj> it can cause License conflict problem. But I'm not sure on every chunsj> part/usage of GST is GPL; it might be similar case of GLibC...
The license I see at http://cvs.savannah.gnu.org/viewvc/smalltalk/main.c?revision=1.6&root=smalltalk&view=markup looks pretty clear:
* This file is part of GNU Smalltalk. * * GNU Smalltalk is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the Free * Software Foundation; either version 2, or (at your option) any later * version. * * Linking GNU Smalltalk statically or dynamically with other modules is * making a combined work based on GNU Smalltalk. Thus, the terms and * conditions of the GNU General Public License cover the whole * combination. * * In addition, as a special exception, the Free Software Foundation * give you permission to combine GNU Smalltalk with free software * programs or libraries that are released under the GNU LGPL and with * independent programs running under the GNU Smalltalk virtual machine. * * You may copy and distribute such a system following the terms of the * GNU GPL for GNU Smalltalk and the licenses of the other code * concerned, provided that you include the source code of that other * code when and as the GNU GPL requires distribution of source code. * * Note that people who make modified versions of GNU Smalltalk are not * obligated to grant this special exception for their modified * versions; it is their choice whether to do so. The GNU General * Public License gives permission to release a modified version without * this exception; this exception also makes it possible to release a * modified version which carries forward this exception.
Doesn't look like I can just lift part of the libs from GST and use it as-is in something that is not as restrictive as the LGPL. Which means I *cannot* use it as-is in a Squeak distro. It has to be relicensed under a more-free license, like MIT or Apache2.
The license I see at http://cvs.savannah.gnu.org/viewvc/smalltalk/main.c?revision=1.6&root=smalltalk&view=markup looks pretty clear:
- This file is part of GNU Smalltalk.
- GNU Smalltalk is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License as published by the Free
- Software Foundation; either version 2, or (at your option) any later
- version.
Doesn't look like I can just lift part of the libs from GST and use it as-is in something that is not as restrictive as the LGPL.
The license I see for kernel/Object.st also looks pretty clear:
| This file is part of the GNU Smalltalk class library. | | The GNU Smalltalk class library is free software; you can redistribute it | and/or modify it under the terms of the GNU Lesser General Public License | as published by the Free Software Foundation; either version 2.1, or (at | your option) any later version.
Paolo
Yes. Lgpl which means we would need to relicense it to include it or anything derived from it in the squeak core. Any chance of that happening?
Sent from my iPhone!
On Jan 9, 2008, at 12:38 AM, Paolo Bonzini bonzini@gnu.org wrote:
The license I see at <http://cvs.savannah.gnu.org/viewvc/smalltalk/main.c?revision=1.6&root=sm...
looks pretty clear:
- This file is part of GNU Smalltalk.
- GNU Smalltalk is free software; you can redistribute it and/or
modify it
- under the terms of the GNU General Public License as published by
the Free
- Software Foundation; either version 2, or (at your option) any
later * version. Doesn't look like I can just lift part of the libs from GST and use it as-is in something that is not as restrictive as the LGPL.
The license I see for kernel/Object.st also looks pretty clear:
| This file is part of the GNU Smalltalk class library. | | The GNU Smalltalk class library is free software; you can redistribute it | and/or modify it under the terms of the GNU Lesser General Public License | as published by the Free Software Foundation; either version 2.1, or (at | your option) any later version.
Paolo
On 09/01/2008, Randal L. Schwartz merlyn@stonehenge.com wrote:
Yes. Lgpl which means we would need to relicense it to include it or anything derived from it in the squeak core. Any chance of that happening?
If your comments only apply to "squeak core" then people not involved with that can happily use a mix of Squeak and GNU/Smalltalk. Is that right?
Where could I find a description of "squeak core"?
Thanks, Bruce
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?
On Jan 9, 2008 12:04 PM, Bruce Badger bwbadger@gmail.com wrote:
On 09/01/2008, Randal L. Schwartz merlyn@stonehenge.com wrote:
Yes. Lgpl which means we would need to relicense it to include it or anything derived from it in the squeak core. Any chance of that happening?
If your comments only apply to "squeak core" then people not involved with that can happily use a mix of Squeak and GNU/Smalltalk. Is that right?
Where could I find a description of "squeak core"?
Thanks, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/
On Jan 9, 2008 3:01 PM, David Zmick dz0004455@gmail.com 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.
Haven't been sued yet, huh?
Cheers!
--Tom Phoenix
13 year olds dont normally get sued :)
i just dont get it. On Jan 9, 2008 5:07 PM, Tom Phoenix rootbeer@redcat.com wrote:
On Jan 9, 2008 3:01 PM, David Zmick dz0004455@gmail.com 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.
Haven't been sued yet, huh?
Cheers!
--Tom Phoenix
"David" == David Zmick dz0004455@gmail.com 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.
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
On 9-Jan-08, at 3:02 PM, goran@krampe.se 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.
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?
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; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Nihil curo de ista tua stulta superstitione = I'm not interested in your dopey religious cult.
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; tim@rowledge.org; http://www.rowledge.org/tim when people are free to do as they please, they usually imitate each other
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
squeak-dev@lists.squeakfoundation.org
-
Bruce Badger -
chunsj＠embian.com -
David Zmick -
goran＠krampe.se -
Jimmie Houchin -
merlyn＠stonehenge.com -
nicolas cellier -
Paolo Bonzini -
Randal L. Schwartz
-
tim Rowledge -
Tom Phoenix