A Blog About Intellectual Property Litigation and the District of Delaware


Source Code
Markus Spiske, Unsplash

This is an issue I've seen come up a few times, but I don't know of another opinion on it offhand.

Source code is typically managed using a source control or version control system, typically (but not always) using a program called git. Git is a command-line program that allows developers to manage different versions of source code in a tree structure called a "repository."

A developer can create a "branch" within the repository, for example, to work on a specific feature. As they work on aspects of the code for that feature, they can "commit" them, along with a message about the purpose of their revisions. When they are done working on that feature, they can merge that branch with the main branch, and it becomes part of the code.

With that in mind, source control systems like git can include a lot of metadata, including who authored which specific lines of code, the change history for those lines, when they were revised, and—perhaps most importantly—why they were revised.

Obviously, this could be useful in some instances. But it is also a lot of extremely confidential information, and may be hard to safely collect and produce. Plus, huge parts of it are of limited or no relevance. Thus, parties sometimes fight over whether or not it must be produced at all.

We got some insight from the Court on that point, in the form of a short memorandum order from Judge Fallon that was unsealed this morning. She held that a request for access to git history and prior code versions was overbroad and not proportional, at least where the party seeking the code did not identify the specific features it wanted to investigate:

Plaintiff's motion is DENIED without prejudice . . . . Plaintiff seeks the production of prior source code versions and git history information. . . . Plaintiff acknowledges that Defendant already produced two versions of its code from May 20, 2023 and April 22, 2024, and it fails to articulate why this production is insufficient. . . . Plaintiff explains in conclusory fashion that git history would show "when features and functions were added, modified, or altered, including through engineers' notes and comments." . . . But Plaintiff does not identify specific features or functions it wants to investigate or how those specific features and functions are tethered to the claims in this case. Consequently, the request is overbroad and not proportional.

Orca Security Ltd. v. Wiz, Inc., C.A. No. 23-758-JLH-SRF, D.I. 139 (D. Del. Sept. 10, 2024).

It's easy to imagine how a party might articulate the relevance of version control information as to a specific, narrow area of code—but it's also easy to see how it is over-burdensome if they fail to do so. So keep this order in mind if you deal with cases involving source code.

If you enjoyed this post, consider subscribing to receive free e-mail updates about new posts.

All

Similar Posts