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

[David Holmes]

Dalibor,

Thanks for the very detailed response. You raise some very interesting
points. Sun seems to be pushing this "no taint" aspect of the JRL to
encourage more people to contribute to Mustang development:

http://java.sun.com/developer/technicalArticles/J2SE/peabody/

"And for developers that ask, "Does looking at source code under the JRL
taint me?", the answer is "No!" See the JRL FAQ #18 for more details."

Of course that author may be relying on the FAQ being correct.

Cheers,
David

> -----Original Message-----
> From: Dalibor Topic [mailto:address@hidden
> Sent: Thursday, 5 May 2005 2:31 PM
> To: David Holmes
> Cc: classpath
> Subject: Re: Sun's JRL and source: taints or not?
>
>
> 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
>