This month we turn our attention to the U.S. District Court of Delaware. In his article Best Practices in Software Source Code Discovery, Barr Group co-founder and software expert witness Michael Barr enumerates six best practices for embedded software source code discovery and the rationale for each. The source code is the human-readable description of a piece of software or an app, which is written in a programming language such as Python, Java, C, C++, C#, Objective-C, Perl, JavaScript, VHDL, Verilog, or assembly.
The District of Delaware's "Default Standard for Access to Source Code" follows many of our six recommended best practices but remains silent in key areas. We focus on the Delaware Federal court because its source code access rules are made publicly available on its website, as well as for the importance of this district in patent litigation. Many large companies are headquartered in the state and the U.S. Supreme Court's 2017 decision in TC Heartland has made "forum shopping" to sue in other districts more difficult for plaintiffs.
1. Get the Source Code Early
Our top recommendation, in short: "The source code should be requested early in the discovery process to streamline the forensic review process, which could result in significant savings in time and money for both experts and litigators."
The Delaware source code access standard provides for production of relevant source code:
- An "electronic copy of source code [] shall be made available for inspection"
- "Access to the [source code copy] shall be permitted [] to two (2) experts retained by the requesting party"
However, the Delaware standard is silent on the timing of source code production. In our experience as expert witnesses, the owners of source code often resist requests for its production and the terms to delay the start of code review. In that respect we view the publication of default rules as an aide to early discovery in that established norms with consideration of security limit the points of possible resistance to production.
Note that nothing in this article is meant to favor plaintiffs or defendants, but rather we aim to ensure the most reliable expert analysis of source code on the assumptions that (i) production of the source code is relevant to the litigation and (ii) eventually going to happen.
2. Ask for the Bug List
We also recommend that "At least in cases of alleged product liability, the software development team’s defect database—or 'bug list'—should be routinely requested and supplied in discovery." However, defect databases are not specifically mentioned in the Delaware source code access standard.
The Delaware standard is similarly silent on the production of "copies of software design documents, coding standards, build logs and associated tool outputs, testing logs", etc. This is unfortunate, in our view. Though not the case in every type of technology litigation equally, these and other artifacts of the software design and development process often provide important clues and/or evidence related to questions at issue in a case.
3. Insist on an Executable
In software parlance, the “executable” program is the binary version of the program that’s actually executed in the product. This machine-readable executable is constructed from the set of human-readable source code files using software development tools. Sometimes it is possible to extract the executable directly from the product for expert examination—in which case an expert should often engage in this step.
The Delaware standard addresses the subject of production of executable programs:
- An "electronic copy of source code or executable code shall be made available for inspection"
- "If the court determines that the issue of missing files needs to be addressed, the source code provider will include [] the build scripts, compilers, assemblers, and other utilities necessary to rebuild the [executable] application from source code, along with instructions for their use."
We find these rules a bit odd in that executables (and the means to recreate them) may not always be helpful to a software expert witness solely for the reason of missing files. However, the norms are sufficient as long as the court is open-minded when these additional productions are relevant to source code reviewer(s) for other reasons.
Access to executable versions of software can sometimes have a large impact in litigation. Though not human-readable, an executable may provide valuable information. For example, human-readable “strings” within an executable (e.g., “Press the ‘?’ button for help.”) are readable. In a copyright infringement case once worked by Barr Group software expert witnesses, several strings in the defendant’s executable said basically “Copyright Plaintiff,” which obviously had a major impact on the case.
4. Reproduce the Development Environment
The fourth recommendation in Michael Barr's article is to "confirm that all of the source code has been provided [by using] a copy of the development team’s detailed build settings [to] produce a executable." If the executable as built matches the executable as produced—or ideally, extracted from the product—bit by binary bit, it is certain that the other party has provided a true and correct version of the source code.
The Delaware source code access rules address this issue in the bullets cited in the prior section above.
5. Try for the Version Control Repository
All software is developed one layer at a time over a period of months or years in the same way that a bridge and the attached roadways exist in numerous interim configurations during construction. The version control repository for a software program is like a series of time-lapse photos tracking the day-by-day changes in the construction of the bridge.
If the court only allows a plaintiff to choose one snapshot of the defendant’s source code from some specific software version or date (or, worse, allows the defendant to choose the snapshot), an actual patent infringement or software copyright or trade secret theft may be overlooked. If the plaintiff is lucky, evidence of their intellectual property in that specific snapshot will be found. However, the absence of their intellectual property from that one specific snapshot does not prove that the alleged theft did not happen earlier or later in time.
The default Delaware rules do not specifically address this issue. However, if you do succeed in obtaining multiple versions of the source code, note that another rule addresses the tools you will have at your disposal to compare them:
- The source code review computer "shall include software utilities [] to view, search, and analyze the source code. At a minimum, these utilities must provide the ability to (a) view, search, and line-number any source file, (b) search for a given pattern of text through a number of files, (c) compare two files and display their differences"
6. Remember the Hardware
Though it is comprised of ethereal ones and zeros and lighter than air, software doesn't exist in a vacuum. Every software app or program is written to run on some specific class of electronic computer hardware.
To perform a thorough analysis of a system, firmware testing should be done on the hardware as configured in exemplars of the units at issue. Therefore, it is useful to ask for hardware during discovery if you are not able to acquire exemplars in other ways.
The Delaware rules do not specifically address this issue either, but we hope that plaintiffs will remember to ask for the physical hardware and/or hardware design documents in their requests for production of documents and things and that the court will abide these requests.
Hire the Right Experts
The best practices presented here are meant to establish the critical importance of making certain specific requests early in the source code discovery process. They are by no means the only types of analysis that should be performed on source code. This and other types of technical analysis should be well understood by software expert witnesses with the proper background.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews, expert reports and testimony for product liability, patent infringement, software copyright, and trade secrets litigation involving computer-based technology and software. HIRE AN EXPERT
