Copyright in Software Interfaces After Google v. Oracle: APIs, Compatibility, and Reverse Engineering

Summary. This article explains how United States law treats the copying of software interfaces, from function names and command languages to file formats and protocols, after the Supreme Court's 2021 decision in Google LLC v. Oracle America. It traces the doctrine from Baker v. Selden and the 1980 software amendments through Whelan, Altai, Lotus v. Borland, and the reverse-engineering fair use cases, then walks through each stage of the Oracle litigation and what the Supreme Court did and did not decide. It covers the developments since 2021, including SAS Institute v. World Programming and the Ninth Circuit's treatment of interoperable add-on code, and the walls outside copyright that now matter as much as copyright itself: license terms, the DMCA's anti-circumvention rules, the Computer Fraud and Abuse Act, trade secret law, and patents. It explains why clean-room development still works and where it does not, and how AI coding assistants complicate the picture. An extended worked example, a table of open questions, common mistakes, an FAQ, and practical takeaways for both implementers and interface owners close the article.

The board meeting at Tessellate Analytics lasts eleven minutes before someone says the word "lawsuit." Tessellate, a 60-person company in Raleigh, wants to sell a cheaper engine that runs programs written in the proprietary statistical language of Corvid Systems, the market leader. Corvid's customers, mostly banks and insurers, hold twenty years of scripts written in that language. They would switch tomorrow if the scripts ran unchanged. To make that happen, Tessellate's engine has to accept the same commands, the same procedure names, the same options in the same order, and it has to read and write Corvid's data file format. Corvid's license agreement, which Tessellate's founders clicked through years ago when they used the product at a previous job, says no one may "reverse engineer, decompile, or create a functionally equivalent product."

The chief technology officer has two questions. Can we copy the language and the interface? And if we can, how do we build the thing without walking into a trap?

The first question has had no clean answer for forty years, and the Supreme Court's 2021 decision in Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021) did not supply one. What it supplied is a very strong fair use path for reimplementing an interface, a set of reasons that travel well beyond Java, and a deliberate refusal to decide whether interfaces are copyrightable in the first place. The second question, how to build the thing, turns as much on contract, anti-circumvention law, trade secrets, and patents as on copyright. This article covers both.

The short answer

• Ideas, systems, and methods of operation are never protected by copyright. 17 U.S.C. § 102(b) excludes them by statute. The fight is over whether a particular interface is an unprotectable method of operation or a protectable expression of one.
• The circuits never agreed. The First Circuit held a menu command hierarchy uncopyrightable as a method of operation; the Federal Circuit, applying Ninth Circuit law, held Java's declaring code and its structure copyrightable. Most other courts filter interface elements out under the abstraction-filtration-comparison test.
• Google v. Oracle assumed copyrightability and held Google's reimplementation a fair use as a matter of law. The Court's reasoning (declaring code sits far from the core of copyright, reimplementation for a new platform is transformative, the copying was limited to what programmers needed, and the owner's claimed market value came from programmers' investment in learning the interface) supports most good-faith compatibility projects.
• Reverse engineering to reach unprotected interface information is fair use in the leading cases, Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992) and Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000), but only from an authorized copy and only when the copying is intermediate and necessary.
• Copyright is no longer the main obstacle. License terms banning reverse engineering are generally enforceable in the United States, the DMCA prohibits circumventing access controls with a narrow interoperability exemption, the Computer Fraud and Abuse Act punishes unauthorized access, trade secret law punishes improper acquisition, and patents can cover interface functionality regardless of how it was built.
• Clean-room development still matters. Independent creation defeats a copyright claim, and a documented clean room is the best evidence of it. It does nothing for patents and little for contract claims.
• Owners should protect value outside copyright. After Google, owners who want to control compatible implementations rely on contracts, patents, trade secrets in non-public code, trademarks for certification, and the commercial value of being the reference implementation.

What an "interface" is, and why the law struggles with it

Software engineers use "interface" for several different things, and the legal analysis changes with each. A lawyer advising on a compatibility project should pin down which one is in play.

The difficulty is that an interface is both. To a programmer, max(int a, int b) is a functional handle: if the name or parameter order differs, programs written for the original will not run. To an author, choosing the name, grouping it into a Math class, and placing that class in a java.lang package are choices among many alternatives, and copyright protects original choices among alternatives. Courts have spent forty years deciding which description matters more.

The statutory frame

Four provisions set the terms of every interface dispute.

The definition. The Copyright Act defines a "computer program" as "a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result." 17 U.S.C. § 101. Congress added the definition in 1980 on the recommendation of the National Commission on New Technological Uses of Copyrighted Works (CONTU), whose 1978 Final Report concluded that programs should be protected as literary works. After the amendment, courts quickly held that both source and object code, and operating system programs as well as applications, are protected. Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240 (3d Cir. 1983), involved a clone maker that copied Apple's operating system programs wholesale to achieve compatibility, and the court rejected the argument that compatibility justified copying the code itself.

The idea/expression line. Section 102(b) codifies the rule of Baker v. Selden, 101 U.S. 99 (1879), in which the Court held that a copyright in a book explaining a bookkeeping system did not give the author exclusive rights in the system or in the ruled forms needed to use it. The statute denies protection to "any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied." Every interface dispute is, in the end, an argument about where this line falls.

The owner's copy. 17 U.S.C. § 117 lets the owner of a copy of a program make the copies or adaptations that are an essential step in using it with a machine, and archival copies. Because loading a program into memory creates a "copy," MAI Systems Corp. v. Peak Computer, Inc., 991 F.2d 511 (9th Cir. 1993), section 117 matters for anyone who runs software to study it. Its catch is the word "owner." Courts disagree on when a licensee is an owner: the Ninth Circuit asks whether the copyright holder specifies a license, significantly restricts transfer, and imposes notable use restrictions, Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010), while the Second Circuit looks to whether the possessor exercises sufficient incidents of ownership, Krause v. Titleserv, Inc., 402 F.3d 119 (2d Cir. 2005). Most commercial software is now licensed on terms designed to defeat ownership, so section 117 rarely carries a reverse-engineering project alone.

Fair use. 17 U.S.C. § 107 and its four factors (purpose and character, nature of the work, amount and substantiality, and market effect) did most of the work in the reverse-engineering cases and all of the work in Google.

A fifth provision, added in 1998, now sits beside these: the interoperability exemption to the DMCA's anti-circumvention rules in 17 U.S.C. § 1201(f). It is discussed below with the other walls outside copyright.

Forty years of doctrine in four stories

Whelan: the structure of a program is protected

Jaslow Dental Laboratory hired Whelan Associates to write a program to run its business, then wrote its own version in a different language for a different computer, with a similar structure. The Third Circuit held the structure, sequence, and organization of a program protectable and offered a simple test: the idea of a program is its purpose or function, and everything not necessary to that purpose is expression. Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc., 797 F.2d 1222 (3d Cir. 1986).

