Source Code Discovery in Software Disputes

Source code sits at the centre of high-stakes software copyright, patent, and trade secret disputes in the UK courts. Unlike standard commercial correspondence or transactional documents, source code represents both the primary evidential record of alleged copying and the proprietary crown jewels of the business that owns it. Disclosing it carries existential commercial risk, yet withholding it or attempting to review it using ordinary litigation workflows guarantees failure. Modern software is rarely a loose collection of text files; it is an interconnected ecosystem of repositories, build scripts, third-party libraries, and historical commit logs that document precisely who wrote what line, when, and from where.

Litigators managing disputes under Practice Direction 57AD or CPR Part 31 must balance the requirement for full and frank disclosure with strict, proportionate safeguards. Treating source code like standard email or document disclosure creates severe vulnerabilities, including accidental intellectual property leakage, spoliation of forensic commit histories, and unusable review productions. A structured, forensic methodology is required from the moment a claim is contemplated, combining technical repository handling with rigorous inspection protocols agreed between the parties or ordered by the court.

The Nature of Source Code as Evidentiary Material

In software litigation, the code itself tells only part of the story. Modern software development relies on distributed version control systems, predominantly Git. A complete repository does not simply contain the latest snapshot of the codebase; it stores the entire forensic timeline of development. Every commit records an author, a committer timestamp, a cryptographic hash, a commit message, and the exact lines of code added, modified, or removed.

When intellectual property theft or breach of a software development licence is alleged, the repository metadata is frequently more probative than the current functional code. Forensic examination of the Git object database can reveal deleted branches, detached heads, cherry-picked commits, and attempts to scrub author identity using tools like Git filter-branch. Where an ex-employee is suspected of injecting proprietary algorithms into a competitor's product, comparing the initial commit dates in the target codebase against the departure date and exfiltration timeline provides direct evidence of provenance.

Litigators must also distinguish between human-written source code, generated code, third-party dependencies, and compiled binary artefacts. Modern applications incorporate vast quantities of open-source frameworks via package managers such as npm, NuGet, or Maven. In copyright infringement claims, failing to isolate standard open-source dependencies from bespoke proprietary algorithms leads to inflated claims, wasted expert costs, and flawed comparison exercises. Identifying the exact scope of the bespoke code base is the foundational technical step in any software dispute.

Balancing Confidentiality and Inspection under PD 57AD

Under Practice Direction 57AD, disclosure must be directed to the issues and proportionate to the value and importance of the claim. Because source code contains commercially sensitive trade secrets, parties routinely resist standard Model C or Model D disclosure requests without bespoke protective orders. The standard procedural response in the High Court is the creation of a tiered confidentiality club, restricting access to external solicitors, counsel, and nominated independent technical experts, excluding direct commercial competitors.

Source code is rarely produced by simply delivering raw files to the receiving party on an unencrypted drive. Instead, the court will expect the parties to agree a detailed Source Code Inspection Protocol. This protocol dictates the physical and digital environment in which the receiving party's experts may examine the material. In high-value disputes, this takes the form of an air-gapped inspection facility or a locked-down, standalone review terminal with disabled internet access, locked USB ports, and restricted local administrative privileges.

The protocol must govern specific operational constraints: what analysis software the examining expert may install, how notes may be taken, the procedure for requesting limited printed extracts of relevant code lines for inclusion in expert reports, and the logging of all user activity during the inspection sessions. Vague agreements over inspection terms invariably collapse into contentious interlocutory applications, delaying the trial timetable and escalating costs.

Source Code in the eDiscovery Lifecycle

Handling source code requires adapting the standard Electronic Discovery Reference Model (EDRM) to accommodate the idiosyncrasies of software engineering environments. Standard eDiscovery platforms are designed for unstructured text, email threading, and linear review; they perform poorly when ingested with millions of lines of syntactically complex code spread across tens of thousands of dependent files.

Identification

Identify all relevant repositories, hosting environments, and version control systems early. This includes cloud-hosted platforms such as GitHub, GitLab, Bitbucket, and Azure DevOps, as well as on-premise servers and local developer workstations. It is essential to identify the relevant branches, tags, and historical snapshots that correspond to the disputed releases, rather than assuming the main development branch captures the necessary evidence.

Preservation

Preservation must be forensically sound and compliant with ACPO principles. A standard copy-paste of a directory destroys file system creation, access, and modification (MAC) timestamps and risks omitting hidden repository files, particularly the hidden .git directory. Custodians must preserve the complete bare repository or generate full forensic disk images of the hosting infrastructure where local developer tampering is suspected.

Collection

Collection must encompass the full version history. For Git repositories, this involves performing a bare clone or creating a forensic bundle using the git bundle command, capturing all commits, tags, and reflogs. Bit-level physical images should be acquired from developer laptops where evidence of offline staging, external USB exfiltration, or manual code cleansing is anticipated.

