Selling source code and private repositories for AI training

Coding is one of the main things AI models are trained to do, and public code is already well used. The Stack, an open dataset built for training code models, collected 3.1 TB of permissively licensed source code in 30 programming languages from public repositories (Kocetkov et al., arXiv, November 2022). What public code mostly lacks is the inside of real businesses: private codebases, built over years, with the tickets, reviews and test results that show how the work was actually done.

That is why private repositories have joined tickets, SOPs and project history on buyers' lists. One AI data program even asked contractors to upload code and other work files from their past jobs (TechCrunch, reporting on Wired, January 10, 2026). A company that owns its code can do this properly, on its own terms, and get paid for it.

Why buyers want private repositories

A finished codebase shows what was built. Its history shows how. The researchers behind SWE-bench, a widely used test of AI coding ability, built it from 2,294 real GitHub issues paired with the pull requests that fixed them across 12 Python projects (Jimenez et al., arXiv, October 2023). That pairing (a problem, the change that solved it and the tests that prove it) is exactly what a well-kept private repository holds, many times over, in domains public projects rarely cover.

What makes a repository valuable

What lowers the value

• Little original work. Forks of open-source projects, boilerplate and starter templates add little that public code doesn't already have.
• Generated or vendored files. Minified bundles, lock files, generated clients and copied dependencies are noise to a buyer and a license problem for you.
• No history. A single export of the current code, without commits, issues or reviews, is worth far less than the same code with its history.
• Code you don't own. Anything built for clients under contracts that give them the rights has to stay out.

Check that the code is yours to license

This is the step that decides whether there is a deal at all. Before you scope anything, work through these with your lawyer:

• Employees and contractors. Employee work usually belongs to the company under the employment agreement. Contractor code depends on each contract, so check that the IP assignment clauses actually cover it.
• Client work. Agencies and consultancies often assign ownership of deliverables to the client. Code written under a statement of work may not be yours to license, even if it sits in your repositories.
• Open-source and third-party code. Vendored libraries, copied snippets and licensed SDKs keep their own licenses. Exclude third-party directories and list what remains.
• Customer data in the code. Test fixtures, seed files, logs and database dumps committed by mistake can hold real customer records. They are covered by your customer contracts and privacy law, not just by your ownership of the code.
• Security-sensitive systems. Authentication, payment handling and infrastructure code can reveal how to attack you. Many companies leave those modules out of scope entirely.

What to remove before anyone sees it

Secrets are the first problem. A scan of customers' private repositories by GitGuardian found at least one plaintext secret in 35% of them, and found private repositories far more likely to contain secrets than public ones (GitGuardian, 2025). Teams are less careful in private code because they assume no one else will read it.

1. Scan the full history, not just the current code. A key deleted three years ago is still in the commit that added it. Rewrite the history or leave the affected commits out.
2. Rotate anything you find. Treat every secret found in a repository as exposed, whether or not it ends up in the delivery.
3. Strip personal data from the metadata. Commit authors' names and email addresses, and names in comments and review threads, need the same treatment as names in tickets.
4. Remove customer names and data. Check config files, fixtures, comments and feature flags named after clients.
5. Remove internal infrastructure details. Hostnames, IP addresses, internal URLs and cloud account IDs.
6. Deliver a cleaned export. Build a separate copy of each repository from the cleaned history and review samples before it leaves. Never give a buyer access to your source control.

Our guide to anonymizing company data covers the review process in more detail, and it applies to code threads as much as to tickets.

Terms that matter for code

A code license needs everything in a normal data licensing agreement, plus a few terms of its own:

• Training and evaluation only. No right to run, deploy, distribute, sell or build on your software. The buyer gets examples to learn from, not a product.
• No reproduction in outputs. The buyer should take steps so its models don't reproduce your code verbatim, and must not identify your company as the source.
• Scope by repository and date range. List exactly which repositories, branches and years are licensed. Anything unlisted stays out.
• Third-party code excluded. State that third-party and open-source components are not licensed by you.
• Confidentiality and deletion. The export is your confidential information, stored securely and deleted at the end of the term, with written confirmation.

What code is worth

There's no public price list for private code, and offers depend heavily on the domain, the size and quality of the history, and whether the buyer already has similar material. The same factors that price other records apply: complete tasks with recorded outcomes, years of history, specialized work and the right to repeat the license with other buyers. See what company data is worth for the deals that have been reported, and data valuation for how to set your own floor before an offer arrives.

If your company is closing

A closing company's codebase is often its most complete record, and it can be licensed alongside chat, email and ticket archives. Sort out the order of events first. If the IP is being sold to an acquirer or assigned to a lender, a training license has to be agreed before that happens or with the new owner's consent, and the license should say what happens to it if the IP changes hands.

Common questions

Can we sell our source code to AI companies?

Often, yes, if the code belongs to your company. Buyers want private repositories with their history of commits, issues and reviews. You license the code for training rather than selling the product, so you keep ownership and the buyer gets no right to run or ship your software.

Can developers sell code they wrote at a previous job?

Usually not. Code written for an employer normally belongs to the employer under the employment agreement, and it is often confidential. When an AI data program asked contractors to upload work from past jobs, an IP lawyer quoted on it called the approach risky for exactly this reason.

Do we have to give the buyer access to our GitHub organization?

No, and you shouldn't. Deliver a cleaned export of the repositories in scope. Never hand over credentials or add a buyer to your organization, because that exposes everything else in it.

Is open-source code in our repositories a problem?

It needs handling, not panic. Vendored dependencies and copied open-source files come with their own licenses, and you can't grant rights you don't have. Most deals exclude third-party directories and list what remains, so the buyer knows which parts are yours.

Is licensing code for training the same as selling the IP?

No. A training license gives the buyer limited rights to use the code to train and evaluate models. Selling the IP transfers ownership, as in an acquisition or an asset sale. If a closing company plans to sell its IP, it should settle any training license first, because the buyer of the IP will inherit or block it.