Litigants in software and IT disputes often request the production of source code. Whether investigating claims of misuse of intellectual property, or analyzing source code quality in software project failure disputes, production of source code is usually needed. To ensure that legal arguments can be supported without compromising the security of unrelated information, it is imperative for counsel to draft appropriate production requests and understand those of the opposing party.
This article outlines principles for effective source code discovery in IT litigation.
Benefits of Source Code Production for Analysis
Source code analysis may be relevant in various types of software litigation. In software patent disputes, for example, it can be important to conduct detailed tracing of source code to understand whether a defendant’s algorithm falls under the aegis of an asserted patent claim.
Further, it can be critical in copyright infringement cases to compare the opposing parties’ source code to identify instances of literal copying. Source code analysis may also be helpful for determining whether a defendant has copied the structure, sequence, or organization of the plaintiff’s software.
Analysis of source code can also be crucial in software failure disputes. It is often helpful in such cases to examine source code repository metadata to determine the authorship, timeframe, and rationale for source code modifications.
If the quality of the source code is at issue, automated tools may be used to assess the security, maintainability, portability, and readability of the source code. Finally, an examination of source code modifications may be useful for determining whether a vendor timely resolved software defects.
Source Code Examination & Discovery Tips, Techniques and Pitfalls
Source code can be organized in a variety of ways. For example, software developers frequently manage source code repositories using a formal version control system, or “VCS,” such as Git, Mercurial, or Subversion.
A VCS manages multiple versions of source code files and automatically captures data relating to the nature and authorship of source code modifications.
As such data are typically the most complete, accurate, and reliable record of the source code’s version history, production requests should usually include the opposing party’s version control system.
Though version control systems may be hosted on local servers, it is increasingly common for software developers to rely on third parties to host such systems.
In these cases, providing the receiving party with access credentials to the third party’s system may be more efficient than copying the source code to an external storage device.
As hosting systems often provide varying degrees of access to source code, it is important that the receiving party be provided with access privileges sufficient to view the source code and corresponding metadata. These credentials can be suspended after the dispute is resolved.
Some software developers do not use a VCS to organize source code. In such cases, the requesting party should tailor its discovery requests to include all relevant source code in its native file format, such as “.java”, “.sql”, or “.html”.
It is especially important to request any documents, such as work logs, that identify the timeframe and authorship of source code modifications. Since developers sometimes use passwords to restrict access to source code files, the producing party should also provide any access credentials needed to review the produced materials.
The failure to obtain the above materials can limit the analysis that can be performed during litigation. For example, if a copyright defendant does not produce all relevant versions of its software files, it may not be possible to determine whether it has copied a plaintiff’s source code.
Further, the absence of work logs, either tracked automatically through a VCS or manually through log files, restricts the ability to research the history of a party’s software construction efforts.
Producing source code files outside their native file format, as PDF exports for example, can prevent them from being properly authenticated.
Special consideration should be given to the dispute’s legal claims and corresponding factual timeline. Source code production should be limited to versions created or modified during the relevant time period.
In a trade secret dispute, for example, a plaintiff might claim that the defendant incorporated confidential information into a competing software product. If the plaintiff requests production of the source code for the competing product, the defendant should only produce versions created during or after the alleged misappropriation.
It is helpful to frame discovery requests with as much specificity as possible. For example, vendors sometimes co-mingle source code for different software modules within the same source code repository or version control system. When possible, the production should be limited to source code from software modules that relate to the dispute.
Where co‑mingling of source code prevents such a limitation, it may be desirable to negotiate a protocol prohibiting an opposing party from examining irrelevant materials.
Conclusion
In both intellectual property and software failure disputes, source code discovery is an important aspect of the litigation process.
Careful consideration should be given to the mechanisms used for storing and organizing source code repositories, tracking modifications, and protecting security.
Production requests should be informed by the parties’ legal arguments and the underlying factual timeline. When drafting source code production requests, attorneys are well advised to collaborate with a software and IT consulting expert to ensure the availability of materials needed to maximize the likelihood of success.
