feature article
Subscribe Now

Parsing Google v. Oracle: What’s It Really Mean?

Long-Running Code Copyright Case Seems Finally Settled

It’s okay to duplicate an API, even if you have to snarf 11,500 lines of somebody else’s code to do it.

That’s the gist of the ruling from the United States Supreme Court in the long-running case of Google v. Oracle. Left unanswered is the larger question of whether software is even protected by copyright in the first place. But if it is, cloning an API falls under the heading of “fair use.” 

It may seem a bit odd to us amateur armchair legislators that you can decide something is protected by fair use without first deciding whether it’s protected by copyright law, but that’s how complex legal cases often work. They pivot on the smallest of details and closely read interpretations. The ruling was 6–2 (one judge did not participate), so the Court was fairly confident in its decision. 

The practical effect of all this is that most programmers can heave a sigh of relief. It’s generally seen as a good thing for coders, unless you’re an ex-Sun Microsystems programmer now working at Oracle. The ruling finally dispels ten years of back-and-forth litigation over whether the Android operating system includes code stolen from Sun (now Oracle), or whether Android is clean and compliant with the law. It’s both. 

Naturally, Google applauded the decision and Oracle slammed it, saying, “they stole Java and spent a decade litigating as only a monopolist can.” Oracle had asked for an eye-watering $9 billion in damages, citing lost revenue. Oracle argued – and the two dissenting judges agreed – that before Google and Android had entered the picture, Amazon had paid Oracle a handsome sum to license Java for use in its Kindle devices. Google also tried to license Java like Amazon had done, but then didn’t. Instead, the company simply copied the parts of Java that were necessary to make the Android API compatible with Java’s API. 

The Wall Street Journal calls Google’s behavior “piracy” and adds, “by declaring Google’s code-cribbing fair use, the 6–2 majority has weakened intellectual property protections.”

In their dissenting opinion, Justice Clarence Thomas and Justice Samuel Alito wrote that Google had “erased 97.5% of the value of Oracle’s partnership with Amazon, made tens of billions of dollars, and established its position as the owner of the largest mobile operating system in the world.” 

“With a free product available that included much of Oracle’s code (and thus with similar programming potential), device manufacturers no longer saw much reason to pay to embed the Java platform.”

The rest of the Court did not agree. 

In the majority opinion, Justice Stephen G. Breyer wrote, “We reach the conclusion that in this case, where Google reimplemented a user interface, taking only what was needed…  Google’s copying of the Sun Java API was a fair use of that material as a matter of law.” 

There are two important parts to that simple sentence. The first is, “taking only what was needed….” Even though Google reportedly used 11,500 lines of Oracle’s code to implement the Android APIs, the company added far more of its own original code. As a result, the “borrowed” code was a comparative drop in the bit bucket. 

But that’s just a detail. More significantly, the court also decided that Google could not have implemented its compatible APIs any other way, so copying the code – Oracle calls it “plagiarism” – was necessary. In effect, Google’s aims were honorable but unachievable without copying. 

Second, the phrase “as a matter of law” is significant. It means this ruling applies to other APIs, not just this particular one. The Court is saying this was not some weird corner case or an obscure example that somehow got off on a technicality. It’s saying that this is the right ruling, that APIs like this are covered under fair use doctrine as a matter of law. That, more than anything, will be the long-lasting legacy of this decision. 

Interestingly, the Court did not decide whether software APIs are even covered under copyright law. This seems a bit counterintuitive. How can you rule on copyright fair use without first deciding whether copyright protection extends to software? 

Turns out, you can. Here’s the relevant passage in the official decision (emphasis mine): 

“Given the rapidly changing technological, economic, and business-related circumstances, we believe we should not answer more than is necessary to resolve the parties’ dispute. We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted. We shall ask instead whether Google’s use of part of that API was a ‘fair use.’ Unlike the Federal Circuit, we conclude that it was.” 

Let’s parse that a bit. “…we should not answer more than is necessary to resolve the parties’ dispute…” means the Court is kicking the can down the road on whether copyright is applicable to software and APIs. Nope, we’re just settling this one case; we’re not tackling the larger decision because that’s not what Oracle asked us to do. Fair enough. 

They then reinforce that position by saying, “…purely for argument’s sake…” Will they assume that copyright does in fact apply? We’re not saying that’s the law, only that we’re temporarily assuming it’s relevant so that we can move ahead with the real question, which is about fair use. 

Finally, the Court triples down on its position by clearly stating that it’s considering a different question. Not whether the API can be copyrighted, but whether it’s covered by fair use if it was copyrighted. By such legal hair-splitting are legal precedents set. 

Elsewhere the Court reiterates, “But we hold that the copying here at issue nonetheless constituted a fair use. Hence, Google’s copying did not violate the copyright law.” Sounds pretty final. 

This case took ten years, multiple lower court decisions and reversals, and untold sacks of cash to reach this point. And a fine point it is. But at least it’s done. 

The net effect is that it should be safer to produce compatible, competitive software products. Not easier, necessarily, but safer. You’re less likely to get sued for copying a competitor’s software API in order to produce a compatible product. The ruling is pro-competition and pro-upstart David versus Goliath (the only time you’ll ever see Google characterized as the little guy.) 

“The software industry has operated under the assumption that cloning APIs and other methods of organizing functionality for decades, despite the periodic attempts by established firms to cut off their competitors [is legal]” says John Bergmayer at Public Knowledge. “So, in some ways, this decision just affirms what was thought to be the legal status quo.” 

