How to sell source code to AI companies

Why AI labs want private codebases

AI labs are building coding agents, models that carry out programming work on their own (Sovereign Magazine). To train them, labs need more than finished code. They need to see how real engineers work: the bug report, the attempted fix, the reviewer’s pushback, the test that proves it worked.

The most cited benchmark for coding agents shows why. SWE-bench is built from 2,294 real GitHub issues and the pull requests that fixed them across 12 Python projects. An agent gets the issue and the codebase, writes a patch, and passes only if tests that failed before the original fix now pass (SWE-bench paper). Every linked issue, pull request and test in your repo is raw material for that kind of task.

Open-source projects have been mined heavily. Private code from real businesses, in languages and domains that rarely appear in public, is much harder to get. That’s why buyers now go to companies directly. Google has emailed Play Store developers inviting them into a “confidential content offer pilot” to license their code (404 Media).

What in your repo buyers actually value

A zip of today’s code is the least valuable version of your codebase. The history around it is what turns code into training tasks.

If your issues live in Jira or Linear rather than GitHub, keep the ticket keys in commit messages and PR titles. Those links let a buyer connect the problem to the fix.

Who buys source code

The buyer list changes month to month. Known routes, in no particular order:

• Big tech, directly. Google’s pilot asks for either the production codebase behind a live app or archives of prototypes and side projects. The license is non-exclusive and developers keep their IP (9to5Google, 404 Media).
• Data vendors that supply the labs. Turing is reported to be buying codebases from failed startups, paying tens of thousands of dollars, then cleaning, licensing or reselling the code for model training (Let’s Data Science). Mercor emailed the CEO of Warmly about buying or licensing its code base and task records eight days after Warmly agreed to be acquired (AI Weekly).
• Coding-data companies. Firms such as Proximal, which raised at a $300 million valuation selling coding data to labs (Sovereign Magazine), and Datacurve, which raised a $15 million Series A (Maginative), turn code into training data and tasks for coding agents.
• Wind-down marketplaces. SimpleClosure’s AssetHub lists codebases, repositories, documentation and tests for AI labs and other buyers to license or acquire (Business Wire). It reported about 100 data deals in a year at $10,000 to $100,000 per company (SimpleClosure).
• Licensing partners like Smelted. We package code from GitHub, GitLab or Bitbucket with secrets and identities removed, and you approve every buyer.

For the wider picture, including tickets, docs and chat, see how to sell your company’s data to AI companies.

What raises the price, and what lowers it

Buyers judge codebases on a few things:

• Years of continuous history. Squashed or re-imported history loses most of the story.
• Tests and CI. A test suite lets a buyer check whether a model’s fix works.
• Real code review. Substantive review threads show judgment, not just output.
• Less common languages and domains. Payments, healthcare, embedded systems or legacy stacks are scarcer than another web app.
• Size and variety. More services and contributors mean more kinds of problems solved.

Rarity can outweigh size. More than 350 companies have listed code and workspace data on SimpleClosure’s AssetHub (Upstarts Media), and its CEO put it this way:

Price drops when large parts of the repo aren’t yours, when history is missing, or when cleaning secrets and customer data out of it is a big job.

Open-source and third-party code in your repo

Almost every codebase contains code you didn’t write: vendored libraries, copied snippets, SDKs from vendors. Black Duck’s 2026 audit found open-source license conflicts in 68% of the codebases it reviewed, and links part of the rise to AI assistants generating code from copyleft sources without the license attached (Black Duck).

You can only license what you own. Before you package anything:

1. Run a software composition analysis (SCA) scan to list third-party code and its licenses.
2. Drop vendored dependency folders and generated files from the dataset.
3. Flag copyleft licenses such as GPL and AGPL, and code with no license at all, for a lawyer to review.
4. Pull out code you wrote for clients. Agency and consulting work often belongs to the client.
5. Check vendor and partner contracts for code shared under NDA.

Scan for secrets in every commit

Hardcoded credentials are common. GitGuardian counted 28.65 million new secrets added to public GitHub commits in 2025 alone, up 34% on the year before (The Hacker News).

Deleting a key from today’s code doesn’t remove it from history, and history is what buyers want. GitHub’s own guidance is to revoke or rotate a leaked secret first, then rewrite history if you still need to (GitHub Docs). For a sale, scan for more than keys:

• API keys, tokens, passwords and private certificates
• Customer data in fixtures, seed files, logs and test snapshots
• Author names and emails in commit metadata and review comments
• Internal hostnames, IP addresses and infrastructure details

Rotate anything that was ever live, whether or not you sell. Then clean the copy you’ll share, never your working repo.

Make sure you own the code

Paying someone to write code doesn’t always mean you own it. Under US copyright law, work by an independent contractor counts as “work made for hire” only if it fits one of nine listed categories and both sides signed a written agreement saying so (U.S. Copyright Office). Otherwise you usually need a signed assignment. Check:

• Every employee signed an invention or IP assignment agreement.
• Every contractor and agency agreement assigns IP to the company in writing.
• Founders assigned code they wrote before the company existed.
• No investor, lender or acquirer already holds rights to the code.

Rules differ by country, so have a lawyer review the gaps. If your company is being acquired, as Warmly was, the acquirer may need to approve or run any sale.

License a copy or sell the IP outright?

You can grant a buyer a license or sell the code itself. They are very different deals.

If you still run the product, a non-exclusive license is usually the safer choice. You keep shipping, and you can license the same history to more than one buyer. An outright sale can make sense when you’re closing down, but it’s hard to reverse, and it may need investor or board approval. Either way, models trained on your code stay trained after the deal ends, so agree on permitted uses, resale rights and deletion of the raw copy before you sign.

A pre-sale checklist

1. Inventory. List repos, languages, years of history, and where issues and reviews live.
2. Ownership. Confirm IP assignments for everyone who committed code.
3. Third-party code. Run an SCA scan and remove what isn’t yours.
4. Secrets and personal data. Rotate live credentials, then scrub every commit in the copy you’ll share.
5. Scope. Pick the repos and date ranges, and leave out client work and anything sensitive.
6. Deal type. Decide on a license or a sale, and which buyers you’ll rule out.

With Smelted, there’s no upfront fee, buyers see redacted previews only, and you’re paid in as little as 7 days after you sign. Our 60-second estimate gives you a range for your code.

Questions founders ask