Why the Very Silly Oracle v. Google Trial Actually Matters
From poetry to paintings to hamburgers, Oracle v. Google has been a confusing mess. Thankfully only everything is at stake.
Oracle's Larry Ellison. Image: Oracle
"This case is about an excuse," said Oracle lawyer Peter Bicks in his closing arguments. "I call it the fair use excuse."
We're now waiting for a jury verdict in Oracle v. Google, a $9 billion lawsuit over the use of Oracle source code in the Android smartphone operating system. Attorneys on both sides wrapped up closing arguments on Monday.
The jury is currently in deliberations over whether Android's use of the declaring code, and the structure, sequence, and organization of 37 Java API packages, was fair use.
The precedent that APIs are copyrightable was already set by the Federal Circuit in 2014. But the US Copyright Act doesn't protect purely functional things. It doesn't extend to any "process, system, method of operation." If it seems to you like APIs are so purely functional that they should be covered under that latter doctrine, you're not alone.
For the non-technical, here's a quick, very clumsy explanation of APIs and implementations, taken from the testimony of one-time CEO of Sun Microsystems, Jonathan Schwartz.
An API is like a restaurant menu. An implementation is the food itself. So two restaurants can offer "hamburgers," using the same word for two different dishes. The word "hamburger" lets the customer know approximately what they're getting, it's a useful shorthand that lets them parse menus that across many different restaurants.
Similarly, java.security tells a developer exactly what kind of library they're calling, because it's similar across many different languages. The implementations of java.security in Java Standard Edition (Oracle's proprietary implementation of Java) and in Android (created by Google) are different. But the function is the same.
A screwdriver looks like a screwdriver because it has to. A fair use trial over APIs is as sensible as a fair use trial over screwdriver heads.
Google's use of the same declaring code and the "structure, sequence, and organization" of the Java APIs looks a hell of a lot like Oracle's Java APIs, because it serves the same function. It's hard to make the case that it's transformative fair use, because this case should have never gone to a fair use trial in the first place.
It might not be legal precedent that's at stake, but the final issue in this case—whether or not the use of the APIs are a fair use—is a last-ditch effort to save a common industry practice: writing independent implementations of an existing API. You can think of it as cooking up different hamburgers while still calling them "hamburgers." Or manufacturing different electrical plugs that all fit the same socket. Or creating two different cars that both have steering wheels. (If these examples sound silly to you, they're not mine: they're all examples that Google brought up at trial.)
Anyways, the point is, people do this all the time. But thanks to the Federal Circuit decision, a cloud of uncertainty already hangs over the ongoing work of many developers (and existing reimplementations of APIs). And if Google loses at this stage, the cloud grows even thicker.
Ever since the Federal Circuit handed down its decision, the current state of the law is that APIs are copyrightable, and the only thing that can save Google is a finding of fair use. The thing is, fair use is not a very good fit, for the exact same reasons that the APIs looked too functional to be copyrightable in the first place. A screwdriver looks like a screwdriver because it has to. A fair use trial over APIs is as sensible as a fair use trial over screwdriver heads.
In both opening and closing arguments, Bicks pulled out a literal painting of Java code to illustrate what fair use of the Java APIs would actually look like—stretched canvas on a wooden frame, displaying glowy white text floating against a blue gradient background. The whole thing gave off an aesthetic strongly reminiscent of a Windows 98 screensaver.
Bicks compared Oracle's Java APIs to poetry, to literature, to art, to the Harry Potter series. APIs are highly creative, he said. (Indeed, Google's own witness, Joshua Bloch, said the process of creating APIs was a creative one.) Then Bicks performed a sleight of hand—while the Java APIs are creative, the Android use of the APIs is nothing but code, nothing like the Fair Use Painting above.
Aside from being comically hideous, Oracle's Fair Use Painting offers a troubling insight into the world that Oracle wants.
Nobody wants a goddamn Fair Use Painting hanging in their home. Just look at it. The only time people are going to "remix" an API is when they actually use it. An API is meaningless outside of code. Oracle's interpretation of fair use in software creates a kind of copyrightable work that is for all intents and purposes, immune to fair use.
Oracle's depiction of the Java APIs and Android's use of the Java APIs exploits the biggest problem for Google in this case: fair use is an extremely awkward argument because APIs are highly functional. But Google doesn't have a choice at this point. Fair use is the only argument it has left. To make things worse, what Android did with the Java APIs is dreadfully common in the technology industry, meaning there's a lot more at stake than just $9 billion.
If it's illegal to write clean room implementations of APIs, then no one has clean hands. The now-shelved open source project Apache Harmony, like Android, reimplemented Java SE, and tech giant IBM contributed code to that project. Oracle itself built its business off a proprietary implementation of SQL, which was created by IBM.
The proposition "Reimplementations of APIs are infringements" creates a recursive rabbit hole of liability that spans across the industry. Even the very 37 Java APIs at issue in this trial contain reimplementations of other APIs. Google witness Joshua Bloch—who, while at Sun Microsystems, wrote many of the Java APIs—testified that specific Java APIs are reimplementations of other APIs from Perl 5 and the C programming language.
In a talk that Bloch gave in 2014, he listed 12 other reimplementations, spanning from 1964 to 2009:
In his closing arguments, Google lawyer Robert Van Nest reiterated the testimony of Joshua Bloch. "I've been in the profession for a long time," said Bloch. "...We've always felt free to re-implement each other's APIs."
Where Oracle appealed to the jurors' "common sense" about "theft" and "stealing," Google appealed to the testimony of their techie witnesses, witnesses who insisted that they had always done things this way, that they had believed APIs are not copyrightable.
When Google co-founder Larry Page was called to the stand by Oracle, Bicks had a difficult time pinning him down. Every time Bicks asked about Google's taking of the code, he managed to insert a comment about the copyrightability of APIs. "I don't agree we copied code," he told Bicks.
"Well, we're in this courtroom, and we've agreed 11,000 lines of code were copied," Bicks began to say—a legally correct statement, backed up by the Federal Circuit.
Page interrupted. "For me, code is not declaring code. There's a widespread industry practice of using APIs."
Oracle has muddied the waters by introducing into evidence various emails and deposition tapes where Google employees and others say that the APIs are copyrightable. To Oracle's frustration, these statements have been largely recanted by the speakers, who are clearly pulling for Google in this fight. And to be fair, these statements—often reminiscent of Hacker News comment threads—are from technical workers and executives, not lawyers, and often prefaced with warnings like "HUGE CAVEAT: I am not a lawyer."
It's likely that just as many internal emails were sent about how the APIs aren't copyrightable, and that Google chose not to produce these in discovery, because actual lawyers got looped into those discussions. But all this is beside the point. What a Google engineer thought about the copyright status of APIs is about as relevant as a Sun Microsystems FAQ that said the "Java ecosystem can support multiple implementations."
None of these things have anything to do with fair use. Thanks to the appellate decision, it's a given that copyrightable code was copied. The only question is whether it was a fair use. But because fair use is such a poor fit, neither Oracle nor Google have much to go on.
Oracle can point to their fair use painting, to their bizarre analogy to the Harry Potter series, and to the massive profits that Google made off Android. And Google can point to what a tiny fraction the APIs are with respect to Android—less than half of one percent, situated inside a full stack with an entirely different virtual machine.
We don't yet know what the jury makes of it all. For what it's worth, they're a fairly conscientious group of people who arrived on time (or earlier) every day at 7:45 AM, filling out notepad after notepad with their notes on Java, Android, OpenJDK, the GPL. On Tuesday, Judge Alsup called them "one of the best juries in the history of this courthouse."
This was after the jury's first query to the court regarded how to open the digital exhibits that the attorneys had given to them—apparently there were too many nesting folders and they couldn't figure out how to open up the source code. For better or for worse, it's all in their hands now. Now we wait to see whether they think fair use is just an excuse.
Correction 5/26/2016: This story initially stated that Oracle attorney Annette Hurst questioned Google's Larry Page; it was attorney Peter Bicks. This story also referred to Bicks as "Benjamin Bicks," which is a nice enough name, but not the Bicks at hand.