He’s right. Back in the early Silicon Valley days, everyone copied everyone else’s hardware and software. That’s how the industry grew so fast. Nobody protected their IP (they didn’t call it that then) because innovation was more important, more fun, and more interesting than protecting your business interests. That would eventually change, of course. But in a sense, this ruling returns us to those early days when it was okay to use someone else’s product as a jumping-off point for your own. 

It also cements the importance of APIs as interfaces. Without agreed-upon APIs we’d have a collection of walled gardens instead of an ecosystem of interoperable products. Nobody’s hardware would work with anyone else’s, and all software would be vertical stacks from a single vendor. Nobody wants that. 

For what it’s worth, I’m ambivalent about the Supreme Court decision. I’m queasy about a big company copying so much code with no repercussions. What if I’d been working at Sun Microsystems around that time and it was my code that Google swiped? That doesn’t seem right at all. As a programmer, I’d hate it. 

But as a program user, it works for me. I benefit from Android’s existence, and I’m much more likely to reuse code than to create code that gets reused. I come out ahead on this deal, enough to put my legal qualms aside. 

It’s tempting to adjudicate legal cases from the sidelines by cheering for your favorite company and applying pseudo-legal logic to rationalize why they should prevail. If you like Brand X better than Brand Y, then of course the former is in the right and the latter is just a bunch of trolls. But regardless of your opinions about Google or Oracle, I think Google did us a big favor. 

Granted, the company is no underdog. It’s one of the few firms that could have afforded this decade-long slog through a legal system that’s supposed to ignore such pecuniary matters. Apart from saving itself $9 billion in damages (unless it spent that much on lawyers…) it’s helped set a legal precedent that should benefit us all. 

Ironically, it may now be easier to compete with Android. Although the core operating system is open-source, Google adds many proprietary tweaks, like the Google Maps API or the Play Store. As Huawei discovered, you can’t produce a competitive smartphone without those, and replicating them from scratch is a tall order. Maybe now that will be a slightly less impossible task.

4 thoughts on “Parsing Google v. Oracle: What’s It Really Mean?”

  1. Hi Jim, really interesting article this. It gives a really valuable insight into the way the courts think about these issues. Interesting also the bit about deferring any ruling on copyright rules. Hmm. Thank you.

  2. As a guy who teaches and gives away his work (code, circuits etc.) for free for anyone to use and copy, I can understand why copying the structure of an API would be fair use, but I can’t find any logic in saying that copying the actual implementation of said API without consent for profit (direct or indirect) is in any way fair.

  3. This sounds like a big win for open source. Anyone can take any interface copy it word for word. How will Google feel when someone open sources all of it’s APIs? Are they going to get behind a “Free Android” version? Maybe all the phone companies will get together and ripoff (“fair use”) Google?

  4. An API is more a standard than actual code. It’s a contract between software components. Companies invest resources to define such standards and they expect to be compensated when other parties benefit from their work. Extending the ruling to hardware, does it mean the HDMI interface can now be copied without a licence? What about the ARM processor? It can also be seen as a hardware interface between machine code and a processing unit.

Leave a Reply

featured blogs
Oct 22, 2021
Voltus TM IC Power Integrity Solution is a power integrity and analysis signoff solution that is integrated with the full suite of design implementation and signoff tools of Cadence to deliver the... [[ Click on the title to access the full blog on the Cadence Community site...
Oct 21, 2021
We share AI chip design insights from AI Hardware Summit 2021, including wafer scale AI accelerator chips, high-bandwidth memory interfaces, and custom SoCs. The post 4 Futuristic Design Takeaways from the AI Hardware Summit 2021 appeared first on From Silicon To Software....
Oct 20, 2021
I've seen a lot of things in my time, but I don't think I was ready to see a robot that can walk, fly, ride a skateboard, and balance on a slackline....
Oct 4, 2021
The latest version of Intel® Quartus® Prime software version 21.3 has been released. It introduces many new intuitive features and improvements that make it easier to design with Intel® FPGAs, including the new Intel® Agilex'„¢ FPGAs. These new features and improvements...

featured video

Intel Architecture Day 2021: Data Center - Infrastructure Processing Unit

Sponsored by Intel

Intel unveiled its biggest architectural shifts in a generation for CPUs, GPUs and IPUs to satisfy the crushing demand for more compute performance at Architecture Day 2021. Guido Appenzeller, Chief Technology Officer of Intel's Data Platforms Group explains how the IPU's design enables cloud and communication service providers to reduce overhead and free up performance for central processing units.

Click here to learn more

featured paper

Why long-term consistent performance matters for relative humidity sensors

Sponsored by Texas Instruments

The open cavity sensing element included in relative humidity sensors is constantly exposed to the environment, leading to drift over time. The new relative humidity sensor, the HDC3020, offers integrated drift correction technology to reduce drift caused by environmental stress or interactions with contaminants. This article discusses the accuracy and long-term drift of humidity sensors and how these parameters impact end-equipment performance and lifetimes.

Click to read more

featured chalk talk

KISSLING Products: Rugged and Reliable Solutions

Sponsored by Mouser Electronics and TE Connectivity

Rugged and reliable designs today have a specific set of design requirements that may not be found in other industries including robustness, durability, and the ability to resist harsh environments. In this episode of Chalk Talk, Amelia Dalton chats with Mark Dickson from TE Connectivity about the KISSLING product family which includes a wide variety of rugged and reliable solutions for your next design.

Click here for more information about TE Connectivity / KISSLING Ruggedized Switching Products