Whelan is the high-water mark for broad protection, and almost every later court rejected its test. A program has many ideas at many levels, not one, and treating everything but the program's single purpose as expression would give the first programmer in a field a monopoly over every efficient way to organize a solution.

Altai: abstraction, filtration, comparison, and the first famous clean room

The test that replaced Whelan came from a case that was, among other things, a story about a clean room. Altai hired a programmer from Computer Associates who brought with him code from CA's scheduling program and used about 30 percent of it in Altai's OSCAR 3.4. When Altai learned of it, it had programmers who had never seen the CA code rewrite the affected modules from a functional description, producing OSCAR 3.5. Altai conceded liability for 3.4. The question was whether 3.5, written without the code, still infringed because of similarities in structure.

The Second Circuit held that it did not, and it set out the three-step test courts still use. Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992). First, abstract the program into levels of generality, from code at the bottom to its ultimate function at the top, following Learned Hand's abstractions approach in Nichols v. Universal Pictures Corp., 45 F.2d 119 (2d Cir. 1930). Second, filter out at each level what is not protected: elements dictated by efficiency (merger), elements dictated by external factors such as hardware specifications, compatibility requirements, and industry demands (scènes à faire), and material taken from the public domain. Third, compare what remains, the "golden nugget" of protectable expression, with the accused program.

The filtration step is where interfaces go. Altai named compatibility with other programs as one of the external factors that limit a programmer's choices, which means that interface specifications a compatible program must match are filtered out before comparison. Circuits that adopted or adapted the test applied that reasoning to interface elements specifically. The Tenth Circuit filtered out command codes for telephone call controllers that technicians had learned to use, Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997), and described a detailed filtration method in Gates Rubber Co. v. Bando Chemical Industries, Ltd., 9 F.3d 823 (10th Cir. 1993). The Eleventh Circuit held that interface specifications may be unprotectable where they are dictated by external factors, Bateman v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996). The Fifth Circuit, by contrast, found that some input formats in an engineering program could be protectable expression, Engineering Dynamics, Inc. v. Structural Software, Inc., 26 F.3d 1335 (5th Cir. 1994), a reminder that filtration is fact-specific and not a categorical exemption.

The clean-room lesson of Altai is easy to miss. The court did not say the rewrite was immune because it was clean. It said the rewrite did not infringe because what survived in it, after filtration, was unprotected. The clean room mattered because it eliminated literal copying and made the remaining similarities explainable by function. For the mechanics of running one today, see Running a Clean Room Software Development Project: A Practical Guide.

Lotus v. Borland: menus as methods of operation

Lotus 1-2-3 dominated spreadsheets in the 1980s, and users wrote macros, sequences of menu commands, to automate their work. Borland's Quattro Pro offered a "Lotus Emulation Interface" that reproduced the 1-2-3 menu tree (469 commands arranged in more than 50 menus and submenus) so that users could keep their macros and their habits. Borland did not copy any Lotus code.

The First Circuit held the menu command hierarchy uncopyrightable as a "method of operation," which it defined as "the means by which a person operates something, whether it be a car, a food processor, or a computer." Lotus Development Corp. v. Borland International, Inc., 49 F.3d 807 (1st Cir. 1995). The court accepted that Lotus made expressive choices in naming and arranging the commands. It held that did not matter: the hierarchy was how users operated the program, and section 102(b) excludes methods of operation regardless of the creativity that went into them. Users who had written macros would be "locked in" to Lotus if forced to rewrite them, and the court found that prospect inconsistent with the statute. Judge Boudin's concurrence, which is still the most quoted passage in the case, framed the problem in terms of users' investment rather than Lotus's: the value of the menu tree came largely from what users had built on it.

The Supreme Court granted certiorari and affirmed by an equally divided Court, with Justice Stevens not participating. Lotus Development Corp. v. Borland International, Inc., 516 U.S. 233 (1996). An affirmance by an equally divided Court has no precedential value, so Lotus binds only the First Circuit. Its reasoning about user investment, though, reappears almost verbatim in Google.

Sega, Atari, and Connectix: copying to learn the interface

The reverse-engineering cases ask a different question. Not "may I reproduce the interface in my product?" but "may I copy the original program while studying it to learn what the interface is?"

Accolade wanted to make games for Sega's Genesis console without a Sega license. It bought Sega cartridges, disassembled the object code into human-readable form, studied it to find the few bytes the console checked for before running a game, and wrote a manual describing the functional requirements. Its programmers then wrote original games using the manual. Sega sued for the intermediate copies made during disassembly. The Ninth Circuit held them fair use: "where disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted computer program and where there is a legitimate reason for seeking such access, disassembly is a fair use of the copyrighted work, as a matter of law." Sega, 977 F.2d 1510. The court gave weight to the public benefit of more independently created games and to the fact that Accolade's final products contained none of Sega's code.

The same year, the Federal Circuit, applying Ninth Circuit law, endorsed reverse engineering as potentially fair use but ruled against the reverse engineer, because of how it got the code. Atari's Tengen subsidiary wanted to make cartridges for the Nintendo Entertainment System, which used a lockout program (10NES) to reject unlicensed games. Atari obtained a copy of the 10NES source code from the Copyright Office by representing that it needed it for litigation with Nintendo, which was not then pending. The court held that "to invoke the fair use exception, an individual must possess an authorized copy of a literary work," and that Atari's copying of more than was necessary to achieve compatibility went beyond fair use. Atari Games Corp. v. Nintendo of America Inc., 975 F.2d 832 (Fed. Cir. 1992). Atari is the standing warning for every reverse-engineering project: the source of the copy and the scope of the copying are both on trial.

Eight years later, Connectix built the Virtual Game Station, a program that let PlayStation games run on Macintosh computers. Its engineers repeatedly copied Sony's BIOS while developing their own replacement BIOS from scratch. The Ninth Circuit held the intermediate copies fair use and called the Virtual Game Station "modestly transformative" because it created a new platform for playing the games. Connectix, 203 F.3d 596. The court rejected Sony's argument that the number of intermediate copies mattered, and it treated Connectix as a legitimate competitor whose product could reduce Sony's console sales without that being the kind of market harm copyright recognizes.

Together, Sega and Connectix stand for a workable rule in the Ninth Circuit and the many courts that follow it: copying a program to discover unprotected interface information, when there is no other practical way to get it and the final product is independently written, is fair use. Atari adds the conditions that the copy be lawfully obtained and the copying be limited to what the purpose requires.

The Oracle litigation, stage by stage

