Sublicensing

Andreas Raab andreas.raab at gmx.de
Tue Aug 19 21:27:49 UTC 2003


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 are just trying to get this to sound "silly" of me.

Really not. I simply didn't get your line of thought.

> 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.

[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]

> 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
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
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).

> 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.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list