Source code escrow at shutdown: release triggers and AI licensing conflicts

What happens to source code escrow when a software company shuts down?#

Source code escrow usually comes into play at shutdown, because closing a software company can satisfy one or more release conditions in its escrow agreements. A beneficiary, typically an enterprise customer running on-premises or business-critical software, asks the escrow agent to release the deposit, and the agent follows the release procedure the agreement sets.

A release does not transfer ownership. The company, or whoever controls its assets after the shutdown, still owns the code. What changes is that customers may now hold a copy of the deposit and a license to use it, which matters the moment anyone proposes licensing the same code to an AI developer.

Escrow therefore belongs at the top of the rights review for any closing company that holds source code. Granting an AI training license first and reading the escrow file later is how disputes start.

Which release triggers can a shutdown set off?#

Release triggers vary by agreement, but most escrow contracts list a familiar set of conditions, and a wind-down can satisfy several of them at once. Read the wording closely: some conditions fire on a filing, others only after written notice and a missed cure period.

Multi-beneficiary agreements, where many customers enroll against one master deposit, often differ from single-beneficiary agreements negotiated by large customers. Pull every agreement, amendment and enrollment form rather than relying on a note in the CRM.

What does a beneficiary receive when the deposit is released?#

A released beneficiary receives a copy of the deposit materials and a license to use them, usually limited to supporting and maintaining its own licensed use of the product. Deposits commonly include source code, build instructions and documentation, and sometimes the scripts and environment details needed to compile and deploy.

The release license rarely lets a beneficiary resell, sublicense or commercialize the code, and confidentiality obligations usually continue. In most agreements the beneficiary cannot license the code to an AI developer itself, and the escrow agent, acting as a custodian, holds no license rights at all.

Where escrow and an AI training license collide#

Escrow and an AI training license collide less through the escrow agreement itself than through the promises around it: exclusivity, confidentiality, customer ownership and signing authority. The table lists the conflicts counsel most often needs to clear first.

A workable decision rule: if any release condition has fired, may fire before signing, or is in dispute, settle the beneficiaries' position first and treat the AI license as a later, separate decision.

Bankruptcy, ABCs and asset sales: who gets to decide?#

Authority to license code from a closing company depends on how the company is closing. Before any formal proceeding, the board and the officers it authorizes usually decide. After a bankruptcy filing, the debtor in possession or a trustee controls the estate's assets, and a license outside the ordinary course of business may need court approval.

US bankruptcy law includes protections for licensees of intellectual property, and many escrow agreements are drafted with them in mind so beneficiaries can keep their rights even if the debtor rejects the underlying license. How they apply in a given case is a question for bankruptcy counsel.

In an assignment for the benefit of creditors, the assignee controls the assets and decides how to realize their value. In an asset sale, the buyer will expect clean representations about ownership and existing licenses; a recent AI training license must be disclosed, can reduce what the buyer will pay and may be barred by the sale agreement. Plan the two transactions together.

Checklist before licensing code from a closing company#

A pre-license escrow checklist keeps the rights review concrete and gives counsel one file to work from. Run it while the CTO, the head of customer success and whoever managed escrow renewals are still on staff.

Do not use the escrow deposit as the source of an AI license package. The deposit sits with the agent for the beneficiaries, is often older than the live repositories, and lacks the issues, pull request reviews and commit discussion that give engineering records their value.

• 1Collect every escrow agreement, amendment, beneficiary enrollment and deposit receipt, including SaaS continuity arrangements.
• 2Match each agreement to the license or support agreement it serves, and note the release conditions, the release license grant and any confidentiality or exclusivity terms.
• 3Log every release request, agent notice and objection received so far, with its current status.
• 4Compare the last deposit with the current repositories and flag customer-specific modules, configurations and data.
• 5Confirm ownership: employee and contractor IP assignments, customer-owned work, vendored libraries and open source licenses.
• 6Scan code and git history for secrets and personal data, and rotate any credentials that are still live.
• 7Keep escrow fees paid and deposits current until counsel decides otherwise, since in some agreements a lapse is itself a release condition.
• 8Name who can sign for the company now: the board, a trustee, an assignee or, where required, the court.

Illustrative: a fleet maintenance software vendor works through its escrow file#

Illustrative: a fictional vendor of on-premises fleet maintenance software decides to wind down after losing its main reseller. Three enterprise customers hold single-beneficiary escrow agreements, and one of them funded a parts-forecasting module under a statement of work that assigned ownership of that module to the customer.

Ceasing business in the ordinary course is a release condition in all three agreements. Counsel confirms the triggers, the company cooperates with the agent, and two customers receive the deposit under licenses limited to maintaining their own installations. The third migrates to another product.

Only then does the board consider an AI training license. The package excludes the customer-owned module by repository path, drops two vendored libraries with unclear terms, and covers the core platform code with its Jira issues and GitHub pull request reviews. The license is non-exclusive, the buyer is told that two former customers hold maintenance-only copies, and the company avoids a claim from the customer that owns the forecasting module.

How SourceX handles code with an escrow history#

SourceX handles an escrow history as part of the rights review rather than as a disqualifier. The initial fit check collects metadata only, such as repositories, years of history and whether escrow agreements exist, so nothing is shared while release questions are open.

If a package proceeds, the Rights step of the SourceX five-step transaction reviews the escrow agreements, release notices and the license agreements they reference, and customer-owned modules are carved out before Preparation. Because the SourceX Enterprise Data Value Framework treats exclusivity as a driver of price, released copies are recorded plainly. The SourceX Evidence Packet then documents provenance, licensing rights, permitted use, the privacy record and release authorization, meaning the supplier's sign-off to deliver, which is separate from any escrow release.