Clean-room design is a way of building software that works like, or is compatible with, an existing product without copying that product’s code. A US appeals court described it in 1992 as a procedure used in the computer industry to prevent direct copying of a competitor’s code during the development of a competing product, in which the programmers are given only the functional specifications for the desired program.[1] The method is also called a “Chinese wall” approach in industry usage, referring to the separation between the people who see the original and the people who write the new code. The cited opinions describe the procedure as an industry practice, and none of the sources cited here treats it as a statutory requirement.
The method sits at the point where copyright, trade secret law and licence terms meet. Copyright protects expression and not ideas, functions or methods of operation.[2] A compatible product therefore needs to reproduce functions but not expression. A clean-room process is a way to show that it did so. Licence clauses that forbid reverse engineering can still limit how the original is studied, and the law on how far those clauses can go differs between the United States and the European Union.
The two-team structure
A clean-room project typically has two separated roles. This description follows the courts’ accounts and the practice they reflect, and it is not a legal standard:
- Specification. A group examines the existing product through permitted means, such as published documentation, observation of its behaviour and testing, and writes a description of what it does. In Sega v. Accolade, the court said programmers in a clean room get only functional specifications.[1]
- Implementation. A second group, which has not seen the original code, writes new code from the specification.
The separation matters because a claim of copying often depends on access to the original. Courts look at the result as well as the process: whether the new program is substantially similar in protected expression to the original.[2]
Altai: a documented rewrite
Computer Associates v. Altai is the standard primary-source example on this wiki; see Computer Associates International, Inc. v. Altai, Inc. for the full case. The opinion does not use the words “clean room” for what Altai did, so the following is a description of the facts as the court recorded them, not a label the court applied.
A Computer Associates programmer named Arney had taken the source code of a component called ADAPTER and used it to write Altai’s OSCAR component. After Altai received the complaint and learned about the copying, its manager started a rewrite on the advice of counsel. The court recorded that Arney was entirely excluded from the process and his copy of the ADAPTER code was locked away. Eight other programmers, none of whom had been involved in developing OSCAR 3.4, were given a description of the ZEKE operating system services and rewrote the affected code over about six months, producing OSCAR 3.5.[2]
The Second Circuit agreed with the district court that OSCAR 3.5 did not infringe the protected expression in ADAPTER. The court noted that after the purge none of the ADAPTER source code remained in version 3.5, so the literal elements were no longer substantially similar. It then examined the non-literal structure using the three-step abstraction-filtration-comparison test.[2]
Abstraction, filtration and comparison
The test is what makes a clean-room result measurable under copyright law:[2]
- Abstraction. The original program is broken down into its structural parts at increasing levels of generality.
- Filtration. At each level the court removes ideas, elements dictated by efficiency, elements required by external factors such as compatibility requirements, and public domain material.
- Comparison. What remains, the core of protectable expression, is compared with the defendant’s program.
Because filtration removes elements dictated by compatibility, a program that reproduces only what interoperability requires can lack substantial similarity in protected expression even when it behaves the same way.[2]
What the rewrite did not settle
The court did not treat the rewrite as the end of the matter. It held that Computer Associates’ trade secret claim was not preempted to the extent it rested on a duty of confidentiality, and it remanded the claim. It reasoned that because Altai had rewritten OSCAR with full knowledge of the earlier misappropriation, OSCAR 3.5 was created with actual knowledge of trade secret violations.[2] Altai also stayed liable for OSCAR 3.4, the version with the copied code, and did not appeal the damages award for it.[2]
When a clean room is not enough: Sega and Connectix
In Sega v. Accolade, Accolade made games compatible with Sega’s Genesis console. It disassembled Sega’s game code to learn the compatibility requirements. The district court suggested Accolade could have used a clean room instead. The Ninth Circuit held that finding to be clearly erroneous: Accolade’s expert testified that a clean room would not have avoided disassembly, because disassembly was necessary to discover the functional specifications for a Genesis-compatible game.[1]
The court held that disassembly of copyrighted object code is, as a matter of law, a fair use if it provides the only means of access to the unprotected elements of the code and the copier has a legitimate reason for seeking that access.[1] In 2000 the same circuit held in Sony v. Connectix that intermediate copies made and used by Connectix while reverse engineering the Sony PlayStation BIOS, to build a PlayStation emulator that contained none of Sony’s code, were protected fair use.[3]
These decisions show that a clean room addresses the risk of copying from a visible source. It does not remove the need to learn how the original works when documentation is missing, and the law on how that learning may be done is separate.
Statutory reverse-engineering rules
United States
Section 1201(f) of the US Copyright Act allows a person who has lawfully obtained the right to use a copy of a program to circumvent an access control for the sole purpose of identifying and analysing the elements necessary to achieve interoperability of an independently created program, where those elements were not previously readily available and the acts do not constitute infringement. The information may be made available to others solely to enable interoperability, to the extent that does not infringe or violate other law.[4]
European Union
Directive 2009/24/EC allows a person with a right to use a copy to observe, study or test the program to determine its underlying ideas and principles (Article 5(3)), and allows decompilation where indispensable to obtain information necessary for interoperability of an independently created program (Article 6). Article 6(2) bars use of the information obtained for developing a program substantially similar in its expression. Contract terms contrary to Article 6 or to Article 5(2) and (3) are null and void under Article 8.[5] The Court of Justice applied these provisions in SAS Institute v World Programming, where the competitor had no access to source code and did not decompile the object code. It held that functionality, programming language and data file formats are not protected expression under the Directive.[7] See EU Software Directive (2009/24/EC) and SAS Institute v. World Programming.
Licence terms that forbid reverse engineering
Vendor licences can prohibit reverse engineering, decompilation and disassembly. A clause of that kind bears on the specification stage, because that is the stage where the original is studied. Adobe’s General Terms of Use, effective 2025-10-03, are one primary-source example. Section 17 says users must not reverse engineer, “including but not limited to monitoring or tracking the inputs and outputs flowing through a system or an application in order to recreate that system”, decompile, disassemble, or otherwise attempt to discover source code, data representations or underlying algorithms. It also prohibits using the software or its output to train or improve machine learning systems.[6]
The same section addresses the legal right to decompile for interoperability: where the law of the user’s jurisdiction grants that right, the user must first request the information from Adobe, and Adobe may either supply it or impose reasonable conditions, including a reasonable fee, on the decompilation.[6] How that request-first condition interacts with Article 8 of the EU Directive, under which contrary terms are null and void, is a question of national law and has not been addressed in the sources cited here.
A clause of this kind restricts the specification team’s methods, and a breach of contract is a separate claim from copyright infringement.[2][5] For a recent dispute over a terms-of-service ban on reverse engineering, see Figma v. Motiff. For mainframe compatibility, see IBM v. LzLabs.
Out of scope
This article does not cover patent rights, trade secret law beyond the Altai remand, or the position under national laws other than those cited. It does not rely on NEC v. Intel (1989), which is often cited for clean-room microcode development, because a primary record of that decision was not read for this article.