A source code purchase agreement is the written contract that moves ownership of your code from you to the buyer. It names who is selling and buying, lists exactly what is included, assigns your rights in the code, records the promises you make about ownership and originality, sets out the cleaning you do before handover, and fixes the price and when it is paid. Nothing should change hands until it is signed by both sides.
This is general information, not legal advice. Contracts, ownership and data protection depend on your country and situation; have a qualified lawyer review any agreement before you sign.
Why does selling code need a written agreement at all?
Because in many countries a transfer of copyright does not work without one. In the US, a transfer of copyright ownership is not valid unless an instrument of conveyance is in writing and signed by the owner or their authorized agent. In the UK, an assignment of copyright is not effective unless it is in writing and signed by or on behalf of the seller.
A written agreement also protects you. It records the price, the moment of payment and what the buyer may and may not do with your name. A buyer who asks for code before there is a signed document is skipping the step that protects the seller, which is one of the red flags when someone offers to buy your code.
What are the main parts of the agreement?
Most agreements for code follow the same outline, even if the headings differ. Some are drafted as an asset purchase agreement limited to the code and related materials.
| Section | What it says | What to check |
|---|---|---|
| Parties | Who sells and who buys | The seller is the actual owner, or someone who can sign for it |
| Definitions and schedule | Exactly which repositories and files are included | Every repository, plus history, docs, tests and tickets as agreed |
| Exclusions | What is not part of the sale | Databases, user records, customer data, chat logs, third-party code |
| Assignment | Transfer of your rights in the code | Covers what your team wrote, nothing you do not own |
| Warranties | Your promises about ownership, originality and cleaning | Only confirm what you know; disclose gaps |
| Cleaning | Removal of secrets, keys and personal data before transfer | Who does what, and that the buyer helps |
| Transfer | How the code is handed over | A method you are comfortable with; no software to install |
| Price and payment | One cash price and when it is paid | Paid on transfer, no conditions tied to later performance |
| Use and confidentiality | How the buyer uses the code and your name | No use of your brand or name; sale kept confidential |
What does the assignment of rights cover?
The assignment is the clause that actually transfers your copyright and related rights in the code. It should be tied to the schedule, so there is no doubt which code is meant.
You can only assign what you own. If an employee wrote the code as part of their job, the company usually owns it; if a contractor wrote part of it, the company may need a separate signed IP assignment from that contractor first. Our guide on who owns the code explains the usual gaps. Fix them before signing, not after.
What is included, and what is left out?
The schedule should be specific. A typical list: named repositories with full git history (all branches and tags), exported pull requests and review comments (they live on the host, not in git), documentation, the test suite, ticket exports, design files and runbooks.
The exclusions matter as much. When you sell to Odys AI Labs, databases, user records, customer data and chat logs are never part of the deal. Third-party code, such as open-source libraries, is described rather than sold: it stays under its own license, which travels with it, and license notices stay in place. Our guide on open source inside your codebase explains why this is normal and does not stop a sale.
What promises (warranties) will you make?
A warranty is a promise that a stated fact is true. In a code sale, the common ones are:
- Ownership. You own the rights being sold, or are authorized to sign for the owner.
- Originality. The code described as yours was written by your own team, not copied from client work or another product.
- No conflicting deals. You have not already sold or exclusively licensed the same code to someone else.
- Cleaning. Secrets, keys and personal data have been removed as agreed.
- Disclosure. Anything you know that affects the above has been disclosed.
The safest approach is honesty over polish. If a contractor’s module lacks an assignment, say so and agree how to handle it. A gap that is written down can be dealt with; a gap that surfaces later is what creates claims.
What cleaning obligations come before transfer?
The agreement usually says that before handover you will remove secrets (passwords, API keys, tokens, private keys) from the files and the history, and remove personal data from fixtures, seed files, logs and exports. With us, we help you do it. Our guide on how to prepare a codebase for sale covers the steps, including rotating keys first and scrubbing history with git-filter-repo.
How are transfer and payment described?
The transfer clause names the method, such as moving a GitHub repository to the buyer’s account or handing over a git bundle, and what counts as complete delivery. It should never require you to install or run software on your computer.
The payment clause sets the price and when it is paid. With Odys AI Labs, that means cash, one agreed price, paid on transfer. There are no earn-outs and no royalties. Compare that with a license, where payment is usually for use over time; our comparison of selling code outright vs licensing it explains the difference. The price and its timing also matter for tax, which our guide to taxes when you sell source code covers by country.
What else sits in the closing clauses?
The last pages are easy to skim, but they decide what happens if something goes wrong. Look for:
- Limits on your liability. A cap on how much the buyer can claim under the warranties, and a time limit for bringing claims.
- Governing law. Which country’s law applies and where disputes are heard.
- Moral rights. In the UK and many EU countries, authors have personal rights such as being named; agreements often include a waiver so the code can be used without attribution.
- Further assurance. A promise to sign any extra paperwork needed to complete the transfer, such as a short confirmation for a registry.
If any of these are missing or one-sided, raise it with your lawyer before signing.
What does the agreement say about your name and the code’s future use?
Read this section carefully. With us, it states that Odys AI Labs uses the code for AI training and R&D, and that we may also work on it with research partners. It also states that we never use your brand or name, never relaunch the product as yours, and keep the sale confidential.
If an agreement from any buyer is vague about use, or leaves room for the product to reappear under your old brand, ask for it to be made specific before you sign.
Who needs to sign?
The owner, or someone with authority to sign for it. For a solo founder, that is you. For a company, it is usually a director authorized to bind the company, and investors or co-founders may need to approve. For a dissolved company, an insolvency or an estate, authority may sit with a liquidator, administrator or executor; our guide on selling code when the company is dissolved or in liquidation explains who that is. Again, this is not legal advice: confirm authority with a qualified lawyer.
What to do next
- Gather the ownership documents: employment contracts, contractor agreements and any assignments.
- Write the list of what you would include and what stays with you.
- When you are ready, send us a few details for a free code valuation, and ask for the agreement early so your lawyer has time to read it.
Frequently asked questions
Do I need a lawyer to sign a source code purchase agreement?
It is strongly recommended. The agreement transfers rights and contains promises you make about ownership and originality, so a qualified lawyer should read it, especially if the code belongs to a company, a dissolved company, an estate or a business in insolvency. A lawyer can also check that the description of what is sold matches what you actually own.
What is a warranty in a code sale?
A warranty is a promise in the agreement that a stated fact is true, such as that you own the code, that your team wrote it, or that secrets and personal data have been removed. If a warranty turns out to be false, the buyer may have a claim. That is why you should only confirm what you know, and disclose any gaps openly.
Can I keep using my code after selling it?
Usually not, unless the agreement says so. A sale typically transfers the rights in the code your team wrote, so keeping a working copy or reusing parts would need to be agreed in writing. If you want to keep something, raise it before signing so it can be written in, rather than assuming it is allowed.
Does the agreement cover open-source libraries in my code?
It should describe them, not transfer them. You can only sell rights you hold, which means the code your team wrote. Third-party libraries stay under their own licenses, which travel with the code. A good agreement says so plainly, and you should never remove license notices to make the code look more original.
Find out what your old code is worth right now.
Tell us about the product in about a minute. No code needed. We review the details and come back with a cash offer or a plain no.
Get my free code valuation →