ask for APSL? for real this time?

Doug Way dway at
Tue Jan 13 06:50:19 UTC 2004

On Friday, January 9, 2004, at 07:22 PM, Andrew C. Greenberg wrote:

> ...
> Can we, at least, first see if we can come to consensus as to what 
> license, if any, to which we might shift if at all?  That is to say, 
> is there any license for which EVERY person who's initials appear in 
> the code can either:
> 	1) firmly adopt; or at least
> 	2) agree to consent to shift the code over
> which also might have at least a reasonable shot of getting consent 
> once we bring it to the appropriate level at the several corporate 
> sponsors?  If not, I would strongly recommend just dealing with 
> Squeak-L, and alas, shunning any non-conforming code from general 
> distribution.
> For my part, I can be talked into almost anything that is not 
> monolithic image incompatible.  While I like the safe and quasi-viral 
> aspects of Squeak-L, I would not oppose a BPL-like license.  I am not 
> a partisan of APSL, but I do consider that Apple would be far more 
> likely to consent to APSL than to BPL.  I understand that Cees 
> believes he has fathomed this issue, but I sincerely believe that a 
> concerted approach after proper preparation, supported by the 
> illuminati (Alan and cabal) and directed to executives well above the 
> "manager" position, further supported by competent counsel to 
> negotiate issues properly, would fare much better.

I should mention that currently, after discussing with some SqC 
members, we (the Guides) will not be approaching Disney about the 
possibility of re-licensing.  Disney is not a software/computer company 
like Apple, and has no motivation to play nice with the open source 
community, so the chances of them allowing a re-licensing without a big 
incentive are pretty much zero.  (Unless something changes, and they 
have an incentive.)

So, that kind of rules out re-licensing the whole image at the moment.  
But re-licensing the original Apple Squeak release (by having Alan & 
co. talk to Apple) and building something up from that could be a 
possibility.  But that is much more of a "do-over".  In theory, Craig's 
Squat project could be based on something like this.  And of course the 
community would have to agree on what exactly the replacement license 
would be.

So, it seems like there are only a few options, if as you said a 
clean-room re-implementation is not practically feasible:

1. Live with Squeak-L, which is mostly fine except for non-acceptance 
from some groups such as OSI and Debian.

2. Re-license the original Apple Squeak release and build up something 
up new from that.  (A major effort.)  Starting over with Slate is a 
more extreme version of this.

3. Try some trickery with sublicensing to get around the Squeak-L 
clauses which are problematic for OSI/Debian/etc.  Andrew, do you have 
any thoughts on whether this is possible?  Squeak-L says a sublicense 
must be "no less protective of Apple and Apple's rights than this 
License".  If we crafted a sublicense SqueakSub-L which was acceptable 
to OSI and Debian, and got a written agreement from Apple (with the 
help of some luminaries if need be) that it was indeed an acceptable 
sublicense of Squeak-L, would that work?  Or is investigating 
sublicensing pointless?

-  Doug

More information about the Squeak-dev mailing list