For code you no longer use, there are four main routes: sell it, archive it privately, release it as open source, or delete it. Relaunching the product yourself is a fifth, but it is a business decision more than a code decision. The most important thing to know before choosing is that archiving keeps every option open, while open-sourcing and deleting each close some doors permanently.
This guide compares the four routes on what each costs, what you keep, what you give up and whether you can change your mind. It also explains why the order of decisions matters, and gives a plain rule for choosing.
The four options side by side
| Sell | Archive privately | Open source | Delete | |
|---|---|---|---|---|
| What you get | Cash, one agreed price paid on transfer | Time to decide | Goodwill, a portfolio piece, possible contributors | Nothing to maintain |
| What you keep | Usually nothing in the code, unless agreed | Everything | Copyright, but not exclusivity | Nothing |
| What you give up | Ownership of the code your team wrote | Little, beyond upkeep | Control over who copies and uses it | The code and its history |
| Effort | Answer questions, clean secrets and personal data (with help) | A few clicks | License review, secret and data cleaning, public scrutiny | A few clicks |
| Can you undo it? | No, once transferred | Yes | Not for copies already taken | No, unless a clone survives |
| Risk if done carelessly | Low with a written agreement | Old keys still valid in history | Leaked secrets and personal data become public | Losing value and records you may need |
Why archive first?
Archiving is the holding position. On GitHub, archiving a repository makes it read-only for all users: code, issues, pull requests, wiki and commits are frozen, and you can unarchive it whenever you like. Other hosts have similar features, and a private repository with no write access does much the same job.
What you keep is everything: the code, the full git history, the tickets and the reviews. What you give up is very little. The cost is upkeep: someone must keep admin access, pay for the account if needed and remember the repository exists.
Archiving is not the same as being safe. Secrets committed years ago stay in history unless removed, and GitGuardian found that 64% of valid secrets leaked in 2022 were still not revoked in 2026. If you archive, rotate any key that was ever committed. Archiving is the right first step, but it is a pause, not a decision. Our comparison of selling versus leaving code archived goes further.
When does selling make sense?
Selling makes sense when the code is original, reasonably complete and yours to sell, and when you have no plan to run the product again. It is the only route that turns the work into cash.
On this site the buyer is Odys AI Labs, the research and development arm of Odys. It buys the source code of software people no longer use and uses it for AI training and R&D; we may also work on it with research partners. The terms are simple: cash only, one agreed price, paid on transfer. The offer comes after a review of what you tell us, and there is no obligation. No code changes hands before a signed written agreement. We never take databases, user records, customer data or chat logs, we never use your brand or name, and we never relaunch the product as yours.
What you give up is ownership of the code your team wrote. If you might want to reuse parts of it, say so before signing; it belongs in the written agreement. Software still making money is not something we buy. A profitable, running product belongs with a marketplace or broker that sells whole businesses, and Acquire.com, for example, generally lists only startups that generate revenue. Our guide on what old source code is still worth explains why a product with no revenue can still have value as code.
What about relaunching the product yourself?
Relaunching is the fifth route, and it is a business decision more than a code decision. It makes sense when the reason the product stopped has changed: the market has grown, a new team has time and funding, or a partner wants to use it. The code may need updating, the infrastructure has to be rebuilt and customers have to be won again, which is often the hardest part.
If relaunching is a real plan, keep the code and do not sell it. If it is a vague maybe that has sat untouched for years, be honest with yourself about the odds. The code will not become more useful by waiting, and the people who knew it best keep moving on. Selling means letting the code go: you no longer own it, and we never relaunch the product as yours, so a sale and a relaunch do not mix.
When does open-sourcing make sense?
Open-sourcing makes sense when you want the code to help other developers, when you have no wish to sell, or when the project was always meant to be shared. It can bring goodwill, a public record of your work, and sometimes a community that keeps it alive.
It also carries real work and real risk:
- License choice. A permissive license such as MIT lets anyone reuse the code almost freely, as long as the notice is kept. A copyleft license such as the GPL attaches conditions when the software is passed on.
- Third-party code. Libraries and vendored dependencies keep their own licenses. Black Duck found license conflicts in 68% of codebases it audited for its 2026 report, so a license review before publishing is wise. Never strip existing license notices.
- Secrets and personal data. Anything in the history becomes public. GitHub’s own docs note that even after a rewrite, old clones, forks and cached views can still hold sensitive data.
- When copyleft duties apply. Under the GPL, using the software in-house triggers no conditions; handing copies to others does. Publishing your own code under a license you choose is a different question from the licenses of what is inside it, which is why the review matters.
- Permanence. Public code gets copied. Software Heritage aims to collect and preserve all publicly available source code, and public code datasets are built from public repositories.
Licensing questions depend on the specific code and contracts. This is general information, not legal advice, and a qualified lawyer can review your case. See our sell versus open source comparison for a closer look.
When does deleting make sense?
Deleting makes sense in a narrow set of cases: the code is trivial, it is so entangled with personal data that cleaning is not realistic, or a contract or legal duty requires destruction. Even then, check whether the obligation applies to the whole repository or only to specific data.
Deleting is also less complete than it looks. GitHub’s docs point out that deleting a file in a new commit does not remove it from git history, and deleting a whole repository does nothing about clones on old laptops, forks or backups. If the goal is to get rid of sensitive data, removing the specific files and their history, and rotating any keys, is usually more effective than deleting everything. Whether a contract or data protection law actually requires destruction is a legal question; this is general information, not legal advice, so check with a qualified lawyer before deleting on those grounds.
Deleting is cheap in effort and costly in options. Once the repository and all clones are gone, so is any chance of selling, open-sourcing or reusing the work. You may also lose records you need later, for tax, a dispute or a due diligence question about a past company. Our comparison of selling versus deleting old code covers the cases where deletion is genuinely right.
Why are some of these choices one-way?
The order of decisions matters because two of the four routes cannot be reversed:
- Open-sourcing is one-way for exclusivity. You may still hold the copyright, but everyone who took a copy keeps the rights the license gave them. A buyer cannot get exclusive code that is already public, and public code is the kind that has been widely used already.
- Deleting is one-way for everything. Without a surviving clone, there is nothing left to sell, publish or reuse.
- Selling is one-way for ownership, which is the point of a sale, and it is done under a written agreement you have read and signed.
- Archiving is fully reversible, which is why it belongs first.
So the safe sequence is: archive, then decide whether to sell, then, only if you decide not to sell, consider open-sourcing or deleting.
Can you combine the routes?
Some combinations work and some do not. You can archive now and sell later; that is the most common path. You can sell the code and keep the old product’s domain, or sell the domain separately: if the old website still gets organic traffic, TheBlueOceanWebsites.com buys websites of former businesses. You can sell one product’s code and open source an unrelated small library your team wrote, if it is genuinely separate.
What does not work is open-sourcing first and then selling exclusively, or selling and then publishing the same code. The written agreement for a sale will say what you may and may not keep.
Which option should you choose?
A plain decision rule:
- Is the software still making money? Keep running it, or sell the business through a marketplace or broker.
- Do you have the rights? If not, sort out ownership first, or archive and wait. Our guide on who owns the code explains the usual fixes.
- Is the code original and reasonably complete? If yes, find out what it is worth before you publish or delete anything. The free code value check takes a couple of minutes.
- Do you care more about community than cash? Open source it, after cleaning secrets and reviewing licenses.
- Is the code trivial, or bound by a duty to destroy it? Delete it, carefully, and keep any records you are required to keep.
If you are unsure, archive. It costs least and keeps every door open.
What to do next
- Archive every repository you are not actively using, and rotate any key that was ever committed.
- Before publishing or deleting anything, check how codebase value is measured against your own code.
- Send us a few details for a free code valuation, with no code and no obligation, so you know what selling would mean before you choose.
Frequently asked questions
Can I sell my code after I have open-sourced it?
Not exclusively. Once code is published under an open-source license, anyone who took a copy keeps the rights that license gave them, and public archives and datasets may already hold it. You may still own the copyright, but a buyer cannot get something nobody else has. If selling is a possibility, decide before you publish. Private code that has never been released is what buyers value.
Is archiving a GitHub repository the same as deleting it?
No. Archiving makes a repository read-only for everyone, keeps all code, history, issues and pull requests, and can be undone at any time. Deleting removes it, and unless someone has a full clone, the history is gone. Archiving is the safe default while you decide what to do; it keeps every other option open, including a sale later.
Should I delete old code to protect customer data?
Deleting the whole repository is rarely the right fix. Customer data usually sits in specific places, such as seed files, fixtures, logs or a committed database dump, and those can be removed while the code itself is kept. Rotate any keys first, then clean the specific files and their history. If you sell, secrets and personal data are removed before transfer, and we help.
What does it cost to keep old code archived?
Often very little in money: a private repository on a hosted platform may cost nothing or a small subscription. The real costs are quieter. Someone must keep admin access, credentials in the history may still work, and the knowledge of what the code does fades as people move on. Archiving buys time, but it does not turn the code into anything.
Can I sell the code and keep using it myself?
That depends on the agreement. A full sale usually transfers the rights to the code your team wrote, so you would no longer own it or be free to reuse it. Anything you hope to keep has to be written into the agreement before it is signed, and nothing is assumed. If continued use of some part matters to you, raise it on the first call so it can be discussed openly.
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 →