Selling Your Old Code vs Open-Sourcing It

The short answer: open-source your old code if real people still depend on it and you want them to keep it alive. Sell it if the product is finished, nobody needs it running, and the code is mostly your own team’s work. Order matters most. You can open-source code after you decide not to sell, but you cannot usefully sell code after it has been public.

What each route actually does with your code

Open-sourcing means publishing your source code under a license that lets anyone read, copy, change and reuse it. It is a gift to whoever finds it. You keep your name on it, and nothing comes back except goodwill and, sometimes, contributions.

A sale is the opposite trade. Odys AI Labs, the research and development arm of Odys, buys the code of software people no longer use for cash, and uses it for AI training and R&D: models learn to read, write and fix real software. It is not published: Odys AI Labs uses it for AI training and R&D, we may also work on it with research partners, and the agreement sets out exactly what rights transfer. We never use your brand or name and never relaunch the product as yours, and we do not publish who we buy from.

Side by side: eight questions

Why public code stays public

Releasing code is a one-way door. The moment a repository is public, people can clone it, fork it and mirror it. Software Heritage says its ambition is “to collect, preserve, and share all software that is publicly available in source code form,” and as of October 2026 its archive counters show over 30 billion unique source files from about 448 million projects. Public code datasets such as The Stack v2 are built from that archive.

GitHub’s own documentation is clear that you cannot pull it back: you “cannot remove sensitive data from other users’ clones,” and commits that exist in forks stay accessible there. Making the repository private again later hides your copy, not everyone else’s.

The same one-way logic applies to mistakes. GitGuardian counted about 29 million secrets leaked in public GitHub commits in 2025, up 34% in a year, and found that 64% of valid secrets leaked in 2022 were still not revoked in 2026. An old repository opened in a hurry is exactly where a forgotten database password sits in a commit from five years ago. Our guide to removing secrets from old code, including git history covers the cleanup either way.

When open-sourcing wins

Open source is the better route in a few clear cases:

• People still run the software. If customers, a community or your own former users rely on a self-hosted version, a public release lets them keep it working after you stop.
• It is a fork of someone else’s open-source project. If your product is mostly a modified copy of a copyleft or other open-source project, releasing your changes back may be the natural end point, and it would not qualify for a sale anyway, because we pass on open-source forks.
• It is small, generic or educational. A utility library, a template or a tutorial project has more value as a public example than as a private asset. These also fall outside what we buy.
• You want the credit more than the cash. A well-documented release can show your skills to future employers or clients. That only works if you put in the effort to document it.

If you go this way, pick the license deliberately, keep every third-party license notice intact, and add a clear note saying whether anyone maintains it. You also do not have to publish the full history: many teams release a fresh repository with a single snapshot of the current files. That removes old commits from view, but it does not remove a secret that is still in today’s files, so rotate keys either way.

When selling wins

Selling is the better route when the product has ended and the code has no community waiting for it. That describes most shut-down SaaS products, dead mobile apps, retired internal tools and shelved games. Their users have moved on, the hosting is gone, and a public release would likely sit untouched.

It wins most clearly when the code is complete and original: a real product written by your own team, ideally with its git history, tests and docs. Private code of this kind is scarce. Researchers at Epoch AI estimate the public stock of human-written text could be used up between 2026 and 2032, and private code is not in public datasets at all. That is why a finished product’s code can still be worth something, as we explain in what old source code is still worth.

Selling also means less cleaning work in public view. We never take databases, user records, customer data or chat logs, and we help remove secrets, keys and personal data before transfer. No code changes hands before a signed written agreement, and we never ask anyone to install or run anything.

A common worry is that GPL libraries inside the product force you to publish everything. They usually do not. The GPL FAQ says that if you only run GPL code yourself, the license “does not place any conditions” on that, and GPLv3 says users merely interacting with a hosted app is not conveying. The AGPL is the exception to check, because it covers network use of modified code. In a sale, the libraries stay under their own licenses and what changes hands is the code your team wrote. This is general information, not legal advice.

Two founders, two choices: an illustration

Suppose two founders each close a project management SaaS after four years, each with about 60,000 lines of their own code, full git history and decent tests.

The first still has a few hundred self-hosting users asking what happens next, and two of them offer to maintain it. Open source is the right call, accepting that the code cannot be sold afterwards.

The second founder’s users left when the hosted service closed, and nobody is waiting for the code. A release would likely collect a few stars and sit untouched. Asking for an offer first costs nothing, and open source remains available if the founder declines.

Can you do both?

Not with the same code, and not in the order most people try. Open-source first and the code is public for good, so it can no longer be sold as private code. Sell first and the rights belong to the buyer, so publishing it is no longer your decision.

What you can do is share the story without the code. A post-mortem on why the product ended, a talk about the architecture, or a write-up of a hard bug you solved gives you much of the reputational value of a release. If part of your repository is a generic library you already published separately, say so on the call; your own published code is simply not part of what is sold.

Ownership and license questions depend on your contracts and country. This is general information, not legal advice, so check anything uncertain with a qualified lawyer. Our deep article on open source inside your codebase explains permissive and copyleft licenses in plain English.

Which to choose

Use this rule, in this order:

1. Does anyone still run it? If yes, and you want them to keep going, open-source it.
2. Is it mostly your team’s own code, and a complete product? If no (a fork, a template, mostly copied libraries), open-source or archive it; it is not a sale candidate.
3. Does it still make money? If yes, it is a running business, not old code, and neither route fits yet.
4. Otherwise, ask for an offer first. Getting a valuation costs nothing and creates no obligation. If the offer does not suit you, open source is still available afterwards. The reverse is not true.

What to do next

• List who, if anyone, still uses the software, and whether they could run it without you.
• Check the code is mostly your team’s own work with a quick count using cloc or tokei, leaving out vendored libraries.
• Send us a few details for a free code valuation before you publish anything, or try the free code value check first.