ORPHANWARE What source code escrow actually is
Escrow is a three-party deal. You are the licensee, the company that bought the software. The vendor is the licensor, the company that built it. The escrow agent is a neutral third party, usually a law firm or a specialist escrow company, that holds a copy of the source code. The agreement between the three of you names the release conditions: the specific events that trigger the agent to hand the deposit to you. Escrow services typically charge an annual fee, which the vendor sometimes passes on in the contract price. The idea is simple. The details are where the protection lives or dies.
What should be in the deposit
A deposit that is only a zip file of the source tree may not rebuild into the program you bought. A deposit worth having contains everything a stranger would need to build and run it:
- The full source tree at the released version. Not a development snapshot from six months before the release you run.
- Build scripts and exact toolchain versions. Compilers, libraries, and build tools change; a build that needs version 8.2 of a library will fail against 8.9.
- Database schemas and migration scripts. The program is half data; without the schema history, the data is a puzzle.
- Third-party dependencies and their licenses, or at least a complete list with versions.
- Deployment and configuration documentation. How the program is installed, what the settings mean, where it expects its files.
- Credential procedures, sealed separately and refreshed. The sealed envelope nobody updated since 2019 is a classic.
- A build guide for a stranger. Step by step, from the deposit to a running program.
A deposit that cannot be built into the running program is a pile of files, not a safety net.
When the agent releases the code
The release triggers must be named in the agreement. Typical ones include: the vendor goes bankrupt or becomes insolvent; the vendor discontinues the product you bought; the vendor fails to provide support for a defined period; the vendor is acquired and the product is sunset; or, for a tiny shop, the death or departure of the key developer, if the contract names it. The key word is named. Vague language invites disputes, and a release request against a disputed trigger can sit in place while lawyers argue. This page is general information about how escrow agreements usually work, not legal advice, and the exact triggers should be reviewed with your own counsel before you rely on them.
How escrow deposits go stale
Escrow deposits are snapshots, not subscriptions, and staleness is the most common way escrow fails. A deposit nobody topped up since 2019 releases the 2019 code. The vendor ships updates every quarter and nobody sends the new snapshot to the agent. The agreement says the vendor will deposit on every release, and nobody enforces it. Staff turnover finishes the job: the one person at your company who knew the agreement existed leaves, the agent's invoices go unanswered, and the account lapses. Remember that the agent holds what it was given. It does not audit the deposit, it does not test whether the deposit builds, and it does not chase the vendor for updates. Every one of those jobs is on you or the vendor.
What to verify every year
Put a yearly escrow check on the calendar, the same way you renew a domain. The checklist:
- Ask the agent to confirm the deposit is current, with the date of the latest deposit and an inventory that matches what the agreement requires.
- Build from the deposit at least once. Some agents sell a verification service that builds the deposit and runs tests against it; for a business-critical system, it is worth the money.
- Read your release triggers again. Do they match your actual risks: bankruptcy, discontinuation, missed support, acquisition?
- Know who to call at the agent and what a release request looks like, before the crisis.
- Keep your own signed copy of the agreement and the deposit receipts where the business can find them.
- Check that the vendor is still operating. The ironic failure mode is the vendor dying years ago while nobody filed a release request.
Where escrow does not help
Escrow is a contract, and contracts have limits. It does not help when no agreement was ever signed, which is the common case for custom programs built by a solo developer or a tiny shop. It does not help when the product was SaaS, because the value was the hosted service and the shutdown took the service with it. It does not help fast when the vendor disputes the trigger, because the release can sit while lawyers argue. And it does not help when the deposit that arrives is old, incomplete, or does not build. You get files, not a working program.
When escrow failed or never existed
This is the situation the rest of this site covers: a compiled program still runs on a machine you control, the source code is gone, and there is no escrow deposit to call. The vendor-death playbook walks through the crisis steps, and the recovery guides explain the fallback path: the pipeline decompiles the binary, reconstructs readable source code, rebuilds it into a working program, and proves the rebuild behaves like the original with differential testing. When the code is truly gone, that is the only route back. A $45 Recon Report gives an honest verdict on whether a specific program qualifies before any larger commitment.
Signing an escrow agreement for new work
If you are commissioning custom software now, negotiate escrow while you have leverage, before you pay the final invoice. Ask whether the source is included in the deal or held in escrow. Name the triggers. Set the deposit schedule to every release, not once. Put build verification in the contract. Calendar the annual check this guide describes. Prevention is cheaper than recovery, and an escrow agreement you actually maintain is the cheapest insurance a software-dependent business can buy.