Software Escrow and Source-Code Access in Vendor Agreements

On the day a software escrow releases, the customer receives a copy of whatever the vendor deposited. That is the whole promise: not a working system, not a support team, and not permission to do anything the license did not already allow. A source-code escrow is a three-party arrangement — vendor, customer, neutral agent — in which the vendor deposits source code and build materials and the agent releases them on defined triggers. Whether that release is useful turns on the trigger definition, the deposit specification, and whether anyone verified the deposit.

What release day actually looks like

Picture the release working perfectly, as a hypothetical. The vendor files for bankruptcy, the agent confirms the trigger, and a package arrives. Inside is a repository snapshot from eighteen months ago, no build scripts, a dependency file pointing at a package server that no longer answers, and nothing describing the production environment.

The customer now owns a puzzle, not a system. That is the ordinary failure mode, and it is why experienced buyers spend their effort on deposit contents and verification rather than on whether an escrow exists. A good release delivers enough material for a competent engineering team to rebuild, run, and patch the software while migrating elsewhere. Escrow is a transition tool, not permanent insurance.

The three parties and what each one owes

The vendor deposits and keeps depositing, usually on a schedule tied to major releases. The customer pays the agent's fees and, on release, uses the material only within the scope the license allows. The agent's duties are entirely contractual: hold the material, confirm it matches the specification if verification is bought, and apply the release conditions.

The agent is not an arbitrator of the commercial dispute. If the vendor objects, most agreements route the disagreement into an objection window and then to arbitration or a court, with the agent holding the material meanwhile.

Bankruptcy and section 365(n)

Bankruptcy is federal law. When a debtor rejects a contract, the counterparty is normally left with a damages claim rather than performance. Section 365(n) of the Bankruptcy Code changes that for intellectual property licenses: a licensee can generally elect to retain its license rights for the remaining term rather than lose them on rejection.

That is why escrow agreements are usually drafted as supplementary agreements to the underlying license rather than stand-alone executory contracts — so the escrow rides along with the retained license instead of being separately rejectable. Outcomes in any given bankruptcy depend on the facts and the court, so treat this as a drafting strategy, not a guarantee.

Copyright in the code is also federal; the U.S. Copyright Office explains how computer programs are registered and deposited. Trademark rights in the product name are a separate federal layer handled through the USPTO, and a code release rarely carries the right to keep using the vendor's brand. The escrow agreement itself, whether a trigger was met, and remedies for breach are state contract law — which is why escrow disputes so often run as two proceedings at once.

Triggers: the clause that decides everything

The trigger list is where escrow agreements succeed or fail. Four categories recur, each with its own drafting problem.

Insolvency or bankruptcy filing. Clean to verify, but also the moment the estate has the strongest incentive to contest anything that reduces asset value. Specify what evidence the agent may rely on, so it is not making a judgment call.

Cessation of business. Harder than it sounds. A vendor that laid off its engineers but still answers the phone has not obviously ceased business. Tie this to observable facts.

Failure to provide contracted support. The most useful trigger in practice and the most frequently watered down in negotiation. Define it against the service levels already in the agreement, with a cure period and notice mechanism.

Failure to cure a material breach. Broad enough to be useful, vague enough to invite an objection. Pair it with the license's notice-and-cure machinery.

Note: Acquisition of the vendor is sometimes proposed as a trigger, and vendors resist it hard. A middle position triggers release only where the acquirer discontinues the product or fails to assume the support obligations.

What has to be in the deposit

Source code alone rarely rebuilds a system. The deposit specification should be an itemized exhibit updated with each deposit, not a line saying "the source code."

Practical step: Match the verification level to the risk. A file-listing check confirms only that something was deposited. A structural review checks the material against the specification. A compile-and-run test, where the agent rebuilds the software in a clean environment, is the only level that reliably surfaces the gaps above.

SaaS changes the whole question

With hosted software there is no code to run. Even a complete deposit does not reproduce the vendor's infrastructure, integrations, or the customer's live data, so a source escrow over SaaS protects far less than the signature page implies.

Three alternatives do more real work. Data escrow places regular exports of the customer's data with the agent in a documented format. Hosted-replica arrangements keep a standby deployment a third party can activate. Transition-services terms commit the vendor to a wind-down: continued operation for a stated period, export assistance, and migration cooperation.

For most SaaS buyers the strongest protection is unglamorous — an unconditional right to export complete data on demand, in a documented format, without extra charge. Such rights live in the master agreement and its click-accepted terms, and whether those bind is the subject of our explainer on when an online agreement actually binds a user.

Note: If a release includes credentials to systems the vendor still operates, define exactly what may be accessed. Reaching beyond the agreed scope raises exposure under the federal Computer Fraud and Abuse Act.

Where escrow sits among other protections

Escrow is one control among several, and not always the strongest. A properly perfected security interest in the vendor's assets can give a customer priority in an insolvency; the mechanics are in our guide to attachment, perfection, and priority under the UCC. The access-to-documentation problem is not unique to software either — the same tension drives state right-to-repair laws covering parts and repair documentation, and staged release against payment works much as it does in a domain name and website transfer.

As of mid-2026, escrow remains a standard ask in enterprise procurement, but the balance has shifted toward data portability and exit terms as more critical systems moved to hosted delivery. Compliance obligations for the buying organization are collected in the FTC's business guidance.

Common questions

If the escrow releases, can my team keep the software running?

Only if the deposit is complete and the license allows it. A release gives you material, not capability. You still need engineers who can read the codebase, an environment matching the build requirements, and license language permitting you to modify and maintain the software internally. Check the scope grant — some agreements limit use to maintenance, and a few say nothing at all.

How often should a vendor be required to refresh the deposit?

Tie it to releases rather than the calendar alone. A common structure requires a deposit at every major version plus a periodic refresh, with the vendor certifying in writing that the deposit matches production. Add a right to be notified of each deposit and to request verification. A deposit two years stale is the same as no deposit, and staleness is the commonest defect.

Does an escrow do anything if my vendor sells a cloud service?

Less than most buyers assume. Without the vendor's hosting environment, configuration, and integrations, source code will not reconstitute a running service. For hosted products, negotiate data escrow, an unconditional export right in a documented format, and transition-services obligations that survive termination. If continuity genuinely matters, ask whether a standby deployment can be maintained and who is contractually able to switch it on.

Who pays for verification, and is it worth the cost?

Payment is negotiable; the customer commonly pays, sometimes with the vendor sharing where escrow was a condition of sale. Whether it is worth it depends on how much the system matters. For a peripheral tool, a file-listing check is defensible. For software you could not operate without, only a compile-and-run verification reveals an unusable deposit while the vendor can still fix it.

Putting an escrow in place and keeping it useful

1. Decide whether escrow is the right control. For hosted software, ask whether export rights and transition terms protect you better.
2. Draft triggers against observable facts. Name the evidence the agent may act on, with a cure period and notice route for each.
3. Write the deposit specification as an exhibit. List build scripts, dependencies, environment specs, licenses, schemas, and documentation.
4. Buy the verification level that matches the risk, deciding at signature while you still have leverage.
5. Confirm the license scope on release. The agreement should say plainly that you may compile, modify, and maintain the software.
6. Diarize refreshes and re-test after major changes. Require written certification with each deposit, and re-verify after an architecture change.

Practical step: Ask the vendor one question during procurement — could a new engineering team rebuild this from the deposit without calling you? The willingness to prove it tells you more than the clause does.