On Friday, August 15, 2003, at 01:05  PM, Daniel Vainsencher wrote:

> However, I'm becoming somewhat
> reluctant about sublicensing from a slightly different POV - I think 
> the
> healthy thing to do long term is to secure a codebase which presents
> fewer risks by being truly freely licensed. This is not a short term
> goal obviously, but it seems better to me than the community engaging 
> in
> exploratory licensing.

Yes, I think you're absolutely right. To really put Squeak on a stable 
legal footing, we need to get free of the SqueakL. This is going to be 
a long term project, and the sooner we get it started the easier it 
will be.

> I think some steps should be -
> 1. To announce, and include in the web documentation, and in the list
> information that any code sent to the list is dual licensed by default
> under the MIT and SqueakL (as opposed to just SqueakL right now).
> 2. To make a point of replacing entire mechanisms, rather than
> refactoring existing ones. For example, the kind of work KCP does right
> now doesn't improve our license status at all. However, a newly
> implemented kernel (MIT licensed) could. This makes it quite a bit
> harder to keep the system stable, but it isn't impossible.
> 3. Learn from other projects. Some (Python) have non-profit foundations
> that hold copyright for key parts of the system. I don't know what
> exactly is appropriate for us, but we should think about it.
> 4. Search for existing, freely licensed codebases. I know
> LittleSmalltalk doesn't compare to Squeak, but parts of it might be 
> able
> to replace parts of Squeak (and then filled out by the community).
> StrongTalk's code carries a hilarious*, but (unless I'm missing
> something) very free license, so maybe we could reuse part of that.
> 5. To start keeping track of what parts of the code are already
> completely free, and which aren't. This isn't that hard - small fixes
> don't matter for this, only clean rewrites. This is important so that 
> we
> know what still needs to be replaced.

I think 5 is the really important point here. Points 1-3 allow us to 
ensure that all new code is free, but that could take a long time to 
produce a completely free Squeak. Once we start to identify the 
encumbered bits of code, we can figure out what to do about them. This 
could include rewriting them, or going back to the copyright holders to 
negotiate a new license.

I suspect that doing point 5 really well would make renegotiating 
easier than it first appears. I quick trawl through the V2 sources, V3 
sources and 3.6b changes files shows 173 unique author initials. It 
would be feasible to approach all of them regarding relicensing, 
particularly if we have details on exactly what code we're talking 
about. In many cases we'll get responses like, "Sure, but Disney owns 
the copyright on everything I did between this date and that." That's 
fine. It whittles down the encumbered code a bit and ads to our 
knowledge base.

At some point, between new code being free and older code being freed, 
we'll have a really clear set of core modules that we can take to Apple 
and/or Disney. I'm sure that better preparation on our part will make 
that negotiation easier.

Colin