Cees made a good summary of the issues here. Assuming the goals of -
1. Interpreting Squeaks license should not get more complicated over
time.
2. We should not be limiting new code using (exclusively) a bad license.
3. We want new code to have an a-political, free sharing license, that's
DFSG/OSI compatible (if you are curious why some of us care about this
point, see below).

A good policy would be -
1. Find a few DFSG/OSI compliant "non political" licenses. MIT is very
good. BSD is equivalent except for a nit picking policy saying "if you
use this written by me, you can't advertise your product as "based on
software by Berkeley"". So MIT Really Sounds Simple.
2. Make it policy that anything submitted as an ENH is implicitly
licensed as MIT, unless otherwise stated by the author. Stating a
limiting license means the contribution is not eligable to enter the
update stream.
3. Make it policy that anything converted into an update is relicensed
under SqueakL.
4. Allow software with any license into SM, but only DFSG compliant
software would be allowed into any Offical distributions. Until Squeak
base is free, share-alike (aka viral, such as GPL) licenses, would also
be excluded from Official releases (since they mean we can't
redistribute images with the whole distribution loaded).

This means that 
1. The image remains legally simple.
2. If we ever get a free-clean core, we can re-apply all the changes in
SQFIXES since the date of adoption of the policy without fear.
3. The Official distributions are DFSG compliant, except for the
Squeak-L core, until we fix it.

Daniel
PS Why is DFSG/OSI a good thing?
1. Freedom
The Debian Free Software Guidelines [1], and the Open Source Initiative
[2] (later derived from it, and therefore very similar), are there to
logically group a set of licenses as being safe to use. By "safe" I mean
that using them gives you certain freedoms, including the freedom to see
the source, the freedom to fix it, the freedom to redistribute your
changes. Which together consitute a pretty good promise that you can
have a community doing shared development without fear.

2. Brand
So falling under that definition is it's own benefit, because it tells
everyone that wants to play, "have no fear". However, in the world of
open source and free software, DFSG and OSI are also easily recognized
brands. This means that you have tens of thousands of people working on
the problem of explaining these brands and what they mean to their
bosses. To use SqueakL based software commercially, you need to convince
whoever is in control to hire a lawyer to study Squeak-L. To use an OSI
license it might be enough to say "Apple is doing it. IBM is doing it.
......", and if not, you can hire lots of lawyers that already know
these terms.

3. Community
There are lots of programmers out there quite willing to work on
software they like, if it's free. Some of them get tired of the usual
stiff languages, and Squeak could give them wonderful relief from
Repetitive Type Definition Stress Injuries. See how many people use
www.Python.org?

Debian is a software distribution for unix-like softare that is itself a
community project. It happens to be packaging the Linux Kernel now, but
it will probably soon package also the BSD and Hurd kernels - it is not,
conceptually, Linux specific. So these are a bunch of people pooling
their resources to give themselves and other people software that's
"safe" to use. So it is a very influential distribution by virtue of
doing "the right thing". This also makes it a base for other projects.
For example, Debian-Jr for kids, or Knoppix which is a boot-from-cd
autoconfigured demonstration of Linux. I think it's pretty obvious that
being part of Debian, and therefore part of these projects, would be a
good thing for Squeak.


[1] http://www.debian.org/social_contract.html
[2] http://www.opensource.org/docs/definition.php

Cees de Groot <cg at cdegroot.com> wrote:
> 
> --Boundary_(ID_rH7xORLe7EcWW/mvkmhemg)
> Content-type: multipart/signed; boundary="=-1OCFLHfx/pZAQpKGRL4g";
>  protocol="application/pgp-signature"; micalg=pgp-sha1
> 
> 
> --=-1OCFLHfx/pZAQpKGRL4g
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> 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?
> >=20
> Squeak's license is irrevocable(*). So there is no risk at all that
> whatever you add to it (under the SqueakL or anything more open) will
> ever be void. As long as we, as a community, don't care about whether
> some nits in the Squeak license makes it 'not Open Source Definition
> compliant', 'not DFSG compliant', or whatever, it is for all purposes
> just as free as any open source package. Which means that you can use
> it, you can add to it, you can build products with it, and you don't
> have to fear(*) that someone will come down on you or the community or
> anyone else to take <whatever> away. That's impossible(*).
> 
> This ugly discussion creeps up *ONLY* for the following purposes:
> - There are members of the community (me included) who would like (for
> various reasons) to see Squeak under an OSD-compliant license.
> - For this to happen, obviously the SqueakL needs to change.
> - In order to make this even remotely feasible, every single contributor
> would need to agree with the license change.
> Obviously, this gets really really hairy if we have a multitude of
> licenses in Squeak...
> 
> 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.
> 
> 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). Obviously, every additional license
> inside Squeak creates a risk of 'contamination', and this is a
> combinatorial explosion you want to avoid.
> 
> So, there are good reasons to try to keep at least the basics ('kernel',
> 'coder', maybe even 'carnival') clean (SqueakL-code only).
> 
> 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.=20
> 
> 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.=20
> 
> Short summary: please keep contributing, Stef :-)
> 
> (*) I'm talking in absolutes here. To satisfy Andrew: nothing is
> absolute in Law. If Apple and/or Disney or whoever feels like it, they
> can sue you for not walking on the right side of the road. So there are
> no absolutes, I'm just making up a model of reality here in order to be
> able to discuss this whole thing without too many subsentences, OK?
> 
> --=-1OCFLHfx/pZAQpKGRL4g
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: This is a digitally signed message part
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQA+gYli8wOTf+CYnosRAoS9AKChLO18qCI7wsWwvzdQQTYQSEgl9ACggsIh
> 4riufj9Dg1BJTlbufWphUnY=
> =BX6L
> -----END PGP SIGNATURE-----
> 
> --=-1OCFLHfx/pZAQpKGRL4g--
> 
> 
> --Boundary_(ID_rH7xORLe7EcWW/mvkmhemg)
> MIME-version: 1.0
> Content-type: text/plain; charset=us-ascii
> Content-transfer-encoding: 7BIT
> 
> 
> 
> --Boundary_(ID_rH7xORLe7EcWW/mvkmhemg)--