5 Avoidable Pitfalls in Source Code Discovery

A litigator and a Ph.D. in computer science provide practices to avoid misconceptions, dead ends and cost overruns in source code discovery.

November 25, 2013

The costs associated with computer source code discovery can mount quickly. Experts and code reviewers may be needed to examine and sift through large quantities of code to find the relevant information. Multiple versions of the source code may be at issue. Additionally, if multiple products are involved, the review of multiple source code versions becomes even more complicated. Further, many companies consider source code to be their “crown jewels” and may resist an uncontrolled production of the code. Thus, source code production and review can quickly compound the expense of discovery.

In our previous article we discussed several techniques useful for streamlining source code discovery and containing costs. These techniques ranged from using targeted interrogatories about source code operation to narrowing source code production requests with feature descriptions. Still, even after employing these techniques, efficient investigation may be impeded by misconceptions about the source code and related documents.

This article considers several of these misconceptions and suggests practices to avoid dead ends and unnecessary cost overruns.

1. Educate reviewers on the goals and context

An educated source code reviewer is the greatest source of cost savings. Starting with limited instruction on what to find can lead to countless hours wasted when reviewers inspect irrelevant information. One can provide direction beyond the simple instruction to find a certain function in a number of ways, including providing a defined algorithm description or a summary question set. The attorney/reviewer team should also discuss and, if possible, walk through the product features, review product documentation that describes a product’s features, and study the producing party’s internal information (like design specifications) related to the product.

Some of this investigation may have been completed before the suit or counterclaim was filed, but reviewers may not have been involved in the evaluation. This initial investigation provides important leads for additional review. For example, the information may provide references that software developers likewise used when writing the source code. Software developers may have used descriptive names for algorithm functions or variables that relate to other product documentation. These descriptive terms may be good search terms to use to understand the produced source code.

2. Be cautious of product design documentation

Attorneys and reviewers should use software design documentation with caution because it may not accurately reflect how a product works. Design documents are a popular category of information to request. Generally they describe the software to be developed, including requirements, specifications, intended goals, components, and constraints. But these documents have limitations.

Software development spans multiple stages, including requirement gathering, designing, prototyping, developing, testing, deploying, and maintaining. The software design may change in these stages and again as technical problems are resolved. As this occurs, the designer and developer of the software may document the changes in the design document or other document describing the features of the software. But sometimes the fact that there are changes is not recorded at all. Therefore, when the design disagrees with the source code of the product on certain issues, the source code should control. After all, in many cases (like patent infringement) what matters is what the source code “says” and not “what was intended to be said.” Hyperion Solutions Corp. v. Outlooksoft Corp., 2006 U.S. Dist. LEXIS 97106 (E.D. Tex. Aug. 25, 2006).

It is important, however, for the review team to maintain flexibility of legal theories should the source code diverge from the design documentation. But also keep in mind that the importance of the actual source code over product design specifications does not make the latter any less relevant or discoverable. Product design is at least relevant to the intent of the party and damages, and may inform of such things as a party’s intent to copy during development.

3. Don’t ignore source code comments and modification logs

Comments within source code are a valuable resource for describing how the source code works. This is particularly true where, as discussed above, the software itself may diverge from the design specification. In many cases, comments describe in natural language a change in the code that may otherwise be unclear from the code itself.

Still, caution should be exercised. During compressed development or testing cycles, priority may not be given to documenting changes in the code. Instead, developers are focused on making the source code operational for release. Therefore, in some cases comments may be inapplicable to the associated source code, or comments may reflect an early modification to the code that was itself modified. If a comment seems valuable, it is worth confirming its value with a deposition.

4. Don’t assume that a feature in the source code is a feature in the product

Reviewers should also be careful to focus on what features and source code are actually in the accused products, as opposed to features that appear in the source code itself. Source code is usually implemented in a modular design in which each module addresses a particular feature within the product. This strategy reflects good design and development practice. Modular design also allows for multiple related products based on the same source code set.

Some companies may offer software products with a variety of feature sets to different users or markets. Modular design allows the company to account for different software products by only changing the underlying software for differences across products. Thus, during review in litigation, it is possible to get distracted with source code that relates to products that are not accused or features that are not part of the accused product. Reviewers should exercise vigilance to identify these distinctions by using compiling files and configuration files that explain what components comprise each product. These files should be analyzed with release notes. When in doubt, consider using a deposition to clarify ambiguities.

5. Don’t assume the same feature in similar products means the source code is the same

As a product evolves from generation to generation, the underlying software may change. This change can be significant. Software development of a product is usually incremental. From product generation to product generation, an older feature may receive additional functionalities, but the source code executing the feature remains the same. At other times, however, the source code underlying the feature may fundamentally change. One reason might be efficiency: an algorithm that is expensive and slow on performance measures may be redesigned or optimized for better performance. The source code could be modified for use with different hardware architecture. Another reason is to resolve a conflict that arises between a newly introduced feature and an existing feature. Or features may be phased out and/or combined with other features.

Accordingly, the investigation should apply techniques to evaluate the similarities and differences between multiple produced versions of source code. Techniques may involve the simplistic—applying a differential comparison function to files with the same names that are used by each version of source code—to time-consuming and expensive—reviewing every file produced. Intermediate techniques may yield acceptable results while minimizing cost. For example, one can review the first and last versions of a file. If the same, an assumption can be made that interim file versions are the same. And, if it’s important, this assumption may be confirmed with a deposition.

The Bottom Line

Source code discovery presents a host of potential traps for unnecessary costs and inefficiencies. One way to avoid waste is to keep the endgame in mind. If you are vigilant in focusing on the particular relevant features, you can avoid many of these pitfalls and save a great deal of time and money.

David A. Prange is a senior associate with Robins, Kaplan, Miller & Ciresi and focuses his practice on patent and trade secret litigation. In recent years, he has represented plaintiffs and defendants in patent cases involving source code issues, including the successful assertion of source code-based patent claims at trial. Esam A. Sharafuddin Ph.D. (computer science) is an in-house scientist with the firm and experienced in software development and system architecture

Reprinted with permission from the October 2013 issue of Corporate Counsel. Copyright 2013 ALM Media Properties LLC. Further duplication without permission is prohibited. All rights reserved.

The articles on our website include some of the publications and papers authored by our attorneys, both before and after they joined our firm. The content of these articles should not be taken as legal advice. The views and opinions expressed in this article are those of the author(s) and do not necessarily reflect the views or official position of Robins Kaplan LLP.


Esam Sharafuddin, Ph.D.

Science Advisor

Back to Top