Processing and Indexing

Standard eDiscovery text extraction engines struggle with source code files due to non-standard character encodings, lack of natural language structure, and massive file volumes. Dedicated code-aware parsers are required to extract tokens, function definitions, class structures, and comments. Processing must also separate compiled binary artefacts from raw code text and identify external third-party libraries using software composition analysis (SCA) databases.

Review and Analysis

Review cannot be conducted line-by-line within standard document viewers. Review platforms must provide syntax highlighting, structural navigation, and advanced comparison tools. Technical experts conduct both static analysis, such as Abstract Syntax Tree (AST) comparison and algorithmic tokenisation, and dynamic analysis, running the code in a sandbox to observe execution behaviour and functional equivalence.

Production

When producing code to the opposing party, the agreed format is paramount. Producing code as non-searchable TIFF or PDF files is generally considered abusive and technically useless for substantive analysis. Productions must balance the receiving party's need for functional, searchable text with the producing party's right to protect non-responsive or proprietary modules through cryptographic hashing, partial redacting of third-party IP, and delivery within controlled secure review environments.

Technical Inspection Methods: Diffing, ASTs, and Plagiarism Analysis

In software copyright and trade secret disputes, the fundamental legal question often turns on whether the defendant copied substantial parts of the claimant's work or arrived at a similar technical solution through independent development. Determining this requires specific technical analysis methods that go beyond visual comparison.

Simple text diffing tools, which compare line-by-line character matches, are easily defeated. A defendant who has misappropriated code can obscure literal copying by renaming variables, modifying comments, refactoring functions, and rearranging file directories. Expert analysis therefore employs algorithmic tokenisation and Abstract Syntax Tree (AST) parsing. By converting the source code into a hierarchical syntactic tree, the expert evaluates the structural and structural-semantic identity of the programs, ignoring superficial cosmetic changes.

Software similarity tools, such as MOSS (Measure of Software Similarity) or dedicated forensic comparison engines, measure structural commonalities across codebases. Crucially, experts look for anomalous fingerprints: common idiosyncrasies, identical typos in comments, identical structural bugs, arbitrary variable naming choices, and redundant code fragments that serve no functional purpose. In English copyright law, the presence of unexplained, identical arbitrary features provides compelling circumstantial evidence of derivation rather than independent creation.

Practical Steps for Litigators: The Source Code Protocol Checklist

Drafting and agreeing an effective Source Code Inspection Protocol is the single most important tactical step in managing software disclosure. The following checklist outlines the essential operational terms that must be resolved before inspection commences:

• Define the hardware environment: Specify whether the inspection will occur on a standalone, air-gapped machine provided by the disclosing party, a secure escrow terminal, or via a locked-down virtual desktop interface (VDI) without copy, paste, or local export capabilities.
• Agree analysis software and toolsets: Explicitly list the software applications permitted on the inspection machine. This should include suitable integrated development environments (IDEs), diff tools, command-line Git utilities, and agreed static analysis tools. Specify who installs and validates these tools in advance.
• Establish the baseline repository state: Ensure the inspection machine contains the full repository, including the complete commit history, rather than a flattened, unversioned export of source files, unless the court has specifically restricted the scope of disclosure.
• Determine note-taking protocols: Clarify whether the expert may bring handwritten notebooks or must take notes digitally on the terminal. All digital notes must be subject to agreed logging and must not be used as an indirect mechanism for transcribing entire modules of proprietary code.
• Regulate code extraction and printing: Set explicit, manageable limits on the volume of code that may be extracted or printed for inclusion in expert reports. Implement a procedure whereby printed code requests are logged, reviewed by the disclosing party for confidentiality objections within an agreed timeframe, and watermarked with recipient identifiers.
• Define supervision and access hours: Agree whether the disclosing party's representative may visually supervise the room, ensuring that supervision does not breach litigation privilege by observing the expert's specific search queries or tactical investigative work.

Evidential Pitfalls and Sanctions

Failing to manage source code disclosure with forensic precision carries heavy procedural and financial consequences. The Technology and Construction Court and the Commercial Court have little patience for procedural gamesmanship regarding source code access. Unjustified obstruction of inspection protocols or demanding unreasonable restrictions designed to frustrate an opponent's expert will lead to indemnity cost orders and adverse inferences.

Equally, attempting to review source code without qualified forensic computing support exposes litigators to fatal evidentiary oversights. If an expert relies on flawed automated diffing without accounting for common open-source dependencies or standard framework templates, their testimony will collapse under cross-examination. Litigators must treat source code as complex technical evidence requiring specialist collection, meticulous chain of custody, and disciplined cross-examination preparation from the very outset of the dispute.