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