Running a Clean Room Software Development Project: A Practical Guide

Summary. This guide explains, step by step, how to plan, staff, run, and document a clean-room software development project so that the resulting product can be defended against copyright, trade secret, and contract claims. It begins with the threshold decisions: whether a clean room is needed at all, what the compatibility objective is, and how the information about the target will be lawfully obtained. The core steps cover legal review of the target, license and terms-of-service restrictions, team selection and certification, physical and technical separation, the dirty team's investigation, writing a functional specification, gatekeeper review, clean-team implementation and questions, an AI coding tools policy, testing without contamination, records and privilege design, and closing the project. A timeline and cost-driver table, an extended worked example involving a robotics company building a compatible motion-controller driver, guidance for the interface owner evaluating a competitor's clean room, common mistakes, an FAQ, and takeaways close the guide.

Brightwater Robotics makes collaborative robot arms for small factories. Its customers keep asking the same question: will your arm work with the Kestrel Motion controllers we already own? Kestrel dominates the controller market, and its controllers speak a proprietary serial protocol that Kestrel documents only for licensed partners. Brightwater has three assets for the project: a Kestrel controller bought used on an auction site, a customer willing to let Brightwater engineers watch its Kestrel-equipped line, and a newly hired firmware engineer who spent six years at Kestrel. The vice president of engineering wants a working driver in nine months. The general counsel wants to know how Brightwater will prove, three years from now, that it did not copy anything.

The answer is a clean room. Done well, it produces a compatible product and a file that explains, document by document, how every line of the new code came to be written by people who never saw the original. Done badly, it produces the same product and a file that proves the opposite. This guide is about the difference.

The short answer

• A clean room separates the people who learn about the target from the people who write the new code. The "dirty" team studies the target and writes a functional specification. A gatekeeper (usually a lawyer or a lawyer-supervised reviewer) screens the specification for protected expression. The "clean" team writes the implementation from the specification alone.
• Its legal purpose is evidentiary. Copyright infringement requires copying, and independent creation is a complete defense. A documented clean room shows that the implementers had no access to the protected expression. See Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992), where a rewritten program produced by programmers who never saw the original was held non-infringing.
• The clean room cannot launder bad acquisition. If the dirty team breaches a license, circumvents an access control without an exemption, accesses a server without authorization, or uses misappropriated trade secrets, the clean team's independence does not cure it.
• It does nothing against patents. Run a separate patent clearance.
• The specification is the critical document. It must describe what the product must do, in the project's own words, at a level of abstraction that conveys function without conveying the target's expressive structure.
• AI coding tools are a new contamination channel. Approve tools, configure them to log, turn on code-reference filters, and ban prompts that reference the target.
• Records decide the case. Design them from day one to be produced in litigation, with privilege used carefully and never to hide how the clean room worked.
• Expect three to six weeks of setup before the clean team writes code, and ongoing gatekeeper time for the life of the project.

Before you start: four decisions

Decision 1: Do you need a clean room at all?

After Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021), reimplementing an interface by copying only the declarations that compatibility requires, while writing original implementing code, has a strong fair use defense. Many compatibility projects therefore need less than a full clean room for copyright purposes. But clean rooms address more than copyright in interfaces, and the decision should turn on the risk profile.

Decision 2: What exactly is the compatibility objective?

Write it in one sentence. "Brightwater's arm controller will exchange motion commands and status messages with Kestrel KX-series controllers over their serial port so that customers can coordinate Kestrel-driven conveyors with Brightwater arms." The objective defines what information the dirty team may seek, what the specification may contain, and what the gatekeeper should reject as unnecessary. Projects with vague objectives drift into copying things that no compatibility requirement justifies, which weakens the fair use argument that Google built on copying "only those lines of code that were needed."

Decision 3: How will information about the target be obtained?

List every source and rank them by legal exposure, lowest first.

1. Published specifications, standards, books, and public documentation.
2. Observation of the target running, in your own lab or a customer's, without copying it.
3. Black-box testing: sending inputs and recording outputs.
4. Capturing communications between the target and other devices or servers you control.
5. Reading files and data the target produces.
6. Disassembly or decompilation of object code.
7. Anything involving the target's servers, accounts, or credentials.

The higher the number, the more legal review is needed before the dirty team starts. Sources 6 and 7 require written clearance from counsel.

Decision 4: Who is already contaminated?

Before anyone is assigned, find out who on the engineering staff has worked for the target, held a license to it, contributed to its open-source components, studied its leaked code, or worked on a prior project involving it. Those people are not barred from the project. They are barred from the clean team.

The roles

