RESOURCE 05 / PROTECTIVE ORDER

Source Code Inspection Protocol: Model Terms

Nine model terms for the source code provision of a protective order, each printed beside the failure it prevents and the gap it still leaves. Two of the nine are the ones routinely omitted, and they are the two that decide what the examination is able to conclude.

TERMS: 9, annotated in pairs
CONTEXT: Protective order, source code tier
STATUS: Generic · not court-approved
FORMAT: HTML · print · Save as PDF
GATING: None · no email required
ADVICE: Not legal advice

IN SHORT

A source code inspection protocol is the provision of a protective order that governs how the other side’s code is reviewed: a standalone computer, a secured room, designated outside experts, and limited, logged printing. Two terms decide what the examination can actually conclude — which analysis tools the reviewer may install, and whether the production includes repository history or only a snapshot — and both are routinely left out.

This is an educational template, not legal advice

The language on this page is generic drafting, published to be read and understood. No court has approved it, it is not this firm’s filed language in any matter, and it has not been accepted or rejected in any specific proceeding. Nothing here is tailored to your case, your forum, or the order that governs your matter, and using it unadapted is the error the page exists to help you avoid.

Many districts publish a model protective order with its own source code provision, and where one applies it is the starting point rather than this page. The terms below are generic drafting written to be understood; the bracketed values are the negotiation, and the right values depend on the codebase, the claim, the scale of the production and the court.

Reading it creates no attorney–client relationship and no expert-engagement relationship. Check the rules, standing orders, local practice and case law of your own forum before relying on any of it.

Why the protocol is the whole engagement

A code examination can only reach conclusions the protocol permits it to reach. By the time a reviewer is in the room, the scope of the opinion has already been set.

Source code is produced under the most restrictive designation a protective order provides, and the reasons are not procedural theatre: the material is frequently the producing party’s core asset, and the receiving party is frequently a competitor. The structure that makes the litigation possible at all is that no party employee sees the code — review is performed by designated outside experts, and what reaches the client is an opinion rather than the material.

What follows from that structure is easy to underestimate. The reviewer works on a machine somebody else configured, in a room somebody else controls, with whatever software the order permits, on whatever subset of the repository was produced. Each of those is a term, and each term is a boundary on the analysis. A protocol that omits the tooling term produces a reviewer who can read code and not index it; a protocol that omits the history term produces a comparison with no timeline under it.

The examination those terms bound is described in detail on the source code review service page — including the abstraction, filtration and comparison sequence that separates the resemblance which is evidence from the resemblance that is inevitable, and why a raw percentage of matching lines is not an opinion a court can use.

The terms

The designation tier

MODEL TERM — GENERIC

Source code may be designated “HIGHLY CONFIDENTIAL — SOURCE CODE.” Material so designated may be disclosed only to outside counsel of record, to supporting personnel of outside counsel, and to experts and consultants designated under this Order, and may not be disclosed to any party, party employee, officer, or director.

THE FAILURE IT PREVENTS

Keeps the producing party’s code away from the receiving party itself, which is the condition on which code is produced at all. Without a tier above ordinary confidentiality, a competitor’s engineers are inside the designation.

WHERE IT STILL LEAVES A GAP

Says nothing about how the material is handled once designated — that is terms 2 through 9. A tier without a mechanism is a label, and the disputes in code cases are almost entirely about mechanics rather than about who is inside the ring.

The standalone review computer

MODEL TERM — GENERIC

Source code shall be made available on a standalone computer not connected to any network, with wireless and Bluetooth interfaces disabled and external data ports disabled or physically blocked. The producing party shall load the produced material on the review computer and shall maintain it in the same condition for the duration of the review period.

THE FAILURE IT PREVENTS

Removes the route by which designated material could leave the room, and fixes the state of the production so the reviewer is not working against a set that changes between sessions.

WHERE IT STILL LEAVES A GAP

A machine with everything disabled is also a machine with no analysis capability unless term 7 supplies it. It does not address performance either: a codebase of any size on underpowered hardware with no indexing is a functional limit on the examination rather than a security measure.

