Practical legal aspects of software reverse engineering

Reviewer: Gregory M. Aharonian

The apparent errors in this paper are more interesting than the suggestions it makes. While mentioning some important cases, such as Nintendo versus Atari, Sega versus Accolade, and Lotus versus Paperback, the authors point out five basic rules of intellectual property as it applies to reverse engineering: Obtain an authorized copy of the software you want to reverse engineer. (Atari had misrepresented to the Copyright Office why it wanted Nintendos source code.) Also, do not violate any licensing agreements signed with the company whose software you want to reverse engineer. Make sure there are no other ways of obtaining the information in the software other than by reverse engineering. Reverse engineer only those parts of the software you have some interest in. If you adopt much more, you will run into copyright problems. Have two groups involved: one to reverse engineer the original program, the other to develop new software. Research to see if what you want to reverse engineer is patented. In general, this is sound advice. What worries me is that the analysis of some of the examples used to illustrate these points is either partially incorrect, simplistic, or just plain wrong, bringing the relevance of the entire paper into question. First, in discussing reverse engineering while avoiding copyright infringement, the authors write: In Lotus Development Corp. v. Paperback Software International, the court held that Paperback infringed on Lotuss copyrighted software by devising its spreadsheet to have a look and feel similar to Lotuss popular 1-2-3 spreadsheet. Rather than copy only the functional elements of 1-2-3, Paperback had essentially copied much of Lotuss aesthetic qualities as well. This statement is misleading in that it tells part of a story. Lotus was involved with two copyright cases—one versus Paperback, and another versus Borland. In Lotus v. Paperback , Paperback had pretty much copied the entire user interface, except that it had moved the menu bar from the top to the bottom of the screen (or vice versa). Borland, on the other hand, allowed its menus to use the same hierarchy of menu commands, so that it could easily sell to the base of installed Lotus users. The look and feel of the user interfaces of Quattro Pro and Lotus were completely different. While Lotus initially prevailed over Borland in 1990, in 1995 the Court of Appeals for the First Circuit reversed the original 1990 ruling, and in 1996 the Supreme Court upheld the reversal. So this example introduces a nontrivial problem in software copyrights, and the brief treatment is misleading. Second, the authors say that “software developers should conduct research on the product to be reverse engineered to ensure that patent law does not provide protection for the particular process or function that is to be reverse engineered and used in a new program.” Again, this is true, but somewhat simplistic. Several lawyers have told me that they sometimes advise their clients not to do patent prior art searching because of rules imposing triple damages for willful infringement, which could be argued on the basis of searching patents for any reason. While I agree with the authors that the search should be done, they should have mentioned the possibility of triple damages. Third, as part of this discussion of patents, the authors write, “Due to rigorous requirements that must be met in order to get a patent on a certain function or process, few programs are patented.” This is pure nonsense. In 1997 alone, over 13,000 software patents were issued, and about 80,000 total will have been issued by the end of the decade. You cannot apply the term “rigor” to a system that awarded a patent for a 3D pie chart in 1996 (patent number 5,491,779). In short, some straightforward advice is backed up with some misleading information.