Clean Room Defeats Software Infringement Claim in US Federal Court

Under copyright and trade secrets laws as such laws apply to source code, if a person without permission copies the source code or misappropriates a trade secret contained within the code (such as know-how), that person is liable to the owner of the copyrighted code or the trade secret embodied within that code.

For purposes of proving such a claim of copyright or trade secret misappropriation, it is not necessary to prove that actual copying occurred. It is sufficient to show that (1) the accused party had access to the code, and (2) the accused party's code is substantially similar to the claimant's code. Thus, for an independent software developer, accessing competitive or substantially similar code is fraught with legal risks, especially in the situation in which the company is developing software with the same or similar functionality as that which exists in competitive products or existing third party code that the company has already licensed. In order to avoid claims of breach of such terms or claims of infringement, it may be advisable to establish "clean room" software development policies.

The purpose of such policies is to create an environment in which the company’s personnel can develop competitive software in a manner that insulates the company from copyright infringement or trade secret misappropriation claims by third party licensors of functionally similar software. Clean room engineering attempts to defeat the “proof of access” element of such claims. Independent development of code, even if that code happens to be substantially similar, is a complete defense to a copyright infringement claim, and would refute a misappropriation of trade secrets claim as well.

Clean room engineers should obviously at all times avoid direct examination of the original corresponding third party code. Functionality should be designed only by using specifications or tests derived from the third party code being emulated. If it is necessary to internally develop these specifications and/or tests, then such materials may be developed by a separate group within the company that is physically and electronically isolated from the clean room group. This group is known as the "dirty room" group. When it is determined that the specification from which the clean room engineers are working is insufficient to produce the degree of compatibility desired, the only recourse is to search for additional documentation or to write additional tests.

For example, looking at the individual instructions that make up a computer program, even if only to determine specifications that aren't publicly available, is an example of dirty room reverse engineering. Dirty room reverse engineering done by the same engineers who create clean room code runs the obvious risk of deliberate or accidental copyright or trade secret violations. To avoid this risk, dirty room reverse engineering should be done in conjunction with clean room development by using two physically and electronically isolated teams where one team does dirty room reverse engineering and the other does clean room development. If a dirty room team exists, the clean room engineers can write a description of the portion of the specification that needs elaboration or clarification. The dirty room engineers then use that request to create additional functional specifications or tests. These functional specifications or tests should not reveal in any manner the way in which the emulated software was written.

The viability of a clean room defense was put to the test in the case of Nordstrom Consulting, Inc. v. M&S Technologies, Inc. (N.D. Ill. 2008). In this case, the plaintiff (NCI) accused the defendant (M&S) of developing an unauthorized and infringing derivative work of software NCI had licensed to M&S. M&S sought to avoid infringement liability via the use of documented clean room procedures.

In actuality, M&S used what is more accurately referred to as “dirty room” reverse engineering described above, as the court explained in the court’s written opinion:

"Defendants claim that M&S hired independent developers to create a new software program … shortly after [NCI] sent an email … stating [the] intention to renegotiate or terminate [the] relationship with M&S. Defendants claimed to have used a “clean room” procedure to develop the new software. “Clean room” procedure attempts to avoid violations of the copyright laws by using two separate teams of developers to create a competing product. The first team describes the functional aspects of a product to the second team; the second team then uses those descriptions to write the code for the competing product. … If Defendants did indeed follow clean room procedures, the Plaintiffs would be unable to make the necessary showing that Defendants had access to the copyrighted work."

Defendant M&S was successful in this defense despite that one of the engineers in the functional specification team actually (a) sent snippets of code or “pseudo code” to the clean room engineering team – code that was “used to help the developers understand what the new system needed to do”; and (b) offered “suggestions to difficulties encountered by the independent programmers in writing the new code. “ The court ruled that NCI failed to prove that this assistance or pseudo code was in any way identical or substantially similar to plaintiff’s copyrighted code.

A final note: clean room or dirty room procedures do nothing to minimize the threat of patent infringement claims; successful assertion of such claims does not depend on proof of copying or access. Independent worldwide patent searches should be conducted in the applicable fields in order to assess the scope of possible patents and to design around such patents if possible. Also, clean room procedures or reverse engineering could be subject to contractual restrictions in the applicable license agreements covering the third party code being emulated. Such terms should be analyzed prior to any clean room development.