Two important issues...

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Tue Feb 18 10:58:33 UTC 2003


Avi Bryant <avi at beta4.com> wrote:
> On Tue, 18 Feb 2003 goran.hultgren at bluefish.se wrote:
> > 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?
> 
> IANAL, so I'm not sure about anything.  :)

Well, the packages are essentially source packages and I can't
understand how that would suddenly remove the issues of licensing! I
mean, are you implying that I - simply by choosing to distribute
something as source - suddenly have no rights whatsoever to have my
license agreement followed?! ;-)

This is probably not what you mean. I do agree that it may be different
to distributing images - but I am pretty sure that there still are
interesting issues.

> > 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.
> 
> If that's possible, then great, I'm all for it.  If it's not possible -
> well, we should cross that bridge if we come to it.  I wouldn't personally
> want to rule SmaCC out in that case, but I understand your sentiment.  But
> there's no point in arguing about it more until we know that we have to.

I am not ruling anyting out yet, I am sorry if it sounded like that. I
just don't want us to forget about licensing - we simply just can't pick
stuff that is cool and throw it into Squeak without thinking about the
consequences.

I am very hopeful that John and Don can release SmaCC in full under
Squeak-L *for use in Squeak*. Such a restricted license seems to me to
be the best of all worlds for both parties.

I mean, improvements made by the Squeak community on these packages can
be funneled back into SmaCC (since Squeak-L allows this) making John/Don
happy - and even more improvements can be expected if SmaCC can thus
become a core package. Furthermore John/Don can use whatever license
they seem fit for other Smalltalks - typically paying customers etc -
and then include those improvements in that commercial offering.

Of course, that commercial license would need to "protect Apple" etc but
that should be doable. It is these kind of symbiotic relations that GPL
etc can't really foster. On the other hand GPL has other advantages - so
all you FSF followers out there - this is not a glove in your face. ;-)

> > Ok, I haven't found any license for SmaCC yet, do you have a url
> > somewhere?
> 
> There isn't one - John was pretty clear that he didn't have a formal
> license for it.

Oh, sorry. I interpreted both Stephane and you as there was a license
available.

> > 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
> > sortof died.
> 
> I'm happy to help but it's too late at night for me to say anything
> intelligent about it now.  Start a thread and I'll comment on it
> tomorrow...

Okidoki. :-)
 
> Cheers,
> Avi

regards, Göran



More information about the Squeak-dev mailing list