License guide · Comparison
Apache-2.0 vs GPL-3.0
This is the comparison that actually changes what you can ship. Apache-2.0 is permissive; GPL-3.0 is strong copyleft. One lets you build a closed-source product and say nothing; the other requires that anyone you distribute to receives the source of the combined work, under the same license. Everything else is detail.
Updated 14 Aug 2026 · by the depproof team
General information, not legal advice. Primary sources: the Apache License, Version 2.0 and the GNU General Public License v3.0.
The comparison, line by line
| Question | Apache-2.0 | GPL-3.0 |
|---|---|---|
| License family | Permissive | Strong copyleft |
| This single fact drives almost every row below it. | ||
| Use in closed-source commercial software | Yes | Only if you keep it separate |
| Linking GPL-3.0 code into your application generally makes the combined work subject to the GPL when you distribute it. | ||
| Must you publish your own source? | No | Yes, on distribution |
| The GPL obligation triggers on distributing the combined work — not on writing it, and not on internal use. | ||
| Internal use without distributing | No obligations | No source obligation either |
| Widely misunderstood. Using GPL-3.0 software inside your company, undistributed, triggers nothing. | ||
| Running it as a hosted service (SaaS) | No obligations | No source obligation |
| GPL-3.0 has no network clause — that is AGPL-3.0. Serving users over a network is not distribution. | ||
| Express patent grant | Yes — Section 3 | Yes — Section 11 |
| Both grant patent rights expressly. GPL-2.0 did not, which is part of why GPL-3.0 exists. | ||
| Must you mark files you changed? | Yes | Yes |
| Both require modified files to carry prominent change notices. | ||
| NOTICE-file propagation | Yes, if one exists | No such concept |
| Apache-2.0’s distinctive obligation, and the one teams most often miss. | ||
| Can it be combined into the other? | Apache-2.0 → GPL-3.0: yes | GPL-3.0 → Apache-2.0: no |
| The compatibility is one-directional. The result of combining is always GPL-3.0. | ||
| Sublicensing under different terms | Yes | No |
| Copyleft means downstream recipients must get the same freedoms you got. | ||
Permissive vs copyleft, in one paragraph
Apache-2.0 asks you to give
credit. GPL-3.0 asks you to
give the same freedoms you received. Under Apache-2.0 you
keep the notices, mark what you changed, carry the NOTICE file,
and you are done — your own code stays yours, on whatever terms you like.
Under GPL-3.0, distributing a work built on the code means the recipient gets
the complete corresponding source of that combined work, under GPL-3.0, with
the right to modify and pass it on.
That is not a restriction on commerce — it is a restriction on secrecy. Which is why the most common question about the GPL has a counter-intuitive answer.
Yes, you can sell GPL-3.0 software
The single most persistent myth about the GPL is that it forbids commercial use. It does not. You may charge whatever you like for software containing GPL-3.0 code, and companies do. What the license governs is the terms your recipients get: the complete corresponding source of the combined work, under GPL-3.0, with the freedom to modify and redistribute it.
So the real question is never “can I sell this?” — it is “am I willing to ship the source?” For a great many products the answer is no, and that is the honest reason organisations set policies against copyleft in their dependency trees. It is a business decision about disclosure, stated plainly.
Two triggers people get wrong
- Internal use is not distribution. Running GPL-3.0 software inside your company, however heavily modified, triggers no source obligation at all as long as you do not distribute it outside the organisation.
- SaaS is not distribution either. GPL-3.0 has no network clause. Serving users over a network is not distributing the software to them. The license that closes that gap is AGPL-3.0, and its Section 13 is a genuinely different obligation — the one worth actually checking for.
Compatibility runs one way
Apache-2.0 code can go into a GPL-3.0 project. GPL-3.0 code cannot go into an Apache-2.0 one. Combine them and the result is distributed under GPL-3.0 — copyleft wins, by design, because the whole point of copyleft is that it cannot be stripped off downstream.
Worth knowing: this compatibility is specific to GPL-3.0. The same combination is not permitted under GPL-2.0-only, because GPL-2.0 forbids further restrictions on recipients and the Free Software Foundation reads Apache-2.0’s patent-termination and indemnification terms as exactly that. GPL-3.0 was drafted to accommodate them. So an Apache-2.0 + GPL-2.0-only pairing in your tree is a real conflict while Apache-2.0 + GPL-3.0 is not — a version-specific trap that hides well. The license compatibility matrix sets it against every other pairing you are likely to hit.
Choosing one for your own project
- Choose Apache-2.0 for the widest possible adoption, including by companies shipping proprietary products. Corporate legal teams approve it readily, largely because of the express patent grant — it is the default for foundation and enterprise-backed projects.
- Choose GPL-3.0 to guarantee that improvements stay open and that nobody can build a closed product on your work. You are deliberately trading adoption for reciprocity.
- Consider AGPL-3.0 instead if the closed use you actually want to prevent is a competitor running your code as a hosted service. GPL-3.0 does not stop that; AGPL-3.0’s network clause is what addresses it.
Which are actually in your tree?
Choosing a license for your own project is a one-time decision. Living with the licenses of the hundreds of components that arrive transitively is the ongoing one — and a single GPL-3.0 component deep in a dependency tree is exactly the finding that matters before a release, an audit, or due diligence.
- Check your Maven dependency licenses — the full transitive tree, with no build.
- Check your npm dependency licenses — every direct and transitive package, from the lockfile.
- What copyleft means in practice — the family explained, permissive through network copyleft.
Frequently asked questions
What is the difference between Apache-2.0 and GPL-3.0?
Apache-2.0 is permissive and GPL-3.0 is strong copyleft — that is the whole difference in one line. Apache-2.0 lets you use the code in closed-source, proprietary products and never asks you to publish your own source. GPL-3.0 requires that when you distribute a work built on it, recipients get the complete corresponding source of the combined work under the GPL-3.0. Both grant patent rights expressly and both require you to mark files you changed; only Apache-2.0 has the NOTICE-file obligation.
Is Apache-2.0 compatible with GPL-3.0?
Yes, in one direction. Apache-2.0 code can be incorporated into a GPL-3.0 project, and the resulting combined work is distributed under GPL-3.0. The reverse is not permitted: you cannot take GPL-3.0 code and relicense or ship it under Apache-2.0 terms. GPL-3.0 was drafted with explicit accommodation for Apache-2.0’s patent and indemnification provisions — which is exactly why the same combination fails under GPL-2.0.
Can I use GPL-3.0 code in a commercial product?
Yes — the GPL does not prohibit commercial use or charging money, and this is the most common misconception about it. What it constrains is distribution terms: if you distribute a product containing GPL-3.0 code, the recipients must receive the complete corresponding source of the combined work under the GPL-3.0, along with the freedom to modify and redistribute it. Selling that product is entirely permitted. The question is never "can I sell it?" but "am I willing to ship the source?"
Does using a GPL-3.0 dependency force me to open-source my whole application?
It depends on distribution and on how the code is combined. If you never distribute the software — internal use, or running it as a hosted service — GPL-3.0 imposes no source obligation at all, because neither is distribution. If you do distribute a work that links or incorporates GPL-3.0 code, the combined work generally must be offered under the GPL-3.0. Where exactly the boundary of the combined work falls is a genuinely contested legal question, which is why this is one to take to counsel rather than settle from a table.
Which should I choose for my own project, Apache-2.0 or GPL-3.0?
Choose Apache-2.0 if you want the widest possible adoption, including by companies building proprietary products — it is the default for foundation and enterprise-backed projects, and corporate legal teams approve it readily. Choose GPL-3.0 if you want to guarantee that improvements stay open and that nobody can build a closed-source product on your work. It is a values decision about what downstream users may do, not a technical one, and it is far more consequential than choosing between two permissive licenses.
Why is Apache-2.0 compatible with GPL-3.0 but not GPL-2.0?
GPL-2.0 forbids imposing any further restrictions on downstream recipients, and the Free Software Foundation reads Apache-2.0’s patent-termination and indemnification terms as precisely such restrictions. GPL-3.0 was written with explicit provisions accommodating those terms, so the conflict disappears. The practical consequence is that a dependency tree containing both an Apache-2.0 component and a GPL-2.0-only component has a real conflict, while the same tree with GPL-3.0 does not.
Related comparisons
- MIT vs Apache-2.0 — choosing between the two permissive options.
- AGPL-3.0 explained — the network clause GPL-3.0 does not have.
- LGPL-3.0 explained — the weaker copyleft designed for linking.
General information, not legal advice; confirm specific decisions with counsel — particularly where the boundary of a “combined work” falls, which is a genuinely contested question. “Apache” and the Apache License refer to the license published by the Apache Software Foundation; the GPL is published by the Free Software Foundation. Both are used nominatively.