Two important issues...
goran.hultgren at bluefish.se
goran.hultgren at bluefish.se
Tue Feb 18 10:02:11 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. So I
Eh, what? Are you sure about this?
> 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
That might of course be true - and I can't really say what the
differences are, but it would amaze me totally if a package can have
"any license it wants without affecting anything.".
> 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.
Well, I disagree. I simply want Squeak core to be non-mixed licensewise.
And I do think that there is a clear dependency here between the
generated parser and the tool used to generate it. So essentially I do
think both runtime and dev belong in core and therefore should be under
Squeak-L. But that is my opinion.
> > 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
Ok, I haven't found any license for SmaCC yet, do you have a url
And exactly how a license can be revoced (correct word?) depend on the
license I think, they aren't always "forever".
> > 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.
Well, to some extent I agree with you if SmaCC is similarly licensed as
GCC. Is it?
And I still think that we should take care before jumping into these
things, I don't want to end up in the future with a big mess of licenses
to keep track of and stuff that can't be distributed together etc.
If we now adopt SmaCC for rewriting the Parser/Scanner then SmaCC may
turn out to be used a lot for different packages - I just read that
Stephane wants to use it for tons of different packages... So, SmaCC may
turn into a regular tool in the Squeak toolbox. And if that isn't under
Squeak-L then I think we are moving in a dangerous direction depending
on something that simply isn't "under our control".
You may think that, hey - this is just a little "exception" and who
cares, but down that path... Well, you know what I mean. I think we
should really strive to keep Squeak under the same license umbrella.
When someone says "What license is Squeak under?" I want to be able to
say "Squeak-L". Not "Well, most is under Squeak-L but the Parser
generator is under Dippy-L and package X is under LGPL yaddayadda."
Perhaps again I am paranoid and if noone else cares then...
Sidenote: Would you like to help out in defining the package groups we
should have and the rules for them - this is clearly a problem connected
to that set of rules. Martin Wirblat started that thread "SqueakMap vs
Debian" the other day and I tried starting it in this thread but it
More information about the Squeak-dev