Sublicensing Squeak-L (was Re: ask for APSL? for real this time?)
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
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
> 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
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.
More information about the Squeak-dev