A litigation source code review is the expert examination of software source code as evidence in a legal dispute, conducted to determine whether that code was copied, contains misappropriated trade secrets, or practices a patented invention.
The term “source code review” has different interpretations depending on context. In the software development industry, it could mean an internal evaluation of one’s own source code to identify vulnerabilities, evaluate and improve code quality, or reduce maintenance costs. It’s remedial in that context.
In litigation, however, the term refers to an evidentiary analysis performed by an expert to identify facts material to an underlying legal dispute. It entails an expert’s examination of source code evidence to reach factual findings in support of legal conclusions as to whether source code was copied, contains misappropriated trade secrets, practices a patented invention, or even to gain deeper understanding about other specific questions relating to the source code.
This could mean evaluating source code to understand its progeny or dissecting the source code to evaluate potential similarities or understand how it implements certain functionalities, or to prepare a historical timeline of the code’s development.
There is a common tendency to misconceive source code review as merely a single uniform service that involves retaining an expert, handing over source code, and receiving an opinion or report on the questions presented. In practice, the exercise is much more complex than that. As discussed below, litigation-based source code review entails a variety of techniques and analyses with a common purpose: identify information to answer factual questions material to the underlying legal dispute.
As an initial matter, simply providing access to, or “handing over,” the source code and identifying what other artifacts or technical documentation will be helpful or relevant may be a significant effort on its own. Indeed, experts can be effective at supporting counsel in not only identifying which materials will be relevant to either side of the dispute but also can assist in preparing, and responding to, requests for production that concern relevant systems of record.
This assistance helps avoid potentially overbroad, generic, and tenuous requests for materials that contribute to ongoing discovery disputes concerning relevance and responsiveness.
However, having access to the right corpus of systems or information is only part of the equation; what to do with the information and systems once access is provided and how to get out of it what is needed to make a case matters just as much, if not more.
Importantly, litigation source code review is not just one task, but a category of tasks and analytical techniques that can be applied to identify facts material to the range of underlying legal claims.
The factual questions presented for expert analysis and investigation, and the scope of information provided to the expert influence the selection of methodologies and techniques that can be applied. Similarly, other constraints such as scale, complexity, available time, and cost influence the depth and breadth of what can reasonably be accomplished in source code review.
Each individual case comes with its own unique constraints which influence what “source code review” as a category of tasks and analyses means. For example, protective orders that constrain access and location of source code review, and size and complexity of the source code directly impact the time and effort required for thorough analysis.
Analyzing and comparing five large code sets split across twenty different repositories that can only be accessed by an individual reviewer from a single computer is significantly more costly, time consuming, and overall challenging than comparing two distinct source code versions provided to an expert via encrypted hard drive or other secure delivery means.
Moreover, the same corpus of available systems, information, and analyses requested of an expert can support different findings and conclusions depending on the underlying legal claims.
Thus, matching the analytical techniques to the types of underlying legal claims, available information, and systems of record is a threshold decision that can strengthen or weaken a case. This article discusses analytical techniques an expert may deploy to support various types of legal claims.
Example Source Code Review Methodologies
Source code review has significant utility in copyright infringement, trade secret misappropriation, and patent infringement contexts, but relevant analytical techniques and methods differ in each context.
In each scenario, an expert’s analysis often begins with similar raw inputs, including source code repositories or version control systems, relevant versions of source code, source code development history and/or development management systems, release notes, and other technical documentation, but diverge in what the expert ultimately does with those inputs. Below are some classes and categories of analyses that can be employed on different types of matters.
Literal and/or Non-Literal Similarity Analysis
A literal similarity analysis is straightforward in concept, but not in technique. A literal similarity analysis generally involves looking for verbatim or near-verbatim textual duplication between two or more sets of source code. This can be viewed from different levels within the code, however, including character-by-character, line-by-line, block-by-block, or file-by-file.
Further, it’s not always the case that a certain string of characters will appear in the same, or nearly the same, spot within the allegedly offending code, and so experts deploy numerous techniques for identifying these matches throughout the code without restricting focus to just individual files.
Examples of this are techniques like fuzzy-matching, which can identify inexact matches across the entire codebase for manual evaluation, or longest-common-subsequence matching, which is the longest sequence of characters that appear in the same relative order in two sequences, but not necessarily contiguously.
By comparison, non-literal similarity analysis involves applying a much more specific technique. In this type of analysis, an expert applies the Abstraction-Filtration-Comparison test to look at various components of a computer program to identify similarities that may be literally distinct but are similar in their non-literal components.
As we’ve discussed in another recent article about the abstraction-filtration-comparison test, this analysis generally entails decomposing a program into various “levels” of abstraction from source code up to module structure, data structure, program architecture, and general idea or function, filtering out non-protectable components at each level, such as ideas, process, methods of operation, or elements dictated by efficiency or external factors, and then lastly comparing the remaining protectable expressive content to evaluate qualitative and quantitative similarities, if any.
In this type of analysis, the methodology is subtractive in nature; an opinion flowing from this analysis built upon the remainder, which may be only a small, but potentially material amount of similarity.
Additionally, experts often look for various clues that indicate certain strings of text are the result of duplication, such as preserved source code comments, identical variable and function names, carried-over bugs and dead code, and even replicated idiosyncrasies such as typos or unique spellings. Specialized comparison tools, like Beyond Compare, or DisputeSoft’s Code ACETM tool make source code review simpler by leveraging numerous analytical techniques specifically for literal copying analysis and offer different methods for looking at the code and manually evaluating detected matches, even on very large codebases.
Registration and Deposit Copy Validity
Experts can also examine source code as compared to a copyright registration deposit copy to understand which version of code was registered and whether asserted code corresponds to the registration.
While the deposit copy is a vital piece of information for acquiring a copyright registration, the deposit copy does not always contain all essential pieces of information to understand which version was registered or which code files were part of that version. In some cases, extrinsic technical documentation and repository metadata can help an expert piece together the proper combination of source code files that comprise a registered version.
However, as we’ve seen in practice, historical records on these very points can be incomplete, introducing a significant barrier to establishing material facts. For example, if a deposit copy excludes a key source code file that has been heavily modified at various points in its development history, knowing which version of the source code file was present in which version(s) may be significantly important.
Development History Assessment
Experts can perform source code review to assess whether the source code was independently developed, or originates from some other source, such as AI-generated code or code licensed from third parties, or even whether it was developed using clean-room design protocols.
If available at the time, the source code review may accompany review and evaluation of multiple source code repositories and historical repository artifacts, as well as other relevant project documentation, technical specifications, and developer records.
Of course, doing source code review on its own can help develop facts that can support the claims, but combined with other artifacts, it can be vital to assessing access and chain-of-creation evidence to support an inference of copying, misappropriation, or infringement.
Functional Code Analysis and Reverse Engineering
Experts are frequently engaged to conduct source code review early in litigation to help translate vague or ambiguous assertions of program functionality into more concrete functional descriptions, which may be helpful in defining a claimed trade secret or evaluating functions in the context of a patent’s claim, or even to assist with developing or refining technical documentation. This may include stepping through portions of the code to understand the function and significance of algorithms, database schemas, parameter sets, architectural design approaches, or training data pipelines, and documenting the functional operation as observed from the source code review.
This component of source code review can be particularly significant in a trade secret context, where disclosing the claimed trade secrets with some degree of specificity is vital to the matter. For example, on the defense-side of these matters, opposing experts often seek to attack the claimed trade secret as overly broad or not specific enough to identify a trade secret.
Therefore, having a clear understanding of the scope of the trade secret, as learned through source code review, not only strengthens case posture, but also provides key clues to know what to look for in accused products, or even in the public domain or industry to assess whether the claimed trade secret is generally known or readily ascertainable.
Forensic Data Evaluation
Source code review often involves varying degrees of forensic analysis of artifacts to gain a more comprehensive understanding of the source code and what to take away from the review.
Such information may provide key evidence and considerations that support other types of computer forensic analyses listed above, such as development history and similarities analyses. For example, an expert may evaluate artifacts as the source code repository’s version control history, commit metadata, external device connection records, cloud sync and personal email activity.
Importantly, forensic techniques deployed in source code review can enable an expert to reconstruct timelines relating to development history, unauthorized access or copying of certain files. An expert may also look to evaluate other extrinsic data such as file modification and deletion timestamps, and track-covering activities, such as data wiping or timestamp manipulation, which may provide additional context for unauthorized access or copying or evidence of derivative use of claimed material.
Further, leveraging certain forensic techniques can also help an expert assess the degree to which a party deployed means of restricting access and permissions and whether they were effective. For example, evaluating a system’s access logs, confidentiality markings, and credential management can become vital pieces to source code review to help build the timeline and establish key facts such as to whether measures were in place to protect claimed trade secrets.
A relatively clear sense of analytical objectives and techniques to be applied helps ensure that a source code review can be accomplished with minimal issues and greater efficacy. Further, the extent to which an expert can leverage programmatic analytical tools to support these source code review techniques can increase the scope of material an expert can effectively analyze.
This can decrease the cost-per-hour, or cost-per-line of code reviewed and allows an expert to more effectively exercise consistent judgment, rather than relying strictly on manual review and analysis for these challenging tasks.
Source Code Review Methodology Selection Depends on Legal Context
As indicated above, the underlying legal claims heavily influence the methodologies an expert can deploy to support the matter. The starting point in various contexts may appear the same at the outset (e.g., undertake thorough analysis of the source code and related material to investigate factual questions), but the distinct output from each methodological approach matters.
This is the case because the legal claims have different objectives, and meeting those objectives requires different types of evidence, and use of different techniques to identify that evidence.
For instance, consider an expert’s role in supporting a software copyright infringement case. As discussed in a recent article, the governing questions behind an expert’s analysis relate to whether the source code contains protectible expression, and whether there is substantial similarity.
An expert may undertake a combination of literal and non-literal analysis to answer questions around similarity but evaluate the repository metadata and deposit copy material to determine which versions are relevant, whether there are issues with the registration, or even to understand the development and creation history of the program.
To compare, an expert’s role in supporting a trade secret misappropriation matter has distinct governing questions. An expert may undertake a different combination of analyses, including non-literal similarity analysis, development history assessments, functional mapping/tracing, and evaluation of relevant industry materials to aid in meeting the specificity requirements of identifying trade secrets, evaluating whether the claimed trade secrets are secret or are common industry knowledge, or even whether an accused product uses the claimed trade secret information.
When Multiple Claims are Pleaded in the Same Case
Often in software IP disputes, though not always, copyright infringement and trade secret misappropriation claims are plead together; similarly for trade secret misappropriation and patent infringement.
It’s important to note that this does not always mean that one review satisfies multiple purposes; it means that an expert likely needs to run parallel analyses based on the same shared evidentiary foundation and take additional measures to ensure the methodologies used, as well as the conclusions and opinions that flow from them, are clearly separated in a report and subsequent testimony.
Doing this helps establish a clear, linear path from the methods used to the resulting conclusions and opinions without conflating material facts or issues in a way that results in confusion or unreliable testimony.
For example, applying the abstraction-filtration-comparison technique in a trade secret matter may occasionally offer useful insights into the source code’s functionality, because it allows an expert to evaluate the code at different levels of granularity. However, filtering away algorithms and architecture that may embody a key piece of the claimed trade secret reflects a clumsy methodological error which may produce incorrect findings and conclusions.
Similarly, producing findings and conclusions that purport to show similarities produced strictly from a methodology which does not appropriately filter or account for third-party or common industry knowledge, or otherwise offering statistical outputs without contextualizing its significance in the context of the legal issues, suggests methodological errors that can invite Daubert challenges.
Engaging the Right Expertise Early
An important point to note is that determining which methodologies are most relevant early in the process has downstream consequences on discovery scope, protective order negotiation, and preservation obligations. All of these may be easier to shape before positions harden, and early engagement can pressure-test the strength of a claim before a complaint fixes the theory.
Conclusion
Source code review can be understood as a family of methodologies that can be deployed for various purposes, targeting specific types of information relating to the underlying factual questions. For example, the “menu” of methodologies that may be deployed in determining whether two sets of source code are similar will differ from the menu of available methodologies deployed for investigating whether a claimed trade secret meets the appropriate standard, or whether the claimed trade secret information is actually being used in the accused software.
Perhaps one of the most important considerations in evaluating an expert witness’s fit is whether the software expert demonstrates the appropriate judgment to know which of these methodologies is likely to be most helpful to the matter disposition, and the discipline to apply it consistently.
Attorneys handling software related disputes, specifically software copyright or software trade secret matters, are encouraged to contact DisputeSoft for a confidential case evaluation.
With over 23 years of experience conducting source code review and analysis in complex software IP disputes, DisputeSoft’s experts bring both the technical tooling and methodological rigor these types of cases demand.
FAQs of Litigation Source Code Review
What is litigation source code review?
Litigation source code review is a combination of tasks and analytical techniques applied by an expert witness to identify material facts to support a range of underlying legal claims. The specific tasks and analytical techniques deployed in any particular source code review session depend on the nature of the legal claims, available information, and specific questions or analyses requested of an expert, as the same body of information can support a range of different findings and conclusions. Identifying the appropriate techniques to use is a threshold decision that can strengthen or weaken a case, and is not merely a technical detail.
What types of analytical techniques would an expert use in source code review?
That depends largely on the specific legal claims or reasons for the source code review. In a copyright infringement matter, for example, an expert may undertake a combination of literal and/or non-literal similarity analyses, development history analysis, or evaluate the deposit copy and registration materials, trying to identify evidence that can support findings relating to substantial similarity or issues with the deposit copy or registration.
In a trade secret matter, an expert may undertake a different combination of analytical techniques geared toward identifying or assessing the scope of a claimed trade secret, or evaluating whether that information or functionality was accessed and/or used inappropriately. In a patent infringement matter, yet another combination of analytical techniques may be used to support findings regarding whether a product practices the claims of a patent.
Why does selecting the appropriate analytical technique matter?
There are a few practical reasons why selecting the appropriate technique matters. First and foremost is cost. Source code review can be expensive, requiring significant time and resource commitments depending on a few factors such as the size of the code base, the complexity of the technology, and its intended purpose.
Understanding which techniques are most relevant can help avoid unnecessary costs associated with investigating an issue not in dispute. Second, but equally significant, is quality. In matters that involve multiple legal issues and multiple techniques to support case theories, it can be easy to conflate findings and their significance if there is some disconnect between the methodology and the conclusions and findings. A source code review undertaken with sound technique often results in conclusions that are clearly delineated and defensible.
Why are forensic techniques and analyses important for source code review?
Forensic techniques and analyses can help identify meaningful and significant context to findings that are purely derived from a source code review. Forensic techniques help build a narrative around what happened at key points in time, why those events matter, and can help a fact finder understand what likely occurred based on concrete data and information that is largely inscrutable on its own.
