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
|