Following on from yesterday's news post, which looked at whether Oracle could copyright an API or not, a couple of new facts have come to light which puts Oracle in a difficult situation.
Firstly, Judge Alsup has determined that he will decide if APIs are copyrightable, and not the jury.
- Judge Alsup: The copyrightability of the 37 APIs is my call. But I want more briefing on it. I want you to take a firm position. Could you get a patent on structure, sequence, and organization (SSO)? Say "yes" or "no". Also, do you know if the copyright office investigates SSO of copyrighted source code? I would guess not. [Google answers "no", Oracle answers "maybe yes, maybe no"; I'm not sure which question this refers to. Copyright office only gets first 50 lines and final 50 lines of the source for a SW copyright registration, so of course they don't look at SSO.]
- Judge Alsup: OK, what about derivative works? Does the plaintiff have to prove that the source work was actually used? What if it was accidental overlap?
- Oracle: Proof requires access, plus substantial similarity.
- Google: Unauthorized work has to include copyrightable material.
- Judge Alsup: When Google did their clean room implementation, did they have access to the English language comments [in Java source]?
- Google: Yes, they had the English language prose descriptions of the APIs.
- Judge Alsup: Does that make it a derivative work?
- Google: No, the fully-qualified names are the organization.
Judge Alsup. I have to decide on copyrightability, not the jury. You don't have to do exact copies, e.g., you could use science.sqrt() as your method rather than math.sqrt()- Google: It wouldn't work; existing code wouldn't find it.
The second interesting observation is that if APIs are copyrightable, it's possible that the entire Java API library is under the GPL. This is based on the observation that the work as a whole restriction in the GPL may well taint both the Java language and the Java APIs if such are deemed to be copyrightable. Any generated JavaDocs from the GPL source would themselves be considered as copyright under the GPL, and if accepted by the court could result in the Java language being deemed as under the GPL.
The final egg on Oracle's legal face is the "smoking gun" that is the copied 'rangeCheck' function in the TimSort API, mentioned by InfoQ's earlier coverage. In this statement, Joshua Bloch agreed that he had written code for Sun whilst he was there:
Bloch was specifically asked whether the 9 lines of "range check" code that he wrote whilst he worked at Sun, was used for Android. "I don't recall," Bloch said. Jacobs showed code for Timsort.java (Android) and Arrays.java (Java), both of which included "range check". Bloch agreed they were almost the same, and admitted that he was aware that Sun copyrighted code during his work there.
Unfortunately, Oracle legal didn't investigate far enough in this matter. Whilst Joshua Bloch was indeed the author of these lines of code, it is a matter of public record that not only did Joshua write it whilst he was at Google (and therefore, that Google own the copyright and can relicense as necessary) but that through the goodwill of the Java community was donated to Sun:
A new merge sort algorithm with significantly better performance, adapted from Python’s "TimSort" by Josh Bloch.
From the JDK mailing list in June 2009, when Josh Bloch was at Google:
Google would like to contribute a new implementation for sorting of Object arrays, which has much better performance for input that is already partially sorted, based on Tim Peter's sort used in Python.
This sort is already being used in the java.util. that comes with Android.
Written by Josh Bloch.
In fact, the header for the TimSort file clearly states that google is the copyright holder of that file:
1 /*
2 * Copyright 2009 Google Inc. All Rights Reserved.
3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
So now Oracle are attempting to claim that the file, which clearly has Google copyright notices on it, looks similar to the file which pre-existed in Android prior to Google's donation of that file to Sun.
Finally, Oracle appear to have published evidence on page 32 of their 1596388 email which links to Tim Bray, then at Sun, who approves of independent forks:
The FAQs argue that the risk of forking under the GPL is low; the Free Software and OSS communities don't want to; and given the massive installed base of compatible Java, nobody seems likely to try a repeat of the Microsoft shenanigans that we went to court over.
But I think there’ll be lots of forks, and I approve. I suspect that basement hackers and university CompSci departments and other unexpected parties will take the Java source, hack groovy improvements into it, compile it, and want to give it to the world. They’ll discover that getting their creation blessed as "Java" requires running the TCK/trademark gauntlet, which isn’t groovy at all. So they’ll think of a clever name for it and publish anyhow.
Which is terrific. I see no downside, and I see huge upside in that the Java mainstream can watch this kind of stuff and (because of the GPL) adopt it if it’s good, and make things better for everybody.
Remember: However many forks there are, it ain't Java unless it’s called "Java" or has the coffee-cup on it. If it has the name and cup, it is Java and it's compatible. And Sun will absolutely enforce that in court if we have to. We have in the past and we will again.
Given that Google couldn't agree on a license to run the Java TCK, they went with the alternative which was to create a fork which wasn't called Java and didn't claim to be compatible.
The only break which Oracle has had is the USPTO's re-approval of a patent 5966702.