Pick a license before your first commit, not after your first contributor asks what the rules are. Changing it later needs consent from every contributor who owns copyright on their contributions — with a handful of people that’s an email thread, with fifty it’s a project-ending headache. Get it right once.

The three you actually need to know

MIT — the default for a reason. Anyone can use, modify, and sell your code, including in closed-source commercial products, as long as they keep the license notice. Maximally permissive, minimal text, no ambiguity. If you’re not sure what you want, this is the safe default for a library or tool you want widely adopted.

Apache 2.0 — MIT’s permissiveness plus an explicit patent grant: contributors grant users a license to any patents they hold that read on the code. This matters once your project is big enough that patent litigation is a realistic risk — mostly relevant for infrastructure-level projects, not a weekend CLI tool. It also requires stating changes made to the code, which MIT doesn’t.

AGPL — the copyleft option. If someone modifies your code and runs it as a network service (a SaaS, essentially), they must release their modified source too — this is the clause GPL doesn’t have and it’s the whole point of AGPL. Use this when your actual goal is preventing a cloud provider from taking your project, hosting it, and never contributing anything back.

The decision that actually matters: do you want companies building closed products on top of you?

flowchart TD
    A{"Want companies building closed\nproducts on top of you?"} -->|"Yes, no strings"| B["MIT or Apache 2.0"]
    A -->|"Yes, but must credit,\nno patent trolling"| C["Apache 2.0"]
    A -->|"No, hosted use must\ngive back changes"| D["AGPL"]
  

This is the one real fork in the decision tree. Everything else (dual licensing, CLA requirements, trademark policy) is a layer on top of this choice, not a replacement for making it.

What “AGPL protects me from big clouds” actually means

AGPL doesn’t stop a hosting provider from running your software as a paid service — it just forces them to open-source any changes they made to do it. In practice, most large providers avoid AGPL-licensed dependencies entirely rather than comply, which is often the real deterrent effect people are after. If your actual goal is a commercial dual-license business (open core, paid enterprise features, or “AGPL unless you buy a commercial license”), AGPL is the standard mechanism — MongoDB started on it before moving to the stricter SSPL, and Grafana Labs still ships Grafana itself under AGPL today.

Don’t skip the CLA question

If you want the option to relicense later, or to offer a commercial license alongside the open one, you need contributors to sign a Contributor License Agreement (or use a Developer Certificate of Origin, the lighter-weight alternative most projects actually use now) from day one. Retrofitting this onto an existing contributor base is the exact problem you’re avoiding by choosing carefully now — you’d need every past contributor’s sign-off.

DCO: contributors add "Signed-off-by" to commits — lightweight,
     no legal paperwork, sufficient for most projects.
CLA: contributors sign a formal agreement — heavier, needed only
     if you plan to dual-license or relicense later.

What to actually do

For most solo developers open-sourcing a tool: MIT, add a LICENSE file, done in five minutes. If you’re building something you might later dual-license commercially, or you specifically want to stop hosted clones: AGPL with a clear note in the README about why, plus a DCO from the first external PR. Skip the exotic licenses (SSPL, BSL, Elastic License) unless you’ve read what happened to the projects that adopted them and specifically want that tradeoff — they’re built for a narrow “protect against one specific hyperscaler” case, and they come with real community and ecosystem cost (several are no longer OSI-approved, which quietly excludes you from some distros and marketplaces).

---