Cees de Groot <cg at cdegroot.com> wrote:
> On Wed, 2003-03-26 at 08:51, Stephane Ducasse wrote:
> > Could a group of people identify a path or multiple ones and make a=20
> > clear analysis?
>
> Squeak's license is irrevocable(*). So there is no risk at all that

How sure are you of that? I have been trying to find info on
irrevocability but had a hard time finding stuff.

[SNIP]
> There's a second argument that's not related to this open source
> business: Squeak (whatever that means) is distributed under the SqueakL.
> So, by reading the SqueakL, you now your rights (use it for whatever you
> like, don't sue us) and obligations (share some modifications, don't
> give it to people living in Libya). If Squeak, as you get it, would
> contain code under various licenses, you'd need to study all the
> licenses and it would make it less easy for you to evalutate whether
> Squeak is usable by you.

Right. And frankly, this is perhaps my main reason for keeping some form
of core/base (whichever suits your vocabulary) under Squeak-L *only*.

Again, note that other "groupings" of Squeak stuff (think distros or
whatever) can contain multiple licenses. But it still is nice if there
is one subset of all possible Squeak packages that can be had under ONE
license. And the community tendered official subset of those would be
what we call the core.

(since I don't think we will ever get around to changing it)

> A third argument is that some licenses have viral qualities - if you
> combine code under two licenses, one license may state that 'the other
> code' comes under its terms. The GPL is a clear example of this: if you
> link any code to GPL-licensed code, the GPL states that the resulting
> whole counts as a derived work and therefore must be licensed under the
> GPL. This is good if your political agenda is called 'copyleft' - in
> effect, they are founding a protected commons - but bad if your agenda
> is 'I do not care about political agendas'. Other licenses may have
> similar terms; for example, the SqueakL stating that everything you
> modify of Squeak (as you received it) should be shared with the
> community is viral: if you file-in code that has modifications to, say,
> Object>>asString, the modification *must* be shared with the community
> under the SqueakL (only if you redistribute or sublicense it - read the
> SqueakL for the gory details).

Eh, IIRC Andrew even got to the conclusion that you *must* share it even
if you are not distributing it! Probably an unintended flaw in the
license, but anyway.

> Obviously, every additional license
> inside Squeak creates a risk of 'contamination', and this is a
> combinatorial explosion you want to avoid.

Right. At least we want to avoid it in the core.

> So, there are good reasons to try to keep at least the basics ('kernel',
> 'coder', maybe even 'carnival') clean (SqueakL-code only).

Right.

> What I'm arguing here, and what caused this whole discussion it seems
> ;-), is that there are alternative licenses that are strict supersets of
> the SqueakL(*).

> There is also public domain code - code, where the
> original owner has relinguished all rights (including the copyright) to
> the work and everyone is free to do as they please with the work. Code
> under these licenses (I think even refactory.com's 'click here to
> download the Refactoring Browser' constitutes a license - they keep the
> copyright by default, so they must grant some rights based on this
> privilege by offering copyrighted works for download; a safe assumption
> is that the BSD/MIT terms apply: use as you like, don't sue us), being
> supersets of the SqueakL in terms of granting you at least all the
> rights of the SqueakL and not burdening you with more obligations, could
> be considered for inclusion into Squeak.

Yes, I agree - there is a "license" from refactory.com. (I just read up
a bit more http://faqs.org/faqs/law/copyright/faq/part2/)

This is the interesting question. So you mean that we should allow
multiple licenses in "official Squeak core"?

Wouldn't this create a big messy pile of licenses that possibly
conflict? I mean, who am I/you to say that MIT/BSD doesn't conflict with
Squeak-L? I agree - it looks like they don't but hey... :-)

> I'm not saying that, therefore, this code should be willy-nilly included
> into Squeak. Of course, it is preferable to go to the author, explain (a
> Swiki page might be in order) this whole thing here and discuss the
> issue of dual licensing; however, *iff* the author refuses to do so and
> *iff* the code is deemed important enough, I would vote in favor of
> nevertheless including the stuff.

And then nothing is stopping this scenario from happening. I am not sure
I like the potential outcome.

> Short summary: please keep contributing, Stef :-)

Definitely. There is no reason whatsoever to stop contributing - Squeak
is AFACT on pretty sound ground licensewise. We just want to make it
better and simpler! :-)

regards, Göran