Source Code Review Expert Witness Services
Comparative examination of source code where the dispute is what was copied, what was built independently, and what was carried out the door — conducted under the protective order's source code tier and cited to file and line so that every assertion can be checked against the production.
- DISPUTES
- Trade secret · Copyright · Patent
- METHOD
- Abstraction · Filtration · Comparison
- HISTORY
- Version control · CI · Registry
- SETTING
- Secured review room, AEO tier
- CITATION
- path/file.ext:line + Bates
- DELIVERABLE
- FRCP 26(a)(2)(B) report
A source code review compares two bodies of code, or examines one against a claim, to establish whether material was copied, when, and by what route. It runs inside the protective order’s source code tier, filters out the similarities that prove nothing, and cites every conclusion to a specific file and line an opposing expert can open.
What a source code examination covers
Two codebases written to do the same job will always resemble each other. The work is separating the resemblance that is evidence from the resemblance that is inevitable.
Comparative analysis
Literal comparison identifies identical or near-identical text between codebases, but the probative findings are rarely the functional lines. They are the artifacts that have no reason to travel: identical comments, the same misspellings, the same dead code left in place, the same unusual constants and magic numbers, identical error strings, matching formatting idiosyncrasies, and the same defect reproduced in both. Non-literal comparison addresses structure, sequence, and organisation — module decomposition, data models, call graphs, and control flow — which is where a re-implementation intended to disguise its origin shows itself.
Both are run through abstraction, filtration, and comparison, so that elements dictated by efficiency, imposed by external factors such as hardware, protocols, and interoperability, or drawn from open-source and public-domain material are separated out before anything is called similar. An analysis that reports a raw percentage of matching lines without that step is not an opinion a court can use.
Version control and build history
- Commit history and authorship — author and committer identities, message content, and the shape of the history, read with the knowledge that every one of those fields is client-supplied and can be set arbitrarily.
- Rewritten and concealed history — reflog entries, unreachable objects, orphaned branches, evidence of rebasing, squashing, or force-pushing, and imports that introduce a large body of code in a single commit with no development history behind it.
- Server-side corroboration— push and audit logs from the hosting platform, code review and ticket timestamps, continuous-integration build records, and package registry publication times, which are outside the committer’s control and therefore carry weight the local history does not.
- Build outputs and dependency manifests — what is actually compiled or linked into the shipped artifact, as distinct from what happens to sit in the repository, and the third-party components carried along with it.
- Correlation with device and account evidence — repository clones, archives, and exports appearing in endpoint artifacts or cloud audit records, which is how a code-similarity finding becomes a route of transmission.
Where this comes up
| DISPUTE | THE QUESTION THE CODE HAS TO ANSWER |
|---|---|
| Trade secret misappropriation | Is the asserted secret actually present in the defendant's code, and how did it get there — and were reasonable measures in place to protect it? |
| Copyright infringement | After filtration of unprotectable elements, is what remains substantially similar, and was there access? |
| Patent infringement or invalidity | Does the accused code path practise each element of the asserted claim, mapped element by element to specific files and lines? |
| Open-source compliance | Which third-party components are in the shipped product, under which licences, and what obligations attach? |
| Contract and development disputes | Was the deliverable built as specified, what was actually delivered, and what does the history show about when? |
| Defect and failure analysis | Which code path produced the behaviour complained of, and what does the record show about who knew? |
Working inside the protective order
Source code is produced under the most restrictive tier a protective order provides, and many districts use a model order with a dedicated source code provision. Conditions typically include a standalone review computer with networking and external ports disabled, a secured room with scheduled and escorted access, a prohibition on recording devices, printing limited in volume with every page Bates-stamped and logged, and disclosure of designated reviewers to the producing party in advance, subject to objection.
Two terms are worth negotiating before the first review session rather than after: which analysis tools the reviewer may install on the standalone machine, and whether the production includes repository history or only a snapshot. Both are routinely omitted, and both determine what the examination can conclude.
The terms of an inspection protocol are frequently the first thing fought over. In In re: Facebook, Inc. Consumer Privacy User Profile Litigation, No. 3:18-md-02843 (N.D. Cal., Chhabria, J.), Law & Forensics’ founder Daniel B. Garrie, serving as court-appointed eDiscovery Special Master, set the source code inspection protocol in that MDL and resolved discovery motions brought by both sides.
How code is cited
Every assertion in the report points at a path, a file, and a line range, paired with the production Bates range the material was produced under. That format is what allows opposing counsel to open the same lines, and it is what keeps a report internally consistent across hundreds of pages and several rounds of supplementation. Quoted code appears in the report only to the extent necessary, and the report is filed under seal where the order requires.
How the engagement runs
- Conflicts and scope. Parties run for conflicts. The scoping call establishes the claim, the codebases in play, the languages and scale involved, the deadline, and whether the role is testifying or consulting.
- Protective order review. The source code tier is read before anything is produced, gaps are identified — tooling, history, printing limits, remote access — and the reviewer is designated so the objection period runs early rather than against the deadline.
- Preservation. Repositories, hosting platform audit logs, CI records, and the devices of relevant developers are preserved. Hosting platform logs and CI records have retention limits of their own.
- Baseline and filtration. Third-party, open-source, and generated code is identified and separated first, so that the comparison operates on the material actually in dispute.
- Comparison and history analysis. Literal and non-literal comparison, then version control and build history, with each finding recorded against its file, line range, and Bates cite as it is made.
- Report and testimony. Written opinion with comparison exhibits and, where the claim requires it, an element-by-element chart. Then deposition and trial.
What you receive
For a retained testifying expert in federal court the deliverable is a report meeting Fed. R. Civ. P. 26(a)(2)(B): a complete statement of the opinions and their basis, the facts or data considered, the exhibits, qualifications with a ten-year publication list, a four-year testimony list, and a statement of compensation. In a code matter the exhibits are usually side-by-side comparison charts, a filtration table showing what was excluded from the comparison and why, a history timeline, and — in patent matters — a claim chart mapping each element to specific code.
On a motion, the same analysis is delivered as a declaration under 28 U.S.C. § 1746, which is the common posture on a preliminary injunction in a trade secret case. A rebuttal report answering another expert’s comparison is due within 30 days of that disclosure unless the court orders otherwise. See the expert witness testimony page for disclosure timing and Rule 702 practice.
Questions counsel ask
How can code be compared without our engineers seeing the other side's code?
What does a source code inspection protocol usually require?
Can you establish when code was copied, and by whom?
Is similarity between two codebases enough to show copying?
Do you work from a printed production or live access to the repository?
Can you assess open-source license exposure in the same review?
Related reading
- Computer forensics
The device side of a code-theft claim — what was cloned, archived, or copied to removable media, and when.
- How to hire and vet a forensic expert
Testifying versus consulting, conflicts, timing, and what to demand before retention — all of which bite harder under a source code protective order.
- Daubert challenges to digital evidence
Rule 702 after December 2023, and why a similarity percentage without filtration is the classic exclusion candidate.
- What a digital forensic expert witness actually does
The role across the life of a matter, from defensible collection through testimony.
Review terms, tooling, and whether history is produced are decided before the first session and are hard to reopen afterwards. Send the matter, the venue, the key dates, and the protective order if one has been entered — a conflicts check and a scoping call follow.
A conflicts check and scoping call follow, normally within one business day. Please do not send privileged or case-sensitive material until conflicts have cleared.
Attorney advertising / expert services. This page describes forensic practice and the procedural rules that govern expert evidence in general terms. It is not legal advice, and it is not a substitute for checking the rules, standing orders, and case law of your own forum. Prior results do not guarantee a similar outcome.