ask for APSL? for real this time?

Doug Way dway at
Tue Jan 13 05:22:59 UTC 2004

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

>> p.s. We (the Guides) did decide to allow MIT-only licensed code to be 
>> part of the base Squeak release, if there are no alternatives.  This 
>> was for the SmaCC compiler which is licensed only under MIT, and has 
>> been added to 3.7alpha (and tracked via SqueakMap).  So we have 
>> conciously broken the rule for avoiding a "multiply-licensed Squeak 
>> release" to some extent, but this will likely be the only other 
>> license allowed in the release.
> Once again, there is still time to stop and save the project.  I 
> commend that to you.  In the long haul, it WILL kill Squeak or make it 
> impossible for us to improve the present licensing issues.  In the old 
> days when I advised SqC regularly on this, I frequently negotiated 
> appropriate licensing concessions with most such projects.

Note that the SmaCC compiler is the only part of the current 
image/release which is not Squeak-L licensed (it is MIT only).  Also, 
it was developed outside of Squeak.. a VisualWorks project originally, 
I believe.

Regarding dual-licensed code, it looks like there are only three 
packages in the base image/release like this at the moment... SUnit, 
SqueakMap and SMPackageLoader.

SUnit was brought in from an external cross-dialect Smalltalk project, 
so it seems to be a reasonable example of a dual license.  It was 
already released under a different license (public domain, it appears), 
and Squeak-L was added when it was incorporated into Squeak.

SqueakMap & SMPackageLoader were both developed in Squeak, and have the 
SqueakL+MIT license applied as per the current practice.  If it is 
truly invalid to claim the additional MIT license on these packages, we 
could consider abandoning this particular practice... it would be easy 
enough for the authors to release future versions under Squeak-L only.

With SmaCC it might be more difficult to get the authors to release it 
under Squeak-L... but because it was developed outside of Squeak, 
perhaps this is not as big an issue?  Although I can understand the 
argument for keeping everything in the base image/release as Squeak-L.

- Doug

More information about the Squeak-dev mailing list