On the Rocks with Owen Astrachan: Expert Witness in Google v. Oracle

Written by Sam Carpenter (Duke ’24) and Luiza Wolf (Duke ‘22)

On August 13 2010, Oracle sued Google for copyright and patent infringement. Oracle argued that Google had stolen its code by reimplementing Java’s APIs in Android, which Oracle claimed it held the copyright to. More than a decade later, on April 5th of this year, the Supreme Court ruled in favor of Google, ending years of legal battle between the two tech giants and asserting the fair use rights of software developers across the country. Throughout much of the case, Owen Astrachan, professor of computer science at Duke University, served as an expert witness for Google. We spoke to Professor Astrachan about his time on the case and the implications of the ruling ‒ but first, let’s dive deeper into the case itself.

Android Inc. was founded in 2003, and bought by Google in 2005. Throughout its development, it was crucial that the operating ensured the operating system stayed open-source and developer-friendly, two of its core tenets. As such, Google sought to use Java as the main language for app developers due to its wide usage and interoperability. With this goal in mind, Google approached Sun Microsystems, the company that created Java, to license the language’s libraries. Sun requested a licensing fee that Google was more than willing to pay, but then it requested more: Sun wanted partial control of Android. Google believed this would prevent them from keeping the operating system open-source and Sun believed that, if unsupervised, Google would create a completely new version of Java and compromise the language’s core principles. The companies could not resolve their issues and were unable to reach a deal.

But Google still wanted Java. So, they decided to make a bold move and completely reimplement the language’s libraries from scratch. When a developer used any function from the Java libraries in Android, thanks to Google’s work, they would get the same result as they would from Sun’s standard Java, even though Google’s implementations were extremely different under the hood. By uniquely reimplementing Java’s most valuable APIs, Google was able to make Java the standard language for Android, keeping it easy and familiar for developers, while completely bypassing those who originally created it.

As Astrachan explains, the API that Google reimplemented was a collection of 37 packages, each filled with utility functions for developers to use. For example, Java’s java.langpackage has a function called Math.maxthat returns the maximum value in a list, and another called Math.sin that returns the sine of a number. Google used the function headers of these functions, meaning that they named all of their functions in the exact same way that Java did, but they implemented the functions without looking at Java’s implementation. So, calling java.lang.Math.sinwill calculate the sine of a number whether you’re developing on Android or with an official Java distribution, but the functions don’t calculate sine the same way. Android developers thought that, even though the API implementation was copyrightable, these API headers wouldn’t be. Unfortunately, not everyone felt the same way.

When software giant Oracle bought Sun in April 2009, a lawsuit would follow only sixteen months later. Oracle asked for billions of dollars in compensation on the ground that, by reimplementing Java’s APIs, Google had effectively stolen their intellectual property and violated the copyrights to Java. The case had begun.

TechCrunch

Google countered Oracle’s argument by saying that it took only what was needed for interoperability and, historically, interoperability has been covered by fair use. Interoperability was the promise Java allowed Google to make to developers; a program they wrote in a language they already knew that already ran on their other devices would be guaranteed to run on Android as well. By reimplementing the libraries developers used in their code, Google guaranteed that the tools developers used everywhere else would be present on mobile.

Oracle disagreed that their API wasn’t copyrightable. The interface was designed to be simple, easy to use, and to work everywhere that they allowed it. Designing the API to be easy and useful, Oracle claimed, was incredibly difficult work; the API was so widely used because it was well-made, and Oracle had done the work to make it that way. If Google could have all that work for free, that was stealing their intellectual property. They wanted the API to work everywhere, sure, but they wanted to benefit from it doing so as well.

The case was first argued in California District Court in 2010, which ruled in favor of Google and claimed that APIs are not copyrightable. The case was appealed to a federal court, which reversed the ruling and sent the case back to the district court. In 2016, that district court once again ruled in favor of Google, a verdict which was once again appealed and reversed. Finally, in 2019, the Supreme Court accepted Google’s request for them to examine the case, and the Court ruled in Google’s favor this April.

