Apache 2.0 and GPL solve different problems, so the real choice is one question: do you want your code used anywhere, or do you want every copy of it to stay open? Pick Apache when you want wide reuse, including inside proprietary and commercial products, with patent protection written into the license. Pick GPL when you want every derivative to stay open source, full stop. Read the actual license text before you commit, not a blog's summary. The clauses that decide real cases are precise legal mechanisms, not vibes.

Last updated: 2026-07-21

I've watched this choice drive hard engineering calls on driver projects: how teams share code, how they manage risk, how they work with the community. Some pick permissive terms to speed adoption. Others take copyleft to guarantee the code stays open when someone ships it. You feel the tradeoff fast. Expect concrete pointers here, plus real outcomes like Linux's GPL stance and macOS shipping permissive BSD code.

What the Apache License actually is

Apache 2.0 is a permissive license: use the code, modify it, ship it, even inside a closed product, as long as you follow a few conditions. It shipped as Version 2.0 in January 2004, and that revision is the one everyone means today. It asks three things. Keep the license text and copyright notices. State what you changed. Preserve the NOTICE file if the project has one.

What it does not do is force you to open your own source. There's no share-alike clause. That single absence is why a company can build Apache-licensed code into a product it never releases, and why copyleft folks distrust it. For the exact wording of each clause, read the Apache License 2.0 itself before you rely on any summary.

Where the Apache License actually gets used

Libraries, SDKs, and infrastructure meant to be embedded everywhere. If you're publishing a client library you want in as many codebases as possible, Apache removes the friction that scares legal teams off. They can link it, ship it, and never worry that shipping triggers a source-release obligation.

Companies default to it for one more reason: the patent grant. A large project run inside a foundation, with many corporate contributors, needs each contributor to promise they won't sue users over patents in the code they donated. Apache bakes that promise in. That's why so much of the modern data and cloud stack, Kafka, Cassandra, Hadoop and their kin, sits under it. It's a license built for organizations, not just individuals.

How the two licenses actually differ

Permissive versus copyleft. That's the whole split, and everything else follows from it. Apache lets downstream users take your code closed. GPL forbids it: distribute a derivative work and you ship the complete corresponding source under the same license, or you don't ship at all.

Here's the head-to-head that matters in practice.

The philosophical gap is real, not academic. Apache trusts adopters to do the right thing and optimizes for reach. GPL doesn't trust them and encodes that distrust as a legal obligation. Neither is wrong. They serve different goals, and picking the wrong one for your goal is how projects end up stuck.

What GPL's share-alike rule forces on you

It forces you to hand over source whenever you distribute a derivative work. Not when you use the code privately. Not when you run it on a server for your own use, under GPLv2 or GPLv3. The trigger is distribution: the moment a modified binary leaves your building and reaches a user, that user is owed the complete source, the build instructions, and the same license.

The hard part is deciding what counts as a derivative. For a Linux kernel module, that turns on linking and how deep you reach into kernel internals, and it has burned real projects. A module that uses GPL-only kernel symbols is treated as derivative. One that talks only through a narrow, documented interface is arguable. So engineering and legal need to agree on the architecture early, not after the ship date. If you're touching kernel code, our guide on keeping kernel modules GPL-compliant walks the real cases.

What the Apache patent clause protects you from

It protects you from the contributor who donates code, then sues you for using it. Every Apache contributor grants a perpetual, worldwide patent license covering their contributions. So when you build on the code, you already hold a license to the patents that read on it. That's a concrete shield against assertion risk, not a theoretical nicety.

The retaliation clause is the clever part. Sue someone claiming the software infringes your patent, and your grant terminates. Termination is automatic and applies only to the party filing the lawsuit, not to downstream users. So it deters patent aggression without punishing the whole community when one company turns litigious. GPLv2 has none of this, which becomes a problem the moment you try to mix the two.

Is Apache 2.0 compatible with GPLv3?

Yes, and this is where people trip. Apache License 2.0 is compatible with GPLv3, but not with GPLv2. The compatibility runs one direction: you can pull Apache-licensed code into a GPLv3 project, and the combined work goes out under GPLv3. You cannot go the other way and relicense GPL code as Apache.

That one-way flow is how permissive and copyleft coexist. GPLv3 was written to accept Apache's patent and notice terms, because those terms don't conflict with copyleft. So the Free Software Foundation lists Apache 2.0 as compatible. If your project is GPLv3, you can safely depend on Apache libraries. Just know the result is GPLv3, and it stays that way.

Why Apache and GPLv2 don't mix

