Mission for Squeak Foundation
Doug Way
dway at mailcan.com
Wed Dec 21 05:32:04 UTC 2005
I agree with Stef & Daniel that this is a very appropriate and useful
task for the Squeak Foundation to pursue.
>> On December 21, 2005 8:56 Daniel Vainsencher wrote:
>>
>> I agree that a general (preferably not country specific) professional
>> legal analysis of the license would be useful.
>>
>> I think the points of interest would be:
>> - Risks in it for users, developers and redistributors
>> ...
>> - Analysis of its interaction with other code: fixes to existing
>> classes
>> vs. separate packages, and MIT vs. Squeak-L.
Agreed.
>> - Analysis of the strategy I proposed a while ago for living with and
>> eventually replacing SqueakL. The strategy is: dual license all new
>> code
>> as MIT/SqueakL, try to replace subsystems rather than fix them. If its
>> bad, propose an alternative strategy.
I should mention that a lawyer, in discussions on squeak-dev a year or
two ago, strongly discouraged this approach, at least for anything in
the official image/package set. (Although this was not given as
official legal "advice" of course... just conversation on squeak-dev.)
I believe the concern was whether a package developed within the Squeak
environment/toolset (which is Squeak-L licensed) could legitimately be
licensed with something other than Squeak-L, if it was replacing a
package which was formerly Squeak-L. (i.e. it would be hard to prove
that the original Squeak-L code was not looked at/used) Or something
like that... one would need to re-read the original thread to be sure
of the argument made.
But yes, it would be nice to have an alternate long-term replacement
strategy if the above is determined to be a bad idea. In any case, the
above strategy should be studied as a possibility.
Other strategies that have been discussed in the past:
1. Get Apple to re-issue Squeak 1.0 under a different license, then
re-build on that. This is legally clean, but is a huge amount of
coding re-work, kind of starting over from scratch.
2. Try to exploit a possible sublicensing loophole in Squeak-L to tweak
the problems of the license. No coding re-work, may or may not be
feasible.
3. Live with the license as-is... the license isn't all that bad. It
just misses qualifying as "Open Source" (OSI) and Debian Free on
technicalities, mostly because it predates both of those standards.
Overall it's still a fairly simple license, much shorter in length than
say GPL or APSL. A number of companies have gone ahead with Squeak
projects after having lawyers look over the license.
On Dec 20, 2005, at 1:52 PM, Ron Teitelbaum wrote:
> Dan has asked about these issues, and early on I pointed him to
> documentation that included your strategy. ... I would think that
> for now it would
> be best to answer Stef's question using the parameters he set (no
> change in
> license) and we can move to a more comprehensive risk assessment when
> (if)
> the time comes to change our license strategy.
Definitely agreed.
- Doug
More information about the Squeak-dev
mailing list
|