NOTESpecify the hardware where the codebase is large. Indexing a substantial repository is bounded by memory and disk, and “a computer” is not a specification.

Location, scheduling, and escorted access

MODEL TERM — GENERIC

Review shall take place in a secured room at the offices of [PRODUCING PARTY’S OUTSIDE COUNSEL] during normal business hours, on [N] business days’ notice. The producing party shall make the room available for [N] consecutive business days per request and shall not monitor the content of the reviewer’s work or the materials the reviewer accesses.

THE FAILURE IT PREVENTS

Gives the producing party physical control of the material, and gives the reviewer a schedule that can be planned against. The no-monitoring sentence protects the reviewer’s work product, which is otherwise visible to the party whose code is being examined.

WHERE IT STILL LEAVES A GAP

Notice periods and consecutive-day blocks are where a schedule is quietly constrained. A protocol allowing review only in single days, with long notice, in a distant city, complies with every word of this term and can still make a real examination impracticable before an expert deadline.

Recording devices and personal equipment

MODEL TERM — GENERIC

No cameras, mobile telephones, recording devices, scanners, or portable storage media may be brought into the review room. The reviewer may bring notes and non-networked writing materials, and may take handwritten or typed notes provided that no portion of the source code is transcribed verbatim except as permitted under the printing provisions below.

THE FAILURE IT PREVENTS

Closes the obvious route around the printing limits, which otherwise do no work at all: a page limit means nothing beside a phone camera.

WHERE IT STILL LEAVES A GAP

“Verbatim” is where this term is argued about. A reviewer has to record identifiers, file paths, line numbers and short fragments to work at all, and a protocol that forbids all transcription forbids note-taking. Define the boundary rather than leaving it to be discovered.

Designated reviewers and the objection period

MODEL TERM — GENERIC

Before accessing source code, each expert or consultant shall be identified to the producing party in writing, with a curriculum vitae, a list of the party’s competitors for whom the person has consulted within the previous [N] years, and a signed undertaking to this Order. The producing party may object within [N] days, stating the grounds, failing which the designation stands.

THE FAILURE IT PREVENTS

Gives the producing party a genuine opportunity to object to a reviewer with a competitive relationship, before rather than after the code has been seen. Making an unstated objection ineffective prevents the period being used as a delay.

WHERE IT STILL LEAVES A GAP

It is a timing trap for the receiving party. Designating a reviewer late means the objection window runs against an expert deadline, and a sustained objection at that point may mean starting the examination over with somebody new.

NOTEDesignate at the start of the engagement, not when the review is ready to begin. This is the single most common self-inflicted scheduling problem in a code matter.

Printing: volume, stamping, and the log

MODEL TERM — GENERIC

The reviewer may request printing of source code only to the extent reasonably necessary to prepare court filings, expert reports, and other work product, and not for general review. Printed material shall be provided by the producing party, stamped with the source code designation and a unique identifier on each page, and recorded in a log identifying the file, line range, and date. Requests exceeding [N] pages continuously or [N] pages in aggregate are subject to objection.

THE FAILURE IT PREVENTS

Stops a review becoming a production by printout, and creates a record of exactly which material left the room — which is also what makes a later report’s citations checkable against the production.

WHERE IT STILL LEAVES A GAP

Three mechanics are usually unresolved and all three bite: whether the cap counts pages or continuous blocks, whether exhibits to an expert report count against it, and what happens when the reviewer needs more. The answer arrives mid-examination as a motion unless it arrives here as a sentence.

Tools the reviewer may install

MODEL TERM — GENERIC

The review computer shall be provided with, or the reviewer permitted to install, software reasonably necessary for the examination, including a text editor, a cross-reference and code-indexing tool, a file and directory comparison tool, a version control client, and a compilation or build environment for the languages produced. The reviewer shall identify requested software in advance; the producing party may object within [N] days on stated grounds.

THE FAILURE IT PREVENTS

This is the first of the two terms that decide what the examination can conclude. Indexing, comparison and build capability are the difference between analysing a codebase and reading it in a text window — and non-literal comparison of structure, sequence and organisation is not feasible by eye.

