How to Choose an Open Source License (Without a Law Degree)
Picking an open source license feels like it should be a five-minute task, yet it paralyzes developers for days. MIT vs Apache vs GPL. Permissive vs copyleft. Patent grants, tivoization, the “SaaS loophole.” The vocabulary alone is enough to make you close the tab and ship your code with no license at all — which, as you’ll see below, is the one choice that is genuinely dangerous.
This guide walks through everything a working developer needs: what the eight most important licenses actually require of you, how MIT vs Apache 2.0 vs GPL really differ, how open source license compatibility works when you mix code, and how to apply a license to your project in about sixty seconds. By the end, you’ll be able to answer the question “which license should I choose?” with confidence instead of vibes.
Why your project needs a license at all
Here is the uncomfortable truth most tutorials skip: if you publish code with no license, nobody is allowed to use it. Copyright law in almost every country grants the author “all rights reserved” by default. Pushing code to a public repository does not waive those rights — it just lets people look at your code. Without a license, other developers have no legal permission to copy it, modify it, or build on it, no matter how public the repository is.
An open source license is simply you, the copyright holder, granting the public a set of permissions in advance: to use, study, modify, and share your work. Every license on the Permitly deck does that. What differs is the conditions attached — and those conditions are the entire game.
MIT vs Apache 2.0 vs GPL: the big three, compared
Roughly nine out of ten open source projects use one of three licenses, so let’s settle the MIT vs Apache vs GPL debate properly.
The MIT License is the shortest and most popular license in the world. It says, in essence: do whatever you want with this code — use it, change it, sell it, bury it inside a proprietary product — as long as you keep the copyright notice attached. That’s it. No patent grant, no share-alike requirement, no paperwork beyond the notice. Its brevity is its superpower: every developer on earth understands it in thirty seconds, which is why libraries like React, Vue.js, and Node.js chose it. If your goal is maximum adoption, MIT is the default answer.
The Apache License 2.0 is MIT’s more careful sibling. It grants the same broad freedoms, but it adds two things lawyers care about: an explicit patent grant (every contributor automatically licenses their relevant patents to users, and anyone who sues over those patents loses their license) and precise definitions of terms like “derivative work.” It also asks you to document significant changes you make. The cost is length — a few pages instead of a paragraph — but the payoff is corporate adoption: most large companies’ legal teams have pre-approved Apache-2.0, which is why Kubernetes, Android, and TensorFlow wear it.
The GNU General Public License (GPL-3.0) plays a different game entirely. Where MIT and Apache are permissive — “do what you want” — the GPL is copyleft: “you may build on this, but your version must grant the same freedoms.” Anyone who distributes your code, or a program built from it, must release the complete source under the GPL too. It also includes patent protection and famously blocks “tivoization” (shipping GPL software on locked-down hardware). The GPL is the license you pick when your priority isn’t adoption but freedom that can’t be taken away — no one can ever turn your work into a proprietary product.
| MIT | Apache-2.0 | GPL-3.0 | |
|---|---|---|---|
| Copyleft | None | None | Strong |
| Closed-source forks allowed | Yes | Yes | No |
| Explicit patent grant | No | Yes | Yes |
| Must document changes | No | Yes | Yes |
| Text length | ~20 lines | ~200 lines | ~600 lines |
| Famous users | React, Node.js | Kubernetes, Android | GCC, WordPress* |
* WordPress uses GPL version 2 or later; the GPL family shares the same copyleft philosophy.
Permissive vs copyleft: the one distinction that matters
Strip away the legalese and every license decision reduces to one question: when someone builds on your work, must they keep it open?
Permissive licenses (MIT, Apache-2.0, BSD-3-Clause) say no. They maximize the number of people who can use your code — including inside proprietary products — at the cost of letting improvements disappear behind closed doors. Choose permissive when adoption matters more than control: libraries, frameworks, developer tools, and anything where ubiquity is the goal.
Copyleft licenses (GPL-3.0, AGPL-3.0, and the weaker LGPL-3.0 and MPL-2.0) say yes, to varying degrees. Strong copyleft (GPL) infects the entire combined work: distribute a program containing GPL code and the whole thing must be GPL. Weak or file-level copyleft (MPL-2.0, LGPL-3.0) is surgical: only the licensed files — or the library itself — must stay open, while the rest of the project can be anything. Network copyleft (AGPL-3.0) extends the GPL’s reach to software used over a network: run a modified AGPL program on your servers and you must offer its source to your users. Choose copyleft when you want to guarantee the software — and everything built from it — stays free forever.
Neither camp is morally superior; they optimize for different outcomes. The Linux kernel’s GPL kept an entire ecosystem open. MIT’s permissiveness made JavaScript’s ecosystem explode. Know which game you’re playing.
The other five cards in the deck
LGPL-3.0 is the GPL’s kinder sibling, designed for libraries. A proprietary application may link against an LGPL library (dynamically), but modifications to the library itself must be shared. Qt, FFmpeg, and VLC use it: the libraries stay open while the apps built on them can be anything.
MPL-2.0 (Mozilla Public License) is the pragmatic middle path and a favorite of corporate open source programs. Copyleft applies file by file: change an MPL-licensed file and that file stays open; add your own new files and they can be proprietary. It even declares itself compatible with the GPL, so a future relicense is painless. Firefox and Thunderbird ship under it.
BSD 3-Clause is MIT’s near-twin with one extra sentence: nobody may use your name to endorse products built from your code. Academic projects (Django, FreeBSD, NumPy) love it. In practice, choose between MIT and BSD on vibes — they’re functionally interchangeable.
AGPL-3.0 exists because of a loophole. The GPL’s share-alike duty triggers on distribution — but a company can take GPL code, modify it, run it on their servers, and never “distribute” anything, keeping all improvements private. The AGPL closes that gap: network use counts too. If you run a SaaS and want its code to stay open, AGPL is your card. Mastodon, Nextcloud, and MinIO chose it. Be warned: it’s the strictest mainstream license, and many companies ban AGPL dependencies outright.
The Unlicense is a public-domain dedication — you waive every copyright interest you hold, and anyone can do anything, not even attribution required. It’s perfect for snippets and tiny utilities where even a license header feels like friction. One caveat: some jurisdictions don’t fully recognize public-domain dedications, so for international projects the Creative Commons CC0 dedication is the safer equivalent.
Open source license compatibility: the rules of mixing code
Modern projects are mosaics: your code plus dozens of dependencies, each with its own license. License compatibility asks whether those licenses can legally coexist in one combined work. Get it wrong and you can accidentally obligate yourself to open-source your entire proprietary product — or ship code you had no right to combine.
The good news: the rules are simpler than they look. Permissive licenses combine with everything. MIT, BSD, and Apache-2.0 code can be dropped into any project — you just keep their copyright notices. (Apache-2.0 is even explicitly compatible with GPL-3.0 projects.) The friction always flows one way: from copyleft into permissive. You can put MIT code inside a GPL project, but you cannot put GPL code inside an MIT project without the whole thing becoming GPL.
Three classic traps to memorize. Trap one: pulling a GPL-3.0 library into your MIT-licensed app. The moment you distribute the combination, your entire app must be GPL-3.0. Either relicense, or find an alternative library. Trap two: assuming “we only use it on our servers” protects you from the AGPL. It doesn’t — that’s precisely what the AGPL was written to catch. Trap three: statically linking an LGPL library into your binary. The LGPL’s freedom to link applies to dynamic linking; bake the library into your executable and your program inherits the LGPL’s terms. When in doubt, run the pair through the compatibility checker above — it encodes all of these rules in plain English.
How to apply a license to your project in 60 seconds
Choosing is the hard part; applying takes a minute. Generate your LICENSE file with the mint above, save it as LICENSE (no extension) in your repository root, and add the license identifier to your package metadata — the license field in package.json, setup.py, or Cargo.toml. For GPL-family licenses, also add the short copyright-and-license header to the top of each source file; the generated text includes the exact template. That’s genuinely all most projects need.
Can you change your license later?
Yes — but only with permission. You own your copyright, so you can relicense your own code any time. The catch is other people’s contributions: once someone contributes under MIT, you need every contributor’s consent to move the project to GPL. This is why large projects ask contributors to sign a Contributor License Agreement (CLA) up front. Moral of the story: pick carefully now, because every merged pull request makes a future switch harder.
Three myths worth killing
Myth: “Open source means I give up copyright.” No — you keep your copyright. A license is you exercising it by granting permissions on your terms. Only public-domain dedications like the Unlicense waive copyright itself.
Myth: “GPL means I can’t make money.” The GPL explicitly permits selling software — “free” refers to freedom, not price. What you can’t do is sell it without the source and freedoms attached.
Myth: “If I rewrite it from scratch, the license doesn’t apply.” A genuine clean-room reimplementation is yours. But “rewriting” that closely follows the original’s structure is a derivative work in most jurisdictions — don’t launder licenses.
Still torn? Scroll up and take the five-question quiz — it scores every license against your actual priorities and shows its reasoning. Then mint your LICENSE file and get back to building.