A small company may combine roles (counsel as gatekeeper, a project manager as records custodian), but the dirty and clean teams must stay separate people. Legal ethics rules apply to the gatekeeper function when a lawyer supervises nonlawyer reviewers; under ABA Model Rule 5.3, the supervising lawyer is responsible for making reasonable efforts to ensure that nonlawyer assistants' conduct is compatible with the lawyer's professional obligations.

Step 1: Define the compatibility objective and the element list

What to do. Turn the one-sentence objective into an element list: each interface element the product must match, why, and how the dirty team expects to learn it. For a protocol, that means message types, field layouts, sequencing, timing, checksums, and error responses. For an API, it means function names, parameters, types, return values, error codes, and observable behavior. For a file format, record structures and field semantics.

Why. Every element on the list must be justified by compatibility. The list is the project's first defense to over-copying and the backbone of the fair use and filtration arguments. Under the abstraction-filtration-comparison test in Altai, elements dictated by compatibility with other programs are filtered out before comparison; the list shows what the external constraints were.

Authority. 17 U.S.C. § 102(b) (no protection for ideas, procedures, processes, systems, or methods of operation); Lotus Development Corp. v. Borland International, Inc., 49 F.3d 807 (1st Cir. 1995) (menu command hierarchy as method of operation); Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997) (command codes filtered as dictated by external factors).

Pitfalls. Listing "everything the target does." Listing internal implementation details that no external program observes. Including user-interface layouts and documentation text that no compatibility requirement reaches.

Timing and cost. One to two weeks of engineering and counsel time; low cost relative to everything else, and it prevents the most expensive mistakes.

Step 2: Conduct a legal review of the target

What to do. Before investigation starts, counsel prepares a short clearance memo covering:

• Copyright. Registrations for the target's software and documentation (registration is a prerequisite to suit for United States works under 17 U.S.C. § 411 and affects statutory damages and fees under 17 U.S.C. § 412), and the elements most likely to be claimed as protected.
• Patents. A freedom-to-operate search directed at the functionality the element list requires. A clean room is no defense to infringement under 35 U.S.C. § 271.
• Technical protection measures. Whether any access control (encryption, authentication handshakes, license keys, signed firmware) stands between the dirty team and the information. Circumventing one implicates 17 U.S.C. § 1201 separately from infringement.
• Contracts. Every license, terms of service, developer agreement, NDA, and partner agreement that touches the target (Step 3).
• Computer access. Whether any source requires accessing the owner's servers or accounts, which raises 18 U.S.C. § 1030.
• Trade secrets. Non-public information anyone on the team holds, including former employees, contractors, and partners.
• Trademarks. How the product may describe its compatibility.
• Jurisdiction. Where the teams work, because European law permits decompilation for interoperability under Article 6 of the Software Directive and voids contrary contract terms, while United States law generally enforces them.

Why. The clean room protects the implementation. The clearance memo protects the acquisition, and acquisition facts lose more of these cases than implementation facts. In Atari Games Corp. v. Nintendo of America Inc., 975 F.2d 832 (Fed. Cir. 1992), the reverse engineer lost its fair use defense because it obtained the target's source code from the Copyright Office by misrepresentation; the court held that a party invoking fair use must possess an authorized copy.

Pitfalls. Treating the memo as a formality. Writing it after investigation starts. Failing to update it when the investigation plan changes.

Timing and cost. One to three weeks; moderate counsel cost, higher if a full patent search is needed. The detailed clearance steps are in the Software Interoperability and Reverse Engineering Clearance Checklist: A Practical Checklist.

Step 3: Clear contract and terms-of-service restrictions

What to do. Collect every agreement the company or any team member has accepted for the target, including click-through licenses, trial and academic licenses, developer program terms, partner agreements, and NDAs. Read each for reverse-engineering prohibitions, "no competing product" or "no functionally equivalent product" clauses, benchmarking restrictions, confidentiality obligations, audit rights, and choice of law. Then decide, source by source, whether the project can use it.

Why. In most United States courts, a license term prohibiting reverse engineering is enforceable and not preempted by the Copyright Act, even where the reverse engineering itself would be fair use. Bowers v. Baystate Technologies, Inc., 320 F.3d 1317 (Fed. Cir. 2003); Davidson & Associates v. Jung, 422 F.3d 630 (8th Cir. 2005); see also ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996) (contract rights not equivalent to copyright under 17 U.S.C. § 301). A breach of license claim is often the owner's strongest claim, and a clean room does not answer it.

Options when a restrictive license exists.

