[ANN] Closure Compiler

Doug Way dway at riskmetrics.com
Wed Mar 26 00:44:44 UTC 2003


Andreas Raab wrote:
> 
> > > Please don't do this folks.  We have enough licensing
> > > issues already. Promiscuously cross-licensing like this
> > > could kill either SM or Squeak, or both.
> > >
> > Or neither. Most likely outcome, I believe.
> 
> I don't think so. I know that various people are already quite concerned
> about changes to the current license and in fact I have got an inquiry by
> someone who is quite likely to feed back into the community if it is "safe"
> to stick to 3.4 in order to prevent any future licensing issues. The danger
> is quite real as you get into random cross-licensing. As soon as (for
> example) the first GPLed package is going to be widely used, _everything_
> that uses any bit of it is GPLed. It's a spreading wave and the only way to
> prevent that wave from happening is to fork on a clear path. And that has
> the potential to kill either Squeak or SM. Or both.

I generally agree.  I think it's pretty certain that we will *not* include any
GPL packages as part of the "Squeak official" packages/distribution.

However, one possibility is that we could consider having a Squeak-compliant
license guideline, similar to Debian Free Software Guideline/DFSG, as Daniel
suggested.  The Squeak-compliant guideline would differ from something like
DFSG in that GPL would not qualify, because GPL is incompatible with the
Smalltalk monolithic image concept.  But MIT and some others would qualify.

But this sort of thing we might want to keep to the more "outer" layers, such
as perhaps the Full/Kitchensink layer and outside of that, and still require
that the Core/Developer and Kernel layers be strictly Squeak-L licensed.  I
would guess that most people considering using Squeak for commercial purposes
would start with the Core/Developer layer anyway, and wouldn't need most of
the outer layer stuff (email client, Balloon3D, voice synthesis, etc.).  Is
this roughly how Python licensing works, for example?

Anyway, I'm mostly just brainstorming here along with everyone else.  Until
we're sure about what we're doing, I'd say we should probably require Squeak-L
for everything going into official Squeak for now.

Also, something like SmaCC might be considered to be at a lower layer
(Core/Developer), and thus might be something we really want to be under
Squeak-L anyway.  (Although I guess the SmaCC compiler is perhaps less
fundamental than the runtime... hmmm, so many questions. :-S )

- Doug Way



More information about the Squeak-dev mailing list