This is the second of three consecutive posts on information gleaned from last night's filings in Oracle v. Google. I previously blogged about Sun's proposal to create a Red Hat-style Android distribution with open source Java.
While patents are the most important part of Oracle's lawsuit against Google, the copyright infringement part shouldn't be underestimated. Google is currently trying to get rid of it on summary judgment, but Oracle defends its related claims.
Judge Alsup denied the filing of various interesting documents under seal, so they entered the public record last night. Also, documents that were heavily-redacted are now much less redacted or even unredacted.
One of Oracle's allegations of direct copying of code from the Java codebase into Android is a function that is in the Arrays class of Java and resurfaced in the Android TimSort class. The following image (click to enlarge) shows a line-by-line comparison of the two code segments -- it's fair to say they're simply identical:
Google said (in its motion for summary judgment on the copyright infringement claims) that "[t]hose nine lines (which are the same in both of the Android files) implement a mundane utility function". So rather than denying that there was copying in play, Google argues that it should be allowed to copy such small amounts of code.
But in connection with other infringement allegations, Google claimed (in its reply to Oracle's amended complaint last yar) that there was "Third Party Liability":
"Any use in the Android Platform of any protected elements of the works that are the subject of the Asserted Copyrights was made by third parties without the knowledge of Google, and Google is not liable for such use."
Against that background, it's quite interesting to see that the copied code segment shown above was created by a Google engineer -- not a third party -- and the said engineer (Joshua Bloch, who previously worked for Sun and whose title at Google used to be, or still is, Chief Java Architect) even admitted in a deposition that he likely had access to the original Sun code when he wrote that code segment:
"Q. BY MR. JACOBS: Do you have a recollection of accessing Sun code while you were working on TimSort?
A. I don't have a recollection, but I'm perfectly willing to believe that I did. You know, I think the similarity of the signature, the fact that, you know, the three arguments are in the same order and have the same name, you know, is a strong indication that it is likely that I did."
Asked about the motivation for so much similarity between the original code and his code, he testified:
"[...] the only functionality that it shares is this little function here, and it is very much in the interest of the users of the new sort that it behave exactly like the old sort. You want it to throw exactly the same exception. You want it to actually emit the same prose. You want that text to be the same.
So, you know, it's the one where it makes sense to [have similar signatures]."
And in an earlier part of the deposition, he talked about how he wrote the source file at issue, TimSort:
Q. And you write to Steve: "PS, I am currently working on a drop-in replacement for Harmony's sort function, which has demonstrated a huge up to 20X performance improvements on G1 hardware. This will be my first contribution to Android."
Do you see that?
A. I do.
Q. What is the -- what's the name of that drop-in replacement?
A. TimSort.
Q. And what was the project that you were doing that led to your developing this TimSort drop-in replacement?
A. I undertook it personally a couple years earlier after a conversation with Guido van Rossum. TimSort is Python's system sort. He told me about it. He said it's really fast. I said, oh, wow, I wonder if we can make it work in the Java programming language and contribute it to all the platforms.
Q. And so when you say you undertook it personally, in what way did it fit into your job duties?
A. My job duties are moderately flexible, and if I see something that, you know, I think could be beneficial to Google and to the broader Java ecosystem, and my manager doesn't object, I do it.
So much for third-party liability.
Also, another part of the deposition clarifies that this wasn't just Python code that Oracle obtained from a different original right holder:
Q. The RangeCheck function that we're looking at on page Google 551599 did not come from Tim Peters' list sort for Python; correct?
A. C does not have exceptions. So it most certainly did not.
Here's another interesting excerpt from his deposition. Look how he tries to avoid admitting that he's still Google's Chief Java Architect:
Q. And so what is your -- you are still employed by Google as of today?
A. I am.
Q. And what titles do you have at Google?
A. I am a -- I believe they call it senior staff engineer. I don't -- I don't -- or senior staff software engineer, and I use the courtesy title of chief Java architect occasionally.
Q. Then you continue to serve as Google's representative at the [Java Community Process]; correct?
A. Yes.
Q. And then -- and you have a role at the Open Source Programs Office up through today; is that correct?
A. Yes.
Q. And at some point you were a quote, member, unquote of the Android team?
A. That is correct.
Google engineer admits: API design is a creative activity
Another deposition is interesting with a view to the debate over the copyrightability of APIs. If an API is creative expression, that's a strong argument in favor of copyright protection. Here's what Bob Lee, a Google engineer who developed among other things the award-winning Guice framework, said about this:
Q. Would you say that designing APIs is a creative activity?
[objection to form, by Google lawyer]
THE WITNESS: Yes, absolutely.
According to a now-unredacted part of one of its pleadings, Oracle also elicited a telling statement on APIs from Joshua Bloch: "[I]f someone else were to take this prose and publish it for profit, Sun would probably be upset, and with good reason."
Obviously it's not up to one or two programmers to decide whether APIs are creative. But these statements are definitely useful to Oracle as it claims copyright protection for its Java APIs.
News on the "test files" controversy
The new filings also provide some interesting information on the question of whether certain Java classes that were apparently decompiled and then incorporated into the Android codebase were just test files, and what it would mean legally if they were.
Back in January I published seven such files and then rebutted claims that I had overstated their significance and showed that some (but not all) source availability packages of Android device makers included those files at the time.
Oracle pointed out (which was previously known) that "[t]hese files were not contained in the 'test' area on Oracle's directory" and says that even if they may only have been used as test files by Google, "test files are still valuable". And here's a previously-redacted statement about the commercial value of test files:
"Google paid a software engineering firm $900,000 to develop a software test suite for the Java core libraries."
Noser is the name of the firm that performed that work and possibly some other work for Google. There might be some third-party liability in this context, but even then Google would be responsible for distributing infringing code, even if Google could try to recover the related costs from a third party if there's a contractual basis for that. And Joshua Bloch's testimony shows that Google can't simply attribute all of those infringement issues to unnamed others.
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn:
