Open source inside your codebase does not stop you from selling it. When you sell old code, you sell the parts your own team wrote. The open-source libraries you used stay under their own licenses, with their notices intact, exactly as they were while the product was running. What a buyer cares about is how much of the repository is your original code, not whether you used libraries at all.
This is general information, not legal advice. License questions can turn on details, so for a specific concern, ask a qualified lawyer.
How common is open source in commercial code?
It is close to universal. Black Duck’s 2026 Open Source Security and Risk Analysis audited 947 commercial codebases and found that 98% contained open-source components. The average application pulled in about 1,180 of them, and 64% of those were transitive dependencies, meaning libraries your libraries depend on, which nobody on your team chose directly.
In Black Duck’s 2025 report, about 70% of scanned code had open-source origins. So if your old product leaned on frameworks, packages and SDKs, it looks like almost every other piece of commercial software.
What exactly do you sell when you sell code?
You sell the code your team wrote and the rights in it. In practice that means:
- Your application code: features, business logic, data models, APIs, screens.
- Your test suite, configuration and build scripts.
- Your git history, docs, ticket exports and design files.
What you do not sell, because it was never yours, is the third-party code inside the repository. Each library comes with its open-source license, which gave you permission to use it. That permission travels with the library, not with your sale. The buyer receives the libraries under the same license terms you did.
This is why copying libraries into your repository (a vendored dependency) does not inflate value. When we size a codebase, we look at the share written by your team, and our guide on counting lines of code shows how to separate the two.
What is the difference between permissive and copyleft licenses?
Open-source licenses fall into two broad families. The difference is what you must do when you pass the code on to someone else.
| Permissive (MIT, Apache 2.0, BSD) | Copyleft (GPL, AGPL) | |
|---|---|---|
| Can you use it in a closed product? | Yes | Yes in-house and, for GPL, in a hosted app; not if you hand out copies without source |
| Main condition | Keep the copyright and license notice | Share the source of the combined work, under the same license, when you distribute it |
| What triggers the condition | Distributing copies | Distributing copies (GPL); also offering modified code over a network (AGPL) |
| Effect on a sale of your code | Minimal; notices stay in place | Worth listing, so the GPL parts are handled correctly |
A permissive license asks very little. The MIT License grants permission “free of charge, to any person obtaining a copy,” on the condition that the copyright and permission notice “shall be included in all copies or substantial portions.” The Apache 2.0 license is similar but also asks you to pass on a copy of the license, keep existing notices and mark files you changed.
A copyleft license asks that if you give the software to others, you give them the source too, under the same terms. Under GPLv3, to “convey” means enabling others to receive copies, and “mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.” The GPL FAQ says that if you only copy and run a GPL program yourself, the license requires “nothing.” The AGPL goes further: running a modified version as a network service means offering its source to users.
Does a copyleft library cause problems when you sell?
Usually not for your own code, but it deserves a line in your notes. Copyleft does not change who owns the code your team wrote; it sets the terms on which the GPL parts, and any work combined with them, can be passed on. The GPL FAQ is clear that “providing copies to contractors for use off-site is distribution”, and the same logic applies when a repository passes to another company. So the GPL components travel under the GPL, as they always would.
In practice that means two things. First, do not try to hide or strip GPL code: list it. Second, tell the buyer which parts of the product depend on it, so those parts can be handled correctly. If your SaaS was hosted and never distributed, you may never have triggered GPL obligations while it ran, which is normal and not a problem in itself. If you used AGPL code and modified it, note that too.
What about license conflicts and unclear licenses?
They are common, and they do not mean you did anything wrong. Black Duck found that 68% of audited codebases had license conflicts in its 2026 report, and roughly one in five components had either no detected license or a custom or modified one (8% with none, 11% custom or modified). Most audited codebases also carried outdated parts: 92% had components four or more years out of date, according to Black Duck’s summary of the report.
For a sunset product that has not been touched in years, out-of-date libraries are expected. A buyer using code for AI training and research is not going to deploy it as is. What matters is that the libraries are identified, the notices are intact, and your team’s work can be separated from them.
How do you list the open source in your codebase?
You do not need a commercial scanner for a first pass. Most ecosystems already record dependencies:
- Read the manifest files. package.json, requirements.txt, Pipfile, Gemfile, pom.xml, build.gradle, composer.json, go.mod, Cargo.toml.
- Find copied code. Look for folders such as vendor, third_party, lib or external, and minified .js files that came from somewhere else.
- Note each license. Most packages show a license field in the manifest or a LICENSE file in their folder.
- Flag copyleft. Mark anything under GPL, LGPL or AGPL so it is easy to discuss.
- Write it down. A simple table of library, version, license and where it is used is enough.
Leave every LICENSE, NOTICE and copyright header exactly where it is. This list fits naturally into the wider checklist in our guide to preparing a codebase for sale.
When is open source a reason we pass?
Not because you used libraries. We pass when the repository is mostly someone else’s work: open-source forks, templates and tutorial projects, or repos that are mostly copied libraries or generated code. The test is the same one explained in how codebase value is measured: how much of what is there did your team actually write? And if you are deciding whether to publish the code yourself instead, our comparison of selling versus open-sourcing explains why that choice is hard to undo.
What to do next
- List your dependencies and their licenses from the manifest files, and flag anything GPL, LGPL or AGPL.
- Estimate roughly what share of the repository your team wrote, excluding vendored and generated code.
- If most of it is your own work, send us a few details for a free code valuation.
Frequently asked questions
Does using open-source libraries stop me from selling my code?
No. Using open-source libraries is normal and does not stop a sale. What you sell is the code your team wrote: your features, your business logic, your tests and your history. The libraries stay under their own licenses and keep their license notices. A buyer mainly checks that most of the repository is your own original work, not copied code.
Should I delete the license files from libraries before selling?
No. Never remove license notices or copyright headers from third-party code. Most open-source licenses require those notices to stay with the code, and removing them can turn a normal, licensed use into a breach. Leave them exactly where they are. If anything, a clean list of the libraries you used and their licenses makes a sale easier.
My product used a GPL library. Is that a problem for a sale?
Usually not for the code your team wrote, but it is worth noting. GPL duties are triggered when software is distributed to others, so handing a repository that contains GPL code to a buyer counts as distribution of that GPL part. The GPL code then travels under the GPL. Tell the buyer which components are GPL so it can be handled properly, and ask a lawyer if you are unsure.
What if my repository is mostly a fork of an open-source project?
Then it is usually not a fit for a sale, because the original work belongs to the upstream project's authors and is already public. We pass on open-source forks, templates and tutorial projects. If your team made large, original changes on top of a fork, describe them on the call, because the part your team wrote may still be relevant.
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 →