Hi!
Andrew - you don't have to continue this thread if you are "sick of it" - I know that you have been answering questions like these for a long time on the list. :-) Still, I haven't really gotten "LGPL/GPL vs Squeak-L" fully clear in my head and perhaps there are others out there with a similar confusion. Thanks for your answers sofar!
"Andrew C. Greenberg" werdna@mucow.com wrote:
But the module system will also probably fulfill the role of something like CPAN where people publish their apps and libraries not necessarily meaning that they are defined as being "base Squeak" modules. And you should be able to publish something that you have built without being forced to use Squeak-L2, right? :-)
Except in particular cases, you have never been "forced to use" any license when deriving work from other people's IP, particularly in Squeak. I see no reason, however, to encourage use of anything other than Squeak-L, modular or otherwise. Ultimately, mixed licensing will likely corrupt a monolithic image and make it either unusable or unpublishable and that is, IMHO, a bad thing.
Ok, maybe we are misunderstanding each other. I am not talking about what currently is in the image - which probably will turn into a defined subset of all the published modules in the module system. We will probably say "These modules are in the officially blessed Squeak base" or something similar, and yes, those modules should all be under one license. and yes, the modules system will open up the possibilities of more "controlled forks" but most of us are aware of the sociological (?) forces at work in an OpenSource community - forks are pretty unlikely, and if they occur successfully then they are probably allright. My guess is that the "kernel" of Squeak will stay focused since it is "hard technical work" and the fluff around it will turn into modules that are exchangeable. I think the Linux kernel with all the distributions around it is a good analogy in fact.
I am not sure if you have followed the discussions on the module system but it will among other things give us the ability to name/find & download a "module" using only a path-notation like for example "People/gh/SuperTetris".
So it will be a general publishing system as well as a system for maintaining what currently is in the base image.
And thus I would like people to be able to publish, let's say - a shareware little game as outlined above. Or, to be more concrete - I think that Flow by Craig Latta is under the LGPL. That module should also be publishable in the modules system.
Do note that the modules system is a virtual hierarchy (yes, it's in some ways a graph, but...) where subtrees can be located on different ftp/http servers all over the Internet. To start with we will probably set up one single root (but some form of mirrors of that root would be good for bandwidth/failure reasons) - an ftp directory on for example squeakfoundation.org. Then in that directory tree I could ask to place a "forwarder" at "People/gh" directing all subnames of that over to my ftp server in Sweden.
(BTW - I have written up a few thoughts about the repository side of the modules system especially concerning how we handle the update streams, more on that in another thread...)
Could I publish my GPLed code as a Squeak project in for example .pr form and include source with that and then bundle that with a Squeak VM and a small "boot" image that loads the .pr when started? (More or less mimicking how the Java guys do it).
Not according to RMS. Certainly, any image derived from a mixed use will be unpublishable. Such is the nature of FSF's notion of "free" software.
If we could consider loading a .pr or ImageSegment as being "linking" then it should be ok, right?
It should be. RMS thinks not.
Oh wait, oops, I think I might have expressed this the wrong way. "Linking" is ok for LGPL but not for GPL. Sorry, I was implying that linking is ok for GPL - which of course is quite the opposite. I checked out the FAQ and found:
http://www.gnu.org/licenses/gpl-faq.html#TOCInterpreterIncompat
And that seems to imply that I could use a GPL license for my app with perhaps an added clause saying that running it in Squeak is fine. Or something like that.
I also found:
http://www.debian.org/doc/manuals/debian-java-faq/ch2.html (last paragraph)
I assume that shipping a premade image is probably stretching it, that was why I was jibbering about a .pr file that the user loads when starting the app.
I wondering how many Java developers know this...
I would just like to have an answer when a GPL-advocate says he can't use Squeak for his app since it is not "GPL-compatible"...
Answer, he is correct, at least as RMS understand the GPL. Squeak-L is not GPL-compatible, and vice-versa. Reasonable lawyers may differ with RMS on his interpretations of the agreement.
Could you contrast this with my "findings" above? It all seems to come down to how "static" or "dynamic" the bindings are...
All we really need is the will to do it. In the meanwhile, the failure to include Squeak in Debian reflects, to me, more of a weakness in Debian policies than in Squeak-L, and is a shame. But in preparation
Could you elaborate on that? I mean, do you think they are "wrong" in their argument or that they just are too "picky"?
Clearly, they are free to add or refuse whatever they want. I think that they are wrong to refuse to publish Squeak-L for the reasons they choose. I'm a big fan of open source and of some, but not all, of the
So... you mean that refusing Squeak-L because of the export restrictions (which I think was a biggie for Debian) was wrong?
My personal view:
Is that I understand Debian's puritan view of "free". They are creating a free OS for anybody to use - including people in countries which the US has decided restrict export to. ;-)
I also understand the BSD/MIT camp and the RMS view of it all. I think it just depends on your viewpoint and the situation at hand. They all seem to have valid arguments from their respective viewpoints.
BSD/MIT is the simplest one - free. Period. More or less like Public domain without giving up the copyright. Easy to understand. But those licenses also might suffer from poor feedback of contributions and they (as RMS would put it) do not assure that "the next guy in the foodchain" get the same rights as you do.
So again, my view is that given a speicific situation I would probably choose between these:
- GPL (perhaps without the "version 2 or higher" in case RMS looses it even more... :-) If I want my program not to be turned commercial by someone else - LGPL if I feel that GPL does a good job, but I want to enable people to use it commercially - BSD (or something similar) if I don't really care at all what people will do with my program (turn it commercial or whatever) - Non OpenSource (shareware, fully commercial etc.) - Another license that you can't really change, like Squeak-L for base image contributions
I have a hard time seeing that Public Domain has any advantage and all the other licenses out there don't seem to really have any distinctive differences.
tenents of the free software movement. However, ideology has overcome reason, so far as I am concerned. I do not share RMS' definition of free which, for example in the case of software based on a monolithic late-bound program image, makes it impossible to have mixed and non- GPL'd software.
In my view, such software isn't free in the common, linguistic sense of the word, but hopelessly and unrationally over-restricted. No amount of big-brotheresque double-talk to redefine the ordinary use of the word suffices as argument to the contrary.
As RMS freely admits, he is no advocate of open source software, if it isn't "RMS-free." Likewise, I am no advocate of "RMS-free" software if it isn't, in fact, free.
Sounds like you are a BSD/MIT guy then! :-)
regards, Göran
So again, my view is that given a speicific situation I would probably choose between these:
- GPL (perhaps without the "version 2 or higher" in case RMS looses it
even more... :-) If I want my program not to be turned commercial by someone else
- LGPL if I feel that GPL does a good job, but I want to enable people
to use it commercially
These are not correct. Perhaps let's not open this discussion here on the Squeak list, and everyone can go read up on the different licenses if they desire.
-Lex
"Lex Spoon" lex@cc.gatech.edu wrote:
So again, my view is that given a speicific situation I would probably choose between these:
- GPL (perhaps without the "version 2 or higher" in case RMS looses it
even more... :-) If I want my program not to be turned commercial by someone else
- LGPL if I feel that GPL does a good job, but I want to enable people
to use it commercially
These are not correct. Perhaps let's not open this discussion here
Okay, I was a bit terse, and it *is* relevant. I just didn't relish the thought of the inevitable 50+ messages hashing out the subtle differences between these licenses. :(
One thing I know is that LGPL allows linking with non-LGPL programs, but GPL does not. It's a good thing that GNU libc (the one that Linux uses) is LGPL, because if it was GPL it would be illegal to compile non-GNU C programs on Linux! It's unclear where Squeak images would fall here -- is loading Smalltalk code into Squeak "linking", or is it making a derivative of the base image? Blah, let's be happy we're not using one of these licenses and so don't have to decide. :)
Otherwise, LGPL and GPL are pretty similar, and perhaps even identical. For example, they both disallow commercial use of the software.
Here's an official site about the GNU licenses:
http://www.gnu.org/licenses/licenses.html
I dunno about the other open source licenses. Some of them do allow commercial use, however.
-Lex
On Tue, 30 Oct 2001, Lex Spoon wrote:
[snip]
Okay, I was a bit terse, and it *is* relevant. I just didn't relish the thought of the inevitable 50+ messages hashing out the subtle differences between these licenses. :(
How about the misuse of the word "commercial". "Proprietory" == "commerical". If you think that *de facto*, forbidding proprietoriness eliminates commerical potential, that's *still* a different thing.
(Contrast with the VisualWorks Non-commercial licence, which *explicitly* forbids commerical activity. Rather generally. Last I checked, it looked like even non-profits got swept in.)
[snip]
Otherwise, LGPL and GPL are pretty similar, and perhaps even identical. For example, they both disallow commercial use of the software.
And this is even more bogas. At best, the only *use* that might be constraint is selling derivative works. Using a GPLed word processor to churn out commerical books is clearly fine on *any* level (even without the tendentioius connection to proprietoriness.
To be explicit, from, http://www.gnu.org/licenses/gpl-faq.html#GPLCommertially:
"If I use a piece of software that has been obtained under the GNU GPL, am I allowed to modify the original code into a new program, then distribute and sell that new program commercially? You are allowed to sell copies of the modified program commercially, but only under the terms of the GNU GPL. Thus, for instance, you must make the source code available to the users of the program as described in the GPL, and they must be allowed to redistribute and modify it as described in the GPL."
Having a licence that, in a certain situation, makes using (or selling) the product commercially *infeasible* is very distinct from a licence that forbids commerical *use*.
But *please* let's not blow this up. :) I'm perfectly willing to concede that loads of buisness might not be able to sell GPLed software for a variety of reasons. But they certainly can use it in a variety of ways, and neither license explicitly forbids, in general, commerical use.
Terseness isn't the issue; accuracy is.
Cheers, Bijan Parsia.
Lex Spoon wrote:
Otherwise, LGPL and GPL are pretty similar, and perhaps even identical. For example, they both disallow commercial use of the software.
Eh? Sorry to drag out the thread, but this surely needs radical re-phrasing (that's to say, "commercial use" is pretty wooly): half of the US film industry seems to use Gimp (the other half uses Photoshop ;-) and Little Igloo FTP is a commercial product (that is, it's for sale) which uses a fair bit of LGLP (at least) code: it's pretty obviously built on top of gtk. (It's actually damn good, too, but beware of stoopid servers that don't understand its "auto" switch.)
Cheers
John
squeak-dev@lists.squeakfoundation.org
-
Bijan Parsia -
goran.hultgren＠bluefish.se -
John Hinsley -
Lex Spoon