links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
(obsolete) The problem of derivability
Last updated at 9:31 pm UTC on 22 March 2017
(obsolete) Licensing Discussion in 2004 Very obsolete; the Squeak licensing 'issue' was solved and Squeak is not properly accepted as open source and is a member project of the Software Freedom Conservancy


From: goran krampe Sent: Friday, January 09, 2004 11:30 AM
[Addressing Andrew,]... I would like to quote one of your earlier posts in the matter:

"I believe that we could survive with a communal understanding to release all of our code under Squeak-L, or a more liberal license, dual licensed with Squeak-L understanding that it gets viraled into Squeak-L when thrust into the image."
I can only assume that you don't feel the same today then.

... I would seriously hope that if I write an app in Squeak without touching the existing classes - just using them, then that app is clearly according to Squeak-L not a derived work of Squeak itself. If that is not so then PLEASE tell us, because I assume many of us would like to know that. [Andrew responded to this question latter. His answer: “It is not necessarily so. You have been told.”]

What constitutes derived code

From: Andrew C. Greenberg Sent: Friday, January 09, 2004 7:33 PM
[Responding to Doug attempt to reconcile the two views]... 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 idiomatic 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. . . .

Clarification on Derivability

Answers From: Andrew C. Greenberg Sent: Sunday, January 11, 2004 8:50 AM
Questions From: Lothar

Question: Goran Krampe quoted:
"Portions of Squeak are:
Copyright (c) 1996 Apple Computer, Inc.
Copyright (c) 1997-2001 Walt Disney Company, and/or
Copyrighted works of other contributors.
All rights reserved."
Which leads me to a lot of questions: Which part of the code belongs to Apple, which part belongs to Disney, which part belongs to which other contributors?
Answer: Under work made for hire doctrine, virtually everything developed by SqC, at least, during their tenure at Apple belongs to Apple. Virtually everything developed by SqC, at least, during their tenure at Disney belongs to Disney. (Same with Xerox by the way).

Question: Is there a reliable record?
Answer: The best we have are the two and three-letter initials in the change set and the recollections of the indiividuals – happily, Squeak itself makes an excellent record of deltas, embodied in the source files and changes.

Question: What would be the granularity of dividing the code into different ownership: packages? class hierarchies? Individual subclasses? changesets? Individual methods? Is Squeak-L applicable and valid in all cases?
Answer: Generally, all of those, and not only individual methods – but also lines of code within them.

Question: Which conditions have to be met to make self-developed code be (demonstrably)non-derivative?
Answer: Generally, it is common sense: they not be derived at all from the earlier code. Problem is, the burden is on the Defendant to prove non-derivation once a plaintiff shows mere access plus similarity.

Question: What if an author implements new code by modeling it after existent code, for example a Foo Browser (with Foo=application objects) modeled after one of the existing browsers?
Answer: You begin to understand the problem.

Question: Can she still claim it to be her work? Would it be a possible violation of Squeak-L (not protective of Apple rights) if she released her work under MIT only or even dual-licensed it under Squeak-L and MIT? Are there similar implications if I subclass one of my classes from an existing class and override some of the methods with roughly similar code?
Answer: None of these questions can be legally answered in the abstract – the devil is in the details.