Does source code escrow affect licensing your code for AI training?

Does escrow restrict an AI training license?#

Source code escrow usually does not restrict an AI training license for a company that is still operating and supporting its product. Escrow is a three-party arrangement: the vendor deposits code and build materials with an escrow agent, and a customer, the beneficiary, can obtain a copy only if agreed release conditions occur, such as the vendor ceasing to support the product.

Nothing in that structure transfers ownership, and nothing makes the code exclusive to the beneficiary. The vendor already licenses the same software to many customers, and an AI training license adds another non-exclusive grant of a different kind. The real questions sit in the drafting of specific clauses, which is why general counsel should read them rather than assume.

The three clauses to read#

Three clauses decide whether escrow touches an AI license: release conditions, the beneficiary's rights on release, and promises in the customer agreement that travel alongside escrow. Most escrow packages put the first two in the escrow agreement and the third in the master license or SaaS agreement, so pull both documents for every beneficiary.

The table shows where each clause lives, the question to ask, and when it usually needs counsel. A clean answer on all three for every beneficiary is the normal outcome; the exceptions come from negotiated deals with large customers.

Use rights on release are usually narrow: the beneficiary may use, modify and compile the released code to support its own installation, often under the same confidentiality duties as the original license. That right coexists with any other license the vendor grants. Look harder only where a release grants rights to commercialize, sublicense or exclusively control the code, which is unusual and typically appears only in heavily negotiated deals.

Release conditions: the loose wording to look for#

Release conditions are the clause most likely to cause confusion, because some are drafted around events that sound like licensing. Standard triggers such as bankruptcy, ceasing business or failing to support the product have nothing to do with an AI license. Problems arise with phrases like "transfer of the source code to a third party" or "disposal of the software" that are not defined.

A non-exclusive data license is not an assignment or sale of the code, but a beneficiary looking for leverage might argue otherwise if the wording is vague. Where the language is loose, counsel can confirm the reading in writing, and the license itself can state that no ownership or exclusive right passes to the licensee.

Customer-specific code inside the deposit#

Customer-specific code is the more common escrow complication, and it has little to do with escrow itself. Large customers sometimes fund modules, integrations or reports, and their agreements may give them ownership or exclusive rights to that work. Those modules often end up in the same repositories and therefore in the escrow deposit.

Use the deposit inventory as a starting map. Escrow agents typically ask for a description of what was deposited, and verification reports, where a customer paid for them, describe repositories, build steps and third-party components. That inventory helps the team list what to exclude before an AI license is scoped.

• 1Modules or integrations funded by a named customer under a work-for-hire or assignment clause.
• 2Customer data, fixtures or configuration files copied into the repository for testing.
• 3Third-party or open-source components whose licenses need separate review.
• 4Credentials, keys and tokens committed to history, which a secrets scanner such as Gitleaks can detect in git repositories (its maintainer has said it is now feature complete, with security patches only).
• 5Contractor-written code where the IP assignment is missing or unsigned.

Illustrative: an ERP vendor for precast concrete plants#

Illustrative: a fictional software company sells ERP software to precast concrete manufacturers and keeps escrow agreements with several of its largest customers. When it began scoping a license of its GitHub history, code reviews and Jira issues to an AI developer, its general counsel pulled every escrow agreement and the matching master agreements.

The release conditions were standard and did not mention transfers or licensing. One master agreement promised that the vendor would not license the software to the customer's direct competitors, which an AI developer is not, and counsel confirmed that reading in a short memo. Another customer had funded and owned a yard-scheduling module that lived in the main repository.

The company excluded the funded module's directories and history, ran a secrets scan across the remaining repositories, and kept its escrow deposits on their normal update schedule. The license stated that it granted no ownership or exclusive rights in the code.

Checklist before signing a code license with escrow in place#

A short checklist keeps escrow from becoming a late-stage surprise in diligence. Run it once across every beneficiary, record the answers in the rights file, and repeat it when a new escrow agreement is signed.

How SourceX handles code with escrow arrangements#

Escrow agreements go into the same rights file as customer contracts during Rights, the second stage of the SourceX five-step transaction, and that review finishes before a single repository is prepared. Excluded modules, open-source findings and the escrow position are written into the SourceX Evidence Packet under licensing rights and permitted use, so the buyer sees what was reviewed and the supplier approves the final scope.

Large repositories stay in the supplier's own storage or ship on encrypted drives; SourceX does not host multi-terabyte codebases. Escrow at shutdown raises different questions, because release conditions may actually fire, and that case is covered separately.