Source code escrow is a three-party arrangement in which a software developer deposits its source code with a neutral custodian, who releases that code to the client only if specific events spelled out in the contract occur. The point is simple: you license software you depend on, but you usually receive only the compiled version, which no one but the developer can meaningfully fix or update. Escrow puts the human-readable code in safe hands so that if the developer goes bankrupt, shuts down, or stops supporting the product, you aren’t stranded.
How the Arrangement Works
Three parties sign a single agreement. The licensor is the developer that owns the code and wants to keep it confidential during normal business. The licensee is the client that depends on the software and needs continuity if the developer fails. The escrow agent is a neutral custodian that stores the deposited materials securely and follows the release procedures in the contract without taking sides.1SEC.gov. Three-Party Escrow Agreement
Until a release condition is triggered, the code stays locked away. The developer keeps control of its intellectual property during the ordinary course of business, and the client has a documented path to the source if things go wrong. The agent’s role is procedural: verify that deposits arrive, keep them in secure storage, and release them when the contract says so.
What Actually Goes Into the Deposit
A deposit that holds only source code files is close to useless if it lacks the pieces needed to turn that code into a running application. A well-structured deposit contains everything a reasonably skilled programmer would need to compile, deploy, and maintain the software without help from the original team. One agreement filed with the SEC specifically requires that deposited materials be in human-readable form and on suitable media to let a reasonably skilled programmer understand, maintain, and correct the code.1SEC.gov. Three-Party Escrow Agreement
In practice that means the complete source code in human-readable form, plus compiled object code or executables. Build scripts, configuration files, and environment setup instructions tell a new team how to recreate the development and production environments. Third-party libraries and dependencies, often overlooked, should be documented and, where licensing allows, included. Database schemas, API documentation, and architectural design documents round out the package. Some deposits also include encryption keys, access credentials, and contact information for the original developers.
Deployment and Infrastructure Files
Modern applications rarely run on a hand-configured server. They are deployed through automated scripts that define the infrastructure itself, using tools such as Terraform, Ansible, or Kubernetes manifests. Without those files, a new team might compile the code and still have no practical way to deploy it. For cloud-hosted software, the deposit should also include container images, infrastructure-as-code templates, and API version histories.
When the Code Gets Released
The escrow agent will not hand over materials just because the licensee asks. Release happens only when a trigger event defined in the agreement has occurred and been verified. The common triggers are:
- Bankruptcy or insolvency of the developer, including receivership or inability to pay debts as they come due.
- Cessation of business, whether through shutdown, acquisition that discontinues the product, or simply ceasing to operate as a going concern.
- Failure to maintain the software, meaning the developer stops providing updates, bug fixes, or support required under the license and does not cure the problem after notice.
- Material breach of the license that the developer does not fix within the agreed timeframe.
When the licensee believes a trigger has occurred, it submits a written release request to the agent with supporting evidence. The agent notifies the developer, who typically has 30 to 60 days to dispute the claim. Silence or non-response during that window results in release. A dispute sends the matter to arbitration or whatever resolution mechanism the agreement specifies.
Contested Releases
Contested releases are more common than most licensees expect. The developer or its bankruptcy trustee may argue that the trigger never occurred, that the licensee caused the problem, or that the breach was cured. Because the agent is a neutral custodian and not a judge, most agreements require the agent to pause and refer the matter out when the developer objects in time. Speed matters, because a licensee facing a non-functional application cannot wait months for a ruling. Arbitration clauses in these agreements should specify expedited timelines, and some agreements let the agent make a provisional release while the dispute is pending, leaving the developer to seek damages rather than block the handoff.
Bankruptcy Protection Under Section 365(n)
Developer bankruptcy is the scenario licensees worry about most, and it is where escrow intersects with federal law in a way that matters. When a company files for bankruptcy, a trustee can reject contracts the company no longer wants to perform. Without special protection, a trustee could reject a software license and leave the client with no right to keep using the software.
Section 365(n) of the U.S. Bankruptcy Code addresses this directly. If a trustee rejects a contract under which the bankrupt company licensed intellectual property, the licensee can elect to retain its rights under that license, including rights under “any agreement supplementary to such contract,” language that covers the escrow agreement itself.2Office of the Law Revision Counsel. 11 U.S. Code 365 – Executory Contracts and Unexpired Leases A licensee who makes that election keeps the right to use the software for the remaining term of the license and can obtain the intellectual property from the escrow agent or any other entity holding it.
The trade-off is real. A licensee who retains rights must continue making all royalty payments due under the contract and gives up certain setoff rights and administrative claims in the bankruptcy.2Office of the Law Revision Counsel. 11 U.S. Code 365 – Executory Contracts and Unexpired Leases Even before the trustee formally rejects, the licensee can submit a written request requiring the trustee to either perform the contract or hand over the intellectual property and not interfere with the licensee’s rights.
Section 365(n) only protects “intellectual property” as the Bankruptcy Code defines it, which covers trade secrets, patented inventions, copyrighted works, and mask works.3Legal Information Institute. 11 U.S. Code 101(35A) – Intellectual Property Definition Source code generally fits comfortably as a copyrighted work or trade secret, so licensees of traditional software usually qualify.
The Ipso Facto Trap
Here is where many escrow agreements quietly fail. An “ipso facto” clause is a contract provision that triggers solely because the other party filed for bankruptcy. Section 365(e) of the Bankruptcy Code makes these clauses generally unenforceable; a contract cannot be terminated or modified solely because of the debtor’s insolvency, the filing of a bankruptcy case, or the appointment of a trustee.2Office of the Law Revision Counsel. 11 U.S. Code 365 – Executory Contracts and Unexpired Leases
If an escrow agreement’s only release trigger is “the developer files for bankruptcy,” a court could rule that trigger unenforceable, leaving the agent unable to release the code at the exact moment it is needed. The safer approach is to tie release conditions to concrete harms: the trustee’s rejection of the license, the developer’s failure to provide support for a specified period, or a material breach of the license terms. Those triggers survive bankruptcy scrutiny because they rest on performance failures rather than on the filing itself.
Verifying the Deposit Actually Works
A deposit that cannot be compiled or deployed is worthless, and discovering that at the moment of crisis is too late. Verification confirms that the deposited materials actually work and comes in different levels.
The most basic is an inventory check: the agent confirms the deposit arrived, catalogs files by name, type, and size, and checks for encryption or corruption. This confirms existence and nothing more. Technical verification goes further; the agent or a third-party specialist checks that the source code can be compiled using the provided build instructions and dependencies. Missing libraries, outdated build scripts, and incompatible environment configurations surface at this stage. Full build verification is the most thorough option: the specialist compiles the code, deploys it to a test environment, and confirms the application runs and performs its core functions.4GOV.UK. Escrow as a Service (EaaS) Service Definition Document
Each level costs more. For mission-critical software, the expense is small compared to a release that produces an unusable deposit. Push for at least a technical verification at the initial deposit and after any major software release. Annual re-verification is a reasonable baseline for software that changes frequently.
SaaS and Cloud Software
Traditional source code escrow was designed for software installed on the client’s own servers. SaaS flips that model: the software, the data, and the infrastructure all live in the vendor’s cloud, so a standard source code deposit may not be enough to get the application running elsewhere.
SaaS escrow extends the concept to cover the cloud environment. A SaaS deposit typically includes database snapshots, cloud configuration files, and the credentials needed to access or replicate the production environment.4GOV.UK. Escrow as a Service (EaaS) Service Definition Document Some arrangements maintain a dormant copy of the entire cloud environment that can be activated quickly if the vendor fails.
Access credentials deserve particular attention. Root administrative credentials and any multi-factor authentication tokens need to be captured and stored securely, along with documentation explaining how to access the live cloud environment.4GOV.UK. Escrow as a Service (EaaS) Service Definition Document If those credentials are missing or stale at the moment of release, the rest of the deposit may be worthless. Verifying that the credentials actually work is one of the most important quality checks in a SaaS arrangement.
Setting It Up and What It Costs
Setup begins with negotiating a three-party agreement among the developer, the client, and a chosen escrow agent. The agreement should cover, at a minimum, what gets deposited, how often deposits are updated, the trigger events, the dispute resolution process, verification requirements, and who pays for what.
After signing, the developer makes the initial deposit. A well-drafted agreement will require updates within a set time after any material modification, upgrade, or new release. One SEC-filed agreement, for example, requires updated deposits within 60 days of any material modification.1SEC.gov. Three-Party Escrow Agreement Other agreements use quarterly or annual cycles, or tie updates to major version releases. Software receiving weekly patches needs more frequent deposits than a stable product that changes once a year.
Choice of agent matters more than most clients realize. Look for an established provider with experience in software escrow specifically, offering secure, encrypted, geographically redundant storage, verified deposit capabilities, and a clear release procedure. Asking how many releases the agent has processed and how disputes were handled will tell you more than its marketing materials.
Annual fees for a standard source code deposit typically range from roughly $1,000 to $6,000, depending on the complexity of the deposit, update frequency, and the level of verification included. Basic agreements with annual updates and no verification sit at the lower end. SaaS escrow with full build verification and cloud replication costs more, and complex arrangements are often priced on a custom basis. Who pays is negotiable; sometimes the licensee pays because the escrow protects its interests, sometimes the developer absorbs the cost to close an enterprise deal where escrow is a procurement requirement. Setup fees, verification fees, and per-update charges may be separate from annual storage, so review the full fee schedule before signing. Where negotiations tend to get stuck is not price but verification level and update frequency, both of which have a far bigger impact on whether the escrow will actually work when it matters.