On Tue, 2003-03-25 at 21:06, Andrew C. Greenberg wrote:
> Please don't do this folks.  We have enough licensing issues already.  
> Promiscuously cross-licensing like this could kill either SM or Squeak, 
> or both.
> 
Or neither. Most likely outcome, I believe.

SqueakL is of course just as much a farce as anything else. Ever since I
saw exactly the same code comments deep in the bellows of VW and Squeak
I wondered whether a) Apple has duly documented what code licensed from
<insert ancient name of Smalltalk-80 company here> has flown into
Squeak, how comes they could 'open source' that stuff, and b) who is
going to protect you/us if Cincom decides that 'their' code is in Squeak
and it shouldn't be there. 

Let's go back to this 'SqueakL only' rule. Now, I do agree that
inserting GPL'ed code is tricky, but I don't think I was talking about
that. I'm talking about free/unlicensed/pd/whatever code (Andrew - could
you be so kind and answer my question on the RB code?). 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 (the deafening silence in response to my
concrete offer to setup a foundation and do something about it tells me
enough about how much people care - enough to debate it, not enough to
act), so that (and the practicalities of hunting *every* contributor
down and get them to sign on a new license) is not a good reason IMHO.

SmaCC and the RB are extremely useful bits (well, bits...) of code. They
are clearly meant to be 'includable' in Squeak and similar systems.
There's nothing you say you can't, and I don't see any real issues with
doing so. The stuff is released, there's a minor string attached to
SmaCC ('please make available any major parsers you write with it') but
that doesn't hurt us a bit and will not hurt anyone using SmaCC inside
Squeak (as opposed to SmaCC to write a cool commercial, err, DSSSL
processor inside Squeak). 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030325/87e2c8c3/attachment.pgp