Re: Sun's JRL and source: taints or not?

[Dalibor Topic]

David Holmes wrote:
> According to Sun, accepting their Java research license
> (http://java.net/jrl.html) and seeing their source code does not "taint" you
> from working on other open-source implementations of the JDK specifications.
>
> -----
> 18. Does the JRL prevent you from being able to create an independent
> implementation of J2SE?
>
> The JRL is not a tainting license, and includes an express "residual
> knowledge" clause. Under the JRL, merely looking at Sun's code does not
> prevent you from being able to create your own independent implementation of
> J2SE, and in any event, you can terminate the JRL at any time for any
> reason. So, yes, you can look at Sun source code and then later on go and
> work on an open-source J2SE implementation.
> ----
>
> The relevant license clause is:
>
> B.  Residual Rights.  You may use any information in
> intangible form that you remember after accessing the
> Technology, except when such use violates Sun's copyrights
> or patent rights.
>
> What's the view on this from the Classpath/FSF/GNU side?

Hi David,

Speaking just for myself, not being a legal scholar and all that, I've 
had another look at what the JRL says, and I think Sun's JRL FAQ is a 
bit overly enthousisatic about the license text. Specifically regarding 
'Residual Rights' FAQ entry here a problem in the JRL that I see in a 
cursory glance:

Modifications(b) claims as modifications "new source or object code 
implementing any portion of the Technology.".

Technology is in particular defined as "the source code, object code and
specifications of the technology made available by Sun pursuant to this 
License."

Since specifications are according to the JRL parts of the licensed 
'Technology', and Sun according to Modifications(b) claims your 
independent, new files implementing any portion of the specifications as 
Modifications of their JRLd code, they seem to claim rights on those new 
files, as long as they are implementing the specs for J2SE.

That puts someone who actually accepts the JRL, for whatever reason, 
into the awkward position, that, while the Residual Rights clause gives 
her the right to his memory, Sun on the other hand claims her new files 
implementing any part of the *specs* as 'Modifications'. Given that 
'Modifications' may not be published under an open source license 
according to III.A.3, the clause "except when such use violates Sun's 
copyrights" in the Residual Rights section turns it into a blocker, for 
someone who wants to both create an open source implementation *and* 
distribute it under an open source license.

As long as Sun says that anything that implements the specs for J2SE, 
without actually being derived from Sun's JRLd code, is nevertheless a 
modification of their work, the FAQ is pretty misleading, in my opinion, 
though it may be factually correct:

Yes, the JRL-bound developer probably can *create* your own independent 
implementation, but she can't distribute it without violating Sun's 
claimed rights, unless she distributes it under the JRL or an 
equivalent, which is very, very far from being open source. Yes, she 
probably can *work* on an open source implementation, but she can't 
distribute the results of her work under an open-source license.

That means the Residual Rights section, while well-meant, is not useful 
in real life. Most people writing open source software also happen to 
like to distribute their own, independant works to other people, under 
open source licenses, even. :)

I believe Sun could, for example, get rid of the Modifications(b) part 
of the JRL to fix that particular problem. There are various other 
problems regarding residual rights, and termination, though, but 
enumerating all of them would go into too many details for this list.

For an analysis of the problems with Residual Rights clauses in 
proprietary software from an attorney, check out Larry Rosen's 'Open 
Source Licensing' book, also available online at 
http://www.rosenlaw.com/oslbook.htm .

In chapter 11, Rosen deals with a nearly identical Residual Rights 
clause from Microsoft's 'Shared Source' initiative (p. 257):

"     You may use any information in intangible form that you re-
      member after accessing the Software. However, this right
      does not grant you a license to any of Microsoft's copyrights
      or patents for anything you might create using such informa-
      tion. (Microsoft Shared Source CLI, C#, and JSCRIPT
      License.)"

p.258 continues to explicitely deal with the case of implementing 
'competing' open source software after looking at 'Shared Source' code:

"If you are a software developer who intends to write software that 
might potentially compete with Microsoft's copyrights or patents, there 
is great risk in looking at Microsoft's source code. Under the copyright 
law in the United States, if Microsoft proves that there is "substantial 
similarity" between your commercial software and theirs, you may be an 
infringer. You may have to prove that you saw and read Microsoft's 
source code but that you relied only on intangibles and only
on your memory when you wrote your own software.

   That's a difficult evidentiary burden. I'm not sure how even
an experienced programmer can walk that fine line. Perhaps the best way 
is simply not to look at Microsoft's source code at all."

I hope that kind of sums it up nicely.

In closing, the JRL, just like the license it has been ripped out from, 
the SCSL, is not exactly a blueprint for a well-written software 
license. But, contrary to the SCSL, the JRL has one thing going for it: 
it is reasonably short, and can be understood without dedicating an army 
of lawyers to it.

One must note that, though, for Sun, the JRL is a major breakthrough, 
and given where they are coming from, i.e. the mind-boggling SCSL, it 
surely must feel that way. So the enthusiasm of some Sun employees for 
the JRL is understandable for me, though I believe that regarding 
Residual Rights, the enthusiasm is unfortunately unfounded.

If Sun wants to have a license that does not taint Free Software runtime 
developers, they could simply ask the Free Software runtime developers 
*i.e. the people right here* for assistance in analysing their residual 
rights clause, and they would certainly receive helpful suggestions.

For all I know, Sun didn't do anything like that. But that doesn't mean 
that Sun can't take the above constructive suggestion, and work to fix 
the JRL to match their FAQ and intent more closely.

cheers,
dalibor topic