[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dalibor Topic
Subject: Re: Sun's JRL and source: taints or not?
Date: Thu, 05 May 2005 06:30:50 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1

David Holmes wrote:
According to Sun, accepting their Java research license
( 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 .

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

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.

dalibor topic

reply via email to

[Prev in Thread] Current Thread [Next in Thread]