When source code escrow is demanded: what it costs to be wrong
A source code escrow demand means the counterparty wants a guaranteed route to your code if you disappear, get acquired, or stop supporting the product. Getting the trigger conditions wrong costs you control at the one moment you actually need it. Refusing the demand without an alternative costs you the deal itself.
Why the request exists at all
Software is protected as a literary work under Directive 2009/24/EC. That protection runs to the rightholder, not to whoever licensed the software. A customer with an ordinary object-code licence has no legal path to the underlying source if the vendor stops maintaining the product, sells the business, or fails outright. Escrow is the contractual fix for that gap. It is not a regulatory obligation anyone imposes on either party.
This is why the demand is commercial rather than statutory in almost every case. Nobody requires escrow by law for an ordinary software licence. A counterparty asks for it because business-continuity risk sits entirely on their side of the relationship, and they want part of it moved back to yours through a documented, third-party-verified mechanism.
What escrow actually has to hold
A deposit that only contains the raw source files satisfies the letter of most clauses and fails the point of the exercise. Rebuilding a working system from a stale code dump, without build scripts, dependency versions, configuration files, and deployment documentation, can take longer than writing the software again. The demand is really for a reproducible build, and that scope belongs in the clause, not left to be assumed later.
What changes once escrow is on the table
The negotiation stops being about the software and starts being about three mechanics: what triggers release, how current the deposit stays, and who pays the escrow agent. Each of these carries a deadline that starts running from signature, not from the first dispute.
- The deposit update cadence — usually tied to each material release rather than a calendar date — begins the day the clause is signed.
- The verification window, in which the agent confirms the deposit builds and matches what is running in production, is fixed in the clause itself.
- The release notice period is the number of days the vendor has to contest a release request before it happens automatically.
Missing any of these dates does not void the clause. It simply shifts the outcome toward whichever party kept better records when the dispute eventually arrives.
What to do, in order
- Read the demand as written, not as a template you have seen before. Confirm whether it already names a specific escrow agent, jurisdiction, and release trigger list, or leaves those open for negotiation.
- Check the delivery contract for an existing escrow clause before drafting a new one. Escrow terms buried in an old master agreement are the most common source of later conflict, precisely because nobody remembers they are there.
- Instruct the escrow agent directly rather than letting the counterparty manage that relationship alone. The agent's verification report becomes the evidence a dispute is later decided on.
- Define release triggers as facts, not opinions. Insolvency filing, confirmed cessation of support for a stated period, an uncontested breach notice — never a vague standard such as "material deterioration of service".
- Set the update cadence against release events, not calendar dates, so a fast-moving codebase does not fall out of compliance by default between scheduled updates.
- Allocate the agent's fee explicitly. Silence on this point defaults, in practice, to whichever party requested escrow — which is rarely the outcome either side actually intended.
- Specify the deposit format as a reproducible build with dependencies and configuration, not a source-only archive. This single line prevents most disputes over whether the deposit "counts".
Who decides, and on what evidence
In the ordinary case, nobody outside the two parties decides anything. The escrow agent releases the deposit strictly on the conditions the clause states, and on nothing beyond those. A dispute over whether a trigger has actually occurred goes to whatever forum the underlying contract names — arbitration or the courts of the agreed jurisdiction. That forum decides on the escrow agent's verification records, the notice correspondence, and the deposit history. It does not decide on the quality of the software itself, which is a separate and unrelated question.
| Trigger event | What the agent checks | Typical evidence |
|---|---|---|
| Insolvency of the vendor | Filing status with the relevant register | Court or register extract |
| Cessation of support | Whether the stated notice period has lapsed | Support correspondence, ticket logs |
| Uncontested breach | Whether the vendor filed an objection in time | Notice log, agent's timestamp record |
| Change of control | Whether the clause defines acquisition as a trigger | Public filing, transaction notice |
Where this gets complicated
If the delivery contains open-source components, escrow does not resolve the separate question of licence compliance inside the deposited code. That is a different failure with its own cost, covered on its own terms in When open source is found in the delivery step.
If the code, or the right to use it, has been offered as security rather than deposited purely for continuity, the mechanics run closer to a pledge than to an escrow release, and the trigger logic follows a different set of rules — see When a right is pledged on-chain step by step.
Who decides, and on what evidence
The escrow agent decides whether a release condition has been met, on the trigger wording in the agreement and the documents the clause names as proof — a notice log, an agent's timestamp, a public filing. A court decides only if that release decision is challenged. The clause that defines the trigger does more work than the deposit itself.
What this page does not settle
This page does not tell you whether a particular release condition has been met in your case, which turns on the exact wording and the record behind it, and it does not draft the clause for you. It does not resolve licence-compliance questions inside the deposited code, which run on their own track.
FAQ
What does it cost to get source-code escrow wrong?
A deposit that never triggers when you need it, because the release conditions were drafted around events that did not occur, or a release blocked because the proof the clause demands was never kept. The cost is continuity you believed you had and do not.
Which deadline is already running?
The objection window the agreement gives the depositing party after a release is requested. Miss the record of when that window opened and closed, and an uncontested breach becomes contestable after the fact.
Who decides, and on what evidence?
The escrow agent decides first, on the trigger wording and the documents named as proof; a court reviews that decision only if it is challenged.
Verified
Describes the general mechanics of software escrow and release triggers, independent of any single national contract-law regime. The review date for this page is shown in its metadata.