April 5, 2021. The Supreme Court rules, and refuses to answer the question everyone asked.
Here’s the number that should stop you: eleven thousand five hundred lines of code. That’s what the fight was actually about, after roughly a decade of litigation, two jury trials, and two trips to the Federal Circuit before it reached the Supreme Court.
A decade. Two juries. Two rounds at the country’s top patent-and-tech appeals court. And the one question everybody assumed the case would settle (is the structure of an API protected by copyright?) never got answered at all. (A decade of litigation to arrive at a shrug, very on-brand for software disputes.)
Software disputes make people ask the wrong first question. “Is this thing copyrightable?” is a lawyer’s opening move. It is rarely the question a court actually needs answered to resolve the case in front of it. Google LLC v. Oracle America, Inc. is the clearest example on the books: the Supreme Court had the chance to rule, once and for all, on whether the structure of an API is protected by copyright, and it declined. It assumed the code was copyrightable, for the sake of argument, and decided the case on fair use instead.
That’s the whole lesson, not a technicality.
The artifact: declaring code, not the API
Strip away the years of appeals and here’s what actually happened. Oracle owned Java. Google built Android and wanted developers who already knew Java to write Android apps without relearning a language. So Google copied the declaring code of 37 Java API packages (the method and class headers, the names, the parameter lists, the organizational structure a programmer calls to invoke a function) and wrote its own implementing code underneath. Roughly 11,500 lines were copied verbatim, a small fraction of the 2.86 million lines that made up the full Java SE program at issue; the rest of Android’s implementation was Google’s own.
Hold onto that distinction, declaring code versus implementing code, because it isn’t legal language. It’s the artifact the entire case turns on. A court cannot rule on “did Google copy Java” without someone establishing, line by line, what was copied verbatim, what was rewritten, and what function each piece performs inside a working system. That’s a job for someone who can read the code, not just the complaint.
What the record actually shows
Follow the sequence, because it’s a lot to hold in your head at once. Oracle sued in 2010. A jury found Android infringed Oracle’s copyrights but deadlocked on fair use; the district court (Judge William Alsup) then ruled the declaring code wasn’t copyrightable at all, as a matter of law. The Federal Circuit reversed that ruling in 2014 and sent the case back for a fair-use trial; a second jury sided with Google in 2016; the Federal Circuit reversed again in 2018, holding no reasonable jury could find fair use, which sent Google to the Supreme Court. The Court took the case and, in April 2021, reversed the Federal Circuit a second time (six votes to two, in an opinion by Justice Breyer), holding Google’s use of the declaring code was fair use as a matter of law.
Read that sequence again. Two juries, two Federal Circuit reversals, one Supreme Court reversal, all over the legal status of code that both sides agreed, more or less, existed exactly as copied. (Five judicial rounds, zero consensus: the legal equivalent of a group chat that can’t agree where to eat.) The technical facts weren’t seriously in dispute by the end. What kept moving was how courts characterized those facts: creative work or functional interface, market substitute or complementary product, verbatim copying or necessary reimplementation.
Why that’s a java expert witness problem, not a lawyer’s
Notice where the fight actually lived. A generalist reads “Google copied Oracle’s code” and stops there. A court-appointed software expert has to answer a narrower, harder question: what, precisely, is declaring code, how does it differ functionally from the code beneath it, and does copying it serve an interoperability purpose that copying expressive or algorithmic code would not? The majority opinion leaned on exactly that functional distinction: treating Java’s declaring code as off-limits, the Court reasoned, would risk locking programmers out of skills built around the API, not just protecting Oracle’s original expression. That’s a technical claim wearing a legal opinion’s clothes, and it needed a technical foundation to survive.
This is the part worth sitting with: an Israeli company shipping an SDK, a plugin architecture, or an API-compatible reimplementation is one dispute away from needing the same thing, someone who can define the narrow technical question (what was copied, at what layer, for what functional reason), list the materials (source repositories, API specifications, version history, commit logs), apply a repeatable method for separating declaring code from implementation, and state plainly what the analysis can and cannot show. That opinion then has to survive cross-examination by a lawyer who has read the Google v. Oracle briefs and knows exactly where to push.
The side that brings in a computer forensics expert witness early, rather than once the evidence is already filed, is the side that holds.
The takeaway
Google v. Oracle didn’t settle whether APIs are copyrightable. It settled something quieter and, for anyone building software, more useful: that the copyrightability question can be sidestepped entirely if someone establishes, with technical precision, what was actually copied and why. That’s the pattern in every software-structure dispute. The court needs a tested account of the artifact, not a philosophy of code.
The above is general information only and does not constitute legal advice. Case facts are drawn from the sources cited.