Source Escrow: Separate Deposit, Release Rights and Buildability

What does source-code escrow actually protect?

An escrow arrangement can hold specified materials for release under agreed conditions. Its value depends on those conditions and the buyer's subsequent permissions, not simply on having an independent custodian. WIPO's licensing checklist raises software escrow in the context of supplier bankruptcy. It does not establish a universal insolvency remedy, guarantee enforceability or require every research subscription to include source delivery. Qualified reviewers must assess the actual arrangement.

Begin with the continuity question. Does the buyer need historical output access, a limited transition service or the ability to operate software independently? An output archive may answer the first question while source escrow addresses a different dependency. If the proposed benefit requires ongoing proprietary data or specialist judgment that the deposit excludes, the buyer should not describe the arrangement as complete operational continuity protection.

Define a deposit that matches the accepted version

List source revision, configuration, parameters, build instructions, dependency versions, schemas and representative synthetic fixtures. Identify separately any data, hosted component or commercial library that cannot be deposited. A repository snapshot without the parameter file used by the accepted model may recreate a program but not its delivered behavior. Tie each deposit to a named release so the receiver knows what baseline it is supposed to reproduce.

Ask how updates are deposited and how omissions are detected. A receipt for an old version can coexist with a substantially changed live service. Specify which evidence connects the current accepted version to the most recent verified deposit, and who checks that connection. Do not place live credentials into a deposit merely to make a demonstration succeed; continuity access needs an authorized transfer and replacement process.

Reconcile an illustrative build rehearsal

A synthetic rehearsal manifest requires twelve components. Ten arrive with matching hashes, one is present but has the wrong version, and one is absent. Receipt completeness is eleven of twelve, or 91.67% rounded. Version-matched completeness is ten of twelve, or 83.33%. Neither percentage is an acceptable universal threshold: a single missing parameter file could prevent the entire package from producing its intended outputs.

The receiving engineer records the missing item and the version mismatch before running a frozen fixture. If a replacement package later reproduces the fixture, the receipt records that narrow result and the environment used. It does not imply investment validation or prove that production operation is authorized. Component inventory, successful compilation and agreement on expected output are successive observations rather than interchangeable meanings of verified escrow.

Separate release procedure from post-release use

Have the agreement review identify triggering events, notice requirements, challenge periods and the party that can authorize release. Supplier distress may create uncertainty long before a defined release condition is satisfied. The buyer needs to know what it may do during that interval. Do not assume that the custodian decides commercial disputes or that an operational incident automatically satisfies a contractual insolvency condition.

Next ask what use is allowed after release: inspection, maintenance, execution, modification, third-party assistance or a limited transition. Identify confidentiality and onward-disclosure restrictions that continue. Releasing files and granting an unrestricted software licence are different acts. Any replacement operator must fit the reviewed permissions, and third-party library or data rights may still need their own arrangements even after the main software package becomes available.

Use software evidence without overstating certification

NIST's Secure Software Development Framework includes preserving release artifacts and provenance. Those practices inform package-integrity questions; they do not certify escrow. Request an inventory, integrity checks and a build record while assessing security, investment usefulness and post-release permissions separately.

A practical rehearsal starts from an isolated receiving environment and approved fixtures, with no implicit access to the supplier's developer account. Record every manual intervention and external dependency needed to complete it. A demonstration on the supplier's laptop may conceal missing instructions, cached libraries or private services. The important failure question is which step stops working when that supplier environment is genuinely unavailable.

Decide whether the remaining dependency is tolerable

Ask who would maintain the released code, how much handover effort is plausible, and whether the buyer can replace unavailable inputs within its permitted scope. Source availability does not create the staff capacity to understand a research system. Where continuity depends on undocumented judgment, the decision should acknowledge it explicitly. A limited archive or negotiated transition plan may be more relevant than a technically impressive but unusable deposit.

Stale deposits, unverifiable parameters and missing data rights can defeat the continuity assumption. Assign each unresolved dependency an owner and consequence; rehearse again after material implementation changes. Escrow does not eliminate supplier risk or authorize an unapproved operating environment.

Source notes

1. WIPO GREEN: Licensing Checklist, software escrow and termination questions
2. NIST SP 800-218: Secure Software Development Framework, public full text