Before we incorporate the SmaCC compiler into the base release (it's already been approved), I thought I'd double-check this point.
Up until now, only Squeak-L licensed source code has been allowed to be included in the base release. (Base release meaning anything "Squeak Official", including everything in the Full release.) Submitted code which doesn't specify a license is automatically licensed under Squeak-L. So if we incorporate SmaCC, we'll be changing this rule.
Basically, this sounds okay to me, but if we decide to do this, we should be specific that only Squeak-L and/or MIT-licensed code is allowed in the base release... we're not allowing any other arbitrarily licensed code. We've discussed the MIT license a bit and it seems agreeable to most, it's a very simple license, and there doesn't seem to be a problem with having a mix of Squeak-L and MIT-licensed stuff in the base. (I know a few people think that MIT is too unrestrictive, but I don't think that's a fatal flaw at the moment.)
Is this decision significant enough to have a vote of the Guides?
(Non-source-code things such as fonts are a different story... I think it is acceptable to have other non-SqueakL/MIT licenses in the base release for fonts, this includes the Accufonts & BitStream Vera fonts.)
- Doug
Doug Way dway@riskmetrics.com wrote:
Before we incorporate the SmaCC compiler into the base release (it's already been approved), I thought I'd double-check this point.
Up until now, only Squeak-L licensed source code has been allowed to be included in the base release. (Base release meaning anything "Squeak Official", including everything in the Full release.) Submitted code which doesn't specify a license is automatically licensed under Squeak-L. So if we incorporate SmaCC, we'll be changing this rule.
Yes, and I agree. MIT should be fine. So I vote for allowing it. But only it.
regards, Göran
Hello,
No voting power, but wanting to express one simple question/thought. :)
goran.krampe@bluefish.se wrote:
Doug Way dway@riskmetrics.com wrote:
Before we incorporate the SmaCC compiler into the base release (it's already been approved), I thought I'd double-check this point.
Up until now, only Squeak-L licensed source code has been allowed to be included in the base release. (Base release meaning anything "Squeak Official", including everything in the Full release.) Submitted code which doesn't specify a license is automatically licensed under Squeak-L. So if we incorporate SmaCC, we'll be changing this rule.
Yes, and I agree. MIT should be fine. So I vote for allowing it. But only it.
I think allowing MIT would be great. In fact I would think any standard as free as SqL or better should be allowed. Why only MIT?
BSD is also a standard well known license that may be more comfortable to corporate types. MIT is great for individuals and some corporations might be perfectly happy with MIT but for some BSD is better.
From OSI: http://opensource.org/licenses/bsd-license.php
Explains the difference between MIT and BSD.
""" Note the new BSD license is thus equivalent to the MIT License, except for the no-endorsement final clause. """
BSD allows individuals or corporations to place a no-endorsement final clause. That's the difference.
Thanks for listening.
Jimmie Houchin
Jimmie Houchin jhouchin@texoma.net wrote: [SNIP]
Yes, and I agree. MIT should be fine. So I vote for allowing it. But only it.
I think allowing MIT would be great. In fact I would think any standard as free as SqL or better should be allowed. Why only MIT?
Definitely not. If we mix up a lot of licenses we will make it more or less impossible for people to know under what circumstances they can use Squeak.
BSD is also a standard well known license that may be more comfortable to corporate types. MIT is great for individuals and some corporations might be perfectly happy with MIT but for some BSD is better.
I hardly think the difference between those is significant.
Nevertheless, my point is that allowing MIT and Squeak-L gives us a mixed situation that we still can handle. Adding more licenses to the soup would IMHO be disastrous. And that is btw also the view of Andrew Greenberg, our own specialist. Though it was a long time ago I saw Andrew post.
regards, Göran
goran.krampe@bluefish.se wrote:
Jimmie Houchin jhouchin@texoma.net wrote: [SNIP]
Yes, and I agree. MIT should be fine. So I vote for allowing it. But only it.
I think allowing MIT would be great. In fact I would think any standard as free as SqL or better should be allowed. Why only MIT?
Definitely not. If we mix up a lot of licenses we will make it more or less impossible for people to know under what circumstances they can use Squeak.
I don't believe it would lead to a proliferation of licenses. I also don't believe there to be very many licenses which qualify by my statement of as free or freer than SqL. MIT, BSD, X11 (I think) being the only ones I am consciously aware of.
BSD is also a standard well known license that may be more comfortable to corporate types. MIT is great for individuals and some corporations might be perfectly happy with MIT but for some BSD is better.
I hardly think the difference between those is significant.
Having a no endorsement clause is significant and is very standard in business. BSD is every bit as free as MIT, but includes a very minimal clause which is very conducive for businesses.
As a businessman I can easily see wanting the no endorsement clause.
Example.
ezboard decides it really doesn't want to pay Cincom VW license fees anymore and decide to migrate to Squeak. They think Squeak is perfect but will require some infrastructure improvements to handle their load. They want to be a part of the community and decide to open source their non-business exclusive infrastructure code. The community agrees some of their code would be great to include in the image. ezboard elects by the advice of their attorney to use the BSD license and include a no endorsement clause. They didn't want Göran Squeak developer extraordinaire to market his new product Squezeboard using ezboard name as a contributor to Squeak to market his product.
Or lets say ezboard themselves release a BSD Squezeboard product to SM2. Fine you would say to that. But ezboard wants all ezboard OS contributions under a single license. MIT isn't it.
The community would then have to decide ezboard infrastructure contributions go in the image or no? If no, the Squeak community chalks up another, we didn't accept another great piece of code in the image. That would be sad if it would be entirely due to using BSD not MIT.
Don't underestimate business needs or requirements. The no endorsement clause is a good thing, when needed and applied appropriately.
Nevertheless, my point is that allowing MIT and Squeak-L gives us a mixed situation that we still can handle. Adding more licenses to the soup would IMHO be disastrous. And that is btw also the view of Andrew Greenberg, our own specialist. Though it was a long time ago I saw Andrew post.
Yes, I understand your point. You don't want proliferation. Neither do I. I don't think SqL, BSD, MIT is proliferation. If I were voting for only two it would be SqL, BSD. (if I really had my druthers the SqL could go. :) BSD is as free as MIT but more business friendly. BSD is as well known if not more so than MIT.
Since you invoked Andrew's name: ;)
Quotes out of context and condensed. More context and links if desired are at the end of the message. The emphasis below is mine, not Andrews.
Nov2002: I would strongly recommend Squeak-L or BSD for Smalltalk-based code.
Jan2003: For original code, suggest using Squeak-L, or freer (as in BPL/MIT, not GPL).
March2003: As much as I agree with this (and _*like BSD over any other alternatives suggested to date*_),
later March2003: For my part, I think it is better to go KISS -- BSD is a nice, minimalist, OSI-acceptable license that works.
Andrew is pro BSD, (not anti MIT). I am pro BSD, not anti MIT.
Anyway y'all do what y'all think is best. Let your conscience be your Guide. ;)
Thanks for listening.
Respectfully,
Jimmie Houchin Businessman
More context and links: http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-November/049615.... Andrew wrote: (his first sentence) """ In the past we have used an LGPL/Squeal-L dual license, but only in the context of plugins. I would strongly recommend Squeak-L or BSD for Smalltalk-based code. """
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-January/051701.h... Andrew wrote: """ For original code, suggest using Squeak-L, or freer (as in BPL/MIT, not GPL). Anything else is a recipe for failure, and risks a great project rotting on the vine for license conflicts later on. """
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-March/054797.htm... Andrew wrote: """ As much as I agree with this (and like BSD over any other alternatives suggested to date), merely obtaining Apple's consensus would not suffice. """
And then later in that same thread Andrew wrote: http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-March/054856.htm... """ Of course, the hard part is finding a substitute license that everyone can agree on. I like the BSD idea, but there are still some who prefer a viral solution, at least for the interpreter code. For my part, i think it is better to go KISS -- BSD is a nice, minimalist, OSI-acceptable license that works. """
Hi Guys,
There's another way of looking at this problem, which I'd like to point out. If we assume to have a "basic" and a "full" release, then we can effectively include in "full" whatever license there is. How so? Well, practically speaking "full" would constitute only a bundle of packages, which are loaded under their appropriate license. This will (naturally) lead to a pollution of the "full" image with potentially lots of varying license, but given that anyone who cares can use "basic" to load only the packages that fit his or her desires, that's no problem whatsover. Hell, "full" might even include GPL-ed stuff, since if you want to ship a system which is not affected by GPL, you simply load your packages (I wouldn't really want this but it sure as hell is an option).
So the point here is that if we have a "basic" and "full" release, the licenses of the packages loaded into full matter not one bit, except from what we think the most common users of "full" likely would accept (which I think includes BSD, MIT and possibly even more).
Of course, this doesn't really solve the problem at hand since for SmaCC and RB we're really talking about "basic" here. But it is worthwhile to keep this in mind - it brings us down to a discussion on a much more limited basis (for example, Jimmie's ezBoard example would fall through since this were a package loaded into full).
Cheers, - Andreas
"Andreas Raab" andreas.raab@gmx.de wrote:
Hi Guys,
There's another way of looking at this problem, which I'd like to point out. If we assume to have a "basic" and a "full" release, then we can effectively include in "full" whatever license there is. How so? Well, practically
Yes, very good point.
regards, Göran
Hello,
Andreas Raab wrote:
Hi Guys,
There's another way of looking at this problem, which I'd like to point out. If we assume to have a "basic" and a "full" release, then we can effectively include in "full" whatever license there is. How so? Well, practically speaking "full" would constitute only a bundle of packages, which are loaded under their appropriate license. This will (naturally) lead to a pollution of the "full" image with potentially lots of varying license, but given that anyone who cares can use "basic" to load only the packages that fit his or her desires, that's no problem whatsover. Hell, "full" might even include GPL-ed stuff, since if you want to ship a system which is not affected by GPL, you simply load your packages (I wouldn't really want this but it sure as hell is an option).
GPL is a very sticky wicket for Squeak. I think we should be very reticent to include any GPL Smalltalk code any pre-package image, ie: full or such.
What end-users load after they receive the image is their own business and should not cause any responsibility upon the community.
Example, the MySQL driver is GPL.
So the point here is that if we have a "basic" and "full" release, the licenses of the packages loaded into full matter not one bit, except from what we think the most common users of "full" likely would accept (which I think includes BSD, MIT and possibly even more).
Of course, this doesn't really solve the problem at hand since for SmaCC and RB we're really talking about "basic" here. But it is worthwhile to keep this in mind - it brings us down to a discussion on a much more limited basis (for example, Jimmie's ezBoard example would fall through since this were a package loaded into full).
Well the ezboard example had two components. One was in image infrastructure contributions, the other the Squezeboard bboard package on SM.
The infrastructure contributions would need to be a community (Guides, Squeak-authority, whoever puts stuff into the canonical images) acceptable license.
Fantasy example: ***disclaimer Say they rewrote the socket code based upon BSD's KQueue or Linux's epoll(?) and whatever if MSes comparable. Say it doubled socket code performance and increased stability. Stephen, Avi, Göran and Cees were drooling over this contribution. :)
Would the Squeak-authorities allow the BSD licensed contribution, because the business required a no-endorsement clause. I would think this would probably be *basic* image code. If not for sake of discussion, consider the contribution to be *basic* image code.
The Squezeboard contribution would be an SM package and could be licensed most any way but hopefully not GPL.
I hope that makes my example clearer.
Jimmie Houchin
***disclaimer The example was merely a fantasy example to demonstrate what could be consider definitively in image code. I am in no way making any claims that there are any major problems with the socket code.
***no-endorsement clause ;) Please don't use my name any connection with claims against the Squeak socket code.
Fantasy example: ***disclaimer
And yet, if this would be a package on SqueakMap and if it can be loaded into "basic" it would still remain a non-issue for the purpose of our discussion. This is what I wanted to point out here - as long as there's a way to start from a well-known point and assemble your image you don't have a (legal) problem. For example, you could download the basic image _without_ sockets at all and the first thing you'd have to do is to get yourself a socket implementation (which you'd load via the file list for example).
If you go to the extreme (such as Squat) we may never have a problem with licenses except at the very lowest level. As long as you say "this is Squeak and everything else is just packages loaded for your convenience" there is (AFAICT) no problem.
This isn't to say that I _like_ having all those licenses mixed up with one another (in particular not if one package requires one with a different license) but maybe that's another good reason to start thinking about a community license for Squeak.
Cheers, - Andreas
-----Original Message----- From: squeakfoundation-bounces@lists.squeakfoundation.org [mailto:squeakfoundation-bounces@lists.squeakfoundation.org] On Behalf Of Jimmie Houchin Sent: Monday, November 17, 2003 8:59 PM To: Discussing the Squeak Foundation Subject: Re: [Squeakfoundation] Allow MIT-licensed code to be partof "SqueakOfficial"?
Hello,
Andreas Raab wrote:
Hi Guys,
There's another way of looking at this problem, which I'd
like to point out.
If we assume to have a "basic" and a "full" release, then
we can effectively
include in "full" whatever license there is. How so? Well,
practically
speaking "full" would constitute only a bundle of packages,
which are loaded
under their appropriate license. This will (naturally) lead
to a pollution
of the "full" image with potentially lots of varying
license, but given that
anyone who cares can use "basic" to load only the packages
that fit his or
her desires, that's no problem whatsover. Hell, "full"
might even include
GPL-ed stuff, since if you want to ship a system which is
not affected by
GPL, you simply load your packages (I wouldn't really want
this but it sure
as hell is an option).
GPL is a very sticky wicket for Squeak. I think we should be very reticent to include any GPL Smalltalk code any pre-package image, ie: full or such.
What end-users load after they receive the image is their own business and should not cause any responsibility upon the community.
Example, the MySQL driver is GPL.
So the point here is that if we have a "basic" and "full"
release, the
licenses of the packages loaded into full matter not one
bit, except from
what we think the most common users of "full" likely would
accept (which I
think includes BSD, MIT and possibly even more).
Of course, this doesn't really solve the problem at hand
since for SmaCC and
RB we're really talking about "basic" here. But it is
worthwhile to keep
this in mind - it brings us down to a discussion on a much
more limited
basis (for example, Jimmie's ezBoard example would fall
through since this
were a package loaded into full).
Well the ezboard example had two components. One was in image infrastructure contributions, the other the Squezeboard bboard package on SM.
The infrastructure contributions would need to be a community (Guides, Squeak-authority, whoever puts stuff into the canonical images) acceptable license.
Fantasy example: ***disclaimer Say they rewrote the socket code based upon BSD's KQueue or Linux's epoll(?) and whatever if MSes comparable. Say it doubled socket code performance and increased stability. Stephen, Avi, Göran and Cees were drooling over this contribution. :)
Would the Squeak-authorities allow the BSD licensed contribution, because the business required a no-endorsement clause. I would think this would probably be *basic* image code. If not for sake of discussion, consider the contribution to be *basic* image code.
The Squezeboard contribution would be an SM package and could be licensed most any way but hopefully not GPL.
I hope that makes my example clearer.
Jimmie Houchin
***disclaimer The example was merely a fantasy example to demonstrate what could be consider definitively in image code. I am in no way making any claims that there are any major problems with the socket code.
***no-endorsement clause ;) Please don't use my name any connection with claims against the Squeak socket code.
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Andreas Raab wrote:
Fantasy example: ***disclaimer
And yet, if this would be a package on SqueakMap and if it can be loaded into "basic" it would still remain a non-issue for the purpose of our discussion. This is what I wanted to point out here - as long as there's a way to start from a well-known point and assemble your image you don't have a (legal) problem. For example, you could download the basic image _without_ sockets at all and the first thing you'd have to do is to get yourself a socket implementation (which you'd load via the file list for example).
True. I just didn't know how low or small *basic* would be.
If you go to the extreme (such as Squat) we may never have a problem with licenses except at the very lowest level. As long as you say "this is Squeak and everything else is just packages loaded for your convenience" there is (AFAICT) no problem.
Now I like the Squat and build up proposition. From there with the probable exception of GPL-like licenses most anything would be reasonably okay.
This isn't to say that I _like_ having all those licenses mixed up with one another (in particular not if one package requires one with a different license) but maybe that's another good reason to start thinking about a community license for Squeak.
Absolutely. The fewer the licenses the better, provided the ones we choose meet a high percentage of requirements.
I think the BSD license fits the most, next MIT.
I have long been an advocate of a Squeak Community License and advocate of moving as much Squeak code to that license.
I've even submitted such a license based on BSD to the list. http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-February/053544....
I think a good foundation for license requirements would be:
Requirement: "as free or freer than SqL" Encouragement: (in order) SqueakCommunityLicense, BSD or MIT. Permissible: SqL** and then allow something which meets requirement.***
** SqL should be considered a legacy license and primarily used for stuff which we received under it, but not for post Apple/Disney code if at all possible. But as it would not introduce a license conflict, it would be under the permissible section.
*** Discussion as to why SCL,BSD,MIT are insufficient for licensor.
And if at the same time we move towards having as minimal an image as possible from which to build. I think that would further strengthen what we can use from outside Squeak.
But I think the Requirement/Encouragement is not only legal and technological, but also social. As a community many will select a license based on our social desires/requirements. While a minimal Squeak image would free us up considerably, legally and technologically, socially I think my Requirement/Encouragement should be our position.
My 2 centavos. :)
Jimmie Houchin
[snip]
Hi!
Jimmie Houchin jhouchin@texoma.net wrote:
goran.krampe@bluefish.se wrote:
Jimmie Houchin jhouchin@texoma.net wrote: [SNIP]
Yes, and I agree. MIT should be fine. So I vote for allowing it. But only it.
I think allowing MIT would be great. In fact I would think any standard as free as SqL or better should be allowed. Why only MIT?
Definitely not. If we mix up a lot of licenses we will make it more or less impossible for people to know under what circumstances they can use Squeak.
I don't believe it would lead to a proliferation of licenses. I also don't believe there to be very many licenses which qualify by my statement of as free or freer than SqL. MIT, BSD, X11 (I think) being the only ones I am consciously aware of.
Ok, you wrote "In fact I would think any standard as free as SqL or better should be allowed" - and I think I can find tons of those. But if you are talking about MIT/BSD (isn't X11 the same as MIT? Don't have time to check right now) that is a much, much smaller crowd.
BSD is also a standard well known license that may be more comfortable to corporate types. MIT is great for individuals and some corporations might be perfectly happy with MIT but for some BSD is better.
I hardly think the difference between those is significant.
Having a no endorsement clause is significant and is very standard in business. BSD is every bit as free as MIT, but includes a very minimal clause which is very conducive for businesses.
I know that. But I can admit I didn't think it was that important to people/companies. Fine (sigh, I can see where this is going...) - then why don't we agree to let BSD and MIT go in.
I just hope you don't want to allow all these too: http://www.opensource.org/licenses/index.php
[BIG snip of motivation behind allowing BSD]
Nevertheless, my point is that allowing MIT and Squeak-L gives us a mixed situation that we still can handle. Adding more licenses to the soup would IMHO be disastrous. And that is btw also the view of Andrew Greenberg, our own specialist. Though it was a long time ago I saw Andrew post.
Yes, I understand your point. You don't want proliferation. Neither do I. I don't think SqL, BSD, MIT is proliferation. If I were voting for
As I said, you didn't write "SqL, BSD, MIT" - you wrote what I quoted above.
only two it would be SqL, BSD. (if I really had my druthers the SqL could go. :) BSD is as free as MIT but more business friendly. BSD is as well known if not more so than MIT.
Since you invoked Andrew's name: ;)
Quotes out of context and condensed. More context and links if desired are at the end of the message. The emphasis below is mine, not Andrews.
[SNIP of quotes]
Andrew is pro BSD, (not anti MIT).
But this is not the point - I brought him up as a reference to someone who has repeatedly warned this community from mixing licenses in the official Squeak image. And righteously so IMHO. I did *not* mean or imply that he (or I for that matter) has anything against BSD.
And for that matter - if my memory serves he has always stated that *base official Squeak* should be under Squeak-L (and not BSD/MIT).
I am pro BSD, not anti MIT.
Anyway y'all do what y'all think is best. Let your conscience be your Guide. ;)
Thanks for listening.
Respectfully,
Jimmie Houchin Businessman
I always listen. :)
regards, Göran
Hello Göran,
I am not trying to ruffle any feathers or get you send me a can of Swedish fish. ;)
For those who aren't in the know. http://www.svensson.com/norge/sur1.htm
goran.krampe@bluefish.se wrote: [snip]
I don't believe it would lead to a proliferation of licenses. I also don't believe there to be very many licenses which qualify by my statement of as free or freer than SqL. MIT, BSD, X11 (I think) being the only ones I am consciously aware of.
Ok, you wrote "In fact I would think any standard as free as SqL or better should be allowed" - and I think I can find tons of those. But if you are talking about MIT/BSD (isn't X11 the same as MIT? Don't have time to check right now) that is a much, much smaller crowd.
That is correct. I just don't believe there are many licenses which are as free or freer than SqL. I think most of them bring increased restrictions and not increased freedoms. That is why I wrote a more inclusive statement. But SqL,BSD,MIT would cover to my understanding most any ground that a license which is as free or freer than Squeak will go.
BSD is also a standard well known license that may be more comfortable to corporate types. MIT is great for individuals and some corporations might be perfectly happy with MIT but for some BSD is better.
I hardly think the difference between those is significant.
Having a no endorsement clause is significant and is very standard in business. BSD is every bit as free as MIT, but includes a very minimal clause which is very conducive for businesses.
I know that. But I can admit I didn't think it was that important to people/companies.
I can understand somebody not thinking it was important. No problem there.
Fine (sigh, I can see where this is going...) - then why don't we agree to let BSD and MIT go in.
Okay.
I just hope you don't want to allow all these too: http://www.opensource.org/licenses/index.php
No way.
[BIG snip of motivation behind allowing BSD]
:)
Nevertheless, my point is that allowing MIT and Squeak-L gives us a mixed situation that we still can handle. Adding more licenses to the soup would IMHO be disastrous. And that is btw also the view of Andrew Greenberg, our own specialist. Though it was a long time ago I saw Andrew post.
Yes, I understand your point. You don't want proliferation. Neither do I. I don't think SqL, BSD, MIT is proliferation. If I were voting for
As I said, you didn't write "SqL, BSD, MIT" - you wrote what I quoted above.
Correct, I will concede my lack of clarity.
[snip]
But this is not the point - I brought him up as a reference to someone who has repeatedly warned this community from mixing licenses in the official Squeak image. And righteously so IMHO. I did *not* mean or imply that he (or I for that matter) has anything against BSD.
I agree. I am not for a proliferation of licenses in the Squeak base or image. Well I would prefer not to have a proliferation in general. A few well understood licenses is/should be sufficient.
I just allow for situations I don't understand or can't conceive of myself. If the Guides will start with BSD, MIT, SqL and be open to business arguements in the future for a license which is as free or freer but contains something we don't know about. Then I think we are in good shape to move forward and allow business contributions. Hopefully that will come. :)
And for that matter - if my memory serves he has always stated that *base official Squeak* should be under Squeak-L (and not BSD/MIT).
I don't remember. In one of the messages I quoted he suggested tracking down all changes since 1.0 who contributed them and try to get as many as possible under BSD.
[snip]
Thanks for listening.
I always listen. :)
Ya! and thanks.
Jimmie Houchin
Jimmie Houchin jhouchin@texoma.net wrote:
Hello Göran,
I am not trying to ruffle any feathers or get you send me a can of Swedish fish. ;)
No, I didn't think you were either! And hey! That rott... I mean fermented fish is good for you! ;-)
For those who aren't in the know. http://www.svensson.com/norge/sur1.htm
goran.krampe@bluefish.se wrote: [snip]
I don't believe it would lead to a proliferation of licenses. I also don't believe there to be very many licenses which qualify by my statement of as free or freer than SqL. MIT, BSD, X11 (I think) being the only ones I am consciously aware of.
Ok, you wrote "In fact I would think any standard as free as SqL or better should be allowed" - and I think I can find tons of those. But if you are talking about MIT/BSD (isn't X11 the same as MIT? Don't have time to check right now) that is a much, much smaller crowd.
That is correct. I just don't believe there are many licenses which are as free or freer than SqL. I think most of them bring increased restrictions and not increased freedoms. That is why I wrote a more inclusive statement. But SqL,BSD,MIT would cover to my understanding most any ground that a license which is as free or freer than Squeak will go.
Probably so yes.
BSD is also a standard well known license that may be more comfortable to corporate types. MIT is great for individuals and some corporations might be perfectly happy with MIT but for some BSD is better.
I hardly think the difference between those is significant.
Having a no endorsement clause is significant and is very standard in business. BSD is every bit as free as MIT, but includes a very minimal clause which is very conducive for businesses.
I know that. But I can admit I didn't think it was that important to people/companies.
I can understand somebody not thinking it was important. No problem there.
Fine (sigh, I can see where this is going...) - then why don't we agree to let BSD and MIT go in.
Okay.
I just hope you don't want to allow all these too: http://www.opensource.org/licenses/index.php
No way.
[BIG snip of motivation behind allowing BSD]
:)
Nevertheless, my point is that allowing MIT and Squeak-L gives us a mixed situation that we still can handle. Adding more licenses to the soup would IMHO be disastrous. And that is btw also the view of Andrew Greenberg, our own specialist. Though it was a long time ago I saw Andrew post.
Yes, I understand your point. You don't want proliferation. Neither do I. I don't think SqL, BSD, MIT is proliferation. If I were voting for
As I said, you didn't write "SqL, BSD, MIT" - you wrote what I quoted above.
Correct, I will concede my lack of clarity.
:-)
[snip]
But this is not the point - I brought him up as a reference to someone who has repeatedly warned this community from mixing licenses in the official Squeak image. And righteously so IMHO. I did *not* mean or imply that he (or I for that matter) has anything against BSD.
I agree. I am not for a proliferation of licenses in the Squeak base or image. Well I would prefer not to have a proliferation in general. A few well understood licenses is/should be sufficient.
I just allow for situations I don't understand or can't conceive of myself. If the Guides will start with BSD, MIT, SqL and be open to business arguements in the future for a license which is as free or freer but contains something we don't know about. Then I think we are in good shape to move forward and allow business contributions. Hopefully that will come. :)
Yes. Oh, and btw - we already have IanSqueakL too. ;-)
But I take comfort in the observations of Andreas - note though that if the standard libraries of Squeak (packages) are under a big variety of licenses it will almost make it impossible for business people to figure out what the rules are.
regards, Göran
goran.krampe@bluefish.se wrote:
Jimmie Houchin jhouchin@texoma.net wrote:
Hello Göran,
I am not trying to ruffle any feathers or get you send me a can of Swedish fish. ;)
No, I didn't think you were either! And hey! That rott... I mean fermented fish is good for you! ;-)
Well??????
Well, I got some nice HOT chiles from my part of the world which could warm things up this winter in Sweden. :) I know, I know you would probably prefer to let the Mrs. handle that. ;)
I was telling my wife about the fish. She was thinking, what food from the US do people in other countries think is awful?
I told her I don't know. But if we have anything awful, it is probably awful because it is artificial and not real food. We have too much of that. :(
[snip]
But this is not the point - I brought him up as a reference to someone who has repeatedly warned this community from mixing licenses in the official Squeak image. And righteously so IMHO. I did *not* mean or imply that he (or I for that matter) has anything against BSD.
I agree. I am not for a proliferation of licenses in the Squeak base or image. Well I would prefer not to have a proliferation in general. A few well understood licenses is/should be sufficient.
I just allow for situations I don't understand or can't conceive of myself. If the Guides will start with BSD, MIT, SqL and be open to business arguements in the future for a license which is as free or freer but contains something we don't know about. Then I think we are in good shape to move forward and allow business contributions. Hopefully that will come. :)
Yes. Oh, and btw - we already have IanSqueakL too. ;-)
But I take comfort in the observations of Andreas - note though that if the standard libraries of Squeak (packages) are under a big variety of licenses it will almost make it impossible for business people to figure out what the rules are.
Andreas' observations were excellent.
I think the Require, Encourage and Permit descriptions I gave in a reply to Andreas would be good.
I think the social aspect of what we want/desire license wise will be a contributing factor to a decision. I think that if we had a Squeak Community License to move towards, that would show a clear licensing preferrence by the community. And a clear licensing path for contributions.
Just a thought.
Jimmie
Hi Doug--
My sense is that there is community consensus about the MIT license. Namely, that it's a fine option for base-release material. I don't think it needs a vote, but I'd be happy to participate in one (I'd vote in favor of making the MIT license an option).
thanks,
-C
-- Craig Latta http://netjam.org/resume craig@netjam.org [|] Proceed for Truth!
Once the MIT-licensed code is in the official image, will it become SqueakL? I think that would be the simplest solution, that is, if someone "extracts" something back out of Squeak he would be bound by SqueakL. Otherwise, I guess there would be the need to have a registry of which code in the image is under what license, and fixing/enhancing that body of code would become a mess. Sounds ugly to me. Or am I missing something, not being a lawyer or something? ;-)
Hi Bert--
Once the MIT-licensed code is in the official image, will it become SqueakL?
No, it's only SqueakL-licensed code if the copyright holder says it is.
...if someone "extracts" something back out of Squeak he [should] be bound by SqueakL. Otherwise, I guess there would be... a mess.
If we want that, it seems to me we can only accept exclusively SqueakL-licensed code. I think that'd be suboptimal.
-C
-- Craig Latta http://netjam.org/resume craig@netjam.org [|] Proceed for Truth!
...if someone "extracts" something back out of Squeak he [should] be bound by SqueakL. Otherwise, I guess there would be... a mess.
If we want that, it seems to me we can only accept exclusively SqueakL-licensed code.
Not necessarily. There is SM after all. If a package is at SM under some license you can get it from there under the license you want. This would simplify the in-image situation slightly. E.g., a simple bottom line might be that whatever gets shipped with the Squeak image comes under Squeak-L. If you don't like that, go to SM and see if there's another license, and if so, download and install on your own.
For dual-licensed packages this would be trivial. For those which aren't we can still sublicense the package under Squeak-L if the original license allows it.
Cheers, - Andreas
Hi Andreas--
Indeed; I was referring to the acceptance process for "the snapshot". Good points.
-C
-- Craig Latta http://netjam.org/resume craig@netjam.org [|] Proceed for Truth!
"Andreas Raab" andreas.raab@gmx.de wrote: [SNIP]
For dual-licensed packages this would be trivial. For those which aren't we can still sublicense the package under Squeak-L if the original license allows it.
Yes, we could sublicense it to Squeak-L and it would probably make very little difference to people using Squeak since they would probably need to obey the "common denominator" effect anyway.
BUT... if we *would* sublicense these contributions into Squeak-L (which I am not sure I think is necessary) - who would do it? The very reason John Brant hesitated to release SmaCC etc under Squeak-L was that he couldn't interpret what that meant for *him*.
And I can't really say what it would mean to say Squeakfoundation (though that legal entity doesn't exist yet, or does it?) if it would sublicense stuff available under MIT as Squeak-L.
If it would be something we will try then I would btw assume we made our own Sqf-L.
Cheers,
- Andreas
Cheers, Göran
Am 17.11.2003 um 00:55 schrieb Andreas Raab:
...if someone "extracts" something back out of Squeak he [should] be bound by SqueakL. Otherwise, I guess there would be... a mess.
If we want that, it seems to me we can only accept exclusively SqueakL-licensed code.
Not necessarily. There is SM after all. If a package is at SM under some license you can get it from there under the license you want. This would simplify the in-image situation slightly. E.g., a simple bottom line might be that whatever gets shipped with the Squeak image comes under Squeak-L. If you don't like that, go to SM and see if there's another license, and if so, download and install on your own.
For dual-licensed packages this would be trivial. For those which aren't we can still sublicense the package under Squeak-L if the original license allows it.
But SM is not an option for the case that startet the discussion: You can't load the compiler (AST and SmaCC-runtime) from SM.
The Question is: Can the RB-AST *replace* the Node-classes in the image, if it is MIT-Licensed?
Marcus
-- Marcus Denker marcus@ira.uka.de
On Mon, 17 Nov 2003, Marcus Denker wrote:
The Question is: Can the RB-AST *replace* the Node-classes in the image, if it is MIT-Licensed?
As I understand it, the MIT license says: "Do absolutely anything you want with this code, except claim copyright ownership on it".
Most importantly, MIT is not "infectious" in the way that the GPL is. You can include all, or any part, of any MIT-licensed code in anything you like, provided you keep the boilerplate intact on that code (a class comment would do) in any source distribution you choose to make. I cannot see any incompatibility with SqueakL there at all. The effects of the MIT license do not "leak" out of any of the code you reuse, and whatever effect the SqueakL might have on the MIT-licensed code is completely moot, since the MIT license explicitly gives you permission to do *anything* at all (including relicensing it) -- provided only that the original boilerplate remains in the MIT-derived code.
Please correct me if I'm wrong. :)
Regards, Ian
PS: Witness the kerberos code in the Linux kernel, which is MIT-licensed and then relicensed (implicitly) as GPL (merely by being linked with other parts of the Linux kernel). Other parts of Linux (device drivers, in particular) do the same with (lots of) BSD-licensed code. <ObGripe> (This is really unfair, since the BSD people cannot reuse Linux code in the same manner. GPL is called "free" software, but using it can be very, very expensive -- think "clean room reimplementation" for anything that isn't itself GPLed.) </ObGripe>
Ian Piumarta ian.piumarta@inria.fr wrote:
On Mon, 17 Nov 2003, Marcus Denker wrote:
The Question is: Can the RB-AST *replace* the Node-classes in the image, if it is MIT-Licensed?
As I understand it, the MIT license says: "Do absolutely anything you want with this code, except claim copyright ownership on it".
Most importantly, MIT is not "infectious" in the way that the GPL is. You can include all, or any part, of any MIT-licensed code in anything you like, provided you keep the boilerplate intact on that code (a class comment would do) in any source distribution you choose to make. I cannot see any incompatibility with SqueakL there at all. The effects of the MIT license do not "leak" out of any of the code you reuse, and whatever effect the SqueakL might have on the MIT-licensed code is completely moot, since the MIT license explicitly gives you permission to do *anything* at all (including relicensing it) -- provided only that the original boilerplate remains in the MIT-derived code.
Please correct me if I'm wrong. :)
I believe you are correct and as I said in another post - the only issue I can see is that if we decide to sublicense it as Squeak-L (which I assume there is no actual need to do, licensewise) then someone (a legal entity) would need to do it. And I am not sure what it really "means" for that entity, especially regarding mentionings of Apple and indemnification etc.
So best would probably be to simply not sublicense it. :)
regards, Göran
PS. In short - let us allow packages under MIT in the base. But let's not bring in any more licenses because the waters will otherwise get really murky really fast.
There seems to be agreement that allowing the MIT license into "Squeak Official" (Full/Basic) is reasonable. (And also possibly BSD, but we might as well put that off until it is needed.)
In the case of SmaCC, we're really talking about something in the Basic release, the compiler, which is more central than the multimedia/etc. stuff in the Full release. We could potentially be looser about the licenses of things in the Full release, as Andreas discussed.
(See http://minnow.cc.gatech.edu/squeak/3412 for a description of Full/Basic/Minimal.)
On Monday, November 17, 2003, at 04:45 AM, goran.krampe@bluefish.se wrote:
I believe you are correct and as I said in another post - the only issue I can see is that if we decide to sublicense it as Squeak-L (which I assume there is no actual need to do, licensewise) then someone (a legal entity) would need to do it. And I am not sure what it really "means" for that entity, especially regarding mentionings of Apple and indemnification etc.
So best would probably be to simply not sublicense it. :)
Right, I don't think we need to do that at this point. This means that we just keep SmaCC as MIT-licensed.
But we need to keep track of which code in the Basic image is under which license. For SmaCC, we could do this by having it tracked as another "in-image" package, like the small handful of others in the Basic image such as SUnit and SqueakMap. This is a little bit of a hassle, but it seems like the best way to track the code at this point. Everything else (for now, at least) in the Basic image is licensed under Squeak-L.
If someone wants to make a bug fix to SmaCC, the fix would go into a new version of the SmaCC package (which means the fix would be MIT-licensed like the rest of SmaCC), and then the new package version would be moved into the Basic image when needed. In any case, the SmaCC package on SqueakMap would always contain exactly the code which is MIT-licensed.
How does this sound?
- Doug
(p.s. Yeah, eventually we may want to encourage more and more chunks of Squeak Full/Basic to be licensed under a Squeak-Community-License or some other well-known license without some of the Squeak-L baggage, but that's another issue, and we really need to have things broken up into packages beforehand...)
Doug Way dway@riskmetrics.com wrote:
There seems to be agreement that allowing the MIT license into "Squeak Official" (Full/Basic) is reasonable. (And also possibly BSD, but we might as well put that off until it is needed.
[SNIP of stuff I totally agree on]
Yes, all sounds good.
regards, Göran
On Thursday, November 20, 2003, at 02:21 AM, goran.krampe@bluefish.se wrote:
Doug Way dway@riskmetrics.com wrote:
There seems to be agreement that allowing the MIT license into "Squeak Official" (Full/Basic) is reasonable. (And also possibly BSD, but we might as well put that off until it is needed.
[SNIP of stuff I totally agree on]
Yes, all sounds good.
Alright, I'll incorporate SmaCC-Runtime in the next round of updates then. It will be handled as an "in-image" package for now, so we can keep track of the MIT-licensed code... the master copy of SmaCC will be on SqueakMap, and I'll just include the package as an update.
Hm, I notice the SmaCC Runtime package on SqueakMap says "Other License" at the moment, that should be changed to "MIT". Markus G., could you update this? Hm, also the package itself is a SAR at the moment (containing only one .st file)... it would be better if it were a .st or .cs file instead, so I don't have to keep converting from .sar by hand every time I incorporate a new version as a changeset update. (Not that that will probably happen very often, but...)
- Doug
Ian Piumarta wrote:
On Mon, 17 Nov 2003, Marcus Denker wrote:
The Question is: Can the RB-AST *replace* the Node-classes in the image, if it is MIT-Licensed?
As I understand it, the MIT license says: "Do absolutely anything you want with this code, except claim copyright ownership on it".
Most importantly, MIT is not "infectious" in the way that the GPL is. You can include all, or any part, of any MIT-licensed code in anything you like, provided you keep the boilerplate intact on that code (a class comment would do) in any source distribution you choose to make. I cannot see any incompatibility with SqueakL there at all. The effects of the MIT license do not "leak" out of any of the code you reuse, and whatever effect the SqueakL might have on the MIT-licensed code is completely moot, since the MIT license explicitly gives you permission to do *anything* at all (including relicensing it) -- provided only that the original boilerplate remains in the MIT-derived code.
Please correct me if I'm wrong. :)
Regards, Ian
PS: Witness the kerberos code in the Linux kernel, which is MIT-licensed and then relicensed (implicitly) as GPL (merely by being linked with other parts of the Linux kernel). Other parts of Linux (device drivers, in particular) do the same with (lots of) BSD-licensed code.
I like that example, and indeed it corresponds exactly to what I had in mind. It very much simplifies the discussions if we can say that everything in the Squeak image is available under SqueakL, although certain parts might be available under different licences elsewhere, too.
squeakfoundation@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Craig Latta -
Doug Way -
goran.krampe＠bluefish.se -
Ian Piumarta -
Jimmie Houchin -
Marcus Denker