A Brief History of Oracle v. Google

As the Oracle foretold, the Sun hasn't set on this case...

Oracle LogoIt’s been called “The Case That Never Ends” and for good reason.

It began on August 13, 2010, the date of my 30th birthday, and may last well into my 40s at the current trajectory. In the time it’s been going it has been the subject of two separate trials, two reversals on appeal and (so far) one petition to the Supreme Court.

It’s a case that pits two of the biggest tech companies against one another in a battle over programming, copyrightabilty and fair use. It may be one of the most important copyright cases of the 2010s but it’s also a case that commentators have struggled to define.

With the most recent appeals court ruling sending shockwaves through both the tech and copyright communities, now seems like a great time to look at this case, its history and understand both how we got where we are and exactly the latest ruling may mean.

As you’ll soon see, nothing in this case is simple but it is still an important case to understand, especially for those who are interested in programming, specifically in writing a new programming language.

Before the Lawsuit

Sun Microsystems LogoIn 1991 Sun Microsystems began development of the Java programming language (as well as the accompanying virtual machine and libraries).

The idea was to create a programming language that could run on nearly any platform regardless of processor or operating system. Theoretically, someone who coded in Java could write apps for everything from a microwave to a high-end Mac or PC using the same language and even the same code.

Java saw its first release, JDK Beta, in 1995 and saw rapid development in its early years, reaching version 10 this year.

In 2003, Android Inc was founded and quickly snapped up by Google in 2005. When developing Android, Google decided that it wanted to incorporate Java libraries into the operating system and even approached Sun abut obtaining a license. However, when the licensing deal (worth between $30 and $50 million) fell through, Google instead opted to take the Java application programming interfaces (APIs) and use it to create their own software development kit.

Though it’s difficult to get a good analogy for an API, it’s best to think of them as a set of definitions and instructions. For example, an API might say that protocol “Calculate” is used to access the calculator with parameters for the calculation to be performed. By using the Java APIs, Google ensured that Java programmers could easily write apps for Android. Though it wasn’t intended as a direct port, Google only used part of the Java command structure, it was meant to make it easier for developers to write apps for Android and, in some cases, reuse existing code.

When Google released its beta of Android in November 2007 Sun decided to “Grit our teeth and support it.” Though they were not thrilled about Android bypassing Java licensing in this way, they still saw it as an opportunity. Besides, at the time, Sun did not believe Google needed a license for what it did.

However, when Oracle purchased Sun in April 2009, they did not see it the same way. In August 2010, Oracle filed the now-famous lawsuit claiming both copyright and patent infringement. With that lawsuit, Oracle kicked off what is now nearly eight years of litigation, likely with several more to go.

Round One – Discussing Copyrightability

Google LogoAfter a year and a half of legal maneuvering, the case made it to its first trial in April 2012. The judge, William Alsup, ordered the trial broken up into three parts, the copyright phase, the patent phase and the damages phase (the latter not to occur if no infringement was found).

In the copyright phase, the jury found that Google had infringed but was divided on whether it was a fair use. In the patent phase, the jury found no infringement at all. However, before the case could go to the damages phase, Judge Alsup issued a final verdict in which he ruled that APIs were not copyrightable and, as such, Google had not committed infringement (outside of one function and a eight security files).

While it might seem odd that a judge would allow a jury to hear the case only to rule on a more base issue after the fact, the strategy was aimed at reducing appeals. If the jury had found non-infringement, the issue of copyrightability would have been moot and an Oracle appeal would have had little chance of succeeding. However, with the jury finding infringement and divided on the issue of fair use, Judge Alsup felt the need to step in, even if it set up an obvious appeal.

And that appeal came quickly. Both sides resolved the damages over the remaining infringement. which was comparatively insignificant, and Oracle filed for an appeal. Since the case dealt with a patent issue, the appeal went before the United States Court of Appeals for the Federal Circuit rather than the 9th Circuit.

The Federal Circuit heard the case in December 2013 and, in May 2014, issued its ruling. There, the court found that APIs could be protected by copyright and, as such, sent the case back down to the lower court to be tried solely on the issue of fair use.

Google petitioned the Supreme Court in hopes it would hear the issue but it was denied certiorari in July 2015, kicking the case all the way back down to the lower court for round two.

Round 2 – Fair Use

Android LogoWith the Appeals Court order standing, the case went back to the district court where a new trial was held in May 2016 looking solely at the issue of fair use. There, the jury found that Google had not infringed Oracle’s work because its use of the Java APIs was a protected fair use.

Oracle, after failing to get the jury verdict tossed, quickly appealed the verdict again to the Federal Circuit. There, earlier this week, the court ruled that Google’s use of the APIs was not a fair use as a matter of law.

With that in mind, the Appeals Court sent the case back to the district court, this time for a trial solely on the issue of damages. Google, however, is widely expected to appeal again to the Supreme Court.

If that petition fails, Google could be facing up to $9 billion in damages, the amount Oracle sought in the second trial.

While the case isn’t over, the end game is slowly approaching. If Google is going to pull out a win, it needs either a rehearing at the Federal Circuit, the help of the Supreme Court or to hand Oracle a pyrrhic victory over damages.

In short, things aren’t looking good for Google and that leaves a lot of questions at our doorstep.

APIs: Copyrightable, Not Fair Use

To create a TLDR of the entire trial so far, it would read like this:

The first trial found the APIs were not copyrightable, that was overturned on appeal. The second trial found that Google’s use was a fair use, that too was overturned on appeal.

