Permissive vs copyleft: which license to choose

Once you understand the two families — permissive and copyleft¹ — picking a license for your own project comes down to a single tradeoff. Permissive optimizes for adoption: anyone can use your code, including in closed products, so it spreads with no friction. Copyleft optimizes for reciprocity: anyone who builds on your code and ships it must keep their changes open, so the commons grows but some users walk away rather than accept the condition. You cannot maximize both. Choosing is choosing which one you care about more.

🔗 Learn more — ¹ Copyleft and the GPL family

What each one optimizes

Permissive (MIT, BSD, Apache 2.0) trades control for reach. You give up any claim on derivatives in exchange for the widest possible use. Companies adopt permissive code freely because it never threatens their proprietary product. The cost: a well-funded vendor can take your work, build a closed product on it, and give nothing back.
Copyleft (GPL, AGPL) trades reach for guarantees. Every downstream user keeps the freedoms you gave them, and improvements flow back to the commons. The cost: organizations with a no-copyleft policy — and many large ones have exactly that — won't touch it, so your potential user base is smaller.

The questions that decide it

flowchart TD
    START["What are you releasing?"] --> LIB["A library others embed?"]
    START --> APP["An application or service?"]
    LIB --> UBI["Want it everywhere, even closed products? → Permissive (Apache 2.0)"]
    LIB --> BACK["Want fixes to the library back? → Weak copyleft (LGPL)"]
    APP --> SAAS["Afraid a cloud will host it and give nothing back? → AGPL"]
    APP --> SHARE["Want all redistributors to stay open? → GPL"]
    APP --> SPREAD["Want maximum adoption, don't mind closed forks? → Permissive"]

    classDef plain stroke:#7b88a1,stroke-width:2.5px
    classDef key stroke:#a3be8c,stroke-width:2.5px
    class SAAS key
    class START,LIB,APP,UBI,BACK,SHARE,SPREAD plain

A rough decision tree. The branch that trips people up is the highlighted one: if your worry is a cloud provider hosting your work as a service and contributing nothing, only the AGPL's network clause actually addresses it — plain GPL does not.

In words:

A library you want everywhere → permissive, and specifically Apache 2.0 for its patent grant. This is why almost every widely-embedded library is permissive.
A library where you want fixes back but not to block proprietary users → LGPL (weak copyleft).
An application or server where redistributors must stay open → GPL.
Server software you fear a cloud will resell as a hosted service → AGPL, the only common license whose obligation reaches network use.

My take

For libraries and infrastructure meant to become a standard, permissive — usually Apache 2.0 — is the correct default. Friction kills adoption, and a component nobody can depend on freely never becomes the thing everyone uses. That's the same governance logic that decided the table-format war: the least-encumbered option wins.

But for a finished product — especially server software — I have more sympathy for AGPL than its reputation suggests. The honest fear behind most recent relicensing blowups was a hyperscaler reselling the project as a managed service and returning nothing. The AGPL answers that fear while staying genuinely open source — which is exactly what the source-available licenses that replaced it failed to do. If you're tempted to reach for a "source-available" license to stop a cloud from free-riding, reach for the AGPL first. It solves the real problem without forfeiting the four freedoms.

Whichever you pick, the choice also constrains what you can combine your code with — that's license compatibility², and it has a few sharp edges worth knowing before you commit.

🔗 Learn more — ² Open-source license compatibility