"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Hi Göran,
> 
> > Phew. I thought I was being very clear. I have said that I don't
> > think it is a good idea to get a proliferation of licenses within 
> > what I like to call "Squeak".
> 
> It didn't come across that clearly. So if I understand you correctly, then
> your problem is basically the mere existence of any additional clauses,
> disclaimers, restrictions etc. Is this basically correct?

You make it sound very harmless by using words like "mere existence".
Additional clauses turns it into another license. Period.

So basically, yes, my problem is that we are in fact creating multiple
licenses in "Squeak".
And sure, I agree that the first 3 clauses are more or less harmless.
The fourth one (GPL) is not though. And it doesn't matter - I am trying
to focus on he general problem here, not IanSqueakL.

> > You are just trying to get this to sound "silly" of me.
> 
> Really not. I simply didn't get your line of thought.

Ok.

> > I stand firm by the fact that by downloading Squeak
> > for Unix I am bound by TWO different licenses depending
> > on what I like to do with it.
> 
> Okay, I see what you are saying (but see below)
> 
> > Ok, then. Just to make things abundantly clear to you. If you 
> > say it is just *fine* to add clauses as long as the new license
> > doesn't break SqueakL then why don't we simply say to every
> > contributor in this community that it doesn't matter what kind
> > of clauses they add to their contributions?
> 
> Well, that's what I tried to answer as the last of your three questions. In
> response to "should we care" my answer was yes, we should. However, in the
> particular case we are talking about I don't see any problem. That doesn't
> mean that I would still say the same if we would be talking about other
> parts of the system or other clauses. This is what I meant when I said that
> we need to consider the specific situation.

Ok, now I am seeing why we talk "beside" one another. (Swedish
expression).

I had the choice between two different venues in getting your attention
to the problem:

1. Start discussing the clauses Ian put in there. And we would get
dragged down in silly definitions that not one of us really knows
anything about, because we are not lawyers. It would be a waste of time.
For example, I can come up with lots of scenarios in which the GPL-stuff
would get weird and unclear. I am not even sure it is SqueakL compliant
(protects Apple yaddayadda).

2. Instead of doing the above focus on the general problem here. The
problem of us introducing multiple licenses in Squeak land.

I chose number 2 using IanSqueakL as an example of the problem. You
thought I was taking number 1.

> [BTW, I think that's the problem that I have in this discussion - your
> arguments are based on generalized reasoning ("two licenses") whereas in the
> very situation we are talking about I just cannot see why we should rule out
> clauses like these once and for all; in fact I can see various reasons why
> someone would want to add similar clauses and since most of them wouldn't
> hurt Squeak as a platform in any way I just don't share your concerns here]

You are basically saying that you want us to loosen up the "Only
SqueakL" policy.
I don't like that, it would create an explosion of silly little licenses
that no lawyer has looked at. And we can kiss the "usable for business"
goodbye. Just as Andreas has explained.

What I *do* think on the other hand is that we may need to come up with
one or two SqueakL compatible licenses that people could use when
contributing. It would probably solve the SmaCC case for example.

> > Up til now we have been very clear that we only let SqueakL
> > stuff into the base image. Then we should just dump that idea.
> > Perhaps the official "addon" packages can even be whichever
> > license people like! As long as they are additional code built
> > on top they don't need to be under SqueakL, right?
> 
> Let's try to be not too polemic here. If the Squeak community would _want_
> this, and if the license involved were compatible with SqueakL the above
> would certainly be possible. Whether we _should_ do this is an entirely
> different matter and I have said nothing towards that end (and, no, by and

I was obviously mistaking your arguments then, good.

> large we should not do this but I can think of situations where we may
> consider things in a slightly less strict manner - one of the things that

I don't like "slightly less strict". I like "strict as hell". But I do
want to offer an alternative to SqueakL. :-)

> comes to my mind here is SmaCC where the authors said they don't feel
> covered well enough by SqueakL; I could think about an excemption from the
> rule which adds an additional clause that specifically addresses the authors
> worries).

And how many of these little excemptions would it take to create a Big
Mess?
No, no excemptions. Instead we should IMHO come up with one (or possible
two) alternative licenses for contributors to pick from. I need to read
Daniel's latest thoughts but I am guessing he is leaning towards this
too.

> > You don't see any problem whatsoever with contributors 
> > adding clauses. I do.
> 
> I hope I have made it clear that when I said "I don't see any problems" I
> was talking about this specific situation and not about a card blanche for
> adding whatever clauses people come up with.

Right. Good.

> Cheers,
>   - Andreas

Cheers, Göran

PS. Can Alan or you please clarify the ownership question of Disney work
that keeps popping up?