Yiha!

Here we go again - nothing like discussing licenses over a fresh cup of
morning coffee. ;-) (not)

Andreas wrote:
> I don't think so. I know that various people are already quite concerned
> about changes to the current license and in fact I have got an inquiry by
> someone who is quite likely to feed back into the community if it is "safe"
> to stick to 3.4 in order to prevent any future licensing issues.

This I believe is a reference to the community testing the waters for
moving Squeak-L over to be more MITish. Given that - I don't really
understand the concern. MIT is more forgiving than Squeak-L. Is there
anything in Squeak-L that "someone" wants to keep?

Perhaps this wasn't a reference to changing Squeak-L. ;-)

Later Andreas wrote:
> Simple - the rationale is to have only a single license you have to worry
> about. If it's "free" then it should be really trivial for the authors to
> tell us that we can use it under Squeak-L, right?

Exactly. One minor problem though is that people don't generally know
what it means to put something "under Squeak-L". Actually, I don't
either. I mean, could I end up in trouble for doing that? Could Apple
sue me? ;-) In this particular case (SmaCC) I think this is the problem.
John wants to know what it *means*.

Frankly (reading on a bit) it would be great if Andrew could carve up a
modified Squeak-L template which John could use - and of course everyone
else too. IIUC we can take Squeak-L, rip out the pieces about fonts etc,
change "Apple" into "<your name here>" and perhaps that would be enough.
Andrew? How much would you charge us for that service? :-)

Andrew wrote:
> Be careful about the suggestion that we can survive well with a 
> Squeak-L main distro and various distributions under other licenses.

I don't think this was what I was envisioning. I didn't see distros
having a license of its own - if it includes packages under different
licenses then it is like Debian. Debian doesn't have a license of its
own -. its just a collection of software under a whole bunch of
licenses.

I think the following pillars are important for the discussion:

1. SM should allow packages under different licenses. Right?
2. Distros will be practically possible with SM1.1 using load scripts.

Obviously the "load script maker" will need to take care what licenses
the included packages are under - at least as a service to the users of
the load script. A load script is just an automated way of installing
packages from SM. It is not a distributed image. So given this we
already have the problem - people can already install packages using a
single click from SM and if they don't look at the license they *can
already* shoot themselves in the foot. So I can't see how the upcoming
load scripts will change anything in this regard.

In fact, if you are using SM today you can run this code to find out a
bit about the licenses you have "installed":

| map |
map _ SMSqueakMap default.
licenseCat _ map categoryWithId: 'e7d7991c-cd28-4b09-8d53-f7cd10d0132f'.
(map installedPackages collect: [:p |
	p categories detect: [:cat | cat parent == licenseCat ]]) asSet

Do a "print it" on it. Note: if a package has multiple license
categories the code above only picks the first. Whatever. Btw, the
snippet above is under DWTFYL-license. ;-)

Cees wrote:
> What is the
> rationale for mandating the Squeak License here? I have given up
> believing that this project will ever see the day of light under a
> different license than SqueakL

Well, I agree that I don't either believe it will happen. Unfortunately.
So we could give up the rule - but I want us to do that *fully aware* of
what it means. And also - in that case - with a new rule in its place.

And later:
> Two final arguments:
> 1. Rules are there to be broken;
> 2. I think SmaCC and RB are useful enough to warrant study and rulebreaking.

Again, I don't want to break the rule. That is a slippery slope. I would
rather *change* the rule.

Daniel proposed that we instead use MIT which can expressly be
sublicensed. Hmmm, interesting thought. Would like to hear Andrews view
on that.

Andreas also wrote this:
> > BTW, what is meant by publishing something under both the MIT 
> > license and the Squeak license? How does that work? Does a user
> > pick a license that they like, or are they somehow combined?
> > If they are combined, what about conflicting items?
>
> That's exactly the reason Andrew said that cross-licensing in this way is a
> recipe for desaster. If you have conflicting items you really can't combine
> the two. It's fine as long people get to "choose and pick" because there we
> could (for example) choose the "Squeak-L version" for inclusion in
> Base-Squeak. But mixing them I think is a no-no.

No, no, no, stop - you are confusing each other! (I am not sure Andreas
understood the question) We aren't talking about mixing - we are talking
about *dual licensing*.
They are *not* combined - the user picks whichever he/she wants to use.
It is simple. One of the most known case in the OSS world is TrollTech
which offers Qt under either GPL or a proprietary commercial license.
Pick the one you want.

The idea with the dual licensing "MIT + Squeak-L" category on SM is so
that everyone is pleased. This means that the package is offered under
*either* MIT (perfect for most uses like for example porting over to
Dolphin or whatever) or *Squeak-L* (what we want for including into base
Squeak).

To make things "really tight" I guess the package should include a
textfile with the MIT license and a Squeak-L license with proper names
replaced of course. Perhaps we should introduce some form of mechanism
for this - for example, the SAR format could include a special filename
"license.txt" so that they are easily found etc.

Andrew finally wrote some practical advice:
> I believe that we could survive with a communal understanding to 
> release all of our code under Squeak-L, or a more liberal license, dual 
> licensed with Squeak-L understanding that it gets viraled into Squeak-L 
> when thrust into the image.

This is then exactly what we have been doing so far - the rule of
keeping everything in "Squeak official" under Squeak-L. Then I think we
simply need to explore the following two things:

1. How could a Squeak-L license look like that *I* can use? (I asked if
Andrew perhaps could draft us a template above)
2. Can we be satisfied with people using *only* MIT? As Daniel was
thinking.

> Ideally, my view is that we should encourage TPTB to move to a more 
> BSD-style license.

TPTB?

> Truth to tell, I'm not sure it isn't time to simply clean room the 
> Apple code out of Squeak.  I suggest one or two passes at the masters 
> and then to move on.  Can we get a license to rebuild Squeak from the 
> Smalltalk-80 folks at Xerox, or another licensee, or is that crazy 
> naive?

I would say it is crazily naive. :-) Personally I would *definitely* not
hold my breath for the following two things:

1. Squeak-L being changed into something more MITish.
2. All the code currently in Squeak under Squeak-L being reimplemented.


I also saw that Dean Swan wrote:
> I personally have to side with the "Squeak-L only" group.
> I would recommend that if it isn't available under Squeak-L
> that it not be allowed on Squeak Map, and I would encourage
> EVERYONE to avoid using non-Squeak-L code with Squeak.

I wouldn't go this far. SqueakMap is a map of *all* code available for
Squeak. It shouldn't make any policy on licenses IMHO. BUT... it
correctly categorizes the packages so we can easily see what packages
are possible to have in "Squeak official" etc.

So... John? If you have read this far then my proposal to you (and all
of us) is that you go for a dual licensing scheme (MIT + Squeak-L) using
the MIT template (you can get it at opensource.org) and a Squeak-L
template which I hope we can get drafted together here on the list.

regards, Göran