In March 2018, Google lost the appeal from a lawsuit it had already appeared to win twice. A federal court erased a jury’s finding that Android’s use of Java interfaces was fair and sent the case towards a damages trial. Oracle had previously valued its claim at roughly $9.3 billion.

Existing Android phones were not about to shut down, but the ruling threatened the bargain behind the platform: familiar Java commands, different machinery underneath, and no commercial Java license. It also raised a larger question: how freely could software makers reproduce a familiar application programming interface (API) when building something new?

Android kept Java’s menu but replaced the kitchen

Same order, entirely different chef

Google bought Android Inc. in 2005 and needed an application ecosystem quickly. About six million programmers had already invested years in learning Java, so using commands they recognized offered a shortcut to a ready-made developer community.

The Java language itself was free to use, while Sun Microsystems controlled the broader Java SE platform and its library of pre-written tasks. That distinction matters because an SDK and an API serve different roles. The declaring code identifies a method and specifies details such as its name, accepted inputs, and return type. The implementing code contains the instructions that perform the task.

A food menu is a useful comparison. The declaration tells programmers what they can request and how to request it, while the implementation is the kitchen that prepares the result. This is the basic attraction of integrating an API into an application: developers can request an existing function without rebuilding everything behind it. A programmer familiar with core Java concepts such as methods, parameters, and return values could call java.lang.Math.max(4, 6) to request the larger number without knowing how the comparison worked behind the scenes.

Google and Sun discussed a license, but they could not agree. Sun required licensed implementations to preserve Java compatibility and its “write once, run anywhere” promise. Google wanted manufacturers to modify Android freely, an arrangement Sun viewed as a route towards incompatible Java implementations.

Google therefore built a separate platform around its Dalvik virtual machine. Within the 37 Java API packages eventually disputed, it copied roughly 11,500 lines of declared code and reproduced their organization, while generally writing its own implementing code. Android was not compatible with Java SE, and desktop Java programs did not simply run on it, illustrating why software is not universally compatible across operating systems and platforms. Google retained part of the system developers called, then placed different machinery behind it.

Oracle bought Sun and put a price on Android

Android’s free ride suddenly came with an invoice

Oracle completed its acquisition of Sun in January 2010 and sued Google that August, alleging patent and copyright infringement. The patent case largely fell away, and a jury found no infringement of the patents that reached trial. The lasting dispute concerned copyright in the declarations and organization of the 37 packages.

Oracle’s expert attributed about $21 billion of Google’s profits to more than three billion Android activations, then sought approximately $8.8 billion in profits allegedly connected to the copied material and about $475 million in lost licensing revenue.

Those were contested estimates prepared for Oracle’s 2016 damages case, not an award. Even so, they placed the claimed exposure near $9.3 billion. A loss could have left Google owing billions for older Android releases and strengthened Oracle’s hand in any licensing dispute over the platform’s foundations. Google could change Android going forward, but it could not make years of already shipped releases disappear from Oracle’s claim.

The jury stalled, and Google won anyway

Nobody agreed, so the judge settled the biggest question

District Judge William Alsup split the 2012 trial into phases. The jury considered infringement and fair use, while Alsup reserved the threshold question of whether copyright covered the declarations and their organization.

The jury found infringement in the 37 packages but deadlocked on fair use. A few tiny copied fragments became a separate side issue, although they were never the part of the case that placed Android’s wider design at risk.

Alsup then ruled that the declarations and their structure were not copyrightable. They operated as a command system, he reasoned, and copyright could protect the code implementing those commands without handing Oracle control over the commands themselves.

Oracle’s appeal went to the Federal Circuit because the lawsuit had included patent claims. In 2014, it reversed Alsup and held that the declaring code and the structure, sequence, and organization of the packages were copyrightable. The court reinstated the infringement finding and returned the case for a trial on Google’s remaining defense, fair use.

The Supreme Court declined to review that ruling in June 2015. Google’s first apparent victory was gone, but the lawsuit was still only halfway through its life.