• Do not use that copy or account. Terminate or quarantine it, and do not let anyone who used it under the restrictive terms work on the clean team.
• Use a source the license does not reach. Published specifications, third-party documentation, a lawfully purchased used copy (with care: the original purchaser's license may or may not bind a later owner, and many licenses purport to be non-transferable), or a customer's installation observed with the customer's permission and within the customer's own license.
• Negotiate. Some owners will license interface documentation for compatibility on reasonable terms. The negotiation itself creates a record of good faith.
• Structure the work where the law permits it. For teams in the European Union, Article 6 of the Software Directive may allow decompilation for interoperability notwithstanding contract terms. This is a specialized analysis; get local advice.

Pitfalls. Forgetting individual acceptances: an engineer who clicked "I agree" on a trial version at home may have bound only herself, but the facts will look like the company's. Using a customer's license for a purpose the customer's license does not permit, which can expose the customer and produce an inducement claim. Online contract formation questions (whether a browsewrap bound anyone) are fact-specific; see Website Terms of Service and Online Contract Formation: Clickwrap, Browsewrap, and Enforceable Arbitration and Software License Agreement Review Checklist: A Practical Checklist.

Timing and cost. One to two weeks in parallel with Step 2.

Step 4: Select, screen, and certify the teams

What to do. Interview every candidate for the clean team about prior exposure to the target: employment, contracting, licenses held, open-source contributions, academic projects, competing projects, leaked code, and the target's documentation (manuals and API references count). Record the answers. Each clean-team member signs a certification of no exposure and an undertaking to follow the protocol; each dirty-team member signs an undertaking not to communicate with the clean team outside the gatekeeper channel. Former employees of the target sign an additional acknowledgment that they will not use or disclose the target's confidential information on any team, and they generally belong on neither team for the technical work.

Why. Access is the hinge of the copying inquiry. A plaintiff proves copying by showing access and similarity probative of copying; a clean team with documented lack of access removes the first element. Subconscious copying still infringes, as in Bright Tunes Music Corp. v. Harrisongs Music, Ltd., 420 F. Supp. 177 (S.D.N.Y. 1976), so a person who has studied the target cannot cure exposure by good intentions. Former employees present a separate risk: the Defend Trade Secrets Act reaches acquisition by improper means and use or disclosure in breach of a duty, 18 U.S.C. § 1839(5)-(6), with injunctions and damages under 18 U.S.C. § 1836.

Pitfalls. Certifications that are signed but not supported by an interview. Ignoring contractors and offshore teams. Assigning a former employee of the target as "just a reviewer." Forgetting that exposure includes the target's documentation, not just its code.

Timing and cost. One to two weeks for interviews and paperwork. Forms are in Clean Room Toolkit: Protocols, Team Certifications, and Specification Records. For the departing-employee side, see Employee Departure Trade Secret Protection Checklist: A Practical Checklist.

Step 5: Build physical and technical separation

What to do. Implement separation that an outsider could verify:

• Separate source repositories, with access lists the records custodian reviews and exports monthly.
• Separate document stores for dirty-team materials, the released specification, and clean-team work.
• Separate chat channels; no shared channel for the project. The only channel between teams is the gatekeeper's queue.
• Separate lab equipment where practical; the target device stays in the dirty lab.
• Device controls: clean-team machines cannot reach the dirty repository or the target's download portals.
• A visitor log for the dirty lab.
• AI tool workspaces separated by team (Step 10).
• Written rules for meetings: no joint technical meetings; all-hands meetings may not discuss the target's internals.

Why. Separation must be provable. In litigation, the owner will ask for access logs, repository permissions, and chat records, under Fed. R. Civ. P. 34, and will depose engineers under Fed. R. Civ. P. 30 about hallway conversations. Policies that existed only on paper will be exposed.

Pitfalls. A shared engineering manager who supervises both teams. Shared continuous-integration infrastructure that lets clean-team members see dirty-team test logs. The lunch table.

Timing and cost. One to three weeks of IT and security work; low to moderate cost.

Step 6: Run the dirty team's investigation

What to do. The dirty team works through the information sources in the order cleared by counsel in Step 2, keeping a lab notebook (paper or electronic, dated, attributed) that records each observation, test, input, output, and source. For each element on the list, the notebook should show where the information came from.

Observation and testing. Run the target, send it inputs, and record outputs. Capture serial or network traffic between the target and devices you control. Read files it produces. These activities generally involve no copying beyond what running the program requires, and the owner of a copy may make the copies that are an essential step in using it under 17 U.S.C. § 117, though whether a licensee counts as an "owner" depends on the license terms, Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010).

