Sublicensing

Andreas Raab andreas.raab at gmx.de
Tue Aug 19 08:48:29 UTC 2003


Hi Göran,

> God damn these license threads can pull you in. ;-)

I know ;-)

> > Yes they are. And you want absolutely no restrictions 
> > whatsoever? Well, that's a statement I have an issue
> > with (see below)
> 
> You implied it was like dual licensing. I replied it is NOT like dual
> licensing. These clauses constitute restrictions and are thus
> alterations to SqueakL. In short it is NOT SqueakL. You now say, "Yes
> they are". Period.

You need to look at the concrete situation you are talking about. Squeak-L
is mostly concerned about the image side and doesn't say anything wrt. VM
support (== C) code. The restrictions are for the most part very reasonable
when it comes to _C_ code. I wouldn't want them when we talk about image
side things but for _C_ code I don't see any problems whatsoever with them.

> I merely point out that it is a *different license*. It is *not*
> SqueakL. And this means we now have *multiple licenses* for Squeak.
> I assume you can agree with me on this. So this brings me to my 
> questions: "Is there a problem with this situation? Can it get worse?
> Should we care?"

And my answers to that are: No. Quite unlikely. Yes, to make sure that there
are no "unreasonable" requests. I also think that a dedicated Squeak
community license should address the issues of hacking the C source
differently from that of hacking the image.

> Andrew Greenberg has repeatedly warned us about what will happen if we
> start mixing licenses in Squeak, now I am doing it too.

My understanding is that Andrews concerns were about mixing licenses _in_
Squeak. As a matter of fact (might be worthwhile to point out in this
context) the original point of making it possible to build VM plugins was
precisely to allow people to add their own plugins to Squeak - under
whatever license they choose as long as it is "by and large" compatible with
SqueakL (which doesn't work with GPL but _would_ work with any proprietary
bit of code).

> > > Anyway, it sure saddens me that Squeak has these issues.
> > 
> > Issues? I don't really see an "issue" here. It's just that 
> > not all people have the "I don't give a damn about what you
> > do with my stuff" attitude. Some people are (believe it or
> > not) even proud of their work and would like others to
> > contribute to the base if they have made use of that base.
> 
> And of course I "believe" that some people are proud of their work.
> Andreas, please don't argue with me like I am a child or 
> simply stupid.

As a matter of fact this part wasn't directly addressed to you - you merely
gave me a great excuse to make a point which I wanted to make in this
discussion for a long time and I wanted it to make it very easily
understood. It is that the way Squeak-L "restricts" modifications is a very
healthy and well-chosen tradeoff between the extremes of something like GPL
(political, purely on the "you must every last scrap available") and
something like MIT (hell, I don't absolutely give a damn) licenses. And I
think you'll find that there are a few people who will not uniquely agree on
changing it to an IDGASJDSM license.

In my experience, current Squeak-L turns out to work in favour of those
people who prefer sharing, which I find a very good thing. Given that we
know we don't want to be political about it, there is really no way to
enforce sharing so that by the end of the day it comes down to judgement.
Now, in those one or two cases where I have been involved in discussions
whether certain parts of the work I have done would be released to the
public or not, it turns out that _without_ these restrictions we would have
had a very hard time to argue in favour of sharing. With the existence of
that restriction you can in fact go to your manager and say "you know, by
the license we are using we really ought to share this". Whether people
respond to this or not is a different question but it is really, really
helpful if you are able to, for example, make a distinction between "base
level" and "app level" things your company is doing with Squeak if you want
to share the things you were doing.

Put differently, without being able to argue along the lines of SqueakLs
restrictions it is very likely that some of the things we did at Disney
(which for example includes Balloon, the FFI, and likely some other parts)
would have never made it out of Disney. I have come to value that
restriction quite a bit. It is not political (as it is possible to
distinguish between base and app level stuff) but if you want to share
things you've done it gives you something that the "decision makers" can
understand.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list