The patent termination clause. That's the specific conflict, not some vague philosophical clash. Apache 2.0 ends your patent license if you file a patent suit over the code. GPLv2 says you cannot add any restriction beyond what GPLv2 itself imposes. A lawyer reads Apache's termination condition as exactly such an added restriction, so the two contradict each other and can't be combined in one distributed work.

This matters because the Linux kernel is licensed GPL-2.0 only, not "v2 or later." So you cannot merge Apache-licensed code straight into the mainline kernel. If you're staring at that wall for a driver, check whether LGPL fits a device driver instead, or plan a clean-room path. Know the incompatibility before you write a line, not after you've built on the wrong base.

Selling GPL software without breaking the license

You can, and here's the misconception worth killing: GPL is not anti-commercial. Companies sell GPL software every day. What GPL restricts is closing the source of a derivative you distribute, not charging money for it. Red Hat built a business on this.

The friction is precise. Use GPL code internally, on your own servers, and you owe nothing to anyone. Modify it and ship the binary to customers, and you owe them the source under the same license. So the real question is never "commercial or not." It's "am I distributing a derivative work?" If you are, copyleft applies and no license fee makes it go away. If you can't accept releasing source, you need a permissively licensed dependency or a separate commercial license from the copyright holder. Plenty of projects sell exactly that dual arrangement.

Does the Apache License behave the same across ecosystems?

Legally, yes. The license text doesn't change because you published to npm, PyPI, or Maven Central. Copyright and contract law enforce it, not the package registry, so a permissive grant is a permissive grant whether the artifact is a JavaScript package or a Java JAR.

What differs is the plumbing. Maven and Java tooling surface license metadata and NOTICE files well, because the enterprise Java world has cared about compliance for years. The npm ecosystem is looser, and transitive dependencies bury license terms deep. So enforceability is identical, but your ability to see what you're pulling in varies a lot. Track license metadata in your repo and CI so notices actually travel with the artifacts you ship. The obligation doesn't disappear because a tool didn't show it to you.

Why MIT pulls more contributions than Apache or GPL

It asks for almost nothing. MIT is a few sentences: keep the copyright notice, don't sue, do whatever else you want. A casual contributor reads it in thirty seconds and moves on. Apache 2.0 is pages of patent and notice language, and GPL comes with obligations that make some contributors and their employers hesitate.

That low barrier is the whole story. The less a license makes a drive-by contributor think, the more drive-by contributions you get. MIT trades away patent protection and copyleft guarantees for that simplicity, and for a small library the trade often pays. The catch: no patent grant means no shield if a contributor later asserts a patent, and no copyleft means anyone can close your work. You're buying contributor growth with those protections.

How to pick between MIT, Apache, and GPL

Match the license to what you're actually protecting. Here's how I'd call it.

Apache 2.0 is the pick when you want your code everywhere and you want the patent shield. GPLv3 wins when your nightmare is a company forking your work into a closed product, and you'll take fewer users to prevent it. GPLv2 is mostly a compatibility decision: choose it because you must interoperate with the kernel or another GPL-2.0 codebase, not because it's better. MIT is right when you're publishing a small library and contributor count matters more than protection.

If you're still weighing options for a specific project, our walkthrough on choosing an open source license frames the tradeoffs against real goals. And whichever you pick, document why in the repo, so the next maintainer doesn't relitigate it.

FAQ

Does static versus dynamic linking change GPL obligations?

It can, and it's contested. The FSF holds that linking, static or dynamic, generally creates a derivative work, so both trigger copyleft. Some lawyers argue dynamic linking against a stable interface is weaker. Don't bet a product on the aggressive reading. For kernel modules specifically, the MODULE_LICENSE string you declare also controls which GPL-only symbols you can even link against.

Can I relicense an Apache project under GPL later?

You can distribute a combined work under GPLv3, since Apache 2.0 is compatible with it. You cannot strip the Apache license off code you didn't author. Existing copyright holders keep their grant, so past releases stay available under Apache no matter what you do going forward.

Does Apache 2.0 require me to publish my source code?

No. That's the core difference from GPL. Apache asks you to preserve notices, state your changes, and keep the NOTICE file, but never to release your source. You can ship a modified Apache-licensed binary and keep the code private.

Is dual licensing a way around GPL's copyleft?

Yes, if you own the copyright. Many projects offer the code under GPL for the community and sell a separate commercial license to companies that can't accept share-alike. You can only do this if you hold rights to all the code, which usually means requiring a contributor agreement from everyone who submits patches.

Why is the Linux kernel GPL-2.0 only and not a later version?

The kernel is licensed as GPL version 2 only, without the usual "or later" option, a deliberate choice by Linus Torvalds and other maintainers. It means the kernel can never automatically move to GPLv3, and it's the technical reason Apache 2.0 code can't be merged into the mainline tree.