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 contract triggers are met. The setup protects both sides at once. The developer keeps its proprietary code confidential during the normal course of business, and the client avoids being stranded if the developer goes bankrupt, shuts down, or stops maintaining the software. Federal bankruptcy law reinforces the arrangement through 11 U.S.C. ยง 365(n), which lets software licensees keep access to intellectual property even when a bankruptcy trustee tries to walk away from the license.
Why the Arrangement Exists
In a typical software license, the client receives only the compiled version of the application. That version runs the program but cannot be meaningfully read, edited, or maintained by a human. The underlying source code stays with the developer. If the developer disappears, the client is left with software nobody else can fix or update.
Escrow breaks that dependency. A neutral third party holds a copy of the source code and related materials in secure storage under a written agreement that spells out exactly what gets deposited, how often it gets refreshed, and what events allow a release to the client. Until one of those events occurs, the code stays locked away and the developer’s intellectual property stays protected.
The Three Parties
Every escrow agreement involves three participants, each with distinct interests.
The licensor is the developer that created the software and owns the source code. The licensor’s priority is confidentiality. Under the escrow agreement, the licensor deposits the code, keeps it current, and ensures the deposit contains everything needed to compile and run the application.1SEC.gov. Three-Party Escrow Agreement
The licensee is the client that depends on the software. The licensee’s priority is continuity. If the developer can no longer support the product, the licensee needs enough material to maintain or migrate the software independently. The licensee is the beneficiary who receives the deposited materials when a release condition is triggered.
The escrow agent is the neutral custodian. It stores the deposited materials securely and releases them only when the contract says so. The agent does not take sides. Its job is to verify deposits, maintain secure storage, and follow the release procedures in the agreement. Most commercial escrow agents also offer optional verification services to confirm the deposited code actually compiles and works.
What Goes Into a Deposit
The deposit needs to contain everything a competent developer would require to compile, deploy, and maintain the software without help from the original team. A deposit that holds only source code files is almost useless if it lacks the build scripts, dependencies, or documentation needed to turn that code into a running application.
At a minimum, a well-structured deposit includes the complete source code in human-readable form, along with any compiled object code or executables. Build scripts, configuration files, and environment setup instructions belong in the deposit too, since these tell a new team how to recreate the development and production environments. One agreement filed with the SEC specifically requires that deposited materials be in human-readable form and on suitable media so that a reasonably skilled programmer can understand, maintain, and correct the code.1SEC.gov. Three-Party Escrow Agreement
Third-party libraries and dependencies are easy to overlook and often critical. If the software relies on external components that require separate licenses, the deposit should document those dependencies and, where licensing permits, include copies. Database schemas, API documentation, and architectural design documents round out the package. Some agreements go further and include encryption keys, access credentials, and contact information for the original developers.
Modern applications are often deployed using automated scripts that define the infrastructure itself as code. Without those files, a new team might be able to compile the source but have no practical way to deploy it. For cloud-hosted software, the deposit should include deployment artifacts such as container images, infrastructure-as-code templates, and API version histories.
When the Code Gets Released
The escrow agent will not hand over the deposit just because the licensee asks. Release happens only when a specific trigger event defined in the agreement has occurred and been verified. The most common triggers are:
- Bankruptcy or insolvency of the developer, including receivership or an inability to pay debts as they come due.
- Cessation of business, whether by shutdown, acquisition that discontinues the product, or the developer 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 fails to cure after notice.
- Material breach of the license that the developer does not fix within the agreed timeframe.
When the licensee believes a trigger event has occurred, it submits a written release request with supporting evidence. The escrow agent notifies the developer, who typically has a window (often 30 to 60 days) to dispute the claim. If the developer does not contest the release within that period, the agent releases the materials. If the developer disputes it, the matter goes to arbitration or the dispute resolution mechanism named in the agreement, and the escrow agent steps back while that process runs.
Bankruptcy Protections Under Federal Law
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 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,” which covers the escrow agreement.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 duration of the license and can obtain the intellectual property from the escrow agent or any other entity that holds it.
The trade-off is that 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 formal rejection, the licensee can submit a written request requiring the trustee to either perform the contract or hand over the intellectual property and stop interfering with the licensee’s rights.
Section 365(n) only protects “intellectual property” as defined by the Bankruptcy Code, 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 fits comfortably as either a copyrighted work or a trade secret (and often both), so licensees of traditional software generally qualify.
The Ipso Facto Trap
An “ipso facto” clause is a contract provision that fires 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 exactly the moment the licensee needs it most. The safer approach ties 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 license terms. Those triggers survive bankruptcy scrutiny because they rest on performance failures rather than on the bankruptcy filing itself.
Verifying the Deposit
A deposit that cannot be compiled or deployed is worthless, and finding that out at the moment of crisis is too late. Verification confirms that the deposited materials actually work, and it comes in different levels.
An inventory check is the most basic. The agent confirms the deposit arrived, catalogs files by name, type, and size, and checks for encryption or corruption. That tells you the deposit exists. It tells you nothing about whether the code will compile.
Technical verification goes deeper. 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 settings 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. For SaaS escrow, this may include checking that access credentials work and that the cloud environment can be stood up independently.4GOV.UK. Escrow as a Service (EaaS) Service Definition Document
Verification costs more at each level, but for mission-critical software, the expense is small compared to the cost of a release that hands over an unusable deposit. Technical verification at the initial deposit and again after any major release is a reasonable minimum, with annual re-verification for software that changes frequently.
SaaS and Cloud Escrow
Traditional escrow was designed for software installed on the client’s own servers. SaaS applications flip that model. The software, the data, and the infrastructure all live in the vendor’s cloud environment, which means a standard source code deposit may not be enough to run the application elsewhere.
SaaS escrow extends the concept to cover the whole environment. In addition to source code, 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 special attention. Root administrative credentials and any multi-factor authentication tokens in use need to be captured and stored securely, with documentation explaining how to reach the live cloud environment.4GOV.UK. Escrow as a Service (EaaS) Service Definition Document If those credentials are missing or out of date at the moment of release, the rest of the deposit may be worthless.
Setting Up an Arrangement
The process starts with negotiating a three-party agreement among the developer, the client, and a chosen escrow agent. At minimum the agreement covers what materials get deposited, how often they get updated, what events trigger a release, the dispute resolution process, verification requirements, and who pays for what.
Once the agreement is signed, the developer makes the initial deposit. A well-drafted agreement requires updates within a set timeframe after any material modification, upgrade, or new release. One agreement filed with the SEC, for example, requires updated deposits within 60 days of any material modification.1SEC.gov. Three-Party Escrow Agreement Other agreements specify quarterly or annual updates, or updates tied to major version releases. Software that receives weekly patches needs more frequent deposits than a stable product that changes once a year.
Choosing the escrow agent matters more than most clients realize. Look for a provider with specific experience in software escrow, not just general-purpose escrow services. The agent should offer secure storage that is encrypted and geographically redundant, verified deposit capabilities, and a clear, tested release procedure. Asking how many releases the agent has processed and how disputes were handled tells you more than the marketing materials.
Typical Fees
Annual escrow fees for a standard source code deposit typically range from roughly $1,000 to $6,000, depending on the complexity of the deposit, the frequency of updates, and the level of verification included. Basic agreements with annual updates and no verification sit at the low end. SaaS escrow with full build verification and cloud environment replication costs more, and some complex arrangements are priced on a custom basis.
Who pays is negotiable. In some deals the licensee pays because the escrow primarily protects the licensee. In others the developer absorbs the cost as part of the licensing relationship, especially when escrow is a procurement requirement for an enterprise deal. Setup fees, verification fees, and per-update charges may be separate from the annual storage fee, so review the full schedule before signing. Where negotiations get stuck is usually not on price but on verification level and update frequency, both of which have a bigger impact on whether the escrow will actually work when it matters.