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
|