Sun Microsystems released Java in the mid-1990s, built around the slogan "write once, run anywhere." Programmers write Java programs that call functions in the Java Standard Edition library, organized into packages, classes, and methods. Each method has two parts: a declaration (the "declaring code," which states its name, parameters, and where it sits in the hierarchy) and an implementation (the "implementing code," which does the work).

Google acquired Android in 2005 and negotiated with Sun for a license. The talks failed. Google then built Android's Java-compatible library by writing its own implementing code for 37 Java SE packages but copying the declaring code for those packages, about 11,500 lines, so that programmers who knew Java could write Android apps using the method calls they already knew. Oracle acquired Sun in 2010 and sued Google for copyright and patent infringement that year.

2012: the district court holds the declarations uncopyrightable

After a jury found infringement but deadlocked on fair use, Judge Alsup of the Northern District of California ruled that the declaring code and the structure, sequence, and organization of the 37 packages were not copyrightable. Oracle America, Inc. v. Google Inc., 872 F. Supp. 2d 974 (N.D. Cal. 2012). His reasoning tracked Lotus: the declarations were a system or method of operation, and because a given method could be declared in only one way to work with existing programs, the expression merged with the idea. The jury rejected Oracle's patent claims.

2014: the Federal Circuit reverses on copyrightability

Because the case included patent claims, the appeal went to the Federal Circuit, which applied Ninth Circuit copyright law. It reversed. Oracle America, Inc. v. Google Inc., 750 F.3d 1339 (Fed. Cir. 2014). The court held that the declaring code and the structure of the packages were original and creative, that merger had to be assessed from the perspective of Sun's choices when it wrote the code (and Sun had many ways to name and organize its methods), that short phrases doctrine did not defeat protection for the combination of many names, and that section 102(b) did not exclude the material merely because it was functional. The court expressly declined to follow Lotus and held that interoperability arguments belonged in the fair use analysis, not the copyrightability analysis. The Supreme Court denied Google's first petition for certiorari in 2015.

2016 and 2018: a jury finds fair use, and the Federal Circuit reverses again

On remand, a second jury found Google's use fair. The Federal Circuit reversed again, holding that no reasonable jury could find fair use, because the use was commercial, not transformative (Android used the declarations for the same purpose as Java), and harmful to actual and potential markets for Java, including the smartphone market. Oracle America, Inc. v. Google LLC, 886 F.3d 1179 (Fed. Cir. 2018). The case was remanded for a damages trial on a claim that, according to press reports, Oracle valued in the billions of dollars.

2021: the Supreme Court holds fair use as a matter of law

The Supreme Court reversed, 6 to 2, in an opinion by Justice Breyer. Justice Thomas, joined by Justice Alito, dissented. Justice Barrett did not participate.

The Court began by declining to decide copyrightability. It assumed, "for argument's sake, that the material was copyrightable," and held that Google's copying "nonetheless constituted a fair use." It then made two procedural rulings that matter in every later case. Fair use is a mixed question of law and fact; a reviewing court defers to the jury's findings on subsidiary facts, but the ultimate question whether those facts amount to fair use is primarily legal and reviewed de novo. And the Seventh Amendment did not prevent the Court from deciding the question itself.

On the merits, the Court took the factors out of their usual order.

Nature of the work. The Court started with the second factor, which is usually the least important, and made it central. Declaring code, it said, is different from most code: it is "inextricably bound together" with a general system, the division of computing tasks, that no one claims is a proper subject of copyright, and with the uncopyrightable idea of organizing tasks into packages and classes, as well as with new creative expression (the implementing code Google wrote). Its value derives in significant part from the investment of users (programmers) who have learned the system. The Court concluded that declaring code is, "if copyrightable at all, further than are most computer programs (such as the implementing code) from the core of copyright." This is the passage that does the most work for future interface cases.

Purpose and character. Google copied the declarations to let programmers use their accrued skills in a new and different computing environment (smartphones), as part of a new platform. The Court held that use transformative even though the declarations served the same function in both products, because "a 'transformative' use is one that adds something new and important," and reimplementing an interface to enable new programs on a new platform does that. The Court noted that reimplementation of interfaces is common in the industry and that commercial purpose does not by itself defeat fair use.

Amount and substantiality. The 11,500 lines were about 0.4 percent of the 2.86 million lines in the Java SE API. The Court measured them against the whole API, not against the 37 packages alone, and said Google copied them because they were tied to the skills programmers had acquired, not because of their creativity or beauty. Copying only what is needed for a valid purpose does not weigh against fair use.

Market effect. The jury could have found that Android was not a market substitute for Java SE, which Sun had been unable to make succeed on smartphones, and that Sun stood to benefit from Android's expansion of the Java programmer community. The Court added that the value of the declarations to Oracle came largely from programmers' investment in learning them, and that enforcing copyright here would make Oracle's interface "a lock limiting the future creativity of new programs," a risk of harm to the public that counted against Oracle.

The Court's closing sentence states the holding precisely: Google's copying of the Java SE API, "which included only those lines of code that were needed to allow programmers to put their accrued talents to work in a new and transformative program, was a fair use of that material as a matter of law."

Justice Thomas's dissent argued that the Court should have decided copyrightability and held the declarations protected, that declaring code is not meaningfully different from implementing code because the declarations are what make the implementing code useful, and that Google's use was neither transformative nor harmless, since it eroded Oracle's licensing market for mobile devices. Owners still cite the dissent, and it is a useful catalog of the arguments that remain available where the facts differ.

For a broader treatment of the four factors and what Andy Warhol Foundation for the Visual Arts, Inc. v. Goldsmith, 598 U.S. 508 (2023) later did to the first factor, see Copyright Fair Use: The Four Factors, Transformative Use, and What Warhol Changed.

What Google did not decide

Read carefully, Google leaves four large questions open.

Copyrightability. The Court assumed it and moved on. The Federal Circuit's 2014 holding that the Java declarations are copyrightable was never reviewed, and the Supreme Court reversed the judgment on fair use grounds. Lawyers disagree about how much weight the 2014 opinion still carries. It is a Federal Circuit prediction of Ninth Circuit law, it does not bind the Ninth Circuit, and its premise sits uneasily with the Supreme Court's description of declaring code as "inextricably bound" to uncopyrightable ideas. But no court of appeals has repudiated it, and an owner with a case in the Federal Circuit (because it also asserts patents) will cite it.

How far the reasoning extends. The holding is tied to facts: an API used by millions of programmers, copying limited to declarations, entirely new implementing code, a new platform, and a market the owner had failed to enter. A project that copies more than declarations, targets the owner's core market with a substitute, or reimplements an interface few programmers have invested in learning will need to argue Google by analogy, not by direct application.

