Clean-Room Development Avoids Copyright Battles

If I write a novel about a boy wizard attending a wizarding school, and I never read or heard about someone else’s copyrighted novel about a boy wizard attending a wizarding school, does my novel infringe on the copyright of that other novel? Not if I can prove that somehow I missed the Harry Potter books and movies.

It’s unlikely, I admit. But copyright infringement requires copy, and copying requires access to the infringed work. The same is true for software, but there is an extra twist: Copying functionality is not copyright infringement. If I can demonstrate that any similarity between the original software and my new software is due to functionality or just plain coincidence, I am not liable for copyright infringement. But to prove it, I first need to clean my room.

Imagine waking up in a parallel universe, where you live in a clean room free of the clutter and debris accumulated during day-to-day business. In this alternate universe, everything you design is free of outside influence. Every idea is a new idea — even books about boy wizards.

Back on Earth, companies often depend on software that is licensed under certain terms that are no longer workable. For example, suppose a company licenses a program for use in its operations or its products, but later finds it can no longer use the software under the terms of the license or obtain, on reasonable terms, the licenses it needs.

Perhaps the licensor is unwilling to license on price or usage terms. Maybe the licensor refuses to modify or support the software to meet the company’s needs. In many cases, the licensor is simply out of business.

Abstraction, Filtration, Comparison

So the company decides to replace the software with its own code. The licensor then asserts its copyright against the company. Here is where clean-room development comes in. Documented clean-room development of the replacement software could help the company win a copyright-infringement case brought by the former licensor and even convince the licensor that it does not have a case to bring.

Courts use the “abstraction, filtration, comparison” test to determine if the defendant’s accused software infringes the copyright on the plaintiff’s software. Basically, this test compares the original work with the accused work by removing any parts that are strictly functional (permitted to be copied) and examines the sameness of what is left.

Abstraction examines the software’s structural elements to determine whether they are protectable expression or nonprotectable material, which is filtered out before comparison. Nonprotectable material includes ideas, functionality dictated by considerations of efficiency, functionality required by factors external to the program itself, and elements taken from the public domain.

What remains from the copyrighted work after the filtration is compared with the accused software to determine whether or not the defendant copied protected expression. With proper clean-room development, very little remains from a copyrighted work after the “abstraction, filtration, comparison.”

Technical Teams

Clean-room development requires two technical teams. The first team examines the software to be replaced, observing any license limitations. The second team develops the replacement software from the functional specifications. By documenting the second team’s lack of access to the replaced software and documenting the functional specifications used to develop the replacement software, the developer can build an evidence trail of independent creation regardless of the ultimate similarity between the replaced software and the replacement software.

Of course, it would be better if the second team did not have access before the clean-room development started. While it is difficult to prove a negative, the developer of the replacement software should make a good-faith effort to identify any previous access of prospective second-team members. In the case of Linux, it might be difficult to find second-team members who had no prior access to Linux or Unix-like operating systems.

However, in a Linux clean-room development project, once the potentially tainted portions of Linux are identified, the second team could comprise programmers who know Linux in general but have not had access to the specific portions being replaced.

Consider, for example, a bank that runs a piece of financial record analysis software written in COBOL on its mainframes. Quite possibly, the license granted to the bank is a site-specific license for a specific corporate entity, so when the bank is acquired in a merger or consolidates its operations, a new license might be needed.

It is also quite possible that the software has been running for more than a decade without adjustment or upgrades, and that the original licensor is no longer available. Even if a licensor can be found, the licensor might hold out for extortionary licensing fees, especially if it can hold up the merger process.

Minimizing Risk

In clean-room development, the bank’s first team analyzes the licensed program, determines what the program does, where it gets its data and what it outputs, and documents this functionality, careful to avoid expressions in the original software. For example, the help text, menu names or screen layouts likely involve expressive content, so those details are left out. The first team then generates a functional specification for the replacement software, which it reviews before providing it to the second team.

The second-team programmers never had access to the original software but are otherwise familiar with good programming practices and the programming language used in the replacement software. They are given the functional specification and directed to produce the new software. The expressive content of the replacement software (menu structures, help text or program sequence steps) may match the expressive content of the original software, but without access to the original software, those similarities are due to functionality or coincidence, neither of which is copying as far as copyright law is concerned.

Sometimes an extra step is added. Documents produced by the first team for use by the second team are reviewed prior to giving the second team access, and the queries of the second team are reviewed as well before the first team responds to them. IP lawyers deal with close calls, and company management eliminates unnecessary features. Of course, adding this extra step can also delay the outcome.

Replacing software using clean-room development is not for everyone. Decision-makers should weigh the business risks of a copyright-infringement accusation against the costs of negotiating suitable license terms. It may be that the extra effort is not worth it. But if it does make business sense to replace the software, do it in that parallel universe where you can minimize the risk of copyright-infringement claims down the road.