You can license the code your company wrote and owns. Open-source dependencies, vendored libraries and copied snippets keep their authors' licenses, so they stay out of any grant you make. Strip them or list them before a buyer sees anything.
Every private repository is part yours and part borrowed. The borrowed part is usually larger than founders expect: a mid-sized TypeScript service can pull in hundreds of packages, and an old Rails app may have a vendor/ folder nobody has opened since 2019. When an AI company asks to license your code, the first useful question is not price. It is which files are yours to grant.
What counts as “your” code?
Code is yours to license when the company holds the copyright. In practice that means:
- code employees wrote while employed, covered by an invention assignment agreement;
- code contractors wrote under a contract that assigns the IP to the company (a contract that only grants a license is not enough);
- code you bought outright, with a written assignment.
Everything else belongs to someone else, even if it sits in your repo, ships in your product and was modified by your team.
The four kinds of borrowed code
| Where it lives | Example | Yours to license? |
|---|---|---|
| Installed packages | node_modules/, site-packages/, Go module cache |
No |
| Vendored copies | vendor/, third_party/, a forked library in libs/ |
No, apart from your own changes, and even those are tangled |
| Copied snippets | A function pasted from a GPL project or a forum answer | No |
| Generated code | Protobuf stubs, ORM models, build output | Usually low value; leave it out |
Installed packages are the easy case. They are rarely committed, and if they are, delete them from the export. Vendored code is harder because teams patch it. Your patches may be yours, but separating them from the upstream code is rarely worth the effort, so most sellers drop the folder and mention it.
Copied snippets are where the risk hides. Search your own source for license headers, “adapted from” comments and URLs pointing at other projects. Each hit is a passage you either remove or disclose.
Do permissive licenses change anything?
Not much for this question. The MIT license lets anyone use, copy, modify and sell the software, on condition that the copyright and permission notice are included in copies or substantial portions. Apache 2.0 is similar, adds an express patent license and requires keeping the NOTICE file. Both let you build commercial products on top of the library. Neither makes the library yours, so neither lets you grant someone else rights in it.
The upshot: a permissive dependency is not a problem in your deal, but it is not part of your deal either.
What about the GPL and AGPL?
Copyleft licenses add conditions when you convey the software (GPL) or, under the AGPL’s section 13, when users interact with a modified version over a network. Two points matter for a data deal.
First, depending on a GPL library does not put your own files under the GPL for the purpose of licensing them to a buyer. You still own what you wrote.
Second, GPL code you copied into your own files is a different matter. Those passages are not yours to relicense on private terms, and whether training a model on them counts as distribution is not settled law. A careful buyer will want them out, and so should you.
What do buyers actually want from a repo?
The value is in what only you have: the private commit history, the pull request reviews where someone explained why a change was wrong, the issue threads that trace a bug to its fix, and the tests that pin behavior down. Public open-source code is already available to anyone under its license, so nobody pays for it twice.
That is also why stripping dependencies rarely hurts the price. You are removing material a buyer could download for free and keeping material it cannot get anywhere else.
A clean-export checklist
- List every repo you plan to include and who wrote it: employees, contractors, agencies.
- Pull the contractor agreements and confirm each one assigns IP.
- Delete installed and vendored dependencies from the export; keep a short list of what was removed.
- Search for copied code: license headers, “adapted from” comments, URLs to other projects.
- Remove secrets. Rotate any key that was ever committed, then scrub it from history.
- Remove customer data from fixtures, seeds and test snapshots.
- Check client work. Code built for a client under an MSA usually belongs to the client.
- Ask who else has a claim: a lender with a lien, investors with consent rights, an acquirer.
Do this before any buyer conversation. It shortens diligence, and it stops you promising rights you do not hold.
Where this fits
Weighing whether to sell code to AI at all? The open source and licensing reference goes deeper on contractors, lenders and wind-down assignees. Treat this as general information; counsel gets the final read of any contract.
A tidy file tree is the cheapest diligence you will ever do, and the only part of it you fully control.