Open Source Licensing: A Practical Primer for Developers
MIT, Apache 2.0, GPL, AGPL — choosing the wrong licence can have serious downstream consequences. Here is what each means in plain English.
Why Licences Matter
If you publish code without a licence, it is legally "all rights reserved" by default. No one can use it, modify it, or distribute it. If you want your code to be open source, you must attach an explicit licence.
Permissive Licences
MIT — The most popular. Allows anyone to do anything with your code as long as they include the original copyright notice. No copyleft, no patent grant.
Apache 2.0 — Like MIT but adds an explicit patent licence from contributors. Preferred by companies that care about patent risk.
BSD 2-Clause / 3-Clause — Similar to MIT with minor variations on advertising clauses.
Copyleft Licences
GPL v2 / v3 — If you distribute software that incorporates GPL code, your entire distribution must also be GPL. "Copyleft" or "viral" because it spreads to derivative works.
LGPL — A weaker copyleft. Libraries under LGPL can be linked dynamically without the caller needing to be LGPL.
AGPL v3 — Like GPL but also triggers when software is used over a network. If you run AGPL code as a web service, you must publish your source. This matters for SaaS companies.
Choosing a Licence
| Goal | Recommended licence |
|---|---|
| Maximum adoption | MIT or Apache 2.0 |
| Ensure improvements flow back | GPL v3 |
| Prevent SaaS capture | AGPL v3 |
| Library, minimal friction | MIT or LGPL |
SPDX Identifiers
Use SPDX short identifiers in your package.json:
{ "license": "Apache-2.0" }
This is machine-readable and understood by dependency scanners like Dependabot and FOSSA.