WHERE IT STILL LEAVES A GAP

Even granted, it does not resolve who installs and licenses the software, whether a tool requiring network activation can be used at all on an air-gapped machine, or whether the reviewer may run a tool that writes output the producing party will then argue is a copy of designated material.

NOTERoutinely omitted, and then fought over in the room. Name the categories the examination actually requires.

Whether the production includes repository history

MODEL TERM — GENERIC

Production of source code shall include the version control repository for each produced codebase, including branch and tag references and the repository objects underlying the working tree, for the period [RANGE]. Where the producing party contends that history is not available or not reasonably accessible, it shall state the basis and identify what is produced in its place.

THE FAILURE IT PREVENTS

The second term that decides the outcome. History is where the timing questions live: commit sequence, branch structure, a large import with no development behind it, and evidence of rebasing, squashing or force-pushing. A snapshot supports textual comparison and can say nothing about when anything was written.

WHERE IT STILL LEAVES A GAP

Repository history is self-reported. Author and committer fields and commit timestamps are all set by the client and can say anything, so history alone is not self-proving — the corroboration is server-side push and audit logs, code review and ticket timestamps, build records, and package registry publication times, which are a separate discovery request against a different system.

NOTEAsk for the repository rather than an export, and ask early. It is much harder to obtain once a production has been negotiated around a snapshot.

Code in reports, citation, and sealing

MODEL TERM — GENERIC

Source code may be included in expert reports, declarations, and filings only to the extent reasonably necessary, shall be cited by file path and line range together with the identifier of the corresponding printed page, and shall carry the source code designation. Any filing containing designated material shall be made under seal in accordance with [LOCAL RULE], and served in a manner that maintains the designation.

THE FAILURE IT PREVENTS

Lets an opinion be stated and tested without the code becoming public, and fixes a citation format precise enough that an opposing expert can open the same lines. That format is also what keeps a report internally consistent across hundreds of pages and several rounds of supplementation.

WHERE IT STILL LEAVES A GAP

It does not resolve the practical mechanics of a sealed exhibit set — how a redacted public version is prepared, how exhibits are served on a party who may not see them, or what happens to designated material at a deposition or a hearing. Those are usually settled separately and late.

The order to settle them in

Two of these are genuinely time-critical and the rest can be negotiated in parallel. Designating the reviewer starts an objection clock, and asking for repository history has to happen before the production is negotiated around a snapshot. Everything else is easier to fix than either of those.

Read the existing tier. Where an order is in place its source code provision governs. Identify what it says about the computer, the location, printing, and designation before anything is produced.
Designate the reviewer. Early, so the objection window runs at the start of the engagement rather than against an expert deadline.
Ask for history. Request the repository rather than an export wherever timing is at issue, and say what it is needed for.
Settle the tooling. Name the categories of software the examination requires. A reviewer requesting an indexer at the first session is negotiating from the worst possible position.
Settle printing, then the sealed filing. Pages or blocks, whether report exhibits count, the process for asking for more — then citation format, the extent of quotation, and how a sealed exhibit set is prepared and served.

Remote review

Remote review is the term where practice has moved fastest and orders differ most. Where it is permitted it is normally hedged: a controlled virtual environment supplied by the producing party, session logging, prohibitions on local storage and screen capture, and restrictions on where the reviewer may physically be while connected. Where an existing order does not address it at all, a request arrives as a modification rather than a term, which is a materially harder ask.

Latency is a substantive constraint, not a convenience. Indexing and comparison across a large codebase over a remote session can be slow enough to change what the examination covers in the time available.
Session monitoring reaches work product. A protocol that logs which files the reviewer opened shows the producing party the shape of the other side’s theory.
The reviewer’s location may be a term. Orders increasingly specify the jurisdiction from which a remote session may be conducted, which matters where an expert or a supporting analyst is outside the country.

Questions counsel ask

What does a source code inspection protocol usually require?