The effect of Warhol. Two years after Google, the Court held in Warhol that the first factor asks whether the use has a further purpose or different character, and that the degree of difference must be weighed against the commercial nature of the use, particularly when the use substitutes for the original in the same market. The Warhol majority cited Google with approval and distinguished it as a case where the copying was needed to achieve a new purpose. Owners now argue that a compatible product sold to the owner's own customers, for the same purpose, is a substitute under Warhol. Implementers respond that Google already decided that reimplementation for compatibility can be transformative even when the declarations serve the same function. This is the most important unresolved argument in post-Google interface litigation. For the factor-by-factor method, see Conducting a Fair Use Analysis: A Practical Guide.

Everything outside copyright. Google had nothing to say about contracts, anti-circumvention, computer access, trade secrets, or patents. As discussed below, those are where most interface disputes are now fought.

After Google: what courts have done since 2021

The post-2021 appellate record on interfaces is thin, but the cases that exist point in one direction: plaintiffs must do the filtration work, and interoperability alone is not infringement.

SAS Institute v. World Programming. World Programming Ltd. (WPL), a British company, built the World Programming System, which runs programs written in the SAS language. SAS sued in England, where the Court of Justice of the European Union held in 2012 that the functionality of a program, its programming language, and its data file formats are not protected expression under the EU Software Directive, and WPL largely prevailed. SAS then sued in the United States. In the Eastern District of Texas, Judge Gilstrap held a copyrightability hearing and required SAS to identify the protectable elements of its software after filtration. Once WPL produced evidence that the asserted elements fell outside copyright protection, the court required SAS to show they were protectable, applied the abstraction-filtration-comparison test, rejected SAS's expert report, and dismissed the copyright claim with prejudice. Over a dissent by Judge Newman, the Federal Circuit affirmed, approving the copyrightability hearing as a reasonable case-management tool and the burden-shifting the district court applied. SAS Institute, Inc. v. World Programming Ltd., 64 F.4th 1319 (Fed. Cir. 2023). SAS fared better in separate litigation in North Carolina on contract and unfair trade practice theories arising from WPL's use of a SAS Learning Edition license: the Fourth Circuit affirmed the judgment that WPL breached the license's terms, including its ban on reverse engineering, and the damages award, SAS Institute, Inc. v. World Programming Ltd., 874 F.3d 370 (4th Cir. 2017). That is itself a lesson about where the real exposure lies.

Oracle v. Rimini Street. Rimini Street provides third-party support for Oracle's enterprise software. In December 2024, the Ninth Circuit held, in a long-running dispute between the companies, that a program is not a derivative work of Oracle's software merely because it interoperates with or is designed to work only with that software; a derivative work must actually incorporate protected expression from the original in some concrete or permanent form. Oracle International Corp. v. Rimini Street, Inc., 123 F.4th 986 (9th Cir. 2024). The panel rejected what it called an "interoperability" test for derivative works and remanded for the district court to apply the correct standard under 17 U.S.C. § 101 and 17 U.S.C. § 106(2). Read with the Supreme Court's earlier, unrelated holding in the same litigation that "full costs" under 17 U.S.C. § 505 means only taxable costs, Rimini Street, Inc. v. Oracle USA, Inc., 586 U.S. 334 (2019), it shows how long and expensive software interoperability litigation can become even when the defendant ultimately narrows the claims.

Filtration as the plaintiff's job. District courts since 2021 have generally required software plaintiffs to identify, element by element, what they claim was copied and why it is protectable after filtration. That trend predates Google in the Ninth Circuit, where a software plaintiff who never put the source code in evidence could not prove substantial similarity, Antonick v. Electronic Arts, Inc., 841 F.3d 1062 (9th Cir. 2016). For how filtration charts and expert reports are built, see Copyright Infringement Litigation Toolkit: Similarity Charts, Expert Reports, and Filtration Analyses and Litigating Substantial Similarity in a Copyright Case: A Practical Guide.

A jury on command-line interfaces. In a widely followed 2016 trial in the Northern District of California, a jury rejected Cisco's claims that Arista Networks infringed copyrights in Cisco's command-line interface for network switches, accepting Arista's scènes à faire defense that the commands had become industry standard. The verdict is not precedent, but it tracks Lotus and Mitel and shows how a jury reacts when an owner encourages an industry to learn its commands and then sues a competitor for using them.

The walls outside copyright

A compatibility project that clears copyright can still fail on any of five other grounds. Courts have treated each as independent: winning on fair use does not answer a contract, DMCA, CFAA, trade secret, or patent claim. The clearance steps for each are collected in the Software Interoperability and Reverse Engineering Clearance Checklist: A Practical Checklist.

Contract: the license may forbid what copyright allows

The most important practical fact in this field is that a license term prohibiting reverse engineering is usually enforceable in the United States, even when the reverse engineering itself would be fair use.

In ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996), the Seventh Circuit enforced a shrinkwrap license limiting use of a telephone directory database to noncommercial purposes and held that contract rights, which bind only the parties, are not "equivalent" to copyright and so not preempted by 17 U.S.C. § 301. The Federal Circuit applied the same logic to reverse engineering in Bowers v. Baystate Technologies, Inc., 320 F.3d 1317 (Fed. Cir. 2003), holding (under First Circuit law) that a shrinkwrap prohibition on reverse engineering was not preempted and upholding a breach of contract award against a competitor that had reverse engineered the plaintiff's CAD add-on. Judge Dyk dissented, arguing that a state law allowing a shrinkwrap to override fair use would let mass-market licensors abolish a federal defense. The Eighth Circuit followed Bowers in Davidson & Associates v. Jung, 422 F.3d 630 (8th Cir. 2005), enforcing Blizzard's end-user license and terms of use against volunteer programmers who reverse engineered the Battle.net protocol to build a compatible server.

The counterweight is older and narrower. In Vault Corp. v. Quaid Software Ltd., 847 F.2d 255 (5th Cir. 1988), the Fifth Circuit held preempted a Louisiana statute that made license terms prohibiting decompilation enforceable, because the statute conflicted with the rights section 117 gave owners of copies. Vault concerned a state statute, not a negotiated contract, and most courts have read it narrowly.

Contract claims require a contract, and formation is where many defenses live. A browsewrap notice that users never had to see may not bind them, Specht v. Netscape Communications Corp., 306 F.3d 17 (2d Cir. 2002); Nguyen v. Barnes & Noble Inc., 763 F.3d 1171 (9th Cir. 2014). A company that never accepted the license, because it bought a used copy, obtained the information from a published specification, or studied a customer's installation with the customer's permission, may not be bound at all. But people carry contractual obligations from job to job in practice, if not always in law, and the founders who clicked "I agree" at a former employer create a factual problem even when the legal one is manageable. For contract formation online, see Website Terms of Service and Online Contract Formation: Clickwrap, Browsewrap, and Enforceable Arbitration; for license terms generally, see Drafting Software License Agreements: Key Terms and Negotiation Points.

