Start with your goal
Choosing a license is not a matter of taste but of what you want. Most people sit somewhere between these two goals.
- You want it used as widely as possible — If you want it to go anywhere without friction, whether corporate products, other open source projects or closed-source apps, permissive licenses have the advantage.
- You want improvements to come back publicly — If you want changes to be published whenever someone modifies and distributes your code, copyleft is the right fit.
Permissive: wide adoption, little friction
MIT, BSD, ISC and Apache-2.0 require little more than keeping notices. Most corporate legal teams have them on their pre-approved lists, so adoption is fast. On the other hand, you cannot stop someone from modifying your code and putting it in a closed product.
Choosing among permissive licenses mainly comes down to two things.
- Patents: Apache-2.0 if you need an express patent grant and a patent retaliation clause, otherwise MIT.
- Compatibility with GPL-2.0: The FSF's position is that Apache-2.0 cannot go into GPL-2.0-only projects, so MIT or BSD is easier in the ecosystem around the Linux kernel.
Copyleft: a chain of openness
The GPL sets disclosure obligations for the whole combined program, the LGPL for the library and the MPL per file. For software that runs on servers, the AGPL fills the GPL's gap. With copyleft, some companies may hesitate to use or contribute to your project. The AGPL in particular is restricted by many companies' internal policies. That may be the intended effect, or an unwanted side effect.
Ecosystem conventions matter too
A license causes less friction when it matches community conventions.
| Ecosystem | Common licenses | Notes |
|---|---|---|
| JavaScript (npm) | MIT, ISC | Many small packages, so short permissive licenses are preferred |
| Rust (crates.io) | MIT OR Apache-2.0 | Rust itself uses this dual approach |
| Python (PyPI) | MIT, BSD-3-Clause, Apache-2.0 | BSD-3 is common in scientific computing |
| Go | BSD-3-Clause, MIT, Apache-2.0 | The Go standard library is BSD-3 |
| Linux kernel modules | GPL-2.0-only | Practically required to combine with the kernel |
| Desktop GNU tools | GPL-3.0-or-later | Default for GNU projects |
| C/C++ libraries | LGPL, MIT, BSL-1.0 | The linking method influences the choice |
Decision checklist
- Check dependencies: See whether the licenses of libraries you already use limit your options. If you distribute a program combined with a GPL library, your options narrow to GPL-compatible licenses.
- Check ownership: Code written for work is usually owned by the employer. Check whether your company's open source policy specifies a license.
- Usage: The effect of copyleft differs depending on whether it is installed software, a library or a service.
- Contribution model: If you plan to accept outside contributions, keep in mind that changing the license later will be difficult, because multiple people's copyrights get mixed in.
- Revenue model: If you plan to sell a separate commercial license, consider copyleft + commercial dual licensing together with a Contributor License Agreement (CLA).
One-line summary
- Wide adoption comes first → MIT (Apache-2.0 if patents are a concern)
- Want library improvements back but leave users free → MPL-2.0 or LGPL-3.0
- Want every derived program published → GPL-3.0
- Want even modified server software published → AGPL-3.0
- Want no conditions at all → 0BSD, Unlicense, CC0
Answer these criteria as questions in the license wizard to see candidates and reasons.
This article is general information, not legal advice. Consult a professional for important decisions.
Sources
- choosealicense.com — https://choosealicense.com/
- FSF, Various Licenses and Comments about Them — https://www.gnu.org/licenses/license-list.html
- Rust licensing (MIT OR Apache-2.0) — https://github.com/rust-lang/rust