Source Code Trust Agreement Licensed Program Template

In plain language: Identifies the depositor (licensor), beneficiary (licensee), and trustee by their full legal names, and records the background context — the underlying license agreement, the business purpose of the escrow, and the parties' intent.

Common mistake: Failing to reference the underlying license agreement by date and title. If the escrow agreement exists independently of a named license, disputes about which software version is covered become nearly impossible to resolve.

In plain language: Requires the depositor to place a complete set of deposit materials — including source code, build instructions, dependencies, and technical documentation — with the trustee within a specified number of days of signing, and defines exactly what 'complete' means.

Common mistake: Defining deposit materials as 'source code' without specifying build scripts, dependency lists, encryption keys, and documentation. An incomplete deposit renders the escrow worthless — the beneficiary may receive files that cannot be compiled.

In plain language: Requires the depositor to deposit updated materials each time a new version, major patch, or material update of the licensed program is released, within a defined timeframe after each release.

Common mistake: Setting no update timeline or leaving it entirely to the depositor's discretion. Without a specific deadline, depositors routinely allow the escrowed version to fall 12–18 months behind the production version, making the escrow practically useless on a release event.

In plain language: Gives the beneficiary the right to request a technical verification — and allows the trustee or an appointed expert to confirm the deposit is complete and sufficient to build and operate the program — at defined intervals or on reasonable notice.

Common mistake: Omitting a verification right entirely. Without verification, neither party knows whether the deposit is complete or current until a release event occurs — at which point discovering the deposit is incomplete is too late.

In plain language: Defines the specific events that entitle the beneficiary to receive the deposit materials from the trustee — typically insolvency, cessation of business, material failure to maintain the software, or material breach of the license agreement.

Common mistake: Defining release conditions so broadly that the trustee cannot objectively verify them, or so narrowly that common failure scenarios are excluded. A condition like 'Depositor fails to perform its obligations' is too vague — the trustee has no way to assess a disputed breach without becoming a fact-finder.

In plain language: Defines what the trustee is and is not obligated to do — including custody, confidentiality, and release administration — while limiting the trustee's liability to intentional misconduct and capping the trustee's exposure to fees paid.

Common mistake: Appointing the beneficiary's own legal counsel, or the licensor's affiliated entity, as trustee. The trustee must be genuinely neutral — a conflicted trustee can be challenged, delaying or preventing release.

In plain language: Confirms that title to the source code remains with the depositor at all times, and that if released, the beneficiary receives only a limited, non-transferable license to use the code to maintain or operate the licensed program for their own internal purposes.

Common mistake: Omitting a scope-of-use restriction on the released code. Without it, the beneficiary may argue that release grants them broader rights — including the right to modify and redistribute — which was never the depositor's intent.

In plain language: Requires both the trustee and the beneficiary to treat the deposited source code as strictly confidential, and limits use of any released code to the scope defined in the permitted-use clause.

Common mistake: Using a time-limited confidentiality clause that expires before the software's commercial life. If confidentiality expires in 3 years and the program runs in production for 10, the depositor's core trade secrets are effectively unprotected after year three.

In plain language: Allocates the trustee's setup, annual custody, verification, and release fees between the parties, and establishes which party indemnifies the trustee against third-party claims arising from the escrow administration.

Common mistake: Failing to address who bears the cost of a disputed release — including interpleader proceedings. When licensor and licensee each claim the other has triggered a release condition, trustee legal costs can exceed the annual escrow fee many times over.

In plain language: Specifies the jurisdiction whose law governs the agreement, the mechanism for resolving disputes (arbitration or litigation), and the conditions under which the agreement terminates — including upon expiry of the underlying license.

Common mistake: Not specifying what happens to the deposit materials on termination. If the agreement is silent, the trustee holds materials indefinitely — accruing fees — and neither party has a clear right to direct their destruction or return.

A source code trust agreement is a three-party legal contract among a software licensor (depositor), a licensee (beneficiary), and a neutral trustee that governs the deposit, custody, and conditional release of proprietary source code. The depositor places the source code with the trustee, who holds it securely and releases it to the beneficiary only if a defined trigger event occurs — such as the licensor becoming insolvent, ceasing operations, or failing to maintain the software. It is also commonly called a software escrow agreement or source code escrow agreement.

It is typically required when a licensee relies on a third-party software program for critical business operations and cannot afford a service interruption if the vendor becomes unavailable. Enterprise procurement policies, government contracting regulations, and financial services regulators in many jurisdictions mandate source code escrow for mission-critical licensed applications. It may also be required as a condition of large-scale licensing deals or SaaS platform agreements where business continuity depends on continued access to the underlying code.

The three parties are the depositor (the software licensor who owns and deposits the source code), the beneficiary (the licensee who has the right to receive the code if a release condition occurs), and the trustee (a neutral escrow agent who holds the deposit and administers the release process). The trustee's neutrality is essential — they act as a custodian only and do not adjudicate disputes between the other two parties.

At minimum: all source code files for the licensed program, build scripts and compilation instructions, third-party library references and license keys required to compile the software, API keys and encryption credentials needed for operation, and technical documentation sufficient for a competent software engineer to build and run the program independently. A deposit that omits build scripts, encryption keys, or dependency manifests is frequently uncompilable — and therefore worthless — when a release event occurs.

Common release triggers include the licensor filing for bankruptcy or insolvency, ceasing business operations without a successor, materially breaching the license agreement without curing the breach within a defined period, or failing to provide contracted maintenance and support. Release conditions should be specific and objectively verifiable by the trustee using documentary evidence alone — vague or subjective conditions lead to disputed releases and delays.

No. A source code trust agreement does not transfer ownership or intellectual property rights in the source code. Title remains with the depositor at all times. If a release condition occurs, the beneficiary receives only a limited, non-transferable license to use the released code to maintain or operate the licensed program for their own internal purposes. The beneficiary may not distribute, sublicense, or use the released code to develop competing products.

The deposit should be updated within 30 days of each new material release, version increment, or security patch issued to the beneficiary. An outdated deposit provides diminishing protection — a beneficiary trying to maintain a production system using source code that is several versions behind faces significant security and compatibility risks. The update obligation should be a defined contractual requirement with a specific deadline, not a best-efforts commitment.

Verification is a technical audit confirming that the deposited materials are complete, current, and sufficient to compile and operate the licensed program. Without verification, neither party knows whether the deposit is actually usable until a release event occurs — which is exactly the wrong time to discover it is incomplete. Most agreements allow the beneficiary to request verification once per year, with costs typically ranging from $1,500 to $5,000 depending on the complexity of the software and the scope of the test.

For straightforward domestic software licensing relationships, a well-drafted template reviewed by counsel is typically sufficient. Legal review is strongly recommended when the underlying license involves significant value, when the licensee is a regulated financial institution or government entity with specific escrow requirements, when international parties are involved, or when the deposit materials include open-source components with conflicting license terms. Attorney review for this document type typically costs $800–$2,500 depending on complexity.