The contrast with Europe is sharp. Article 6 of the EU Software Directive (Directive 2009/24/EC) permits decompilation by a lawful user when indispensable to obtain information necessary to achieve interoperability of an independently created program, subject to conditions (the information must not be readily available, the decompilation must be confined to the necessary parts, and the information may not be used to build a substantially similar program). Article 5(3) lets a lawful user observe, study, and test a program to determine its underlying ideas. Article 8 makes contract terms contrary to those provisions void. A license term that is enforceable in Texas may be void in Germany, and multinational projects should be structured with that in mind.

The DMCA: circumvention is its own violation

Section 1201 prohibits circumventing a technological measure that effectively controls access to a copyrighted work, and trafficking in tools that do so, separately from any infringement. 17 U.S.C. § 1201. Civil remedies, including statutory damages per act of circumvention, are in 17 U.S.C. § 1203, and willful violations for commercial advantage are crimes under 17 U.S.C. § 1204.

Section 1201(f) is the interoperability exemption. A person who has lawfully obtained the right to use a copy of a program may circumvent an access control for the sole purpose of identifying and analyzing the elements necessary to achieve interoperability of an independently created program with other programs, if those elements have not been readily available and the acts do not constitute infringement. The person may develop the tools to do so, and may share the information or the tools with others solely for interoperability, again to the extent it is not infringement or a violation of other law. "Interoperability" means the ability of programs to exchange information and to use the information exchanged.

The exemption is narrower than it reads. In Davidson, the Eighth Circuit held it unavailable to the bnetd developers because their server let unauthorized copies of Blizzard's games play online, so the circumvention facilitated infringement and fell outside an exemption limited to acts that are not infringing. Courts also disagree about whether section 1201(a) requires any connection to infringement at all. The Federal Circuit held that a plaintiff must show the circumvention infringes or facilitates infringement of a protected right, Chamberlain Group, Inc. v. Skylink Technologies, Inc., 381 F.3d 1178 (Fed. Cir. 2004), which rejected a garage-door maker's attempt to use the DMCA to block compatible remote controls. The Ninth Circuit rejected that nexus requirement in MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010). And the Sixth Circuit held that a printer lockout scheme did not "effectively control access" to a program that anyone could read from the chip, Lexmark International, Inc. v. Static Control Components, Inc., 387 F.3d 522 (6th Cir. 2004), while also holding the small Toner Loading Program likely unprotectable because its expression merged with functional and compatibility constraints. The Librarian of Congress adds temporary exemptions every three years, codified at 37 C.F.R. § 201.40, including exemptions for good-faith security research and certain repair and diagnosis. For the full architecture, see The DMCA Anti-Circumvention Provisions: Section 1201, Digital Locks, and the Triennial Exemptions.

The CFAA: interfaces that live on someone else's server

When the interface is a network service, the reverse engineer is often sending requests to someone else's computer. The Computer Fraud and Abuse Act, 18 U.S.C. § 1030, prohibits accessing a computer "without authorization" or "exceeding authorized access." Van Buren v. United States, 593 U.S. 374 (2021), decided seven weeks after Google, adopted a "gates-up-or-down" reading: a person exceeds authorized access by entering areas of a computer that are off limits to him, not by having an improper purpose for accessing information he is entitled to reach. On remand in the scraping dispute, the Ninth Circuit reaffirmed that accessing publicly available data is likely not access "without authorization." hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022). But a specific revocation of permission, such as a cease-and-desist letter followed by circumvention of an IP block, can make continued access unauthorized. Facebook, Inc. v. Power Ventures, Inc., 844 F.3d 1058 (9th Cir. 2016). A project that probes a vendor's cloud API with test credentials it was issued is in a very different position from one that keeps going after its account is terminated. See Data Scraping After hiQ v. LinkedIn: Copyright, Contract, and Computer Fraud Claims.

Trade secrets: reverse engineering is a proper means, unless something else is not

Trade secret law has always tolerated reverse engineering. The Supreme Court said in 1974 that trade secret law "does not offer protection against discovery by fair and honest means, such as by independent invention, accidental disclosure, or by so-called reverse engineering, that is by starting with the known product and working backward." Kewanee Oil Co. v. Bicron Corp., 416 U.S. 470 (1974). In Bonito Boats, Inc. v. Thunder Craft Boats, Inc., 489 U.S. 141 (1989), the Court struck down a state statute banning the copying of boat hulls by direct molding, describing reverse engineering of unpatented products as an essential part of innovation and holding that states may not offer patent-like protection to unpatented designs. The Defend Trade Secrets Act codifies the point: "improper means" does not include "reverse engineering, independent derivation, or any other lawful means of acquisition." 18 U.S.C. § 1839(6)(B).

The protection depends on the word "lawful." Reverse engineering a product bought on the open market is lawful. Reverse engineering in breach of a license that prohibits it is harder to defend: "improper means" expressly includes misrepresentation and breach of a duty to maintain secrecy, and using a secret acquired under circumstances giving rise to a duty to limit its use is misappropriation under § 1839(5). Courts have not settled whether reverse engineering that breaches a license is "lawful" within § 1839(6)(B), and a plaintiff will argue it is not. And the most common trade secret problem in compatibility projects has nothing to do with reverse engineering: it is the engineer who joins from the interface owner and brings knowledge of non-public internals. For the full trade secret framework, see Trade Secret Misappropriation Litigation Under the Defend Trade Secrets Act: A Practical Guide.

Patents: no reverse-engineering defense, no independent-creation defense

A patent on an interface-related method (a compression scheme a file format requires, a protocol handshake, a way of dispatching method calls) is infringed by anyone who makes, uses, or sells the claimed invention, however it was developed. 35 U.S.C. § 271. A clean room does not help, and neither does fair use. The defenses are invalidity (including subject matter eligibility under Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), which has eliminated many software patents but not those directed to specific improvements in computer functionality, Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016)), non-infringement, license (including standards-body licensing commitments and open-source patent grants), and exhaustion. Oracle's patent claims against Google failed at trial in 2012, but they were the reason the copyright appeal went to the Federal Circuit. For eligibility, see Patent Eligibility After Alice: Strategies for Protecting Software and Business Method Innovations.

Clean rooms: why they work and where they stop

Copyright infringement requires copying. A plaintiff proves copying circumstantially, with evidence of access and similarities probative of copying, and then must prove that what was copied was protected expression and that the works are substantially similar in that expression. Independent creation is a complete defense; as Feist Publications, Inc. v. Rural Telephone Service Co., 499 U.S. 340 (1991) put it, a work may be original even if it closely resembles another, so long as the similarity is fortuitous and not the result of copying. For the elements of proof, see Proving Copyright Infringement: Access, Substantial Similarity, and the Tests Courts Actually Use.

