Data license vs software license: why licensing code for AI training is different

How do the four license types compare?#

The four license types differ in what they grant, which use they permit, how long they last and how they treat what the licensee produces. A EULA lets a customer run your software; an AI training license lets a developer learn from your code.

The last row is the one most teams have never negotiated. It looks like a software license on paper but behaves like a data license, which changes which clauses matter.

What does an AI training license actually grant?#

An AI training license grants the developer the right to copy, process and learn from the licensed material for a defined purpose, usually model training, fine-tuning or evaluation. It does not give the right to ship your code as a product, publish it or sublicense it to others.

Deletion at term end usually applies to the licensed material and working copies, while models trained during the term often survive. Agree on that point explicitly, because it is the clause most likely to be misunderstood later.

• 1Field of use: which kinds of models or products the material may be used for.
• 2Copies and derived datasets: which processing copies the licensee may make, and where they may be stored.
• 3Restrictions: no redistribution, no deployment of the code as software, no attempts to identify people in the data.
• 4Term and deletion: when the license ends and what must be deleted, separating raw data from trained models.
• 5Outputs: whether the licensee must take steps against models reproducing licensed code verbatim.
• 6Confidentiality and audit: how the licensee protects the material and how compliance can be checked.

Why is ownership the first question?#

Ownership is the first question because you can license only what you own or have the right to sublicense. A software company's repository usually mixes code written by employees, contractors, acquired teams and outside projects, and each source has a different chain of title.

Gaps can often be closed with confirmatory assignments or by excluding affected folders. This is general information, not legal advice; counsel should review the chain of title before any grant.

What must be removed from code before licensing?#

Secrets, customer data and personal details must be removed from the full commit history before code is licensed, not only from the latest version. A key deleted from the main branch years ago still sits in older commits.

Scanners help, and their status matters. Gitleaks, an MIT-licensed tool, detects passwords, API keys and tokens in git repositories; its README was updated in May 2026 to say it is feature complete and future releases will be security patches only. TruffleHog, an AGPL-3.0 scanner, also covers chats, wikis and logs and can test whether a secret it classifies is live, which calls for care when scanning.

Beyond secrets, check fixtures, seed files and test data for copies of customer records, commit metadata for personal emails, and comments for internal hostnames or customer names. Rotate any credential found, even one that appears expired.

Should a code training license be exclusive?#

A code training license is usually non-exclusive, and exclusivity should require a specific reason. Non-exclusive terms let you license the same history to other developers, reuse it yourself and publish parts later if you choose.

When a licensee insists, exclusivity can be narrowed to a field of use, a time period or a type of model rather than all uses. Any exclusivity will surface in diligence if the company is sold, so record it clearly and keep the clause short.

Who needs to approve a code license?#

A code license usually needs approval from the CEO and an authorized signer, and sometimes from the board, investors or lenders. Investor agreements may require consent for licensing material IP outside the ordinary course, and credit agreements may treat IP as collateral.

Check these before a term sheet is discussed, not after. A consent requirement found late can delay signing or force changes to scope.

• 1Board: whether the license falls outside the ordinary course of business.
• 2Investors: protective provisions covering IP transfers or exclusive licenses.
• 3Lenders: security interests in IP and covenants on asset dispositions.
• 4Customers: development agreements that give them rights in specific modules.

Illustrative: a restaurant point-of-sale software company#

Illustrative: a fictional software company builds point-of-sale and kitchen display software for restaurants. Before a proposed AI training license, its CTO reviews the repository and finds code from an early agency, a vendored payment terminal SDK and test fixtures containing real menu and order data from a pilot customer.

Counsel obtains a confirmatory assignment from the agency. The payment terminal SDK is excluded because it belongs to the hardware vendor, and the fixtures are replaced with synthetic data. The team scans the full history, rotates the old keys it finds and pseudonymizes commit authors.

The final grant is non-exclusive, limited to training and evaluating coding models, prohibits redistribution and requires deletion of the licensed material at term end. It also preserves the company's right to publish parts of the code later.

How SourceX structures code licenses#

SourceX structures code licenses as data licenses: licensed, not sold, with the company keeping ownership. In the Rights step of the SourceX five-step transaction, ownership, third-party code and customer material are reviewed before anything is prepared for delivery.

The SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for the package. Large repositories stay in the company's own storage or ship on encrypted drives.