License-back terms after a software carve-out, including AI training rights

What a license-back does in a software carve-out#

A license-back in a software carve-out gives the seller continued rights to code or other IP it has just assigned to the buyer, typically because retained products still depend on it. The mirror image, a license forward, gives the buyer rights to IP the seller keeps, such as a shared authentication library.

Both are usually documented in an IP matters agreement or as exhibits to the purchase agreement, and both are negotiated alongside the transition services agreement. The general counsel's job is to make sure each license matches how the code will actually be used after closing, by whom and for how long.

The license-back term checklist#

The license-back term checklist below covers the clauses that carry most of the negotiation risk. Work through it with the CTO, because engineering facts, such as which products import a module, decide what a reasonable field of use looks like.

Why AI training rights need their own clause#

AI training rights need their own clause because the usual grant language was not written with model training in mind. A license to use, copy, modify and create derivative works for internal business purposes may or may not stretch to training a coding model, and the answer can differ for an internal tool, a commercial product or a dataset licensed to a third party.

The market treats training use as something that can be licensed. On May 9, 2025, the US Copyright Office released a pre-publication version of Part 3 of its Copyright and Artificial Intelligence report, covering generative AI training, fair use questions and the licensing of copyrighted works for training. The report recommends letting voluntary licensing markets for AI training continue to develop without government intervention.

For a general counsel, the practical point is simple: if training use matters to either party, write it down. Ambiguity is cheap at signing and expensive when one side later licenses engineering records or ships an AI feature trained on shared code.

A sample AI training permitted-use clause to discuss with counsel#

The sample below is a starting point for discussion, not recommended wording, and it will need adapting to the definitions in your agreement. Sample language: Licensee may use the Licensed Code, and the commit history, code review comments and issue records delivered with it, to train, fine-tune and evaluate machine learning models solely for Licensee's internal use within the Field. Licensee shall not provide the Licensed Code or those records to any third party for training, fine-tuning or evaluating machine learning models, or include them in any dataset made available to a third party, without Licensor's prior written consent.

Each element of that sample is a choice the parties can make differently. The list below sets out the choices worth discussing explicitly.

• 1Internal models only, or also models embedded in products sold to customers.
• 2Training and fine-tuning, or evaluation and testing only.
• 3Whether the records delivered with the code, not just the code, are covered.
• 4Whether either party may include the code in datasets licensed to AI developers.
• 5Whether models trained during the license may be kept after it ends.
• 6Deletion or certification duties if the license terminates.
• 7Restrictions on outputs that reproduce substantial portions of the licensed code.

Records that travel with the code#

Records that travel with the code, such as Git history, pull request reviews, Jira issues and design documents, are often more useful to AI developers than the code alone, because they show how engineers reasoned and fixed problems. Purchase agreements frequently describe the code precisely and leave these records undefined.

Name them. Decide which records the buyer receives, which the seller keeps, whether the seller may keep a copy of records about assigned code, and whether either party may license its retained engineering records to third parties. If the seller plans to license its own engineering history later, it will want code excerpts from assigned modules handled by a clear rule rather than by case-by-case negotiation.

Customer data inside those records raises separate questions. Issues and support tickets often contain customer names, screenshots and pasted content, and the customer contracts, not the license-back, govern that material.

Drafting mistakes that cause disputes later#

The drafting mistakes that cause disputes later are usually omissions rather than bad clauses. Each one below has a simple fix at signing.

• 1A field of use defined by product names that change after closing; define it by function as well.
• 2Perpetual licenses that can still be terminated for any breach; specify which breaches qualify.
• 3No change-of-control rule, so a sale to a competitor of the other party becomes a fight.
• 4Sublicensing rights that forget contractors, offshore development partners and cloud hosts.
• 5Silence on security fixes in shared modules after the forks diverge.
• 6No mention of AI training, evaluation or dataset licensing.

Illustrative: a connector library and an AI clause#

Illustrative: a fictional fleet maintenance software company sells its fuel card reconciliation product line. A bank feed connector library was built for that product, so ownership moves to the buyer and the seller receives a perpetual, royalty-free license back, because the retained maintenance product also imports it.

The buyer asks to bar the seller from any AI use of the connector code. The seller wants its internal coding assistant to keep learning from its own repositories. The parties agree that the seller may use the connector code to train and evaluate internal models, may not include it in any dataset provided to third parties without consent, and keeps full rights in its own engineering records for retained products.

When the seller later explores licensing its engineering history, the rights review applies the clause directly: connector code paths and their review threads are excluded, and the rest of the history proceeds to preparation.

How SourceX reads a license-back in a rights review#

SourceX reads a license-back during Rights, the second stage of the SourceX five-step transaction, alongside the purchase agreement, customer contracts and vendor terms. The question is narrow: which records the supplier may license, for which permitted uses, and what must be excluded because it belongs to, or is restricted by, the other party to the carve-out.

The result is recorded in the SourceX Evidence Packet under licensing rights and permitted use, next to provenance, the privacy record and release authorization. Records are licensed, not sold, so the supplier keeps ownership and approves every step.