Sublicensing Squeak-L (was Re: ask for APSL? for real this time?)

Doug Way dway at mailcan.com
Fri Jan 16 00:47:44 UTC 2004


Andrew C. Greenberg wrote:

> On Jan 13, 2004, at 1:50 AM, Doug Way wrote:
>
>> 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?
>
>
> It would be a decent beginning, and would overcome the key hurdle.  
> Best practice would be to get signoff from all subsequent 
> contributors, including Disney, but we must work with the art of the 
> possible., and the language of Squeak-L (apparently hardwired to 
> Apple) gives us an opportunity to exploit Disney's lack of diligence 
> (they COULD have, but did not, change the license to be protective of 
> both Disney and Apple).


Yes!  The advantage here is that we wouldn't need to approach anyone 
except Apple.  It's probably worth a try, anyway, and if it solves the 
issue with OSI/Debian/etc acceptance, that would be a significant 
accomplishment.

I vaguely recall that Daniel Vainsenscher had talked to a lawyer who was 
pessimistic about sublicensing, but I don't remember what the exact 
issue was.  It is true though that we potentially have some pull with 
Apple, as opposed to certain other copyright holders (required for a 
re-licensing effort), which might make sublicensing work.

Could it be that OSI or Debian would not recognize a sublicense as a 
valid license to consider for compliance, since the original Squeak-L 
license might still be in effect?  I'm fuzzy on exactly how sublicenses 
work.

> The question is what new license would we adopt?  Can we reach a 
> consensus with which all or everybody should agree?


I'm hoping we could reach some sort of consensus. :-)  I think the only 
real issue in the community is whether the license should be quasi-viral 
(as Squeak-L is) or non-viral.

It may be that Apple's restrictions on what is "no less protective of 
Apple and Apple's rights" will limit our choices anyway.

As an extreme example, I don't think that Apple could give a written 
agreement that the MIT license is a valid sublicense of Squeak-L, even 
with a lot of prodding from Alan & co., since it seems patently false 
that the MIT license is "no less protective of Apple and Apple's rights" 
than Squeak-L.  But I could be wrong.  BSD/BPL might have a slightly 
better chance.

On the other extreme, we could create a customized SqueakSub-L by making 
the minimal number of tweaks to Squeak-L so that it complies with 
OSI/Debian/FSF.  This would mean tweaking the wording in the 
indemnification clause, tweaking or perhaps removing the export clause, 
and probably removing the font clause.  Also, we'd probably want to 
replace all references to "Apple" with something else like "copyright 
holder".  A better name than SqueakSub-L might be SqueakOpen-L, or 
SqueakFree-L.  I'd think it would be relatively easy to get Apple to 
agree to something like this being a valid sublicense of Squeak-L, 
especially with extra prodding.

Other possibilities might include APSL, which it seems they would 
probably agree to.

I'd probably lean toward trying some sort of SqueakOpen-L... it might be 
easier to get consensus on sticking with the status quo regarding the 
quasi-viral aspect.  A minor downside to something like SqueakOpen-L is 
that it is not as well-known as something like BSD or APSL.  But I don't 
consider that a huge problem... lots of other open source 
languages/environments have their own custom licenses, such as Python.  
Among the non-viral licenses I probably like BSD/BPL the most.

- Doug





More information about the Squeak-dev mailing list