Two important issues...

Daniel Vainsencher danielv at netvision.net.il
Wed Feb 19 09:58:34 UTC 2003



Avi Bryant <avi at beta4.com> wrote:
> 
> On Tue, 18 Feb 2003 goran.hultgren at bluefish.se wrote:
> 
> > I am not sure what you mean with "the base image". In my perception of
> > the future there simply is no such thing. There are only groups of
> > packages, and some of them are "core" to Squeak which means they are
> > under Squeak-L and can be depended upon, the community takes care of
> > them etc.
> 
> Well, from a licensing point of view, all that matters is what images are
> distributed, say from the squeak.org download site.  This is what I mean
> by "base image".  Any package that is only loaded after the user downloads
> the image, can have any license it wants without affecting anything.  
I think you might be thinking about license that specifically limit
redistribution as part of new work (GPL). In general, a license could
certainly include other arbitrary limitations that prevent it from being
free enough to use even when loaded by it's end user.

The issue Goran raises is a real one - for Squeak to remain effectively
self hosted and modifiable by it's users, the license for all parts of
the hosting mechanism should be free enough that any user can maintain
it independently, and share his changes.

My reading of John's reply is that the SmaCC maintainers don't care to
exercise their monopoly on licensing SmaCC. If so, using an explicit
license like MIT/Squeak-L is preferable to having no explicit license,
because it means that other can depend on this position for such
versions as are released under it. AFAIK, anything released "Free
without an explicit license" actually is equivalent to "all rights
reserved" (though I choose to do nothing about it now).  Which implies a
risky position for anyone depending on such software too much.

> So I
> think it's useful when talking about licenses to distinguish between what
> we expect to distribute as an image and what we expect to distribute as
> packages.  The Parser itself I would expect to be in virtually any image
> that was available, so definitely needs to be Squeak-L.  The tools for
> generating the Parser I would expect to be available separately, whether
> they're under Squeak-L or not.
> 
> > But perhaps that is what you mean.
> >
> > > why do we care about the license as long as it's
> > > freely available?
> >
> > Ok, but what happens in the future when John and the guys decide to turn
> > SmaCC into a proprietary product? Then we have a core piece of Squeak
> > that we can't change without using a non "Squeak free" tool.
> 
> As long as the current version of SmaCC is licensed acceptably (and
> obviously we'll have to figure out what that means, but that's much
> wider than Squeak-L IMO), it doesn't matter how later versions are
> licensed.
> 
> > Personally I think it is an important problem. And principally it would
> > feel much better IMHO if all parts of Squeak where under Squeak-L -
> > including the tools inside Squeak. For example, what would your reaction
> > have been if SqueakMap was not under Squeak-L?
> 
> SqueakMap is something that is useful to 99% of Squeak users, and thus
> is almost certain to be in any image we wish to distribute.  The same does
> not hold for SmaCC.
> 
> In what way is needing a non-Squeak-L parser generator when building the
> parser different from needing a non-Squeak-L C compiler when building the
> VM?  GCC doesn't need to be under Squeak-L because we only need
> to distribute its output, and it is licensed such that we know we'll
> always be able to use it when we need to; it seems to me that SmaCC would
> be much the same thing.

Yes, this is merely because the GPL is compatible, if you don't release
it in the image. GCC is still free software, which SmaCC isn't unless
explicitly licensed so.

Daniel



More information about the Squeak-dev mailing list