Software and SaaS companies
How to handle GPL licenses when selling a codebase, plus AGPL, LGPL, MIT and Apache 2.0
On this page
- Can you sell code that uses open source?
- What a license grants vs what you own
- Copyleft vs permissive
- License by license
- AGPL code in an acquisition
- Training-data license vs distribution
- SBOM and license scans
- Third-party and vendored code
- Contributor and employee IP
- Selling compliantly, step by step
- FAQ
- Sources
The short answer
To handle GPL licenses when selling a codebase, separate the code you own from the code you only license. Your own code can be sold or licensed on your terms (source: 17 U.S.C. 201, ownership of copyright (Cornell LII), GNU GPL FAQ, copyright holder's other licenses). GPL code inside it stays under the GPL, which gives every recipient the right to redistribute it and forbids you from adding further restrictions (source: GNU General Public License v3, GNU General Public License v2).
In practice: build an SBOM, scan for copied and vendored files, then either leave third-party copyleft code out of the package or deliver it separately under its own license, with its notices and source intact.
Can you sell code that uses open source?
Yes. Open-source licenses do not forbid commercial use. The GNU project's own FAQ says the GPL allows everyone to sell copies, and that the right to sell copies is part of the definition of free software (source: GNU GPL FAQ, selling copies). GPLv3 says you may charge any price or no price for each copy you convey (source: GNU General Public License v3), and the MIT License grants the right to use, copy, modify, merge, publish, distribute, sublicense and sell copies (source: Open Source Initiative, the MIT License).
What changes in a sale is what you can promise. A buyer of your codebase is buying two different things:
- Code your company owns. You can assign it, license it exclusively or non-exclusively, and set conditions on its use.
- Code your company only licenses. Open-source components, snippets copied from public repos, and generated files from third-party tools. You can pass these along only on the terms you received them.
A third category causes the most trouble: code copied from a public repo with no license at all. GitHub notes that without a license, default copyright law applies and no one may reproduce, distribute or create derivative works from it (source: GitHub Docs, licensing a repository). Unlicensed snippets should come out or be replaced before a sale.
What an open-source license grants vs what you own
Copyright vests in the author (source: 17 U.S.C. 201, ownership of copyright (Cornell LII)). An open-source license is the author's permission for you to use their work on stated conditions. It does not make you the owner. That has three consequences in a sale:
- You cannot assign it. Selling “all rights in the codebase” transfers your copyrights only. The buyer receives open-source components under their licenses, directly from their authors.
- You cannot narrow it. GPLv3 says you may not impose any further restrictions on the exercise of the rights it grants, and GPLv2 says the same of recipients' rights (source: GNU General Public License v3, GNU General Public License v2). The GNU FAQ adds that GPL software cannot be distributed under a nondisclosure agreement (source: GNU GPL FAQ, distributing under an NDA).
- You can still license your own code differently. The same FAQ says a copyright holder can release code under several different non-exclusive licenses at different times (source: GNU GPL FAQ, copyright holder's other licenses). But once you have released your code publicly under the GPL, you cannot later give someone exclusive rights to it, because the public already has the right to use it (source: GNU GPL FAQ, later exclusive licenses).
Copyleft vs permissive licenses
Open-source licenses fall into two broad groups, and the group matters more than the name.
- Copyleft licenses (GPL, AGPL, and in a narrower way LGPL) require that the code, and in the GPL's case works based on it, be passed on under the same license with source. GPLv2 requires a distributed work that contains or is derived from the program to be licensed as a whole at no charge to all third parties (source: GNU General Public License v2).
- Permissive licenses (such as MIT and Apache 2.0) let you use the code in proprietary software as long as you keep the notices. MIT's only condition is that its copyright and permission notice be included in all copies or substantial portions (source: Open Source Initiative, the MIT License).
Copyleft is triggered by passing the code on, not by using it. GPLv3 lets you make, run and propagate covered works that you do not convey (source: GNU General Public License v3), and the GNU FAQ says a company can modify GPL code and use it internally without ever releasing it (source: GNU GPL FAQ, private modifications). That is why a codebase that was fine to run for years can raise new questions the day you hand it to someone else.
Open-source license compliance when selling code: license by license
| License (SPDX ID) | What it requires when you pass code on | Risk in a code sale or data license |
|---|---|---|
| GPL v3 (GPL-3.0-only, GPL-3.0-or-later) | Convey with Corresponding Source for object code, mark modified files, no further restrictions on recipients (see: GNU General Public License v3) | High if GPL code is linked into your product or copied into the repo. Recipients can redistribute it, so a confidential or training-only license cannot cover those files |
| GPL v2 (GPL-2.0-only, GPL-2.0-or-later) | Source or a written offer valid at least three years; derived works licensed as a whole to all third parties; no further restrictions (see: GNU General Public License v2) | Same as GPL v3, with older wording; common in Linux-adjacent and embedded code |
| AGPL v3 (AGPL-3.0-only) | Everything in GPL v3, plus a modified version used over a network must offer its users the source (see: GNU Affero General Public License v3) | Highest for SaaS. An acquirer running your modified AGPL service must offer source to its users |
| LGPL v3 (LGPL-3.0-only) | A Combined Work can use your own terms if the user can modify and relink the library, with notices and copies of the GPL and LGPL (see: GNU Lesser General Public License v3) | Moderate. Usually manageable for a library linked as a shared library; modified copies of the library itself go out under the LGPL or GPL |
| MIT (MIT) | Keep the copyright and permission notice in all copies or substantial portions (see: Open Source Initiative, the MIT License) | Low. Ship the notice with any copy you deliver |
| Apache 2.0 (Apache-2.0) | Include the license, keep notices, mark changed files, carry the NOTICE file's attributions; no trademark rights (see: Apache License, Version 2.0) | Low. Patent license ends for anyone who sues claiming the work infringes |
“Or later” matters: a file marked GPL-2.0-or-later can be passed on under GPL v3, while GPL-2.0-only cannot (source: GNU General Public License v2). Record the exact SPDX identifier for each component, not just “GPL”.
AGPL code in an acquisition
The AGPL was written for software that runs on servers. Section 13 requires that if you modify the program, your modified version must prominently offer all users interacting with it remotely an opportunity to receive the Corresponding Source, from a network server at no charge (source: GNU Affero General Public License v3). The GNU FAQ applies this directly: a company running a modified AGPL program on a website must release its modified source (source: GNU GPL FAQ, modified AGPL code on a website).
For a sale, three questions decide how much this matters:
- Is the AGPL code modified? Unmodified AGPL dependencies used as separate programs usually carry less risk than AGPL code your team changed.
- Do users reach it over a network? An internal admin tool is different from a customer-facing service.
- Will the buyer run it? An acquirer that keeps the product running inherits the obligation. An AI company licensing the code as training data does not run your service, but it still receives AGPL files with their GPL-style rights attached.
Why a training-data license is different from distributing the code
A training-data license is narrower than a sale. Typically the company keeps ownership, and the buyer receives a de-identified copy for model training, with limits on redistribution (source: program terms, Regulr buyer directory). Our guide to selling source code to AI companies covers what buyers pay for and how those deals work.
For your own code, those limits are yours to set. For third-party open-source code, they collide:
- Delivery is distribution. The GNU FAQ says internal copies are not distribution, but when an organization transfers copies to other organizations or individuals, that is distribution (source: GNU GPL FAQ, use within one organization). Handing a repo to a buyer counts.
- Copyleft rights travel with the files. A recipient of GPL code can redistribute it, and you cannot distribute it under an NDA or other added restriction (source: GNU GPL FAQ, distributing under an NDA, GNU General Public License v3). A license that says “training use only, no redistribution” cannot bind those files.
- Aggregates are allowed. The GPL permits distributing separate programs together, even with nonfree software, as long as the bundle's license does not stop users exercising each program's own rights (source: GNU GPL FAQ, aggregates). That is the basis for delivering third-party files as a clearly separate set under their own licenses.
What the licenses do not say
The texts of GPL v2, GPL v3, AGPL v3, LGPL v3, MIT and Apache 2.0 do not mention machine learning or model training (source: GNU General Public License v2, GNU General Public License v3, GNU Affero General Public License v3, GNU Lesser General Public License v3, Open Source Initiative, the MIT License, Apache License, Version 2.0). They turn on copying, modifying and passing code on. The cleanest data license avoids the open question by covering only code the company owns.
SBOM before selling software: how to inventory your codebase
CISA describes a software bill of materials as a nested inventory, a list of ingredients that make up software components (source: CISA, Software Bill of Materials). For a sale it answers one question: which code in these repos did someone else write, and under what license?
- Export the dependency SBOM. On GitHub, open the repository's Insights tab, choose Dependency graph, and click Export SBOM. The file is in SPDX format and lists dependencies with versions, licenses and copyright information (source: GitHub Docs, exporting an SBOM for your repository).
- Know its limits. That export reflects only what the dependency graph has detected (source: GitHub Docs, exporting an SBOM for your repository). Code copied into the repo by hand, vendored directories and checked-in binaries can be missing.
- Scan the files themselves. ScanCode Toolkit detects the origin (copyrights), licenses and vulnerabilities of code, packages and dependencies, from the command line or as a library (source: ScanCode Toolkit documentation). Run it on every repo you plan to deliver, including history you will hand over.
- Normalize the results. Map every finding to an SPDX identifier (source: SPDX License List (version 3.29.0)) and a path, and mark each as first-party, third-party permissive, third-party copyleft, or unknown.
- Resolve the unknowns. Find the source of every unattributed file or remove it. Unknown origin is the finding buyers like least.
Third-party code and vendored dependencies
Package-manager dependencies are easy: they are listed in manifests and appear in the SBOM. The harder cases are copies inside your own repo:
- Vendored directories such as
vendor/,third_party/or copied libraries. Treat each as a separate component with its own license file. - Copied snippets from public repos and forums. Check each for a license, and remove those with none.
- Forks of open-source projects your team modified. The modifications are yours, but the combined file is still under the original license.
- Generated code and fixtures from third-party tools, and sample data from other people's projects.
For a data license, the simplest approach is a delivery that contains first-party code only, with third-party paths excluded and listed. For an outright sale of the company's code, deliver everything with a license report so the buyer knows what it is getting.
Contributor and employee IP assignment
Before you can sell code, the company has to own it. Ownership starts with the author (source: 17 U.S.C. 201, ownership of copyright (Cornell LII)), and then depends on who wrote it:
| Who wrote it | Who owns it by default | What to check |
|---|---|---|
| Employees, in the scope of their job | The company, as a work made for hire (see: 17 U.S.C. 101, work made for hire (Cornell LII), 17 U.S.C. 201, ownership of copyright (Cornell LII)) | Side projects and code written before they joined |
| Contractors and agencies | The contractor, unless there is a signed written assignment; software is not one of the commissioned work-for-hire categories (see: 17 U.S.C. 101, work made for hire (Cornell LII), 17 U.S.C. 204, transfers in writing (Cornell LII)) | A signed assignment for every contractor whose code is in the repo |
| Outside contributors to your public repos | The contributor, who licenses it to you on the repo's terms (see: 17 U.S.C. 201, ownership of copyright (Cornell LII)) | A contributor agreement, or treat the contribution as third-party code |
| Founders before incorporation | The founder, until transferred in a signed writing (see: 17 U.S.C. 204, transfers in writing (Cornell LII)) | A founder IP assignment to the company |
A transfer of copyright ownership is not valid without a signed written instrument (source: 17 U.S.C. 204, transfers in writing (Cornell LII)). If a gap turns up, fix it with a written assignment while the person is reachable. In a wind-down that window closes fast, which is one reason our guide to shutting down a startup puts the IP check before layoffs.
How to sell a codebase compliantly, step by step
- Inventory. Export the SBOM from each repo and run a file-level license scan.
- Classify. First-party, third-party permissive, third-party copyleft, unknown. Record SPDX identifiers and paths.
- Check ownership. Employee, contractor, founder and contributor assignments for every first-party path.
- Decide scope. For a training-data license, deliver first-party code and exclude third-party paths. For a sale, deliver everything with the license report.
- Clean the history. Remove secrets, credentials and customer-specific code before anything leaves your systems.
- Keep the notices. Ship MIT and Apache notices, NOTICE files and copyleft source with any third-party code you do deliver.
- Write it into the contract. State that third-party components are provided under their own licenses and that your license covers only company-owned code.
Once the inventory is done, check what your code and records might be worth and compare programs in our buyer directory. If the company is closing, our guide to closing a business covers the deadlines, and the software and SaaS guide covers which engineering records buyers value.
How Regulr is paid, and how we write these pages
Regulr is a sell-side advisor. When a business we introduce signs a license, we may be paid a fee by the buyer or through a program's referral terms. We list every program we can verify whether or not it pays us, order is never set by fees, and every figure is the company's own advertised term with a link to where it says so. Regulr has not closed a data deal yet, so nothing here describes our results.
Frequently asked questions
How do you handle GPL licenses when selling a codebase?
Separate the code you own from the code you only license. Build a software bill of materials and run a license scanner to find every GPL file and dependency, including copied and vendored code. Your own code can be sold or licensed on your terms. GPL code inside it stays under the GPL, which gives each recipient the right to redistribute it and bars you from adding restrictions, so either leave it out of the package or deliver it separately under its own license.
Can you sell code that uses open source?
Yes. The GPL itself allows selling copies, and permissive licenses such as MIT expressly allow selling. What you cannot do is sell rights you never had. You can transfer or license the copyright in code your company wrote; for the open-source parts, the buyer gets the same license you received, and you must pass along the notices and source each license requires.
What happens to AGPL code in an acquisition?
The acquirer inherits the obligation along with the code. Section 13 of the AGPL v3 requires a modified version that users interact with over a network to offer those users its source code. If your product runs modified AGPL code as a service and the buyer keeps running it, the buyer must offer the source. Buyers usually want to know this before they sign, so list every AGPL component and whether you modified it.
Does licensing code as AI training data count as distributing it?
Giving a copy to another company is distribution under the GNU project's own reading: the GPL FAQ says that when an organization transfers copies to other organizations or individuals, that is distribution. So third-party GPL files in a training-data delivery carry their GPL rights with them. The license texts themselves say nothing about machine learning or model training.
What is an SBOM and do I need one before selling software?
CISA describes a software bill of materials as a nested inventory, a list of the ingredients that make up software components. Buyers ask for one because it shows which open-source packages and licenses are in your code. GitHub can export one in SPDX format from a repository's dependency graph, and a file-level scanner such as ScanCode finds licenses in copied code the dependency graph misses.
Can I give a buyer exclusive rights to code I already released under the GPL?
Not exclusive rights. The GPL FAQ says the developer of a GPL program cannot later license it for someone's exclusive use, because the public already has the right to use it under the GPL. As the copyright holder you can still grant additional non-exclusive licenses on other terms, so a non-exclusive commercial or training license is possible.
Do MIT and Apache 2.0 code need anything when I sell a codebase?
Yes, notices. MIT requires its copyright and permission notice in all copies or substantial portions. Apache 2.0 requires a copy of the license, retained notices, prominent notices on files you changed, and the attribution notices from any NOTICE file. Apache 2.0 also ends your patent license if you sue claiming the work infringes, and grants no trademark rights.
Who owns code written by contractors and former employees?
Code an employee wrote within the scope of employment is a work made for hire, so the company is the author. Code from contractors is different: software is not one of the categories that can be commissioned as a work made for hire, so the company owns it only if there is a signed written assignment. Fix gaps before you sell, while the contractors are reachable.
Sources
License texts, the GNU GPL FAQ, the SPDX License List, CISA, GitHub Docs, ScanCode Toolkit documentation and the US Code read on their own sites on November 8, 2026.
- GNU General Public License v3
- GNU General Public License v2
- GNU Affero General Public License v3
- GNU Lesser General Public License v3
- Open Source Initiative, the MIT License
- Apache License, Version 2.0
- GNU GPL FAQ, selling copies
- GNU GPL FAQ, use within one organization
- GNU GPL FAQ, private modifications
- GNU GPL FAQ, distributing under an NDA
- GNU GPL FAQ, later exclusive licenses
- GNU GPL FAQ, copyright holder's other licenses
- GNU GPL FAQ, aggregates
- GNU GPL FAQ, modified AGPL code on a website
- SPDX License List (version 3.29.0)
- CISA, Software Bill of Materials
- GitHub Docs, exporting an SBOM for your repository
- GitHub Docs, licensing a repository
- ScanCode Toolkit documentation
- 17 U.S.C. 101, work made for hire (Cornell LII)
- 17 U.S.C. 201, ownership of copyright (Cornell LII)
- 17 U.S.C. 204, transfers in writing (Cornell LII)
- program terms, Regulr buyer directory
Brian Boesen · Founder, Regulr AI
Brian runs Regulr AI, which works for established businesses that want to license de-identified records to AI companies. He checks each program's published terms against its own pages and updates these guides when they change. Last updated November 8, 2026.
This page is general information, not legal advice, and Regulr is not a law firm. Rules vary by state, by profession and by contract, and they apply to your facts, not to a category. You approve exactly what is in scope before anything is shared.
Keep reading