Terms vary by order, but the recurring elements are a standalone review computer with networking, wireless and external ports disabled; a secure room at outside counsel's or the producing party's premises with scheduled and escorted access; no cameras, phones or recording devices; printing limited in volume and to what is reasonably necessary, with every printed page stamped and logged; designation of the reviewers in advance subject to an objection period; and a record of who accessed the machine and when.

Which protocol terms are most often left out?

Two, and both decide what the examination can conclude. The first is which analysis tools the reviewer may install on the standalone machine — a review computer with no cross-reference indexer, no diff tool and no build environment is a machine for reading code, not analysing it. The second is whether the production includes repository history or only a snapshot, because a printed or exported snapshot supports textual comparison and says nothing about when anything was written.

Why does it matter whether the production includes version control history?

Because history is where the timing questions live. A snapshot supports comparison of text as it stands; the repository — including the objects behind the working tree — supports examination of commit sequence, branch structure, and evidence of rewritten or force-pushed history. History is also self-reported: author and committer fields and commit timestamps are all client-supplied, so the analysis that matters is the corroboration against server-side push logs, review and ticket records, and build history.

Can a party's own engineers review the other side's code?

Not under a source code tier, which is the point of having one. Production is designated to a restricted category that no party employee may access, and review is performed by designated outside experts identified to the producing party in advance. What reaches the client is the expert's opinion, filed under seal where the order requires, rather than the code. That structure is what lets a code dispute be litigated at all without one side handing its product to a competitor.

Is remote source code review permitted?

It depends entirely on the order, and it is one of the terms where practice has moved fastest. Where remote review is allowed it is normally hedged with a controlled virtual environment, session recording or monitoring, a prohibition on local storage and screen capture, and restrictions on the reviewer's physical location. Where it is not addressed at all, a reviewer's request for it arrives as a modification to an existing order rather than as a term of a new one.

What these model terms do not do

They are not drafted for your matter, and they are not legal advice. Every bracketed value is a negotiation, and the right value depends on the codebase, the claim, the scale of the production, and the court.
No term here has been approved by any court. This is generic drafting. It is not this firm’s filed language in any matter and is not presented as having been accepted or rejected in any specific proceeding.
A model order in your district takes precedence. Many districts publish one with a source code provision, and where one applies these terms are at most a checklist against it.
A good protocol does not make an opinion reliable, and it cannot tell you what is proportionate. Filtration of unprotectable and third-party material, and corroboration of self-reported history, are the substance of the analysis; the protocol only decides whether they are possible. Whether history, a build environment, or a given volume of printing is reasonably necessary is an argument about a particular matter.

BEFORE THE ORDER IS ENTERED

The terms above are worth reading against a draft order rather than against a signed one, and a reviewer designated early is a reviewer whose objection window has already closed by the time the examination starts. Conflicts come first.

START A CONFLICTS CHECK→

DIRECT → info@lawandforensics.com·855-529-2466

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.

Other resources

RESOURCE 01 / PRESERVATION
Evidence Preservation Letter
A generic preservation letter, clause by clause, with each clause paired against what it actually preserves and what it leaves exposed. The annotation is the product.
RESOURCE 02 / DEPOSITION
Forensic Expert Deposition Outline
A topic-organised question outline for the deposition of an opposing digital forensics expert — qualifications, scope, tool validation, reproducibility, timestamps, custody, and what they were never asked to do.
RESOURCE 03 / DISCLOSURE
Rule 26 Report Checklist
The six statutory elements of a retained expert's report quoted verbatim, then — counted separately, because the rule imposes six and not sixteen — the practice points that decide whether the six are met.
RESOURCE 04 / CUSTODY
Chain of Custody Form
A blank, printable custody form, plus a field guide explaining why each field exists and what a gap in it costs when the custody record is put to a witness.
RESOURCE 06 / DILIGENCE
Expert CV Red Flags
How to read a digital forensic expert's CV and testimony list for what they do not say — roles in place of examinations, curated publication lists, and what a missing four-year list means.

Attorney advertising / expert services. This page publishes an educational template and general information about forensic practice and the procedural rules that govern expert evidence. It is not legal advice, it does not create an attorney–client or expert-engagement relationship, 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.