Selling Source Code to AI Companies: What to Know First

What a buyer is really after

AI developers rarely want your code in order to run your product. They want it as an example of how software is built in practice: how features are planned, how changes are made, how bugs are fixed and how quality is checked. That is why the context around the code, including commit history, issues, PRDs, reviews, tests and release records, often matters as much as the code itself.

Understanding this changes how you think about risk. The buyer is typically not looking to compete with you or rebuild your product. Even so, you should not rely on assumptions; the permitted uses should be written into the contract.

It also means the most commercially sensitive part of your business may not be the most useful part for training. A routine internal tool with years of careful maintenance, good tests and detailed reviews can be more instructive than your flagship product, and far less risky to share.

Check ownership carefully

The first question is whether you actually own the code. Many companies have a mix of material in their repositories, and each type needs a different answer.

• Code written by employees: usually owned by the company, but check employment agreements, especially for founders and early staff
• Code written by contractors or freelancers: ownership depends on the contract; without a written assignment, it may not have transferred
• Code built for clients: often assigned to the client under services agreements and therefore not yours to sell
• Open-source dependencies: remain under their own licences and are usually excluded or flagged
• Code acquired from another company: depends on the terms of the acquisition

Clean up secrets and sensitive content

Private repositories often contain things that should never leave the company: API keys, database passwords, cloud credentials, customer names in test fixtures, internal hostnames, or production data pasted into a bug report. These can sit deep in commit history even after they were removed from the current version of the code.

Part of preparing code for transfer is detecting and removing or replacing this material. Momentra uses purpose-built tools for this as part of professional anonymization before further use. Independently of any deal, it is good security practice to rotate any credential that has ever been committed to a repository.

Think through competitive risk

A reasonable concern is whether selling code could help a competitor or expose trade secrets. There are practical ways to manage this. You can exclude your most sensitive modules, such as proprietary algorithms or pricing logic, while including the broader engineering history. You can choose older projects, retired products or code from a business line you no longer run. And you can define permitted use narrowly in the agreement.

Companies that have shut down a product or are winding down often find that a codebase with no remaining commercial use still has value as training data, because the engineering history is what matters.

What the agreement should spell out

Because code is both valuable and sensitive, the written terms matter. The NDA signed before any sample is reviewed should limit the sample to evaluation, set a retention period and require deletion if discussions end. The final contract should go further and describe exactly what is being transferred and what the recipient may do with it.

Read these terms with a lawyer who understands software and intellectual property. Pay particular attention to the warranties you are asked to give about ownership, because they are only as reliable as your own records of who wrote what.

• A precise list of the repositories, branches and time periods in scope
• Permitted uses, such as training and evaluating AI models, and prohibited uses
• Whether the arrangement is exclusive, and for how long
• How secrets and personal information are handled during de-identification
• How the code is transferred, stored and secured
• What happens to the data if the agreement ends

Licence or sell outright?

Source code can be shared under different models. A licence grants defined rights to use the code for specified purposes while you keep ownership. A purchase transfers more rights, sometimes including exclusivity. A custom project partnership might involve preparing, annotating or extending the code for a particular purpose.

Each model trades off control, exclusivity and effort differently. The choice should be based on what you want: ongoing control, a clean one-time transaction, or a deeper collaboration.

The process, step by step

At Momentra, the process starts without any code changing hands. You share contact details, company, industry and interests. An initial value assessment then covers the type of code, how complete its history is, how scarce it is and what tasks it could support, such as training coding agents.

If it makes sense to continue, an NDA defines confidentiality, permitted use, retention and security before any sample is reviewed. Momentra then provides a purchase proposal and contract that govern scope, permitted use, transfer and processing. After signing, Momentra supports de-identification and secure transfer. You decide what is in scope at every stage.

• List the repositories you are considering and who wrote them
• Flag any client-owned or third-party code
• Note where issues, PRDs and reviews are stored
• Decide which modules, if any, must stay out of scope