Patent and ITC proceedings: what a repository proves, and what it only appears to

What is actually in dispute

Two questions sit underneath a software patent case and neither is about the claims: whether the code in front of the expert is the code that matters, and whether the history attached to it means what everyone is assuming it means.

The first is a completeness and custody problem. Source is produced from a repository, or from an export, or from a build machine, by an engineer following instructions from counsel; branches are omitted, submodules do not come across, generated files arrive without their generators, and third-party dependencies are referenced rather than included. None of that is necessarily improper, and all of it changes what the production can support. An examiner establishes what is there, what the tree references that is not there, and whether the structure is consistent with the way the producing party says it builds software.

The second is a dating problem, and it is the one that produces excluded opinions. Version control looks like a ledger. It is not one. It is a content-addressed store whose date fields are supplied by whoever made the commit, and treating it as an authenticated timeline is the software equivalent of treating a file’s creation date as the moment a document was written.

Priority, conception and the temptation to date code

Invalidity and priority arguments create constant pressure to say when something existed. A prior-use or on-sale theory wants a date; a derivation or inventorship dispute wants to know who wrote what and when; a trade secret claim travelling alongside the patent claim wants to know when code appeared in a competitor’s product. Every one of those questions is legitimate, and every one of them is answered badly by reading the timestamp off a commit.

What answers them better is corroboration from systems the developer did not control. Build server records, issue tracker entries referencing a commit, release archives with their own publication dates, package registry publication records, cryptographically signed tags, and a copy of the repository held by a third party at a known date. Where those exist, a defensible interval can be stated. Where they do not, the honest finding is that the repository records a sequence and not a calendar.

Which records bear on it

The evidentiary centre of gravity moves off the operating system in this matter type and onto the development toolchain, which keeps records of a different character: rich, structured, and almost entirely under the control of the party that produced them.

The repository

A code repository supplies commit history— the sequence of changes, their parentage, their messages, and the two date fields each carries. The graph itself is cryptographically self-consistent: each commit’s identifier covers its content and its ancestry, so the ordering of a chain cannot be quietly altered without rewriting every descendant. That property is genuinely useful, and it says nothing about whether the dates are true. Blame maps lines to the commit that last touched them, which is an index rather than an attribution.

Builds and binaries

Compiled output carries its own evidence: symbol tables, string constants, embedded version resources, compiler and linker identifiers, debug records where they survive, and the structural layout the toolchain produced. Comparing those against what the produced tree compiles to is how correspondence between source and product is tested. Continuous integration systems, artifact repositories and package registries hold publication records with their own timestamps, and those are among the few dates in this matter type that a developer did not write by hand.

Custody of the production itself

How the code arrived matters as much as what it says. A production hashed at export, with SHA-256 values recorded per file and a chain of custody for the media, can be shown to be unchanged between review sessions and between experts. A production copied onto a review machine by hand, with no manifest, cannot — and in a matter where both sides will examine the same tree months apart, that becomes an argument nobody needs.

Where the same repository is also the subject of a misappropriation claim, the device-side question — how the code left, and by what route — is the trade secret examination, and the two are normally run together because neither answers the other’s question. The comparison methodology itself is set out on the source code review page.

The expert’s role and the deliverable

1. 01Read the protective order before anything else. The protective order decides who may look, on what machine, with what tools, what may be printed, and whether a source code tier above attorneys’ eyes only applies. Expert disclosure and objection periods run on their own clock, and an expert who is not yet approved cannot be in the room.
2. 02Specify the review environment in advance. A stand-alone, air-gapped machine with the searching, indexing and comparison tools already installed, adequate memory for the codebase, and a working printer with a page log. Every one of those is negotiated before the review, because none can be fixed on the day.
3. 03Establish the production’s shape first. Directory structure, build configuration, what the tree references that it does not contain, what is generated, and what is third-party. That inventory is the finding that everything else in the report depends on, and it is often the finding that changes the case.
4. 04Test dating claims against outside sources. Before any opinion rests on a commit date, check whether the history shows rewriting, whether an import boundary exists, and whether a build system, registry or signed tag corroborates the interval. Where nothing does, say so.
5. 05Compare source to shipped product where the question requires it. Correspondence established through symbols, strings, structure and version resources, with the non-determinism that prevents a byte-identical rebuild stated rather than glossed.
6. 06Report, deposition, and hearing. A Rule 26(a)(2)(B) report in district court, or an expert report on the administrative law judge’s schedule at the Commission — with exhibits prepared so that material designated at the source code tier is handled correctly at every step, including at the hearing itself.

Where Rule 702 pressure falls here

Under Rule 702 as amended on December 1, 2023, the proponent must show it is more likely than not that the opinion reflects a reliable application of the method to the facts of the case. At the Commission the administrative law judge looks to the federal rules of evidence rather than being bound by them in every particular, but the reliability arguments themselves travel across both forums largely unchanged.

• Commit metadata offered as a date. An opinion that a feature existed by a certain date, resting on a timestamp the developer’s own client wrote, is the most exposed sentence in this matter type — and the exposure is complete, because the mechanism by which the field can be set is trivially demonstrable.
• Similarity without filtration. A comparison that reports raw matching percentages, without first excluding third-party code, generated output, published interfaces and standard idiom, measures the language rather than the copying. Opposing experts rerun exactly that filtration.
• Tool output presented as the analysis. A similarity detector produces a ranked list. The opinion is the reasoning that survives after each hit has been examined, and a report showing the list without that work invites the argument that no method was applied to the facts of the case.
• Opinions on the ultimate technical issue. Infringement, validity, priority and the domestic industry requirement are not forensic findings. An examiner who reaches them has both a Rule 702 problem and a scope problem in front of a tribunal that will notice.
• Protective order handling in the report itself. Quoting designated code into an exhibit that is not properly marked, or working from notes that left the review room, is not a reliability defect but it can end an expert’s usefulness in the matter faster than any Rule 702 motion.

The Daubert Docket collects rulings on digital forensic and software testimony, and the Daubert exposure check walks an opinion against the same failure modes before it is served.

Questions counsel ask

Related reading

• Source code review

  Comparison methodology, filtration, the protective-order review environment, and what a similarity finding is worth once the noise is removed.

• Trade secret litigation

  The device side of the same dispute — how code left a machine, by what route, and the gap between access and exfiltration.

• Version control terms in the glossary

  Commit history, blame, repositories and protective-order tiers, defined the way they are used in evidence rather than in engineering.

• Daubert challenges to digital evidence

  Rule 702 as amended in December 2023, the reliability factors, and the ways technical opinions actually get excluded.