A clean room is a way of manufacturing proof of independent creation. One team (the "dirty" team) studies the target, through documentation, observation, testing, and where lawful, disassembly, and writes a functional specification that describes what the compatible product must do without containing any of the target's code or expressive structure. A reviewer (often a lawyer, sometimes called the gatekeeper) screens the specification for protected expression. A separate "clean" team, whose members have never been exposed to the target's code, writes the implementation from the specification alone. Everyone keeps records. If the owner later sues, the implementer can show that the people who wrote the code had no access to the protected expression, which defeats the inference of copying, and that any similarities flow from the functional requirements in the specification.

The technique has a famous history. In the early 1980s, Compaq and then Phoenix Technologies built IBM PC-compatible BIOS firmware this way, with engineers who studied the IBM BIOS writing specifications and separate engineers, chosen for their lack of exposure to IBM's code, writing the implementation. Phoenix licensed its BIOS widely, and the resulting clone market is often credited to the method. In NEC Corp. v. Intel Corp., 10 U.S.P.Q.2d 1177 (N.D. Cal. 1989), a dispute over NEC's microcode for its Intel-compatible V20 and V30 processors, NEC presented a clean-room version of the microcode written by an engineer who had not seen Intel's microcode, and the similarities that resulted helped persuade the court that the overlap was dictated by the hardware and not the product of copying. And as noted above, Altai's rewrite of OSCAR in Altai was a clean room in all but name.

Clean rooms also address the problem of subconscious copying: a person who has studied the original may reproduce its expression without meaning to, which still infringes. Bright Tunes Music Corp. v. Harrisongs Music, Ltd., 420 F. Supp. 177 (S.D.N.Y. 1976), is the classic example, and software experts see the same pattern in variable names, comments, and quirks of structure carried from one codebase to another.

The limits are just as important.

• A clean room does not cure what the dirty team did. If the dirty team breached a license, circumvented a technical measure without an exemption, accessed a server without authorization, or used misappropriated trade secrets, the clean team's independence does not erase the claim. Atari lost on the fair use of its intermediate copying because of how it obtained the code, not because of what its final product contained.
• A clean room does not defeat patents. Independent development is not a defense to patent infringement.
• The specification can carry the infection. A specification that reproduces the target's structure in detail, or that quotes its documentation, transmits protected expression to the clean team. The gatekeeper's review is the point of the process, not a formality.
• The records will be discovered. A clean room's value depends on contemporaneous documentation that will be produced in litigation. Communications routed through counsel may be privileged, but a party that relies on its clean room as a defense will be expected to produce the materials that show how it worked, and selective assertion of privilege over clean-room records invites a waiver fight under Fed. R. Evid. 502. Design the process so that its records can be produced.
• After Google, a clean room may protect more than copyright requires. An implementer that only copies declarations and writes its own implementation may not need one for copyright purposes. But it rarely knows in advance which side of the line every element falls on, and the trade secret and contract benefits of team separation are independent of copyright.

The step-by-step method is in Running a Clean Room Software Development Project: A Practical Guide, and the forms (protocol, certifications, specification records, gatekeeper logs) are in Clean Room Toolkit: Protocols, Team Certifications, and Specification Records.

AI coding assistants and the clean room

AI coding assistants raise two separate questions for interface projects.

The first is contamination. A clean team member who asks an assistant to "write a function that behaves like CorvidProc.SORT" may receive code the model learned from the target's own source, if that source was public (open-source projects, leaked repositories, code samples in documentation). If the output reproduces protected expression, the clean team now has access to it, through the tool, and the inference of copying returns. The risk is highest where the target's implementation is widely published and lowest where it is proprietary and never left the owner's servers. Copyright Office guidance on AI (including its January 2025 report on copyrightability) does not address the issue directly, and litigation over coding assistants, most prominently Doe v. GitHub, Inc. in the Northern District of California, had by early 2025 narrowed to a small number of claims, including a contested question under 17 U.S.C. § 1202 about whether removal of copyright management information requires identical copies. The district court read the statute to require identicality and certified that question for interlocutory appeal to the Ninth Circuit, so check for the appellate ruling before relying on the district court's reading.

The second is the record. A clean room's defense depends on showing what each implementer saw. Assistant prompts and outputs are part of what the implementer saw. A protocol that does not log them, or that allows the clean team to use a tool configured to search the open internet or the company's own dirty-team repositories, has a hole in it. The practical controls are straightforward: an approved tool list, enterprise configurations that retain prompts and outputs, duplicate-detection or code-reference filters turned on, a prohibition on pasting target code or documentation into prompts, and separate tool workspaces for the dirty and clean teams. Trade secret risks of the same tools, from the other direction, are covered in Trade Secrets and Generative AI: Reasonable Measures, Prompt Leakage, and Vendor Terms.

Open source, specifications, and licensed interfaces

Many interfaces are not proprietary at all. They are published as open specifications (HTTP, SQL standards, file formats with public documentation), implemented by open-source reference code, or offered under specification licenses with patent commitments. Three points matter.

An open-source license on the implementation does not necessarily license the interface separately. If a reference implementation is under a copyleft license, copying its code, including its header files or declaration files, brings the license with it. Reimplementing the interface from the specification, without copying the code, raises the Google question rather than a license question. Courts enforce open-source license conditions as copyright conditions, Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), so the distinction is not academic. See Open Source Software: Licenses, Compliance, and Risk.

Specification licenses and standards commitments often answer the patent question. A standards body's licensing commitment or a specification's patent grant may cover implementers. Read the scope: many grants cover only "compliant" implementations and terminate on patent assertion.

Some owners license interfaces expressly. A few interface owners publish their APIs under licenses that permit independent implementation. That is a business decision and a strong signal; it is also a contract, and its conditions control.

Splits and open questions

Practical implications

For the implementer

Copy facts and function, write everything else. After Google, a project that copies only what compatibility requires (names, parameters, order, file layouts, protocol messages, error codes) and writes its own implementing code and documentation has a strong fair use position, and in many circuits a strong argument that the copied material was never protected. Copy the documentation's facts, not its prose.

Get the copy lawfully, and stay within your license or outside it entirely. The most dangerous facts in this field are acquisition facts: a copy obtained by misrepresentation, a license someone on the team accepted that bans reverse engineering, credentials used after they were revoked. Inventory who on the team has accepted the target's license, under which entity, and on what terms.

Prefer observation to decompilation. Studying documentation, running the program, capturing network traffic between the program and a server you control, and testing inputs and outputs are lawful in more circumstances than disassembly, and they often yield everything the specification needs. Decompile only after a legal review confirms the copy, the license, and any DMCA exemption.

Separate the teams and document it. A clean room is cheap insurance against the claim that the implementation copied code, and it is the best answer to a trade secret claim built on employee mobility. It is useful even when copyright exposure is low.

