What is source code escrow?
Source code escrow is a tri-party arrangement where a software vendor deposits source code with an independent escrow agent (e.g., Iron Mountain, NCC Group, Codekeeper), with release conditions that protect the customer (licensee) if the vendor becomes unable to support the software. Escrow agreements typically release the source code to the customer upon defined triggers — vendor bankruptcy, material breach of support obligations, cessation of business — letting the customer maintain the software independently. Escrow is the standard customer protection for mission-critical enterprise software licensed under “binary only” terms.
Release trigger events (typical)
- Vendor bankruptcy or insolvency: liquidation, Chapter 11, equivalent jurisdictional proceedings.
- Cessation of business / discontinuation: formal exit from market, product end-of-life.
- Material breach: failure to provide contracted support, maintenance, security patches for extended period.
- Acquisition triggers: change of control where successor entity discontinues support.
- Customer-defined triggers: tailored to deal context (regulatory mandate change, key person departure).
Deposit content beyond source code
- Source code: full version-controlled codebase.
- Build instructions: compilation environment, dependencies, build scripts.
- Documentation: architecture, deployment, configuration documentation.
- Third-party licenses: OSS bill of materials, commercial library entitlements.
- Update cadence: typically quarterly or per major release.
Escrow verification
- Basic verification: escrow agent confirms deposit completeness.
- File-list verification: agent confirms specific files match deposit schedule.
- Compile verification: agent compiles source code in clean environment to verify buildability.
- Functional verification: compiled output meets functional tests — highest assurance level.
Escrow that actually releases
Source-code escrow fails at release time unless drafted backwards from that moment. Release triggers need objective verifiability — insolvency events, formal end-of-support, defined maintenance breaches with cure periods — because “vendor stopped supporting properly” is an arbitration, not a trigger. Verification levels matter more than the deposit: unverified deposits are routinely incomplete, so periodic build-verification (the agent compiles and runs the deposit) is the version worth paying for. The licence that follows release must permit what continuity requires — modification and maintenance use, contractor access — and survive the vendor’s bankruptcy under the governing insolvency regime. For Turkish deployments add deposit-update cadence tied to release cycles and clarity on which entity (local distributor or foreign principal) owes the deposit obligations. Enterprise buyers should test the escrow like the backup it is: a restore never rehearsed is a hope, not a control.