Source Code Escrow Agreements: How They Work for SaaS and Licensing Deals

Quick answer: a source code escrow agreement is a contract in which a software vendor deposits its source code and build materials with an independent escrow agent, who releases them to the customer only if agreed events happen, such as the vendor going out of business or no longer supporting the software. For SaaS, the deposit must also cover deployment and data.

This guide is for founders who license or white-label software and get asked for escrow, and for buyers whose business depends on someone else's software. It explains how escrow works, when it's worth the cost, what to deposit for a hosted product, and which terms each side should negotiate.

Key takeaways

• Escrow protects the buyer's continuity. It doesn't transfer ownership: the vendor keeps the intellectual property.
• Release conditions are the core of the agreement. Define them precisely, with notice and evidence.
• For SaaS, source code alone can't restore the service: deposit infrastructure, deployment steps and data access too.
• Verification is what makes a deposit usable. An unchecked deposit may not build when it's needed.
• Escrow fits critical, high-value deals. For smaller ones, a source license or transition terms can be simpler.

What a source code escrow agreement is

A source code escrow agreement is a contract that keeps a copy of a vendor's source code, and the materials needed to build and run it, with an independent escrow agent. If an agreed event happens, such as the vendor going out of business or no longer supporting the software, the agent releases the deposit to the customer so they can keep the software running.

There are three roles:

• The depositor: the software vendor or founder who owns the code.
• The beneficiary: the customer, licensee or white-label partner who depends on it.
• The escrow agent: an independent company that stores the deposit, checks it if asked, and releases it only under the agreed conditions.

Agreements come in two common forms. In a three-party agreement, the vendor, the customer and the agent negotiate one contract together. In a two-party agreement, the vendor signs a standard agreement with the agent, and each customer joins it as a beneficiary, which suits vendors with many customers. Either way, escrow protects continuity; it doesn't transfer ownership of the code. The licensing glossary defines the related terms.

Source code escrow is different from payment escrow, where money is held until software is delivered. For that, see escrow payments in software deals.

Escrow and its alternatives, compared

When a source code escrow agreement is worth it

Escrow costs money and effort on both sides, so it fits some deals better than others.

Buyers should ask for it when

• The business depends on the software: it runs operations, holds customer data or is resold to the buyer's own clients.
• The vendor is small or new: a single founder or a young company carries more risk of stopping.
• Switching would be slow or expensive: heavy customization, integrations or data that's hard to move.
• They resell it: agencies and resellers of white-label software need to keep serving their clients if the vendor disappears. If the model is new to you, read what white-label software is.

It is usually not worth it when

• The software is inexpensive and easy to replace.
• The buyer could not maintain the code even if they had it, and has no plan to hire someone who could.
• A source code license or clear transition terms would give the same protection more simply.

For founders, offering escrow can help win larger customers and partners, because it answers a question procurement teams ask about smaller vendors.

What to deposit, especially for SaaS

A deposit is only useful if someone else can build and run the software from it. For installed or self-hosted software, the classic deposit is enough:

• Source code for every component, including scripts and configuration.
• Build instructions and a list of tools, libraries and versions.
• Documentation for architecture, setup and maintenance.
• A list of third-party components and their licenses.

A hosted SaaS product needs more, because the service depends on infrastructure the customer doesn't have. Add:

• Infrastructure configuration: infrastructure-as-code, environment settings and the services it relies on.
• Deployment steps: a runbook or scripts to deploy from scratch.
• Database schema and migrations, and how the customer gets a full export of their data.
• Third-party accounts: which external services are needed and how to set them up. Never deposit live passwords or keys; describe how to obtain or rotate them.

Agree how often the deposit is updated: with every major release, or on a fixed schedule. A deposit from two years ago is of little use. Some escrow agents can take deposits automatically from a code repository, which keeps them current with little effort.

Release conditions: the heart of the agreement

Release conditions decide when the customer gets the deposit, so they cause the most negotiation. Common triggers include:

• Insolvency or bankruptcy of the vendor.
• The vendor ceasing to do business or discontinuing the product.
• Failure to support or maintain the software as the license requires, after written notice and a period to fix it.
• A change of control in which the new owner won't honor the license, if both sides agree to include it.

Customers usually want broader triggers and vendors narrower ones. Whatever is agreed, write down how a release works: the customer notifies the agent with evidence, the vendor has a short period to object, and disputes go to a named process. Price disputes and ordinary disagreements shouldn't trigger a release.

Verification: proving the deposit works

Without verification, nobody knows whether a deposit is complete until it's needed, which is the worst moment to find out. Escrow agents offer levels of checking, for example:

• Deposit check: the agent confirms the files arrived, are readable and match the inventory.
• Build test: an engineer builds the software from the deposit using only the documentation.
• Full test: the software is deployed and run, which for SaaS means standing the service up in a clean environment.

Agree which level applies, how often it is repeated after major changes, and who pays. A common arrangement is that the customer pays for verification, but the vendor pays for a repeat if the deposit fails.

After a release: what the customer may do

A release is not a sale. The vendor keeps the intellectual property, and the customer normally receives a limited license to use, maintain and fix the software for their own business, with confidentiality obligations. Spell out:

• Whether the customer may hire contractors to maintain the code.
• Whether a white-label partner may keep serving its existing clients, and whether it may take on new ones.
• That the customer may not resell or sublicense the code unless the agreement says so.

These terms should match the main license. See what to include in a white-label agreement and the SaaS licensing agreement clauses.

Costs and who pays

Escrow agents charge setup and annual fees, and verification is priced separately by level. What you'll pay depends on the agreement type, the number of beneficiaries, how often the deposit is updated and how deep the verification goes. Ask several agents for quotes.

Who pays is negotiable. The customer who asks for escrow often pays, the cost may be split, or the vendor includes it in an enterprise license fee. For a founder with several customers asking, one two-party agreement that each customer joins is usually cheaper than separate contracts.

Source code escrow agreement checklist

• The parties and the escrow agent.
• The deposit contents, including SaaS infrastructure and data access.
• How often the deposit is updated, and how.
• The verification level, frequency and who pays.
• Release conditions, notice, evidence and the dispute process.
• The customer's rights after a release, and limits on them.
• Fees, and who pays each one.
• Confidentiality, term, termination and governing law.

This is general information, not legal advice. Have a lawyer review the agreement, and use the escrow agent's standard terms as a starting point.

Where LicenseSaaS fits

LicenseSaaS is a marketplace for licensing and white-labeling software, source code, AI agents and other digital products. Buyers and sellers agree terms such as escrow, support and data export directly, and use an independent escrow agent for the deposit; LicenseSaaS does not hold source code.

If you're a founder ready to offer licensing or white-label terms, list your software for free and see what buyers ask for in buyer requests. If you're buying, browse software you can license, check each product yourself, and for anything critical ask about escrow before you sign. LicenseSaaS does not verify listings.

Frequently asked questions

What is a source code escrow agreement?

It is a contract in which a software vendor deposits its source code and related materials with an independent escrow agent. The agent releases them to the customer only if agreed events happen, such as the vendor's insolvency or its failure to support the software.

Who pays for source code escrow?

It is negotiated. Often the customer who asks for escrow pays, or the cost is split, and in licensing deals it can be built into the license fee. Verification testing is usually charged separately, so agree who pays for it too.

Does source code escrow work for SaaS?

Only if the deposit covers more than code. A hosted service also needs deployment scripts, infrastructure configuration, third-party service details and a way to get the customer's data, so the service can be rebuilt and run.

What are typical release conditions?

Common triggers are the vendor's insolvency or bankruptcy, the vendor ceasing to do business, and a failure to provide support or maintenance as the license requires. Each should be defined precisely, with notice and a short period for the vendor to dispute a release.

Can the customer resell the code after a release?

Usually not. A release normally gives a limited license to maintain and support the software for the customer's own use. Any wider rights, such as continuing to serve a white-label partner's existing clients, must be written into the agreement.