Run a patent search on the functionality you must match. Copyright clearance says nothing about patents, and a compatibility requirement (a codec, a compression algorithm, a protocol feature) may be covered.

Watch your marketing. Saying the product is "compatible with Corvid" is generally permissible nominative use of a trademark. Saying it is "Corvid" or using Corvid's logo is not. Courts and juries read marketing materials to decide whether the purpose was compatibility or substitution, and under Warhol that matters.

For the interface owner

Do not count on copyright to stop reimplementation. After Google, an owner whose interface has been widely adopted by programmers will have difficulty showing that a reimplementation is unfair, and in many circuits will have difficulty showing the interface is protectable. Copyright remains strong against copying of implementing code, documentation prose, and non-literal structure beyond what compatibility requires.

Use contracts deliberately. License terms on developer kits, trial versions, and enterprise licenses can prohibit reverse engineering and building competing products, and in most United States courts they will be enforced against the licensee. Consider whether the terms reach the people who will actually build the competing product, and whether European law voids them.

Patent what is genuinely new. A specific technical improvement in how an interface works can be patented if it clears Alice, and a patent is the only tool that reaches a truly independent reimplementation.

Keep non-public internals secret. Source code, internal design documents, and roadmap features are trade secrets if reasonably protected. The likeliest leak is a departing engineer, not a reverse engineer. See Employee Departure Trade Secret Protection Checklist: A Practical Checklist.

Use trademarks and certification for what copyright cannot do. An owner that cannot stop compatible implementations can still control the use of its name, run a certification program for compatibility claims, and compete on being the reference implementation.

Think about what you encourage. Lotus, Google, and the Cisco jury all rested in part on the owner's success in persuading users to invest in learning its interface. An owner that promotes its interface as an industry standard and then sues competitors for using it faces a story that juries and judges have repeatedly found unpersuasive.

An extended worked example: Tessellate and the Corvid language

Return to Tessellate. Its plan is to build an engine that runs programs written in Corvid's proprietary language, reads and writes Corvid's data file format, and accepts the same procedure names and options. Here is how a careful plan comes together, and where the risk remains.

Step 1: what will be copied. Tessellate's engineers list the elements a compatible engine must reproduce: the language's grammar and keywords; about 400 procedure names and their options; the data file format; the format of log output that customers parse with their own scripts; and error codes. They also list what they do not need: Corvid's implementing code, its manuals' prose, its graphical interface layout, and its internal algorithms for procedures where outputs need only be statistically identical, not bit-for-bit identical.

Step 2: copyright analysis. Tessellate's lawyers conclude that the language grammar and keywords are very likely unprotectable functionality, consistent with the reasoning that prevailed for WPL in Europe and in SAS; that the procedure names and options are the closest analog to Java's declaring code and present a strong fair use case under Google (and a strong filtration argument in the Fourth Circuit, which would hear a North Carolina case, though the Fourth Circuit has not addressed interfaces directly); that the file format is functional and its specification can be derived from observing files; and that the log format is a closer case, because some of Corvid's formatting choices are arbitrary. Tessellate decides to replicate the log format only to the extent customers' scripts depend on it, and to document why each element is needed.

The Warhol argument is real: Tessellate will sell to Corvid's own customers, for the same purpose, at a lower price. Tessellate's counsel builds the record that distinguishes the use: customers' investment in scripts (the Lotus and Google "lock-in" point), the addition of features Corvid does not offer, and the absence of any copying of implementing code.

Step 3: contract. Two of Tessellate's founders accepted Corvid's license at a former employer, and Tessellate itself holds a Corvid academic license used by an intern program. The academic license prohibits reverse engineering and commercial use. Tessellate's counsel concludes that the founders are not personally bound to the former employer's license for Tessellate's work, but that their knowledge of Corvid's non-public behavior from that period should not reach the clean team. Tessellate terminates the academic license, quarantines everyone who used it, and buys no new license. Instead, it obtains a written agreement with a customer, a regional insurer that holds an enterprise license, under which Tessellate engineers may observe the insurer's own Corvid installation running the insurer's own scripts, with the insurer's counsel confirming that its license permits that use. (If it does not, this route closes too.)

Step 4: DMCA and CFAA. Corvid's desktop engine uses a license-key check. Tessellate's plan does not require circumventing it: the dirty team works only from documentation, the insurer's observed outputs, published books about the Corvid language, and files the insurer creates. Corvid's cloud service is off limits; no Tessellate employee may create an account.

Step 5: trade secrets. Tessellate hires a former Corvid engineer for its sales team. Counsel walls her off from the engineering project entirely, documents the wall, and confirms she returned all Corvid materials when she left.

