In April 2021, the U.S. Supreme Court decided Oracle v. Google, 6–2, closing an eleven-year fight over the most consequential lines of software ever copied. Google had re-created 37 packages of the Java API, roughly 11,500 lines of declaring code, the names and call structure that other programs rely on, so millions of Java developers could write Android apps from day one. Oracle claimed the interface itself as its property. The Court held that Google's use was fair use under 17 U.S.C. § 107.
That result produced a rule worth memorizing: interfaces became far safer to reimplement, and substance stayed protected. If you build an emulator, a compatibility layer, or an API-compatible service, this case is your shield. If someone lifts your implementation code, your assets, or your whole app, it is not theirs. Here is what the Court actually held, where the safe zone ends, and what to do in either direction, whether your compatible code just drew a takedown or your product just got cloned.
The ten-year fight, compressed
Sun Microsystems built Java in the 1990s around a promise: write once, run anywhere. By the mid-2000s its API conventions were the shared vocabulary of a huge developer population, which made Java the obvious foundation for a phone platform. Google tried to negotiate a license with Sun; the talks failed, and trial exhibits later showed Google understood the risk and proceeded anyway. Android shipped with Google's own implementing code, written in part on the clean-room Apache Harmony project, under declarations copied from the Java API. Google never denied the reuse. That was the point: developers already knew these names.
Sun's chief executive publicly welcomed Android's launch. The welcome created no license. Oracle closed its acquisition of Sun in early 2010, the copyrights traveled with the deal, and Oracle sued that August with damages theories that at various points ran into the billions.
Then came a decade of whiplash. In 2012, Judge William Alsup of the Northern District of California ruled that the API's structure, sequence, and organization was not copyrightable. The Federal Circuit reversed in 2014, holding the declaring code protectable, and sent fair use to a jury. In 2016 that jury found for Google. The Federal Circuit reversed again in 2018, taking fair use away as a matter of law. The Supreme Court stepped in late 2019, heard argument in October 2020, and decided the case on April 5, 2021: Justice Breyer for the majority, Justice Thomas in dissent, joined by Justice Alito. Six to two. The software industry exhaled.
How the Supreme Court weighed the four fair-use factors
The Court ran Google's copying through the four statutory factors of Section 107.
Purpose and character of the use. Google reused declarations so programmers who had spent years learning Java could carry that knowledge onto a new kind of device. The majority saw that purpose as transformative, building a new product for a new market rather than substituting for Java itself. Progress, the Court emphasized, is what copyright exists to promote.
Nature of the copyrighted work. Declaring code is functional at its core, bound tightly to uncopyrightable ideas: the division of tasks, the system of organization. The more utilitarian a work, the thinner copyright's reach. The Court also named the lock-in problem directly. Programmers had invested years in the Java structure, and handing its owner a veto over every platform built on that knowledge would turn copyright into a monopoly over ideas.
Amount and substantiality. The roughly 11,500 copied lines were a rounding error against codebases measured in the millions, and Google took no more than interoperability required: the declarations, with fresh implementing code beneath them.
Effect on the market. Oracle's harm theory rested on licensing it might have won rather than sales it could prove it lost; the standard library lived on desktops and servers while Android targeted smartphones. The claimed harm was speculative, and the Court warned that the measurable harm of deciding the other way would land on the public, which depends on interoperability for new platforms to compete.
Fair use is weighed case by case, and Google's facts ran unusually favorable: new market, minimal copy, independent implementation, obvious public benefit. Reuse that substitutes directly for the original walks a much harder path.
The question the Court never answered
The Court never decided whether APIs are copyrightable at all. Breyer's opinion assumed, for the sake of argument, that the declaring code was protected and moved straight to fair use. That maneuver settled the case but left the doctrine standing: the Federal Circuit had held declaring code copyrightable in 2014, and nothing overturned that ruling. Treat API declaring code in the US as copyrightable, and treat fair use, a defense you assert, not an immunity you carry, as the protection for reimplementation.
Three consequences follow. First, never build your strategy on the claim that interfaces cannot be copyrighted; that argument lost below, and the opinion that saved Google never endorsed it. Second, fair use is something you argue, often in court, after a host has already taken your code down; platforms run the notice-and-counter-notice machinery of Section 512 rather than adjudicating defenses. Third, geography matters. The EU drew its own line in SAS Institute v World Programming, where the Court of Justice held that program functionality and programming languages fall outside copyright altogether, friendlier to reimplementation, though enforcement there runs on different rails.
Where the interoperability safe zone ends
The ruling protects the interface, not the substance behind it. Google's own record draws that line sharply: alongside the declarations, Google admitted copying about nine lines of a range-checking helper and a handful of test files. That copying was handled as ordinary infringement and played no part in the fair-use win. Nothing outside the declarations received shelter, and three categories matter most in practice.
Implementation code. Copied logic, comments, algorithms, and configuration files are classic infringement. If someone decompiled your binary or lifted your source, Oracle v. Google protects them not at all.
Assets and content. Art, audio, text, databases, and documentation were never at issue and remain fully enforceable. Documentation counts double here: pasting your README is copying prose, not implementing an interface.
The wholesale clone. A clone that lifts your code, your art, and your store copy is not interoperability; it is piracy with a case citation attached. Cracked redistributions of your release sit in the same category and stay squarely actionable, while monitoring where your builds get republished is a discipline of its own.
Two boundaries deserve respect on the rightsholder side as well. Names, logos, and confusing branding raise a trademark question, not a copyright one. And Google's posture was a new platform in a new market; a reimplementation that substitutes directly in your existing market meets the first and fourth factors running against it.
If your API-compatible code just drew a takedown
Work the problem in order.
First, read the notice properly and identify what is actually claimed: declarations and call structure on one side, implementation, text, and assets on the other. The split decides everything downstream.
Second, audit yourself frankly. If you reimplemented the interface and wrote your own logic, you stand in Google's posture and the Court's reasoning applies directly. If you copied implementing code, comments, or assets, fair use will not carry you, and a counter-notice you do not believe in compounds the exposure.
Third, weigh the counter-notice. Filing one in good faith starts a clock under 17 U.S.C. § 512(g): the host must restore the material within ten to fourteen business days unless the claimant sues. The lever is strong, and it is also a dare. A serious claimant will file suit, so make sure your audit holds up first.
Fourth, preserve everything now, repository history, design notes, clean-room documentation. If the sender knowingly targeted material it knew was lawful, Section 512(f) gives you a misrepresentation claim, though proving "knowingly" sets a high bar. In practice, most interface disputes end when the claimant's counsel reads your audit.
If someone reimplemented your interface
Flip the facts: you own the API, and a competitor built a compatible version. Your leverage is narrower than instinct suggests, and misreading it can cost you.
A clean reimplementation of your public interface, aimed at a different platform or market, is probably fair use after 2021. A takedown aimed at shared declarations alone will usually fail, and it can backfire. The Ninth Circuit's dancing-baby decision requires rights-holders to consider fair use before sending a notice, and Section 512(f) imposes liability for knowing material misrepresentation. Aim a notice at a true reimplementation and you may buy yourself fees and a public record of overreach. Give real thought to when fair use argues against filing at all.
What remains fully actionable: your implementing code, your documentation, your assets, your SDK binaries, pirated and cracked copies. Find the copied substance, identical comments, matching logic, lifted text, and aim the notice there. If the clone sits in a public repository, a code host's DMCA process follows the same statutory rules. From there the mechanics are standard: file a DMCA takedown notice that complies with Section 512 by identifying the specific infringing files and stating a good-faith belief in the claim. A notice targeted at substance survives scrutiny; a notice targeted at the interface itself invites a counter-notice you may regret.
The records that decide interface disputes
When these fights escalate, the side with better records usually wins.
If you build compatible software, keep a clean-room trail: the specifications you worked from, notes showing independent design decisions, and version-control history where your implementing code visibly evolves from your own commits. Timestamped evidence of independent work is the single best answer to a copying claim.
If you enforce, sort your holdings before acting. Registration is a prerequisite for filing a US infringement suit and, when the timing works out, makes statutory damages available, so weigh whether registration is worth it for your codebase. Prepare a comparison memo that separates implementation lines from declarations, and run through an evidence checklist before you file anything. If your project ships under a copyleft license such as the GPL, enforcement runs through license terms, compliance demands and source-code obligations, and open-source license enforcement has its own tested playbook.
Frequently asked questions
Can an API be copyrighted in the United States after Oracle v. Google?
Probably. The Supreme Court assumed without deciding that the declaring code was copyrightable, and the Federal Circuit had already held it protectable. Nothing in the 2021 ruling strips APIs of protection. What shields a reimplementation is fair use, a defense weighed case by case, and the Court's analysis leaned on new markets, minimal copying, and independent implementation.
Does Oracle v. Google let me copy a competitor's entire SDK?
No. The win covered only what interoperability required, declaring code, taken to reach a new market, with implementation written fresh. Sample apps, documentation, binaries, and comments remain protected, and copying them is ordinary infringement. A reimplementation that substitutes for the original in its own market also faces far weaker purpose and market-effect factors.
Someone cloned my app and cites interoperability, can I still send a DMCA takedown?
Yes, once the copying reaches substance. Interoperability is a defense to copying an interface, not a license to lift implementation code, assets, store copy, or data. Draft the notice around the copied material, matching lines, files, and assets, rather than shared API names, and the clone's citation to Oracle v. Google will not slow the removal.
Does the Oracle v. Google ruling apply outside the United States?
It carries no force abroad; it is a US fair-use ruling built on Section 107. The EU drew its own line earlier in SAS Institute v World Programming, holding program functionality and languages outside copyright. Platforms enforce their own policies worldwide, and the DMCA's reach abroad varies by country, so check the local mechanics before you act.
What is the difference between declaring code and implementation code?
Declaring code is the surface: function names, parameter lists, and the organizational structure that other programs rely on to call in. Implementation code is the logic underneath that makes the call actually work. Google copied the first category and wrote its own version of the second. Oracle v. Google drew its protective line through exactly that gap.
Where to go from here
- Classify before you act. Write down what is genuinely shared, declarations and call structure on one side, implementation, text, and assets on the other. Every decision downstream depends on that split.
- If you are the builder, document today. Commit history, design notes, and timestamped proof of independent implementation are worth far more created in the ordinary course than reconstructed after a notice arrives.
- If you are the rightsholder, aim at substance. Notices that target copied code and assets succeed; notices that target interface compatibility invite counter-notices and misrepresentation exposure.
- Register what you might someday sue over. US courts require it before an infringement suit, and statutory damages hinge on timing.
- Pick your filing path. The DIY takedown route walks through the mechanics step by step, or you can hand the work to a professional takedown service that pairs filings with ongoing monitoring.