Google changed the code, then lost again

Google changed course after the legal storm had started

In late 2015, Google began moving Android’s Java language libraries towards an OpenJDK-based approach. The change reached users with Android 7.0 Nougat in August 2016. This placed substantial parts of Android’s later core-library code on an explicit open-source licensing basis, reducing uncertainty around future implementations without erasing claims involving releases already shipped.

The 2016 retrial focused on older Android phone and tablet releases covered by the first jury’s infringement finding. It asked whether Google’s copying qualified as fair use, and this time the jury sided with Google.

Oracle argued that Android had damaged Java’s mobile licensing market. Amazon had licensed Java for an earlier Kindle, adopted Android for the Kindle Fire, and later negotiated a steep discount on another Java license. Google disputed how directly those agreements measured harm to Java SE.

On March 27, 2018, the Federal Circuit reversed Google’s victory again. It accepted the jury’s underlying factual findings but reviewed the ultimate fair-use conclusion as a legal question. Google, it held, had moved Oracle’s declarations into a competing commercial platform without transforming their purpose enough. The case was sent back for a damages trial.

Google now faced potential liability for years of Android releases, while Oracle held an appellate judgment and a damages theory measured in billions. Future versions could use differently licensed code, but Android’s original legal bargain had become a liability.

The consequences reached beyond phones. Software makers regularly reproduce established interfaces so applications can communicate and developers can carry their skills between systems. The importance of clear and consistent API design helps explain why those interfaces accumulate so much value for the programmers who learn them. A broad loss for Google threatened to make compatible operating systems, libraries, tools, and applications more expensive and legally risky.

The Supreme Court gave Google the win that mattered

The final appeal saved Android’s original gamble

The Supreme Court agreed to hear the case in November 2019, taking up copyrightability and fair use. Arguments planned for March 2020 were postponed during the COVID-19 disruption and eventually heard on October 7. The decision arrived on April 5, 2021.

Justice Stephen Breyer wrote for a 6-2 majority. Justice Amy Coney Barrett did not participate because she had not joined the Court when the case was argued. Rather than settle whether the declarations were copyrightable, the majority assumed they were and held that Google’s copying was fair use.

Fair use turns on four connected questions: the purpose of the copying, the nature of the work, the amount taken, and the effect on the market. The court concluded that the balance favored Google in this case.

Declaring code sat further from copyright’s creative core because it was closely tied to a functional system, uncopyrightable commands, and programmers’ accumulated knowledge. Google’s purpose was transformative because Android placed familiar declarations inside a new smartphone environment, paired them with independently written implementations, and let developers apply existing Java skills to new tasks.

Google copied approximately 11,500 lines, virtually all the declaring code needed to call hundreds of selected functions. Those lines represented about 0.4 percent of the 2.86 million lines in the wider Java API, but the majority did not rely on the percentage alone. It asked whether the amount taken was tied to Google’s purpose, and retaining the declarations was what let programmers transfer their knowledge to Android.

On market harm, the majority found that Android was not a straightforward substitute for Java SE. It also worried that enforcing Oracle’s claim would give a copyright holder control over value created partly by programmers who had invested years learning the interface.

Justice Clarence Thomas, joined by Justice Samuel Alito, dissented. He argued that declaring code deserved the protection Congress gave computer programs, that Google copied after license negotiations failed, and that Android had damaged Oracle’s mobile licensing relationships. He also said the copied declarations should have been compared with the declaring code alone, not the entire API.

Android won, but APIs did not become free

Oracle recovered no damages, and Google won without securing the rule it originally wanted. The Supreme Court did not declare APIs uncopyrightable. It held that Google’s particular copying, on this record and for this purpose, was fair.

The decision became an important but fact-specific precedent for compatible reimplementation, not an automatic exemption for copying APIs. The broader value of backward compatibility in software helps explain why developers care so much about preserving familiar commands, standards, and existing knowledge when platforms change.