Disassembly or decompilation. Only with written clearance. The leading cases hold intermediate copying during disassembly fair use when it is the only way to reach unprotected functional elements and there is a legitimate reason for access. Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992); Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000). Record why less intrusive methods were insufficient, limit disassembly to the parts needed, and keep the disassembled output in the dirty repository only. If an access control must be circumvented, confirm in writing that 17 U.S.C. § 1201(f) or a current exemption at 37 C.F.R. § 201.40 applies.

Servers and accounts. If the target is a cloud service, the dirty team uses only accounts the company lawfully holds, within their terms, and stops immediately on any revocation. After Van Buren v. United States, 593 U.S. 374 (2021), the CFAA asks whether the user entered parts of a system that were off limits, but a specific revocation of access can make continued use unauthorized, Facebook, Inc. v. Power Ventures, Inc., 844 F.3d 1058 (9th Cir. 2016).

Why. The lab notebook is the evidence that every specification entry came from a lawful source. It also answers the owner's inevitable argument that the specification must have come from the code.

Pitfalls. Downloading "documentation" from unofficial sites that turns out to be leaked internal material. Using the former employee as an informal oracle. Copying the target's documentation into the notebook verbatim; summarize and cite instead.

Timing and cost. The longest dirty-team phase, from weeks to months depending on complexity.

Step 7: Write the functional specification

What to do. The dirty team converts its findings into a specification: a description of what the compatible product must do, organized by element, in the project's own words. Each entry should state the requirement, cite the lab-notebook entries that support it, and explain why compatibility requires it.

What belongs in a specification.

• Message formats and field layouts, stated as tables of offsets, lengths, types, and meanings.
• Sequences and state transitions, described as behavior ("after a STATUS request, the controller replies within 20 ms with a 12-byte frame; if no reply arrives, the host retries twice").
• Function names, parameters, types, and return values, where the product must expose the same interface. After Google, these declarations are the core of what a compatible product may reproduce; keep them limited to what external programs call.
• Error codes and constants that external programs rely on.
• Observable behavior, including edge cases, timing, and rounding.
• Test vectors: inputs and the expected outputs, generated by the dirty team from the target.

What stays out.

• Any source or object code from the target, including disassembled listings and pseudocode that tracks the target's control flow line by line.
• Internal function names, variable names, comments, and data structures that no external program observes.
• Prose copied or closely paraphrased from the target's documentation.
• The target's internal algorithms, unless the specification describes only required inputs and outputs and the clean team is free to choose any method.
• Anything the dirty team learned from a source that was not cleared.

Abstraction is the craft. The Altai test asks courts to break a program into levels of abstraction and filter unprotected elements at each level. The specification should sit at the level where the target's choices are dictated by compatibility, and no lower. "Compute a CRC-16 using polynomial 0x8005 over bytes 2 through 10" is a compatibility requirement. "Loop over the buffer with a lookup table indexed by the high byte, as the target does at address 0x4F20" is a description of the target's implementation. The first belongs in the specification; the second does not.

Why. The specification is the only bridge between the teams. If it carries protected expression, the clean team has had access to that expression, and every downstream similarity becomes evidence of copying. If it is clean, similarities between the products can be traced to documented functional requirements, which is exactly the explanation the filtration step credits. In SAS Institute, Inc. v. World Programming Ltd., 64 F.4th 1319 (Fed. Cir. 2023), the defendant's evidence that the asserted elements were functional or otherwise unprotected shifted the burden to the plaintiff to show what remained protectable, and the plaintiff could not.

Pitfalls. Writing the specification as an annotated listing of the target. Copying the target's documentation structure (chapter order, examples, phrasing) because it is convenient. Writing at too high a level of abstraction, which drives the clean team to ask many questions and creates a gatekeeper bottleneck.

Timing and cost. Concurrent with Step 6 and continuing as new elements are discovered.

Step 8: Gatekeeper review and release

What to do. Every specification entry goes to the gatekeeper before release to the clean team. The gatekeeper checks it against a written review standard (no code, no copied prose, no internal names, no implementation details beyond what compatibility requires, a cited lawful source for each fact), edits or rejects as needed, and records the decision in a review log: entry number, version, date, reviewer, decision, and the reason for any change. Only released entries move to the clean team's repository, and each release is versioned.

Clean-team questions. The clean team will have questions. They go in writing to the gatekeeper, never directly to the dirty team. The gatekeeper forwards the question to the dirty team in writing, reviews the answer under the same standard, and releases it in writing. Every question and answer is logged and becomes part of the specification.

Why. The gatekeeper's review is what makes the specification defensible. It also produces the record that answers the owner's most effective deposition question: "How do you know nothing from the target's code reached the clean team?"