The Court declined to rule on whether APIs are copyrightable but established that Google’s usage of the API’s function headers was fair use regardless. This dispute was of great interest to the open-source community, not because of the specific conflict but because of the precedent it would set about interoperability. Historically, courts have ruled that using an unoriginal interface for interoperability purposes is covered by fair use. This is why every spreadsheet program can be used in a similar way, for example, and why keyboard manufacturers can all use the QWERTY layout without violating another copyright. Startups often need to make their product work with other larger ones, and up until now, court rulings had sided with them. The ruling is a win for the open-source community as well as developers at large, reestablishing that guaranteeing interoperability is generally protected by law.

While the case was in the second appeal, Google tapped Duke Computer Science Professor of Practice Owen Astrachan as an expert witness. Astrachan has a long history of education, having been at Duke for nearly thirty years where he teaches huge classes of as many as 500 students. He conducts research relating to classroom teaching and has designed two separate AP curriculums for the College Board. When an old student of his who had gone into law reached out to ask him to be an expert witness in the Oracle v. Google case, he accepted, and his expertise quickly became an integral part of Google’s technical argument. We spoke to Professor Astrachan about his time on the case; here are some of the highlights of our conversation.

Q&A

What was your experience like being an expert witness?

Astrachan starts by satiating our curiosities of what it’s like being involved in a huge legal case: sitting quietly in a suit, surrounded by reporters, Google on one side, Oracle on the other. Essentially, just like he expected it would be from TV and movies. He would show up to trial from 8AM — 1PM, then prepare and be grilled by attorneys for 6+ hours afterward, all in the name of speaking to the jury for an hour and a half.

“People with PhDs apparently carry some kind of weight and respect when it comes to judges and juries, so you’re asked to write opinions or explain things that a judge might ask”

Since Google v Oracle in 2010, Astrachan has gone on to be an expert witness on another ten to twelve cases.

In the courtroom, you claimed that Google’s implementation was “transformative” (in the English sense, not the legal sense) because it was done on a smartphone. Do you believe this aligns with the idea of fair use?

When on the stand, Astrachan had temporarily raised havoc by claiming that he thinks “it’s pretty clear that Android is transformative in many ways”. Oracle raised objections to his statement, as it wasn’t in Astrachan’s role to make this kind of statement. The judge threw him a bone, however, dismissing his use of “transformative” to be the plain English usage, as opposed to in the legal sense.

“It’s pretty clear that Android is transformative in many ways”

Astrachan lays out his answer in reference to the different “prongs” of fair use. One of the prongs asks “how much of the work did you use?” — the answer, in Google’s case, was 37 of the APIs, which they absolutely used. The other prong says that “if the fair use is transformative, there’s more legal protection for it.” He recounts Google’s claim that the use of Oracle’s APIs on an Android device was transformative for a few reasons: (1) Android is different from anything else Java runs on (2) it was being used on a whole different operating system and (3) the implementation is fine-tuned to work on a mobile platform.

Do you think Oracle (or other companies) will start tightening up their licensing? How will this affect software development?

Astrachan didn’t seem concerned about the future of software development regardless of how the case concluded. He claims that the “software industry is too huge and too important for a decision to wreak havoc” and that, regardless of who won the case, it would really only affect those trying to start a company. Even if Oracle had won, the ruling wouldn’t have stopped Google from being profitable. More likely, software development would have become a field that requires “more lawyers than software developers”.

What’s a trend in the tech field you’re excited about?

Astrachan foresees a lot of interesting developments in privacy and security. He points to Europe’s differing privacy laws, blockchain, the politicization of social media, and open ethical licenses as some intriguing matters to keep an eye on in the upcoming years.

“The interplay between the tech and life is more than it used to be”

What advice do you have for people reading this article (developing developers!)?

Astrachan stresses the importance of having a good understanding of how the software you develop is going to be used. Both for ethical reasons and for personal comfort, there’s a need for awareness of the impact your lines of code will have.

“If you’re going to go work for a startup that’s going to make our election system not work… that would not be so ideal”

Aside from the impact we can have on the world, Astrachan emphasizes the impact we’ll have on our community and colleagues. As developers, we’ll do more than sit at a computer and write code — we’ll ultimately be working with people. To work with people and develop a community, being aware of issues relating to diversity & inclusion is important.

Soon, it’ll be up to us to decide the people we work with. We can choose to surround ourselves with “people that have a sense of the same community, or same ethics, or set of responsibilities, or mission you do — those are important decisions [to make] when you decide that you’ll no longer be at Duke, but go off and work in the real world”.