The copyrightability question was a particularly vexing one in the early years of the trial. For something to enjoy copyright protection it must be fixed into a tangible medium of expression and have a modicum of creativity. While there’s no doubt about the “fixed” status of APIs, many felt they didn’t deserve copyright protection because they lacked the necessary creativity.

Many compared an API to a phone book in that, while the whole book can be protected, the factual information (names and numbers) is displayed without creativity and enjoys no protection due to a lack of creative expression. Google and others argued that a programming language is similar, one where the language can be copyrighted but the APIs, a set of names and their functions, is not.

This was essentially the argument Judge Alsup used at the end of the first trial. However, on appeal the Federal Circuit ruled that creating an API was, in and of itself, creative. Where putting names and numbers in a phone book in alphabetical order requires no creativity, creating an API requires at least enough to enjoy copyright protection.

However, that ruling would have been mostly meaningless if Google’s use had been ruled a fair use. After all, what they did was to create an entirely new programming language that competes directly with the original using its APIs. If this type of use is a fair use, then APIs might be technically copyright-protected but there would be no practical way to infringe them.

Once again, the lower court (this time at a jury trial) sided with Google. The argument that using the APIs is a fair use is straightforward. APIs, at least in Java’s case, make up a very small percentage of the overall code (thousands of lines of code in a language written with many millions), has low creativity (though enough for copyright protection) and that its use was transformative since Oracle had not ported Java to a mobile platform.

While that argument was good enough for the jury, it wasn’t good enough for the Federal Circuit. It overturned the jury verdict saying that Google’s use of the code was, as a matter of law, not a fair use. According to the Appeals Court:

“There is nothing fair about taking a copyrighted work verbatim and using it for the same purpose and function as the original in a competing platform.”

The Appeals Court acknowledged that Oracle had not brought Java to mobile devices but said that was Sun/Oracle’s decision about when and how to do it. Since, in the view of the Appeals Court, Google’s use was not transformative and harmed the market for the original work, it had no choice but to rule against Google.

Assuming that ruling stands, there’s been a tremendous debate about what it means for programmers and technology in general. The answer, however, is still up for debate.

The Future of APIs

So, where does this leave APIs. Well, barring the recent ruling being overturned, we know two things (at least as far as it pertains to the Federal Circuit). First is that APIs can be protected by copyright and that copying them can be an infringement.

One area of confusion is that this really doesn’t have any bearing on using an API in its intended way. For example, Facebook can’t suddenly start suing people that are using their API to build applications. Not only would that be unwise considering how much Facebook relies on its developers, but it gave permission to its users and, even without direct permission, using an API doesn’t require copying it.

Just like how Android developers who used the copied APIs aren’t being sued, neither will anyone who used the Facebook, Google, YouTube or other APIs to develop applications for those platforms.

Where you might run into trouble is if you created your own social network and copied Facebook’s APIs to ensure that applications written for Facebook could easily be ported to your service or that developers could more easily write apps for your site.

While that porting wouldn’t be 100% since rewriting the code behind the API inevitably means it will operate somewhat differently, it would still make it much easier to move an app written for Facebook to your unnamed service and Facebook would be able to sue you over it.

And that’s really the theme of this case. What Google did is probably the most egregious form of API copying imaginable. They copied the APIs verbatim, by their own admission, and used it to create a competing programming language that became part of the foundation of the largest mobile operating system. All to avoid paying a license to Sun/Oracle.

If copying an API is ever going to be an infringement, this would probably be the time.

Where this case may lead to issues is interoperability. Though Google wasn’t hoping to make Android fully interoperable with Java (choosing not to copy the complete Java command structure), there are many times where systems do strive for such interoperability and, to achieve that, they often copy APIs.

One example of this is the interoperability of Linux and Unix. Linux, which is open source, uses many of the same APIs as commercial Unix. While those standards have been agreed to by the owners of Unix, making a lawsuit over it unlikely, it’s easy to imagine what would have happened if Linux has copied the APIs without permission.

These rulings, if things had worked out different, could have endangered Linux.

But interoperability is a natural desire in tech. When creating a new platform, whether its a video game console, an operating system or a web service, you want to make it as easy to develop for as possible. The easiest way to do that is to copy or mimic the API of an established platform, a practice this case calls into question.

That, in turn, is where this case may insert friction into the tech world. Not by making APIs illegal or impossible to use, but impossible (or at least risky) to copy without permission. How the tech community responds remains to be seen, but just as open standards have been the building blocks for the internet, this case could make open API standards the building blocks of future development.

After all, just like any other copyright-protected work, you can copy it if you have permission. Google did not have it and may pay dearly for it. Other developers, hopefully, won’t make the same mistake should this ruling stand.

Bottom Line

This case has come a long way and it has a long way to go. Even if Google can’t get a rehearing or the Supreme Court doesn’t overturn it, the issue won’t be dead. There are still other circuits (11 to be exact) and any of them could have a different take on the issue.

This case isn’t over and, even if it is, the issue isn’t dead.

Still, if you’re a developer today and you’re thinking about copying an API without permission, I would be wary about doing so. This case will likely be the leading legal guidance on the subject for some time and, even if another court does rule differently, you don’t want to be the test case.

In the end, this isn’t likely to be a “sky is falling” moment. If any copying of an API was going to be an infringement, it was going to be Google’s. Developers would be wise to be aware of this ruling and continue to watch the case, but it isn’t likely to have any impact on most developers, especially those just using or building off of APIs with permission.

This case will certainly have an impact on the internet and development of technology as a whole, but it will likely be a more subtle one than many people fear.

Want to Reuse or Republish this Content?

If you want to feature this article in your site, classroom or elsewhere, just let us know! We usually grant permission within 24 hours.

Click Here to Get Permission for Free