"Andreas Raab" <andreas.raab at gmx.de> wrote:
> 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

I disagree. It explicitly mentions ports of the VM etc. And what would a
port be if not the support code?

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

Again, and I am getting somewhat tired to repeat this: I am not talking
about the Right or Wrong of the two licenses involved here. I am talking
about the very fact that we have TWO licenses currently.

So to be correct we need to change www.squeak.org - AFAIK it doesn't say
anything about the Unix VM being under a different license, etc.

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

Ok, now we are getting somewhere. So in fact you think we should have a
different license for the VM ports/support code?

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

I have sofar not seen the distinction "in" Squeak. I don't share your
understanding of Andrews concerns, but it is rather uninteresting since
I don't think he will participate in the discussion.

To me "Squeak" has always meant the image AND the available VM ports.

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

Plugins are a different thing.

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

Ok then. Fair. "Now don't do it again!" :-) (movie reference Life Of
Brian)

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

I am fully aware of this etc and agree.

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

I can see your point here for sure. And I also was aware of this
mechanism, it actually works much in the same way in other licenses with
"put stuff back into the community-machanisms".

But... :-) I am not talking about the merits of SqueakL etc. I am
talking about the fact that we have a different license for the Unix VM
port. Thus we have two licenses for "Squeak". See the above questions
and continue from there.

> Cheers,
>   - Andreas

Cheers, Göran