ask for APSL? for real this time?

Andrew C. Greenberg werdna at
Fri Jan 9 15:43:48 UTC 2004

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.

In the real world, you don't want technicians to make legal decisions 
regarding the licensing of their code.  Whether code is derived or not 
is not a trivial issue, and certainly not a trivial issue if litigation 
of any kind is implicated in a business decision.  Having dual 
licensing will yield little or no advantage, and may give rise to 
later-insurmountable problems that could be resolved now if we 
responded promptly.

On Jan 8, 2004, at 8:11 AM, goran.krampe at wrote:

> "Andrew C. Greenberg" <werdna at> wrote:
>> Were you my client, I would advise strongly against it.  It is a 
>> recipe=20=
>> for confusion and later contentious dispute.  Sure, if code is 
>> "pure,"=20=
>> in the sense of having no derivation whatsoever from the existing=20
>> image, no problem.
> Eh... that was what I said. Why are you then first advising strongly
> against it, and then saying "no problem"? I am confused. I thought we
> were in clear agreement earlier that dual licensing (MIT/SqueakL) for
> contributions (not modifications) to base Squeak was appropriate since
> we (at least earlier) had agreed that we wanted all base Squeak under
> ONE license.
>>  But how will we later take any significant block of=20=
>> code and actually know what license applies, and to what portions 
>> of=20
>> it?
> For these added base package it is clear: SM tells you the license.
>> Dual-licensing some of the code will not clarify the issue, nor will 
>> it=20=
>> solve the problem, if there is any problem at all.
> Lost me again. Earlier you argued very strongly for keeping base Squeak
> under a single license - SqueakL - and now you argue that doing that
> through dual licensing is the wrong way.
>>  It would be far,=20
>> far more sensible to start from scratch and rebuild a new Smalltalk. 
>> =20
>> The fact that nobody has bothered has much to do with the fact that 
>> the=20=
>> license isn't really a problem.
> There are at least 3 efforts ongoing that I know of:
> - Slate (though not motivated by license issues - it is a new
> "Smalltalk" implementation under MIT)
> - Squat (Craigs from-the-ground-up project with the license issue as a
> base ingredience AFAICT)
> - TFNR/partitioning-the-image (The community's effort of defining the
> image in clear packages)
>> Best solution is to involve Apple with a plan, AFTER WE OURSELVES 
>> FORM=20=
>> A CONSENSUS what plan to undertake.
> [SNIP]
> Personally I have a hard problem seeing how to deal with the other Big
> Player. And I am still to be convinced that the work done there is not
> theirs.
> regards, Göran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2361 bytes
Desc: not available
Url :

More information about the Squeak-dev mailing list