ask for APSL? for real this time?

Andrew C. Greenberg werdna at mucow.com
Sat Jan 10 00:33:25 UTC 2004


On Jan 9, 2004, at 5:04 PM, Doug Way wrote:

> However, Goran was saying that we should encourage "dual licensing" of 
> new (non-derivative) additions to the Squeak release, which is an 
> entirely different thing.  For example, someone could write a new web 
> browser from scratch and dual license it under Squeak-L and MIT (which 
> is the only recommended dual license), so that someone using the 
> browser could pick either license.  This means that if we decide to 
> incorporate this new browser into the Squeak image/release, we can 
> treat it as being licensed under Squeak-L, so that the *entire* 
> image/release is still licensed under Squeak-L, avoiding the problem 
> above.  So in other words, with "dual licensing of new packages" we 
> can avoid the problem of a "mulitply-licensed Squeak release".

With all due respect, we OO coders who have absolute access to all of 
the source codes in the image will constantly be challenges as to any 
similarities between allegedly clean code and existing code.  Look at 
the SCO mess for examples.  The only credible way to have a defense in 
the face of substantial similarity of code when you have clear access 
to existing code is to have ACTUAL EVIDENCE OF NON-DERIVATION.

I am not kidding.  You have to be prepared to prove the negative, 
albeit only by a preponderance of the evidence.   You will have to do 
so before a jury of idiots who won't have a clue, in the face of 
competing experts who are paid for saying whatever they are going to 
say.

In short, you need documentation of a clean room.  NONE OF US DO THAT 
-- EVER.  Even if we do write entirely from scratch, the documentation 
is so outlandish that we wouldn't keep it.  Even so, we all know the 
sources of the system pretty much cold, and thus, would be debarred 
from participating as clean-room coders.

Like it or not, that is the case, and that is the law under which we 
work.  If a dispute should ever arise, proof of access (a FEATURE of 
Squeak) plus similarity is sufficient for the plaintiff to win.  In 
short, there is no such thing as "clean code" in practice.  Compound 
that with the possibility that some of our lesser lights (all partisans 
to this thread excluded, of course) will probably cut-and-paste the 
occasional code, deciding for themselves that they have captured only 
idomatic code not subject to protection or made fair use, and then 
there will be actual derivation.

There is no practical or safe way for the Guides to police this.  None. 
  Even if you had full-time pro-bono counsel, you could not perform all 
the analysis with any degree of confidence, and competent counsel would 
have to commonly give equivocal answers.

> p.s. We (the Guides) did decide to allow MIT-only licensed code to be 
> part of the base Squeak release, if there are no alternatives.  This 
> was for the SmaCC compiler which is licensed only under MIT, and has 
> been added to 3.7alpha (and tracked via SqueakMap).  So we have 
> conciously broken the rule for avoiding a "multiply-licensed Squeak 
> release" to some extent, but this will likely be the only other 
> license allowed in the release.

Once again, there is still time to stop and save the project.  I 
commend that to you.  In the long haul, it WILL kill Squeak or make it 
impossible for us to improve the present licensing issues.  In the old 
days when I advised SqC regularly on this, I frequently negotiated 
appropriate licensing concessions with most such projects.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2361 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040109/bb3b44f7/smime.bin


More information about the Squeak-dev mailing list