Step 6: the clean room. The dirty team (three engineers and a statistician) writes a functional specification for each procedure: inputs, options, outputs, edge cases, and error behavior, described in Tessellate's own words. A lawyer reviews each specification entry and removes anything that reads as Corvid's documentation or reflects internal structure not visible from outputs. The clean team (eight engineers, each of whom certifies no prior exposure to Corvid's code or manuals beyond public marketing materials) writes the engine from the specifications. Clean-team questions go to the gatekeeper in writing, and answers come back in writing. The clean team's AI coding assistant runs on an enterprise plan with prompt logging and a code-reference filter, and the protocol bans mentioning Corvid in prompts.

Step 7: patents. A freedom-to-operate search finds a Corvid patent on a method of distributing a particular procedure's computation across nodes. Tessellate designs around it by using a different parallelization method and documents the design-around.

Step 8: what remains. When Corvid's demand letter arrives eighteen months later, it alleges copyright infringement of the language, the procedure names, and the log format, breach of the academic license, and trade secret misappropriation. Tessellate's answer is a binder: the element list with the reason for each, the specification with the gatekeeper's notes, clean-team certifications, the license termination and quarantine records, the insurer agreement, the ethical wall for the former Corvid engineer, and the design-around memo. The copyright claim on the language and procedure names faces Google and SAS. The log-format claim is narrower and more contestable. The academic-license claim is the most dangerous, which is why Tessellate's records show that no one who used it touched the project after the quarantine date. The trade secret claim depends on what the former engineer did, and the wall is the answer.

None of this guarantees that Corvid will not sue. It does make the suit expensive for Corvid to win, and it is what a court will want to see. The clean room steps are expanded in Running a Clean Room Software Development Project: A Practical Guide.

Common mistakes

Treating Google as holding that APIs are not copyrightable. It did not. It assumed they were and held one reimplementation fair. Advice that says "APIs are free to copy" overstates the law.

Copying the documentation along with the interface. Reference manuals, tutorials, and code samples are ordinary literary works. Paraphrasing a manual entry by entry is copying. Describe the behavior in your own words, from observation, or from a specification written by someone else.

Ignoring the license someone already accepted. The fair use analysis is irrelevant to a breach of contract claim in most United States courts. Find out who accepted what, and when.

Decompiling first and asking later. Disassembly is the most legally exposed form of reverse engineering. Exhaust documentation, observation, and testing first.

Letting the clean team "just take a look." A single exposure to the target's code can contaminate an engineer for the rest of the project. Once exposed, move the person to the dirty team or off the project, and record it.

Forgetting patents. A perfect clean room does nothing against a valid patent.

Over-copying for convenience. Google emphasized that Google copied only what programmers needed. Copying undocumented internal names, private methods, or arbitrary formatting that no customer relies on undercuts that argument and adds nothing commercially.

Assuming European rules apply in the United States, or the reverse. Article 6 of the Software Directive and Article 8's ban on contrary contract terms have no United States counterpart. A plan built on one jurisdiction's rules will fail in the other.

Frequently asked questions

Did Google v. Oracle make APIs uncopyrightable? No. The Court assumed, without deciding, that the Java declaring code was copyrightable and held Google's use fair. Whether interfaces are copyrightable still depends on the circuit and the element: the First Circuit treats command hierarchies as methods of operation, the Federal Circuit has held the Java declarations protectable, and most courts filter interface elements out under Altai.

Can a company build a product that is compatible with a competitor's software? Generally yes, if it writes its own code, copies only what compatibility requires, obtains information lawfully, and does not infringe patents. The most frequent obstacles are license terms, anti-circumvention rules, and trade secrets brought by former employees, not copyright in the interface.

Is decompiling software legal? Copying a program while disassembling it to learn unprotected interface information has been held fair use in the leading Ninth Circuit cases, Sega and Connectix, when there is no other way to get the information and the copy was lawfully obtained. But a license term prohibiting decompilation is likely enforceable, and circumventing an access control to decompile may violate section 1201 unless the interoperability exemption or a triennial exemption applies.

What is a clean room, and is it legally required? It is a development process that separates the people who study the target from the people who write the new code, with a reviewed specification in between. No statute requires it. Its purpose is evidentiary: it shows that the implementers had no access to the protected expression, which defeats the inference of copying. It is most valuable where implementing code or detailed structure is at risk and where former employees of the target are involved.

Does fair use protect a compatible product that competes directly with the original? Possibly. Google held Android's use fair partly because Android was not a substitute for Java SE in the markets Sun had pursued. Warhol emphasized substitution in the first factor. A compatible product sold to the same customers for the same purpose will face a harder fair use argument than Android did, and should be built so that it also wins on copyrightability and filtration.

Do European rules differ? Yes. The EU Software Directive permits decompilation for interoperability under defined conditions, permits observing and testing a program, and voids contract terms to the contrary. The Court of Justice held in the SAS litigation that functionality, programming languages, and data file formats are not protected as such. United States law is more favorable to owners on contracts and less clear on copyrightability.

Are AI coding tools a problem for clean-room development? They can be. If a tool reproduces the target's code that it learned from public sources, the clean team has been exposed to it. Use enterprise tools with logging and code-reference filters, prohibit prompts that reference the target, and keep the logs with the clean-room records.

Takeaways

• Google v. Oracle gives implementers a strong fair use path for reimplementing interfaces, built on four reasons: declaring code is far from copyright's core, reimplementation for new platforms is transformative, copying limited to what programmers need is reasonable, and the interface's value comes from users' investment.
• Copyrightability of interfaces remains unresolved nationally. Build projects that win on both copyrightability and fair use.
• Contract, DMCA, CFAA, trade secret, and patent claims are independent of copyright and now carry most of the risk.
• Reverse engineering is lawful and often fair, but only from a lawfully obtained copy and within what the purpose requires.
• A documented clean room is the best evidence of independent creation. It does not cure acquisition problems and does nothing for patents.
• Owners who want to control compatible implementations should rely on contracts, patents, trade secrets, and trademarks, not on copyright in the interface.

This document is general information, not legal advice for any particular situation; the law changes, and the facts matter.

Related Documents

Related Articles

• Legal Protection of Software: Copyrights, Patents, Trade Secrets, and Contracts: the four protection regimes that interface disputes draw on.
• The DMCA Anti-Circumvention Provisions: Section 1201, Digital Locks, and the Triennial Exemptions: the anti-circumvention rules and exemptions in full.
• Copyright Fair Use: The Four Factors, Transformative Use, and What Warhol Changed: how Warhol reshaped the first factor that Google relied on.
• Data Scraping After hiQ v. LinkedIn: Copyright, Contract, and Computer Fraud Claims: CFAA and contract limits on working with network interfaces.
• Trade Secrets and Generative AI: Reasonable Measures, Prompt Leakage, and Vendor Terms: AI tool risks from the trade secret side.
• Proving Copyright Infringement: Access, Substantial Similarity, and the Tests Courts Actually Use: the access and similarity proof a clean room is designed to rebut.
• Failed Software Implementations: Contract, Fraud, and Warranty Claims When an IT Project Goes Wrong: failed technology projects and the contract, warranty, and fraud claims that follow.

Related Guides

• Running a Clean Room Software Development Project: A Practical Guide: the step-by-step method for the clean room described here.
• Litigating Substantial Similarity in a Copyright Case: A Practical Guide: filtration and comparison in litigation.
• Conducting a Fair Use Analysis: A Practical Guide: applying the four factors to a specific project.
• Trade Secret Misappropriation Litigation Under the Defend Trade Secrets Act: A Practical Guide: the trade secret claims that follow employee mobility.
• Pursuing or Defending a Failed Technology Project Claim: A Practical Guide: failed technology projects and the contract, warranty, and fraud claims that follow.

Related Checklists

• Software Interoperability and Reverse Engineering Clearance Checklist: A Practical Checklist: clearance across copyright, contract, DMCA, CFAA, trade secret, and patent.
• Employee Departure Trade Secret Protection Checklist: A Practical Checklist: the owner's side of the former-employee problem.
• Open Source Software Compliance Checklist: A Practical Checklist: license obligations when the interface comes with open-source code.
• Troubled Technology Project Checklist: A Practical Checklist: failed technology projects and the contract, warranty, and fraud claims that follow.

Related Toolkits

• Clean Room Toolkit: Protocols, Team Certifications, and Specification Records: the forms behind a defensible clean room.
• Copyright Infringement Litigation Toolkit: Similarity Charts, Expert Reports, and Filtration Analyses: filtration worksheets for software cases.
• Software and Open Source Licensing Toolkit: From IP Layers to Compliance Programs: license terms that govern interfaces and their implementations.
• Technology Project Dispute Toolkit: Notice of Breach Letters, Cure Plans, and Project Record Protocols: failed technology projects and the contract, warranty, and fraud claims that follow.