Privilege design. If a lawyer is the gatekeeper, some gatekeeper communications will be legal advice and some will be technical editing. Decide at the outset which records are intended to be produced (the specification versions, the review log, the released answers) and which are privileged legal analysis (counsel's clearance memos). Keep them in separate files. A party that relies on its clean room as a defense should expect to produce the materials that show how it worked; selective withholding invites an at-issue waiver argument, and an inadvertent production should be covered by a protective order and a Fed. R. Evid. 502(d) order. Work product protection under Fed. R. Civ. P. 26(b)(3) covers documents prepared in anticipation of litigation, which may or may not describe a routine engineering process.

Pitfalls. A gatekeeper who rubber-stamps. Verbal answers to "quick questions." A review standard that exists only in the gatekeeper's head.

Timing and cost. Gatekeeper time scales with specification size and the number of questions. Budget for it throughout the project, not only at the start.

Step 9: Clean-team implementation

What to do. The clean team writes the implementation from released specification entries only, using its own design, architecture, names, and algorithms. Each engineer keeps ordinary development records: commits with meaningful messages, design notes, code review comments. The records custodian confirms monthly that clean-team members have not accessed dirty materials, using repository and document-store logs.

Design independence. Encourage the clean team to make its own design choices deliberately and to record them. If the specification requires a function named kmp_send_status with specific parameters, the implementation behind it should reflect the clean team's own decomposition, error handling, and data structures. Where two reasonable designs exist, a short note on why the team chose one is valuable evidence later.

Why. Independent creation is a complete defense to copyright infringement, Feist Publications, Inc. v. Rural Telephone Service Co., 499 U.S. 340 (1991), and courts infer copying from access plus probative similarity, Arnstein v. Porter, 154 F.2d 464 (2d Cir. 1946). The clean team's records show both the absence of access and the independent origin of the design.

Pitfalls. Clean-team members searching the internet for the target's protocol "just to check," which may land them on leaked code or the owner's partner documentation. Hiring a new clean-team member mid-project without the Step 4 interview. Using open-source code that turns out to be derived from the target; vet third-party code for provenance.

Timing and cost. The main engineering phase.

Step 10: Adopt an AI coding tools policy

What to do. Write a short, specific policy for AI coding assistants and chat tools on both teams.

• Approved tools only, on enterprise configurations that retain prompts and outputs for the life of the project plus the retention period, and that do not train on the company's inputs.
• Code-reference or duplication filters on, where the tool offers them, so that outputs matching public code are blocked or flagged.
• Separate workspaces for dirty and clean teams, with no shared context, retrieval index, or connected repositories across the line.
• Prompt rules for the clean team: no mention of the target by name, product, or vendor; no pasting of anything not in the released specification; no requests to "make it behave like" the target.
• Prompt rules for the dirty team: no uploading of the target's code or documentation to tools unless counsel has cleared it (the license may prohibit it, and it creates a copy).
• Review: clean-team code generated with AI assistance goes through the same review as other code, plus a similarity scan against any public versions of the target's code the company knows about, run by someone outside the clean team.
• Records: export and preserve prompt and output logs with the clean-room file.

Why. If a model learned the target's code from public sources (an open-source edition, a leaked repository, sample code), its output can reproduce that code, and the clean team will have been exposed to it through the tool. The inference of copying returns. Separately, uploading third-party code or documentation to an AI service may breach a license and may disclose trade secrets the company is obligated to protect. Litigation over AI coding tools, including Doe v. GitHub, Inc. in the Northern District of California, has tested claims under 17 U.S.C. § 1202 for removal of copyright management information; the district court dismissed those claims for lack of identical copies, and that ruling was on interlocutory appeal to the Ninth Circuit, so check for the appellate decision. The policy side of AI tools is covered in Building a Generative AI Use Policy That Protects Trade Secrets: A Practical Guide.

Pitfalls. Allowing personal accounts. Agentic tools with internet access on the clean team. Tools connected to the company's whole code host, including the dirty repository.

Timing and cost. A few days to write and configure; low cost.

Step 11: Test compatibility without contaminating the clean team

What to do. Compatibility testing requires running the clean implementation against the target, which the clean team must not study. Assign testing to the dirty team or a separate test group. Testers run the specification's test vectors and integration scenarios, then report results to the clean team through the gatekeeper in a pass/fail form: "Test 4.12 failed: the controller rejected frame 3 with error 0x21." They may not explain how the target works internally beyond what the specification already says. If a failure reveals a gap in the specification, the dirty team writes a new or revised entry, and it goes through the gatekeeper.

Why. Testing is the most common leak. A tester who explains "the target does it this way internally" has just transmitted implementation details outside the specification.

Pitfalls. Letting clean-team engineers sit in the lab "to save time." Sharing raw protocol captures that include the target's firmware updates or embedded code. Debugging sessions conducted jointly over a screen share.

Timing and cost. Iterative, through release.

Step 12: Keep records for litigation from day one

What to do. Maintain a clean-room file with a master index. At a minimum:

• The protocol, signed by the executive sponsor, and every version of it.
• Team rosters with dates of joining and leaving.
• Screening interview notes and signed certifications.
• Access-control exports for repositories and document stores, monthly.
• The dirty team's lab notebooks.
• Every specification version and the gatekeeper review log.
• The clean-team question and answer log.
• Test reports.
• AI tool policy, configurations, and exported logs.
• Counsel's clearance memos (privileged, filed separately).
• Records of any breach of the protocol and the remediation.

Preserve the repositories themselves, with full history. Issue a litigation hold when a dispute becomes reasonably anticipated, and suspend any automatic deletion. Fed. R. Civ. P. 37(e) allows serious sanctions when electronically stored information that should have been preserved is lost and cannot be replaced.

Why. The clean room is only as good as its proof. Declarations describing the process should be made under penalty of perjury under 28 U.S.C. § 1746 and supported by the contemporaneous records; summaries of voluminous logs can be offered under Fed. R. Evid. 1006. Expert testimony comparing the codebases, offered under Fed. R. Evid. 702, will rely on them. And the owner may move for summary judgment under Fed. R. Civ. P. 56 or seek a preliminary injunction; a well-organized file lets the defense respond within the deadlines those motions impose.

Pitfalls. Records that are edited after the fact (metadata will show it). Notebooks kept on personal devices. An index that nobody updates. For preservation, see Litigation Hold and Evidence Preservation Checklist: A Practical Checklist.

Timing and cost. Continuous; low incremental cost if built in.

Step 13: Close the project and plan for maintenance

What to do. At release, the records custodian freezes the clean-room file, exports final logs, and has each team member sign a closing certification confirming compliance or disclosing any breach. Counsel writes a short closing memo. For maintenance releases, the same rules apply: new compatibility requirements go through the dirty team, specification, and gatekeeper. Clean-team members who later join the dirty team (for example, to investigate a new target version) cannot return to clean-team work on the same product.

Why. Products evolve. The target ships a new version, customers report incompatibilities, and the pressure to "just look" returns. A maintenance protocol prevents the second release from undoing the first release's defense.

Retention. Keep the file at least as long as any claim could be brought. The Copyright Act's civil limitations period is three years from accrual, 17 U.S.C. § 507(b), but each new distribution can start a new period, and the Defend Trade Secrets Act allows three years from discovery, 18 U.S.C. § 1836(d). Contract claims follow state limitations periods, often longer. Practically, keep the file for the life of the product plus several years.

Timeline and cost drivers

The figures below are planning assumptions for a mid-sized project (one protocol or API surface, five to fifteen engineers), not statistics. Actual time and cost vary widely with the size of the interface, the number of information sources, and whether disassembly is involved.

Most of the incremental cost of a clean room, compared with ordinary development, comes from three places: duplicated engineering effort (two teams learning the same domain), gatekeeper time, and the friction of written-only communication. Those costs are modest compared with defending a copyright or trade secret case without the records.

Worked example: Brightwater and the Kestrel protocol

Before you start. Brightwater's counsel concludes that a full clean room is warranted: the new firmware engineer, Priya Natarajan, worked on Kestrel's controller firmware for six years, and the protocol is undocumented except in partner materials. The objective is written in one sentence (above). Information sources, in order: Kestrel's public product manuals (which describe commands at a high level); observation of the customer line at Halvorsen Packaging; serial captures between a Kestrel controller and a Brightwater test host in Brightwater's lab, using the used controller; and, only if needed, disassembly of the controller's host-side configuration utility.

Step 1. The element list identifies 34 message types, a framing and checksum scheme, a session handshake, 61 error codes, and timing requirements. It excludes Kestrel's configuration utility's user interface and its internal motion-planning algorithms.

Step 2. The clearance memo finds Kestrel copyright registrations for its controller firmware and manuals, two Kestrel patents on motion-synchronization methods, and a challenge-response handshake that might be an access control. A patent attorney concludes Brightwater's planned synchronization method avoids one patent's claims and recommends a design constraint for the other. On the handshake, counsel concludes that observing it in captures, and responding to it in Brightwater's own code using values observed in normal operation, is not circumvention of a measure protecting access to Kestrel's firmware; any attempt to extract keys from the firmware is barred without further review.

Step 3. The used controller came with no license agreement; Kestrel's firmware license, posted on its website, purports to bind "any user" and prohibits reverse engineering. Counsel concludes the posted terms likely did not form a contract with Brightwater, which never assented to them, but directs the dirty team to avoid decompiling the firmware. Halvorsen's license permits it to use its controllers "for its internal operations"; Halvorsen's counsel agrees in writing that letting Brightwater engineers watch the line, without copying software, is within that use. The configuration utility's click-through license prohibits reverse engineering, so disassembly of the utility is ruled out entirely.

Step 4. Priya is excluded from both technical teams and assigned to the customer-integration group, with a written acknowledgment and a trade secret wall. Two other engineers disclose that they used Kestrel's configuration utility at prior jobs; they go to the dirty team. The clean team's six engineers sign certifications after interviews.

Step 5. IT builds separate repositories and document stores, blocks the clean team's network segment from the dirty lab, and sets up a gatekeeper queue in the ticketing system.

Step 6. The dirty team works for nine weeks, logging 1,400 serial captures and the test inputs that produced them. Kestrel's public manuals supply message names; captures supply field layouts.

Step 7. The specification describes each message in tables, the handshake as a state machine, and each error code with its triggering condition. It uses Kestrel's message names only where Brightwater's driver must emit or recognize them on the wire; internal Brightwater names are chosen by the clean team.

Step 8. The gatekeeper, outside counsel's technical specialist supervised by a partner, rejects three draft entries that paraphrased Kestrel's manual and one that described a timing quirk in terms of the firmware's internal task scheduler. The clean team submits 212 questions over the project; all are answered in writing.

Step 9. The clean team writes the driver in Rust, with its own architecture. Its design notes record why it chose an event-driven model.

Step 10. The clean team uses an enterprise coding assistant with prompt logging and a code-reference filter on; prompts may not mention Kestrel. The dirty team's tool workspace is separate. A monthly review finds one prompt that included the word "Kestrel"; the output is reviewed, found unremarkable, and the incident is logged with a reminder to the engineer.

Step 11. The dirty team runs weekly compatibility tests and reports pass/fail results through the gatekeeper.

Step 12. The records custodian maintains the index. When Kestrel's counsel sends a letter fourteen months after release alleging copyright infringement and trade secret misappropriation based on Priya's hiring, Brightwater responds with a summary of the process and an offer to make the clean-room file available to outside counsel under a protective order. The forms Brightwater used are reproduced in Clean Room Toolkit: Protocols, Team Certifications, and Specification Records.

Step 13. At release, each team member signs a closing certification. When Kestrel ships new firmware a year later, the same protocol governs the update.

For the interface owner: evaluating a competitor's clean room

An owner that suspects copying will meet a clean-room defense. Its job is to find the gaps.

Before suit. Compare the products' externally observable behavior for similarities that compatibility does not explain: identical bugs, identical undocumented quirks, identical internal strings or error messages that no external program uses. Those are the classic markers of copying. Review the competitor's hiring from your engineering staff, and your own departure records. Remember that you will need registrations to sue on United States works, under 17 U.S.C. § 411, and that, after Google, a claim built on the interface alone is weak. For pre-suit evaluation, see Copyright Infringement Claim Evaluation Checklist: A Practical Checklist.

In discovery. Ask for the protocol and every version, team rosters with dates, certifications and interview notes, access logs, the specification and its review history, the question log, test reports, AI tool logs, and the dirty team's notebooks. Depose the gatekeeper and a clean-team engineer about informal communications. Ask the competitor to identify each source of each specification entry. Look for entries with no lawful source, entries added late without a review record, and people who moved between teams.

Source code review. Software comparison requires the code itself; a plaintiff who never puts the source code in evidence may be unable to prove substantial similarity, Antonick v. Electronic Arts, Inc., 841 F.3d 1062 (9th Cir. 2016). Courts commonly limit access to competitively sensitive code to outside counsel and experts, and may bar in-house counsel involved in competitive decisionmaking, Brown Bag Software v. Symantec Corp., 960 F.2d 1465 (9th Cir. 1992). See Negotiating a Protective Order and Filing Under Seal: A Practical Guide.

The non-copyright claims. The owner's strongest claims are often outside copyright: breach of a license that prohibited reverse engineering, trade secret misappropriation through a former employee, circumvention under section 1201, or a patent. A clean room answers none of them directly.

Common mistakes

Starting investigation before legal review. The acquisition facts are fixed the moment the dirty team starts. Clear sources first.

Putting the former employee on the dirty team. It seems logical: she knows the target best. It is the fastest way to turn a copyright defense into a trade secret case. Keep former employees off both technical teams.

A specification that reads like the target's documentation. If a reader could map specification paragraphs to manual paragraphs, the gatekeeper has failed.

Verbal shortcuts. One hallway explanation can undo months of separation. Everything between teams goes through the gatekeeper, in writing.

Forgetting AI tools. A clean team using an unlogged assistant has an unprovable gap in its record.

Treating the clean room as a patent defense. It is not one.

Over-designing privilege. A clean room that cannot be shown to a court because all its records are privileged does not help in litigation. Separate legal advice from process records.

Letting the protocol lapse after release. Maintenance releases need the same discipline.

Frequently asked questions

Is a clean room legally required to build compatible software? No. It is an evidentiary tool. It is most valuable when someone involved has had access to the target's code or confidential information, when disassembly is involved, or when the owner is likely to sue.

Can a small company run a clean room? Yes. The essential features are two separate groups of people, a written specification, a reviewer who screens it, written-only communication, and records. A five-person company can do that with an outside lawyer as gatekeeper and a shared drive with proper permissions.

Does the gatekeeper have to be a lawyer? No, but a lawyer, or a technical reviewer supervised by a lawyer, brings both judgment about protected expression and the possibility of privilege for legal analysis. Whoever it is must apply a written review standard and keep a log.

What if a clean-team member is accidentally exposed to the target's code? Stop that person's work on the affected component, record what was seen and when, have counsel assess whether the person's prior work needs review, and move the person to the dirty team or off the project. Disclose and remediate; do not hide it. A documented breach with remediation is far less damaging than one discovered in discovery.

Can we use the target's names for functions and messages? Where compatibility requires them, yes; that is what Google addressed. Internal names that no external program uses should be the clean team's own.

How does a clean room interact with an open-source version of the target? If the target has an open-source edition, its code is public and its license governs copying it. A clean team that has read the open-source code is exposed to it. Decide at the outset whether the project will use the open-source code under its license (in which case it is not a clean room for that code) or avoid it entirely.

Is reverse engineering a defense to trade secret claims? Reverse engineering of a lawfully obtained product is a proper means under the Defend Trade Secrets Act, 18 U.S.C. § 1839(6)(B), consistent with Kewanee Oil Co. v. Bicron Corp., 416 U.S. 470 (1974). It does not protect information obtained from a former employee, through misrepresentation, or in breach of a confidentiality obligation.

Takeaways

• Decide whether you need a clean room by asking who has had access to what, not by asking whether the interface is copyrightable.
• Clear the sources before the dirty team starts: licenses, access controls, servers, trade secrets, patents.
• Keep former employees of the target off both technical teams.
• Write the specification at the level of compatibility requirements, in your own words, with a cited lawful source for every fact.
• Route every communication between teams through a gatekeeper, in writing, with a log.
• Control AI tools as a contamination channel and keep their logs.
• Build the records to be produced. They are the defense.

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

Related Documents

Related Articles

• Copyright in Software Interfaces After Google v. Oracle: APIs, Compatibility, and Reverse Engineering: the doctrine behind each step of this guide.
• Legal Protection of Software: Copyrights, Patents, Trade Secrets, and Contracts: the protection regimes a clean room must account for.
• The DMCA Anti-Circumvention Provisions: Section 1201, Digital Locks, and the Triennial Exemptions: circumvention limits on the dirty team's investigation.
• Trade Secrets and Generative AI: Reasonable Measures, Prompt Leakage, and Vendor Terms: AI tool risks that overlap with the clean-room AI policy.
• 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

• Building a Generative AI Use Policy That Protects Trade Secrets: A Practical Guide: building the broader AI policy the Step 10 rules sit within.
• Litigating Substantial Similarity in a Copyright Case: A Practical Guide: how the clean room's records are used if the case is filed.
• Negotiating a Protective Order and Filing Under Seal: A Practical Guide: source code and clean-room file protections in litigation.
• Trade Secret Misappropriation Litigation Under the Defend Trade Secrets Act: A Practical Guide: the claim that follows hiring from the interface owner.
• 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: the clearance work behind Steps 2 and 3.
• Employee Departure Trade Secret Protection Checklist: A Practical Checklist: onboarding and departure controls for engineers who cross between competitors.
• Litigation Hold and Evidence Preservation Checklist: A Practical Checklist: preserving the clean-room file when a dispute arises.
• Software License Agreement Review Checklist: A Practical Checklist: reading the target's license terms.
• 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 protocol, certifications, logs, and file index used in the steps above.
• Copyright Infringement Litigation Toolkit: Similarity Charts, Expert Reports, and Filtration Analyses: filtration analyses that draw on the specification.
• AI Confidentiality Toolkit: Acceptable Use Policies, Vendor Term Reviews, and Incident Playbooks: AI tool policies and vendor term reviews.
• 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.