ask for APSL? for real this time?

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Jan 7 11:33:06 UTC 2004


Hi Lex and all others!

My reflection:

The only real practical problem AFAIK with the current license is that
it isn't OSI certified. IIRC the export clause was the problem. That
wasn't a problem for the Debian people, they instead got scared by the
indemnification stuff. Anyway, these two clauses in Squeak-L thus
prevents Squeak from being an option/included in many different
contexts.

- "Changing license": The big problem with changing the license is that
we need to
	- Know who all the contributors are. Is Disney for example included?
	- Get them to all agree on a revised license.
My guess is that this includes Apple, Disney, and a whole bunch of
private persons that might be trackable using the signatures in the
image.

The other venues that have been lurking in the back of my head are:

- "Sublicensing" given the fact that Squeak-L is a bit... loose. IANAL
etc so I have no idea about the validity of this, but IIRC Craig had
also noted some "possibilities" in that direction. This route is of
course shaky, because who knows if the Big Two Players "wake up" in the
future.

- "Benefactor": The possibility of some big player stepping in and
helping out by putting pressure on The Two Big Players.

- "Jumping ship": We all simply move over to Slate eventually. :)

- "Rebuilding a free Squeak" from the ground up using the work of Craig
(squat). I think Craig himself is thinking in those directions.

Ok, please feel free to add to the list, but given these I think
"Changing license" will not happen because I can't see Disney
cooperating. It would cost them money to evaluate their options and I
don't think they are interested in doing even that.

"Sublicensing" might work in theory, but I think it wouldn't result in a
clear situation. We would always be looking over the shoulder anyway.
The "Benefactor" possibility is probably not going to happen AFAIK.
"Jumping ship" is too bold a move, Slate is still just in its infancy.

The *only* option that looks interesting to me is to actually rebuild
Squeak from the ground up - and we (Craig) are already doing that "as we
speak".

So finally, my suggestion is to continue with defining Squeak in terms
of packages and their proper licenses, continue Squat, meet halfway and
then be able to produce images by combining packages and then, simply by
choosing packages under MIT or other OSI licenses gradually getting a
Squeak that gives us all the possibilities we want.

regards, Göran



More information about the Squeak-dev mailing list