License guide · Copyleft
GPL-3.0 explained: can you ship it in commercial or proprietary software?
The GNU General Public License v3.0 (GPL-3.0) is genuine, OSI-approved open source — and commercial use is fully allowed. The thing to get right is the strong copyleft: the moment you distribute the software, or anything derived from it, you have to hand over the complete corresponding source under the same GPL. It is a reciprocity deal, not a price tag — and it behaves very differently for something you ship than for something you only run internally.
Updated 27 Jul 2026 · by the depproof team
General information, not legal advice. The controlling text is the license itself and the facts of your specific combination and distribution. Primary source: the GNU General Public License, version 3.
Is GPL-3.0 open source? Yes — that’s the starting point
Unlike source-available licenses such as BSL-1.1, GPL-3.0 is OSI-approved open source. It grants the four freedoms — use, study, modify, and share — and it places no restriction on commercial use. You can run it in a business, build a product on it, charge money for copies, and sell support. There is no “you may not compete” clause. So the question is never “are we allowed to use GPL commercially?” (you are) — it is “what do we owe when we distribute it?”
The trigger is distribution, not use
GPL-3.0’s reciprocal obligations are tied to a specific act the license calls conveying — putting a copy in someone else’s hands. When you convey the software or a derivative work, you must:
- Provide the complete corresponding source under the GPL — the source needed to build, install, and run the version you shipped, including scripts and build details.
- License the whole distributed work under the GPL. A derivative can’t be conveyed under proprietary terms; the freedoms have to pass through to whoever receives it.
- Preserve notices and the license text, and don’t add restrictions that would take those freedoms back.
The flip side is the part teams most often miss: purely internal use is not conveying. Running or modifying GPL software for your own organization’s operations — not distributing binaries to outside parties — does not, by itself, force you to publish anything. The obligation attaches to distribution, not to the fact that you use the code.
Derivative works and linking: why proprietary shipping breaks
Combining GPL code into your own program generally makes the combined result a derivative work — and when you distribute that result, the whole work has to go out under the GPL. The widely-held view, and the position of the Free Software Foundation, is that both static and dynamic linking create such a combined work, so linking is not an escape hatch. (This is one of the genuinely debated points in licensing, but the FSF interpretation is the one most compliance programs plan around.)
The practical consequence: you typically cannot ship closed-source proprietary software that links GPL code. If you need a copyleft component inside a proprietary distributed program, the usual answers are to use a weak-copyleft LGPL-3.0 component instead — which is designed to be linked from non-GPL programs — or to obtain a differently licensed version from the author.
No network trigger: GPL vs AGPL for SaaS
Because the trigger is distribution, running GPL-3.0 software as a SaaS backend does not by itself force you to release source. Serving users over a network isn’t “conveying” a copy to them — you’re not handing out binaries — so the source-disclosure obligation doesn’t fire. This is the well-known SaaS/ASP loophole.
The important contrast is the AGPL-3.0, which exists specifically to close that gap: its network-interaction clause treats remote users as recipients and requires you to offer them the corresponding source. So the same “we host it, we don’t distribute it” deployment is safe under GPL but can trigger disclosure under AGPL. When you inventory copyleft dependencies, GPL vs AGPL is the distinction that decides whether a SaaS deployment is in scope.
GPLv3 vs GPLv2, briefly
GPLv3 keeps the same copyleft bargain and adds three things worth knowing for a shipping decision: an explicit patent grant from contributors (with anti-retaliation terms), anti-“tivoization” provisions that stop consumer hardware from technically locking out modified-but-still-GPL builds, and better license compatibility (notably with Apache-2.0, which GPL-2.0 cannot accept, and an explicit path to combine with AGPL-3.0). For “can we ship this?” the core rule is unchanged from v2: distribute a derivative, and the whole work goes out under the GPL, with complete source.
Weighing it against the permissive alternative? Apache-2.0 vs GPL-3.0 puts the two models side by side — what each obliges you to publish, why selling GPL software is permitted, and why the compatibility runs in only one direction.
Can you…? GPL-3.0 at a glance
| Can you… | Under GPL-3.0? |
|---|---|
| Use it inside your company / internally | Yes — internal use isn’t “conveying” |
| Modify the source and build on it | Yes |
| Distribute a derivative without sharing source | No — you must ship the complete corresponding source under the GPL |
| Link it into proprietary software you distribute | No — the combined work must be GPL (static and dynamic linking, widely-held view) |
| Run it as a SaaS backend without distributing binaries | Yes — no network clause (contrast AGPL) |
| Sell it commercially | Yes — allowed, as long as recipients get the source under the GPL |
Read the table as one question: are you distributing it, or only running it? Almost every GPL surprise comes from a component that ends up inside something you ship.
Where GPL trips up dependency and license policy
The classic failure mode is a transitive GPL dependency in a product you distribute. A strong-copyleft library buried deep in the tree can reach your whole distributed work, and it tends to surface at the worst possible moment — a release gate, a customer audit, or acquisition due diligence. GPL is not something to discover late; it is something to detect early and place on the right side of the distribute/run line.
The practical move is to make copyleft licenses visible across your full transitive dependency tree, then decide per-project whether the component lives in something you ship or only run internally.
- Check your Maven dependency licenses — surface GPL, LGPL, AGPL, and other copyleft licenses across the full transitive tree.
- Check your npm dependency licenses — the same visibility for JavaScript and Node projects.
- What copyleft means — the parent concept behind strong, weak, and network copyleft.
- See your org-wide license posture — copyleft exposure across every repository in one place, for legal and compliance.
Frequently asked questions
Is GPL-3.0 open source, and can I use it commercially?
Yes on both. The GNU General Public License v3.0 (GPL-3.0) is an OSI-approved open-source license, and commercial use is explicitly allowed — you may use it in a business, sell it, and charge for copies. Unlike source-available licenses such as BSL, there is no “no competing service” restriction. The catch is not the money; it is reciprocity. GPL-3.0 is a strong-copyleft license, so when you distribute the software or a work derived from it, you must pass on the same freedoms — including the complete corresponding source under the GPL.
What actually triggers the GPL-3.0 copyleft obligations?
Distribution — the license calls it “conveying.” The reciprocal obligations (offer the complete corresponding source, license the whole work under the GPL, keep notices) kick in when you convey the software or a derivative to someone else: shipping a binary, an appliance, an installer, an on-prem product, or a mobile app. Purely internal use inside your own organization is not conveying, so running or modifying GPL code for your own operations does not, by itself, force you to publish anything. The obligation attaches to the act of distribution, not to the act of use.
Does linking GPL-3.0 code into my program make my whole program GPL?
Generally yes, when you distribute the result. Combining GPL-licensed code with your own to form a single program typically makes the combined work a derivative, which must be licensed under the GPL as a whole when conveyed. The widely-held view — the position taken by the Free Software Foundation — is that both static and dynamic linking create such a combined work, so linking is not a way around copyleft. That is why you usually cannot ship closed-source proprietary software that links a GPL library. If you need to link from a proprietary program, look for an LGPL-licensed component instead, or a differently licensed version from the author.
If I run GPL-3.0 software as a SaaS backend, do I have to release my source?
Not because of the GPL. GPL-3.0 has no network clause: making the software available to users over a network is not “conveying” a copy to them, so hosting GPL code as a backend — without distributing binaries — does not by itself trigger the source-disclosure obligation. This is the so-called “SaaS/ASP loophole.” The important contrast is AGPL-3.0, which was written specifically to close it: the AGPL adds a network-interaction clause that treats remote users like recipients and requires you to offer them the corresponding source. If a dependency is AGPL rather than GPL, a SaaS deployment can trigger disclosure.
How is GPLv3 different from GPLv2?
At a high level, GPLv3 keeps the same strong-copyleft bargain but modernizes it. It adds an explicit patent grant from contributors (and anti-retaliation terms), anti-“tivoization” provisions that stop hardware makers from technically locking out modified-but-GPL software on consumer devices, and improved license compatibility — for example, better interoperability with the Apache-2.0 license and an explicit path for combining with AGPL-3.0. For a “can we ship this?” decision the core rule is unchanged: distribute a derivative, and the whole work goes out under the GPL with complete source.
Why does a transitive GPL-3.0 dependency matter for my license policy?
Because a strong-copyleft dependency buried deep in the tree of a product you distribute is the classic release-blocker. If GPL-licensed code ends up linked into a binary, appliance, or app you ship, the copyleft can reach your whole distributed work — a discovery that is expensive to unwind at a release gate, in an audit, or during due diligence. The practical step is to detect GPL and other copyleft licenses across the full transitive dependency tree early, and decide per-project whether the component sits in something you distribute or only run internally.
General information, not legal advice; confirm specific decisions — especially linking and distribution questions — with counsel. “GPL” and “GNU General Public License” refer to the licenses published by the Free Software Foundation and are used nominatively.