ask for APSL? for real this time?

Doug Way dway at mailcan.com
Fri Jan 9 22:04:32 UTC 2004


Andrew C. Greenberg wrote:

 > To be clear.  It is my conclusion (a considered view of a seasoned
 > intellectual property attorney) that plural licensing will kill the 
project
 > and make it absolutely impossible to make changes in the future. 
 > Nothing I wrote here undercuts that conclusion.  Please, for G-d's
 > sake, don't do it.


I agree with most of Andrew's points in his other message (namely, that 
it is probably not practical to re-license Squeak at this moment), but 
it's pretty clear to me here that he has misinterpreted what Goran said 
about dual licensing.

I believe Andrew is saying above that we don't want a "multiply-licensed 
Squeak release".  (Correct me if I'm wrong.)  That is, a Squeak 
image/release which has different sections under different licenses.  
For example, the kernel licensed under Squeak-L, the networking code 
licensed under BSD (and not Squeak-L), UI code licensed under only APSL, 
a web browser licensed under only LGPL, etc.  Goran and most of us agree 
that this would be a bad thing.

However, Goran was saying that we should encourage "dual licensing" of 
new (non-derivative) additions to the Squeak release, which is an 
entirely different thing.  For example, someone could write a new web 
browser from scratch and dual license it under Squeak-L and MIT (which 
is the only recommended dual license), so that someone using the browser 
could pick either license.  This means that if we decide to incorporate 
this new browser into the Squeak image/release, we can treat it as being 
licensed under Squeak-L, so that the *entire* image/release is still 
licensed under Squeak-L, avoiding the problem above.  So in other words, 
with "dual licensing of new packages" we can avoid the problem of a 
"mulitply-licensed Squeak release".

But with the dual-licensed web browser we also have the option of making 
it part of a MIT-only Squeak image/release, if we ever build such a 
thing from the ground up, which is a real possibility with the splitting 
up of the image into packages and the work on Squat.  This would be our 
OSI-Debian-etc-compliant version of Squeak.

So, if you have a problem with something, please be more specific about 
whether it's with the "multiply-licensed Squeak release", or "dual 
licensing of new packages", or both.

We are currently keeping track of which portions of the Squeak release 
are licensed under Squeak-L versus SqueakL+MIT, via the SqueakMap 
catalog.  So we are not going to lose track of which source code is 
under which license.

 > I ask again, is there broad consensus what license we should use in place
 > of Squeak-L?  If so, what is it.  Let us draft the revised license in 
final form
 > and then, only then, consider what it is we should do.

I realize that one issue is that, with the dual-licensing recommendation 
above, we have somewhat arbitrarily chosen MIT as the alternate license 
here.  My impression is that for most of the Squeak community, MIT does 
have broad support as a OSI-Debian-FSF-etc-compliant license, with only 
one possible exception:  It lacks the "changes to the base must be 
posted publicly" clause which Squeak-L has.  I know that some like this 
clause and others don't... it seems like a nice idea in many ways, but 
may be difficult to enforce, and it is certainly less complicated to 
leave it out.  But anyway, no one seems to be in favor of a more 
restrictive GPL-like license.

I don't think there's been *too much* stuff released under SqueakL+MIT 
yet, so in theory we could decide on something other than MIT to replace 
SqueakL.  But the current tentative "replacement" for SqueakL is MIT, 
for all practical purposes.  If the replacement ever happens. :-)

- Doug

p.s. We (the Guides) did decide to allow MIT-only licensed code to be 
part of the base Squeak release, if there are no alternatives.  This was 
for the SmaCC compiler which is licensed only under MIT, and has been 
added to 3.7alpha (and tracked via SqueakMap).  So we have conciously 
broken the rule for avoiding a "multiply-licensed Squeak release" to 
some extent, but this will likely be the only other license allowed in 
the release.





More information about the Squeak-dev mailing list