How expert witnesses examine source code in IP and copyright disputes. A technical methodology guide covering forensic analysis, git history, and court reporting.
Source code comparison is bread-and-butter work for software developers. We do it constantly: reviewing pull requests, resolving merge conflicts, understanding what changed between releases and why. The tools are mature, the habits ingrained. Most developers have strong instincts about when two pieces of code are too similar to be coincidental.
But what those instincts do not translate into directly is courtroom evidence under CPR Part 35. The gap between “I can see this has been copied” and “I can explain to a court why I hold that opinion, on what methodology, with what degree of confidence” is a significant one. There are plenty of diff tools, code similarity scanners, and plagiarism detectors. None of them were built for expert witness work. None of them produce findings structured around what a court actually needs to understand.
This guide documents the methodology I use when instructed to examine source code in IP disputes.
It began as a personal crib sheet, making explicit the approach I had developed through software engineering practice and applied to forensic examination. I am making it public because solicitors and their clients facing these cases find it helpful to understand how a rigorous examination is conducted, and because nothing comparable appears to exist in the UK market. It is written for both audiences: solicitors and litigation teams who need to understand what a rigorous examination involves, and technical practitioners looking for a structured forensic approach.
Before You Touch the Code: Evidence Preservation
The first thing to do when you receive a code examination instruction is nothing. Not until you have established provenance.
Every codebase you examine is evidence. The way it was obtained, the date it was captured, the person who captured it, and the form in which it was handed to you. All of this matters. A court will want to know that the code you examined is the code that was actually in dispute, and that nothing happened to it between capture and examination that could have altered it. This is the chain of custody, and it applies to source code just as it applies to any other physical exhibit.
In practice, this means documenting precisely what you received: a git repository export, a ZIP archive, a disk image, or access to a live system. If it is a git repository, note the commit hash at the point of export. If it is an archive, hash it. Record the date and time you first opened it, and do your substantive work on a copy rather than the original. These steps take minutes and make your methodology defensible under cross-examination.
In my experience, the form of the export matters more than people expect. A git repository contains history; a ZIP archive of the same files does not. If you are given a ZIP, you have lost everything the repository’s history could have told you. Where possible, instruct your solicitor to request a full repository export rather than merely a snapshot of the current state.
What to Tell Your Client to Preserve Now
Before the expert is even engaged, the solicitor’s most useful contribution is often preservation of evidence that degrades quickly in normal operation. The items below age out in weeks rather than months, often through routine IT processes rather than deliberate destruction. The earlier they are captured, the more complete the eventual examination can be.
- A full git repository export, including history. Not a ZIP of current files, not a tarball of HEAD. The expert can then verify the export against the live system independently.
- Hashes and timestamps of every artefact at the moment of capture. SHA-256 over each file or archive, and a written note of who captured it, on what machine, at what date and time.
- Access logs for the source control system covering the relevant window. GitHub, GitLab, Bitbucket, and Azure DevOps retain these on different schedules; many retention windows are shorter than litigation timelines.
- Mailbox contents for the suspected actor and their immediate team. Mailboxes get archived, holders move on, and retention policies cut in often within months.
- A forensic image of any relevant work device before it is reissued, wiped, or returned to leasing. Devices in normal IT rotation rarely survive a year in their original state.
- DLP and USB transfer reports for the relevant window, where any such tooling was in place. Logs of this kind often have the shortest retention windows of all.
Preservation is cheap when done early and impossible when done late. The expert can advise on which items matter most for the specific shape of the case, but the solicitor’s instruction to preserve everything in this list should not wait on engagement.
Read Before You Compare
The instinct, when faced with two codebases and an allegation of copying, is to reach immediately for a comparison tool. Resist it. Before you compare anything, you need to understand what you are looking at.
Start by characterising each codebase independently. What languages does it use? What frameworks and libraries does it depend on? How much of the code is genuinely bespoke, and how much is open-source or third-party? This matters enormously because a large proportion of any modern codebase will be framework scaffolding, standard library calls, or common patterns that any competent developer would write in the same way. These will appear as similarities in any automated comparison, and they are almost entirely uninformative. You need to know what to filter before you know what to trust.
Look also at the architecture. How are the modules organised? What naming conventions are used: files, classes, functions, variables? Are there structural decisions that are unusual, or that reflect a particular design philosophy? At this stage you are not looking for similarity; you are building a mental model of each codebase so that when you do find similarity, you can assess what it means.
I find it useful to write a short characterisation of each codebase before I begin the comparison. A paragraph describing what kind of software it is, how it is structured, and what its notable features are. It forces you to look properly before you start matching, and it forms a useful preamble to the eventual expert report.
Git History as Forensic Evidence
Version control history is, in my view, one of the most underused sources of forensic evidence in source code disputes. Most attention goes to the code itself. The history of how that code came to exist is at least as telling.
Normal software development leaves a particular kind of trace. Commits are frequent and incremental. They are accompanied by messages that describe what changed and why. Early commits contain skeletal code and failing tests. Later commits refine, fix bugs, respond to review comments, and add documentation. The history tells a story of iterative discovery: the developer working something out, making mistakes, correcting them. It is messy in the way that real work is messy.
Copied code does not tell that story. What I have seen, in cases where copying is suspected, is a different pattern entirely. Files appear fully formed in a small number of large commits. There are no prior attempts, no failed experiments, no early versions that were later replaced. The commit messages are generic or absent. There are no review comments because no review took place. The code does not evolve; it simply arrives.
One of the most telling signals, where the evidence supports it, is the absence of bugs that were later fixed. Real codebases carry the sediment of debugging: commented-out experiments, TODO notes, variables that were renamed halfway through, dead code that was never cleaned up. Not every case will have bug tracking data or issue history to draw on, but where it exists, a codebase with no record of defects and no trace of iterative correction deserves close attention.
Commit timestamps deserve scrutiny too, though with care. Timestamps in git are set by the committing machine and can be manipulated. A cluster of commits all made at the same time, or commits made outside any plausible working pattern, may indicate that a repository was constructed rather than grown. I would not rely on timestamps alone, but combined with other indicators they can add weight to a finding.
Look also at the author metadata. In a genuine collaborative codebase, multiple authors will have contributed over time. Their contributions will be visible in the history. A repository with a single author, or with a sudden change of author at a suspicious point, is worth examining more carefully.
Similarity Analysis — Tools, Limitations, and Method
There is no tool designed specifically for forensic source code comparison in the context of copyright litigation. What exists instead are tools built for adjacent purposes, each of which can be pressed into service with appropriate care and scepticism.
MOSS (Measure of Software Similarity) was built to detect plagiarism in academic submissions. JPlag was built for the same purpose. Simian detects duplicate code within a single codebase, primarily to support refactoring. None of these were designed to produce findings suitable for a court. They will produce a similarity percentage and highlight matching regions, but interpreting that output requires significant human judgement.
Before running any comparison tool, you need to normalise the code. This means stripping comments, normalising whitespace, and paying particular attention to identifier renaming. One of the most common obfuscation techniques is to rename variables and functions. A tool doing simple text matching will miss renamed code entirely. AST-based comparison (comparing the abstract syntax tree rather than the text) is more robust to this, but requires more technical setup, and the tools are less mature.
The most important thing I can say about similarity percentages is this: a number without context is almost meaningless. Forty percent similarity between two Java Spring Boot applications may be unremarkable. Forty percent similarity in a small, bespoke algorithm with no obvious common source is highly significant. The percentage tells you how much code matched; it does not tell you whether that match is explainable.
What matters legally is not the quantity of similarity but its nature. The concept relevant under UK copyright law is whether the defendant has reproduced a substantial part of the claimant’s work. Substantiality is assessed qualitatively, not quantitatively. A single copied function that represents the creative heart of the software may be more significant than fifty percent surface-level similarity in boilerplate code.
For this reason, the analytical framework I find most useful is a version of abstraction-filtration-comparison. First, identify the elements of the claimant’s code that represent genuine intellectual effort and creative choice. Filter out anything that is dictated by the platform, the framework, the programming language, or standard practice. Then compare what remains. If what remains appears in the defendant’s code, and there is no plausible independent source, you have something worth saying.
However, this methodology relies upon access to source code on both sides. Where the defendant’s product exists only as compiled binaries, minified JavaScript, or a deployed service, the analysis becomes more complex. Binary analysis and dynamic runtime tracing can recover some structural information, but the findings carry greater uncertainty and should be framed accordingly. This is a material limitation worth raising with instructing solicitors at the outset.
Distinguishing Copying from Coincidence
This is the hardest part of the analysis, and the part where an expert’s judgement matters most. Automated tools can find similarity. But a human examiner can assess what that similarity means.
The most common source of innocent similarity is shared dependencies. Two teams working independently in the same technology stack may write code that looks alike, because they are using the same libraries and following the same framework conventions. Stack Overflow answers create another category of convergence: a particularly elegant solution to a common problem will be copied, legitimately, into thousands of codebases with no connection to each other. Standard algorithms such as sorting, searching and parsing have canonical implementations that every developer learns.
The probative similarities are the ones that cannot be explained this way. Unusual naming conventions that appear in both codebases. Idiosyncratic architectural decisions that are not dictated by the problem domain. Comments that appear in both codebases, sometimes paraphrased. Dead code (functions that are defined but never called) appearing in both. And most telling of all: bugs that appear in both. If the claimant’s code contains a subtle error, and the defendant’s code contains the same subtle error, that is very difficult to explain by coincidence.
In my experience, the most compelling evidence is often not what is present but what is absent. A codebase that was genuinely developed will contain the marks of its development: the experiments, the dead ends, the things that were tried and abandoned. A codebase that was copied will be clean in a way that real development never is. That absence is itself a finding worth articulating.
When the Theft Happened Before You Arrived
The methodology above assumes you have both codebases in front of you, and the question is whether one was copied from the other. That is not always where a case begins. Not all source code disputes are purely about similarity between two products; some emerge from a wider assessment of a failed software project. Sometimes, the more immediate question is how the defendant obtained the claimant’s code in the first place, and the examination must follow that thread before it can address the comparison.
Where an employee is alleged to have taken code before leaving for a competitor, the evidential picture extends well beyond the code itself. Access logs from the source control system may show unusual activity in the weeks before departure: bulk downloads, repository cloning, access to repositories outside the employee’s normal area of work. Cloud storage sync artefacts may show files transferred to personal accounts. Email records may show code sent to personal addresses. USB transfer logs, where DLP (data loss prevention) tooling was in place, may capture the exfiltration directly.
This territory intersects with digital forensics in ways that go beyond code comparison expertise. Where exfiltration evidence is central to the case, rather than incidental to it, I would recommend considering whether a specialist digital forensics practitioner should be instructed alongside a source code expert. The two disciplines complement each other: the forensics expert establishes that code was taken; the source code expert establishes that the taken code appears in the defendant’s product.
What I can usefully do in this area is advise on what to ask for. Solicitors preparing a case involving alleged exfiltration should consider requesting: full git access logs for the relevant period, cloud storage sync logs for the employee’s work devices, email server logs, DLP reports if available, and a forensic image of the employee’s work machine if it has been preserved. The earlier these requests are made, ideally as part of an early technical assessment at the pre-action stage, the more likely the evidence will still exist.
Writing Findings That Survive Cross-Examination
An expert report in source code proceedings is addressed to the court, not to the instructing party. That distinction matters, and it should be felt in every paragraph of the report. Your duty is to assist the court, which means presenting your findings honestly, including those that are inconvenient for the party that instructed you.
The temptation in a similarity analysis is to lead with the headline percentage and let the reader draw their own conclusions. Resist it. A bare percentage, presented without the filtration methodology, the base rate of innocent similarity in this technology stack, and the specific examples that are actually probative, is not useful to a court and will not survive cross-examination. Present your methodology first, so the court can assess whether it is sound. Then present your findings, distinguishing clearly between what the evidence shows and what you infer from it.
Acknowledge alternative explanations before dismissing them. If a section of similar code could plausibly be explained by a shared dependency, say so, explain why you nevertheless consider copying more likely, and let the court weigh it. An expert who engages seriously with the other side’s arguments is more credible than one who appears not to have considered them.
Prepare to be cross-examined on your tools as well as your conclusions. If you used MOSS, know its limitations. If you normalised the code before running it, be ready to explain why and to demonstrate that the normalisation was even-handed. I have found it useful to keep a detailed working log throughout the examination: not just what I found, but how I looked. That log is not part of the report, but it is invaluable preparation for a difficult cross-examination.
What to Ask in a Letter of Instruction
A Letter of Instruction to a source-code expert lives or dies by its specificity. Vague questions produce vague reports; vague reports do not survive cross-examination, and they do not help the court. Practice Direction 35 requires written instructions to the expert, and the questions in those instructions are what scope the report.
The strongest Letters of Instruction ask the expert to apply a named methodology to a specified set of artefacts, and to state the result objectively. They do not ask the expert to reach a conclusion that the solicitor would prefer. They do not ask the expert to comment on liability, quantum, or fault. Those are the court’s questions, not the expert’s.
Some example framings, drawn from the kinds of cases this methodology is used on:
- Substantial similarity (copyright): “Examine repositories [A] and [B] as preserved at the commit hashes provided. Apply the abstraction-filtration-comparison framework to identify code regions in [B] that, after excluding framework, dependency, and platform-conventional content, reproduce code in [A]. For each region identified, state the nature of the similarity and whether it is consistent with independent creation.”
- Patent infringement: “Trace the implementation of [feature X] through codebase [B]. Map the implementation against the elements of [patent claim Y]. For each element, state whether it is present in the codebase, absent, or implemented in a materially different way, and cite the code that supports each finding.”
- Trade-secret misappropriation or exfiltration: “Examine the development history of repository [B] between [date range]. Identify any commits or files whose introduction is inconsistent with normal incremental development, and characterise the pattern. State whether the pattern is consistent with external introduction of code from outside the repository’s authoring team.”
- Code quality and breach of contract: “Assess whether the source code delivered under [contract reference] meets the contractually specified standards [X, Y, Z]. For each identified departure, explain its materiality with respect to the contract’s quality criteria, citing the code or documentation that evidences the departure.”
- Open-source licence compliance: “Identify the open-source components present in codebase [A], their licences, and any obligations triggered by [the codebase’s distribution / its incorporation into a commercial product / the events at issue]. Where any obligation appears unsatisfied, explain the basis of that conclusion.”
Each of these specifies a methodology, an artefact set, and a form of answer. None of them asks the expert to take sides. None of them invites the expert to opine on whether the other party should be held liable.
If the solicitor is unsure how to frame a question of this kind, the expert can usefully be involved at the drafting stage. The Civil Procedure Rules permit that, and my guide to instructing software experts produces better instructions than guessing alone. The cost of revising a Letter of Instruction is much lower than the cost of receiving a report that did not answer the question the case actually turned on.