What It Does
A software escrow clause, also called a source code escrow clause, requires a software vendor to deposit a current copy of its source code, build instructions, and related materials with a neutral escrow agent, and sets the conditions under which that code is released to the customer. The customer licenses object code in the ordinary course and never receives the source, so the escrow exists for one scenario: the vendor fails, and the customer still depends on the software. Release is tied to defined trigger events, typically the vendor's bankruptcy, insolvency, discontinuation of the product, or failure to meet its maintenance and support obligations. A well-drafted clause also fixes what gets deposited, how often the deposit is refreshed, who verifies that it builds, and what license the customer receives in the released code.
Requires the vendor to deposit source code, build scripts, and documentation with an escrow agent
Releases the materials to the customer only on defined trigger events
Ties triggers to vendor bankruptcy, insolvency, abandonment of the product, or failure to support it
Sets how often the deposit is refreshed and whether a third party verifies that it builds
Grants the customer a license to use and maintain the released source code for its own continuity
Section 365(n) of the U.S. Bankruptcy Code lets a licensee keep using licensed intellectual property even when a bankrupt vendor's trustee rejects the contract, and well-drafted escrow agreements are written as "supplementary agreements" so the release survives the bankruptcy it is meant to protect against.
When You'll See It
The software escrow clause appears in enterprise software licenses, SaaS and on-premise agreements, technology development and OEM deals, and outsourced platform contracts where the customer's operations depend on software it does not control. It is most common, and most heavily negotiated, where the software is business-critical and hard to replace: ERP systems, payment and trading platforms, embedded industrial software, and core infrastructure. The larger and more dependent the customer, the more leverage it has to demand escrow, which is why enterprise vendors often carry source-code escrow obligations specifically for their largest accounts.
SaaS complicates the classic model. For cloud-hosted software, raw source code is often useless without the vendor's hosting environment, configuration, and data, so modern SaaS escrow increasingly covers a deployable copy of the running environment rather than code alone. It matters most where switching costs are high and downtime is expensive, such as a manufacturer running vendor software on a production line or a bank running a licensed core system. The deeper the dependency, the more the escrow is doing.
Examples
Symbotic LLC / GreenBox Systems LLC
Master Services, License and Equipment Agreement
Bankruptcy-triggered release
2023
"The Parties further agree that in the event that any bankruptcy proceedings are commenced by or against Symbotic under the Bankruptcy Code, Customer shall be entitled to retain and enforce its rights under the Source Code Escrow Agreement."
Serve Operating Co. / Magna New Mobility USA, Inc.
License and Services Agreement
Release triggers: uncured breach and escrow lapse
Mutual
2024
"Serve, or its successors or assigns, materially breaches its obligations under this Agreement or the Source Code Escrow Agreement, and fails to cure such breach within sixty (60) days upon receiving notice thereof; or [...] the Source Code Escrow Agreement terminates due to breach by Serve, or its successors or assigns, and is not replaced within thirty (30) days with another escrow agreement reasonably acceptable to Magna..."
E2open Parent Holdings, Inc. / WiseTech Global
Agreement and Plan of Merger
Source-code escrow as a top-customer obligation
2025
"Source Code Escrow Obligations relating to material Company Group Software licensed to any customer who, in the fiscal year ended February 28, 2025 was one of the ten (10) largest sources of revenues for the Company Group, taken as a whole, based on amounts paid or payable..."
Negotiate
You want a release you can actually use
Tie release to broad, objective triggers: bankruptcy, insolvency, ceasing the business, and failure to provide contracted support or maintenance.
Require the deposit to be updated on a fixed schedule and at every major release, not just once at signing.
Insist on verification, so an independent party confirms the deposit compiles and includes build tools and documentation.
Secure a perpetual license to use, modify, and maintain the released code for your own continuity.
Draft the escrow as an agreement supplementary to the license under Section 365(n), so a bankruptcy trustee cannot strip your access.
You want to protect your code
Narrow the triggers to genuine failure events and exclude ordinary disputes or alleged breaches.
Limit the released license to internal maintenance of the licensed version, with no right to distribute or compete.
Require the customer to bear the escrow agent's fees and any verification costs.
Resist depositing build environments or keys beyond what is needed to maintain the specific release.
Add a redeposit-and-return mechanism if a release event is later cured.
A software escrow is only as good as its triggers and its freshness. Code released years out of date, or never verified to build, protects nobody.
Red Flags
Release triggers so narrow that real vendor failure, such as quietly discontinuing support, never releases the code.
A deposit made once at signing and never updated, so the escrowed code no longer matches the version you run.
No verification, leaving you to discover at release that the deposit does not compile or is missing build tools.
A released license limited to "viewing" the code, with no right to modify or maintain it.
An escrow not structured to survive the vendor's bankruptcy, which is the event it most needs to withstand.
FAQs
This content is for informational purposes only and does not constitute legal advice.
