Mainstream Open Source Licenses: From MIT to AGPL, How Engineers Choose

In September 2017, React switched overnight from BSD+Patents to MIT. The reason: the Apache Software Foundation put React’s license on its “do not depend on” list, and Automattic (WordPress’s parent) immediately announced it would stop rewriting its UI on React. Facebook couldn’t withstand the ecosystem pressure and folded. Seven years later, in March 2024, Redis moved its core from BSD 3-Clause to a dual RSALv2+SSPL license — within a week AWS, Google, and Oracle jointly forked Valkey to replace it.

These two events, seven years apart, are about the same problem: open source is not free-for-any-use. Every open source license is a contract that defines what you may do, what you must do, and when your grant terminates. Pick the wrong one and you can be forced to open source your entire product, or eat a copyright lawsuit. Courts in both the US and China have ruled that open source licenses are legally enforceable — we’ll get to that.

This post walks through 14 mainstream OSI-approved open source licenses: where each draws its copyleft boundary, how its patent clause reads, and which scenarios it fits. The follow-up post covers Source Available (source-visible but not open source) and the license battles of the AI era.

The Copyleft Spectrum: Start With a Map

Line up all open source licenses on a spectrum, with virality increasing left to right:

flowchart TD
    A["CC0 / Unlicense<br/>Public Domain"] --> B["MIT / BSD / ISC<br/>Permissive"]
    B --> C["Apache 2.0<br/>Permissive + Patent"]
    C --> D["MPL / EPL / CDDL<br/>File-level Weak Copyleft"]
    D --> E["LGPL v3<br/>Library-level Weak Copyleft"]
    E --> F["GPL v2 / v3<br/>Strong Copyleft"]
    F --> G["AGPL v3<br/>Network Triggers Open Source"]

    classDef free fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    classDef perm fill:#bbdefb,stroke:#2196F3,color:#0D4741
    classDef weak fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef strong fill:#ffcdd2,stroke:#f44336,color:#B71C1C
    class A free
    class B,C perm
    class D,E weak
    class F,G strong

The left end is “use it however, don’t bother me” — CC0 and Unlicense. The right end is AGPL v3: even if you only deploy a modified version as a cloud SaaS and users access it over the network, you must release the modified source. The middle weak-copyleft zone is the easiest for engineers to misread: MPL sits at “file level”, LGPL at “library level” — they sound similar but the contagion boundary is completely different.

Once this map clicks, the four groups below are just details.

Public Domain: CC0 and Unlicense

Code dedicated to the public domain with all rights waived.

The Unlicense (SPDX: Unlicense) — OSI approved. Explicitly waives all copyright interest; anyone can copy, modify, sell for any purpose, no conditions. Projects: kakoune, react-use. Its weakness: no patent grant, and no legal fallback like CC0’s “waiver invalid → public license” mechanism.

CC0 1.0 Universal (SPDX: CC0-1.0) — Recognized as free by the FSF but not approved by OSI. Maintained by Creative Commons, originally for data and content but works for software too. Its key feature is a dual structure of “waiver + public-license fallback”: if your jurisdiction doesn’t recognize copyright waiver, it auto-falls-back to a royalty-free public license, effectively equivalent to public domain. But it explicitly excludes patent grants — for patent-sensitive software it’s less safe than Apache 2.0.

These two see limited real-world use; most people just pick MIT.

Permissive: MIT, BSD, ISC, Apache 2.0

Permissive licenses share one trait: use, modify, close-source and sell — all fine. The only obligation is retain the original author’s copyright notice and license text. This group is what commercial companies love, because it imposes no downstream contagion.

MIT / BSD 2-Clause / ISC: Three Nearly-Equivalent Siblings

Functionally equivalent; the differences are wording only. The legal effect is identical: keep the copyright notice, everything else is released.

• MIT License (MIT): About 170 words, the world’s most popular permissive license. React, jQuery, Rails, .NET Core.
• BSD 2-Clause (BSD-2-Clause): Homebrew, go-redis. The early BSD had an “advertising clause” requiring all derivative promotions to mention the original author; it was stripped, giving rise to the 2-Clause and 3-Clause variants.
• ISC License (ISC): Heavily used in the OpenBSD family and npm ecosystem (Node.js semver, Starship). Cleaner wording than BSD/MIT, with outdated legal language removed.

All three share one weakness: no patent grant clause. If an author holds relevant patents, they can in theory sue you for patent infringement at any time. Not a big deal for sprawling frontend libraries or small utilities; riskier for algorithm-patent-laden core components.

BSD 3-Clause: Adds an Anti-Endorsement Clause

One more clause on top of 2-Clause: without prior written consent from the copyright holder, you may not use the name of the copyright holder or contributors to endorse or promote derivative products. Flutter, LevelDB, Quill use it. Pick this if you don’t want your project’s name hijacked for someone else’s marketing.

Apache 2.0: The Only Permissive License With Patent Protection

Apache 2.0 is the enterprise open source default. Kubernetes, Swift, PDF.js, much of Android use it. Compared to MIT/BSD it adds four things — think of it as “permissive + four safeguards”:

flowchart TD
    AP["Apache 2.0<br/>Permissive Baseline"] --> P1["Patent Grant<br/>Perpetual/Worldwide/Royalty-free"]
    AP --> P2["Patent Retaliation<br/>Sue and License Terminates"]
    AP --> P3["NOTICE File<br/>Attribution Notices"]
    AP --> P4["Change Notice<br/>Mark Modified Files"]

    classDef base fill:#bbdefb,stroke:#2196F3,color:#0D4741
    classDef prot fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class AP base
    class P1,P2,P3,P4 prot

• Patent grant: Every contributor grants you a “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable” patent license covering claims their contribution necessarily infringes. MIT/BSD have nothing like this, which is why large enterprises often ban direct use of patent-sensitive MIT components, or require a legal review.
• Patent retaliation: If you sue any entity alleging the work infringes your patents, your patent grant terminates as of the date the lawsuit is filed. Symmetric protection — prevents someone from using the code while simultaneously patent-trolling the author.
• NOTICE file: If the original work carries a NOTICE file, derivatives must include its attribution notices when distributed. This is the most commonly missed clause — many people copy LICENSE but forget NOTICE.
• Change notice: Modified files must carry a prominent “changed” mark.

Apache 2.0 explicitly does not grant trademark rights — similar in spirit to BSD 3-Clause’s anti-endorsement clause. You cannot slap the Kubernetes logo on your own commercial distribution.

Weak Copyleft: MPL, LGPL, EPL, CDDL, EUPL

The core of weak copyleft is “contagion has a boundary”. Modified parts must be open; newly added parts can stay closed. Where exactly that boundary sits differs per license:

• MPL 2.0 (MPL-2.0): Boundary is at the file. Modify an MPL file, that file stays MPL-distributed; new files you add are unaffected and can be shipped closed as part of a “Larger Work”. Firefox, Thunderbird, early HashiCorp products use it. File-level is the most commercially friendly weak copyleft.
• LGPL v3 (LGPL-3.0): Boundary is at the library. Designed so closed applications can link against LGPL libraries, but modifications to the library itself must be open, and you must provide “Minimal Corresponding Source” so users can relink against a modified library. GTK, parts of Qt, the LGPL portion of FFmpeg.
• EPL 2.0 (EPL-2.0): The Eclipse family, with contagion scope defined by “Modified Works”, similar to MPL’s file level. Eclipse IDE, JUnit 5, Jakarta EE. The key design feature is “Secondary License = GPL v2+”, which resolved the historical EPL/GPL incompatibility.
• CDDL 1.0/1.1 (CDDL-1.0): Oracle-stewarded, evolved from MPL 1.1, file-level. OpenSolaris derivatives, GlassFish.
• EUPL 1.2 (EUPL-1.2): The EU’s official license, available in all 23 official EU languages, each with equal legal force. Its standout feature is an explicit compatibility list (GPL, AGPL, LGPL, MPL, EPL, etc.); derivative works may be relicensed under any license on the list.

Why does file-level matter so much? Because it draws a commercializable boundary. Drop an MPL library into a closed-source commercial product — as long as you don’t touch its source files, the whole product ships closed. Swap in GPL and the entire product must be open. That’s exactly why HashiCorp could raise VC money under MPL before later moving to BSL — MPL gave them room for “open core + closed commercial extensions”.

Strong Copyleft: GPL v2, GPL v3, AGPL v3

Strong copyleft offers no boundary compromise: derivative works must be open sourced in full under the same license. This group is the one commercial companies are most wary of.

GPL v2 vs GPL v3: What’s Different

The Linux kernel remains pinned to GPL v2 (explicitly GPL-2.0-only, not accepting upgrades), while Bash, GCC, and Samba use GPL v3. Both are strong copyleft, but v3 adds three things over v2:

• Explicit patent grant + retaliation: v2 grumbles about software patents in the preamble but has no clause; v3 explicitly grants patent licenses and adds “sue and your grant terminates” retaliation.
• Anti-Tivoization: For consumer products, distributing object code requires providing “Installation Information” — keys and methods needed to install and run modified versions; you can’t use technical measures to block user modifications. The term comes from TiVo set-top boxes, which used a GPL kernel but locked down modified versions via hardware signatures — the FSF considered this a violation of GPL’s spirit.
• Anti-DRM / anti-circumvention: Covered works cannot be treated as “effective technological measures” under the WIPO copyright treaty; distributors waive legal rights to prohibit circumvention of technological measures.

In practice: if your project needs Linux-kernel ecosystem compatibility, you must use GPL v2 (or a “v2 or later” compatibility clause). If you want to close patent loopholes and hardware-locking loopholes, use GPL v3.

AGPL v3: Closing the SaaS Loophole

AGPL v3 is GPL v3 plus Section 13 “network use is distribution”:

If you offer users the ability to interact with a modified version over a network, you must offer them the complete corresponding source of your modified version.

This clause is purpose-built for SaaS. GPL v3 Section 6 only restricts “convey” (transmitting copies to others) — meaning if you don’t distribute copies and just deploy a modified version as a cloud service, no open-source obligation triggers. This is the so-called “ASP loophole”. AGPL closes it: even if users only access it over the network, you owe source.

Mastodon, Nextcloud, and Ghostscript use AGPL v3. MongoDB, Elastic, and Redis all used AGPL v3 at various points — and all later decided AGPL wasn’t enough. The follow-up post covers how they evolved to SSPL and then back to AGPL.

Mainstream License Comparison Matrix

Roll the four groups into one table:

Pulling three dimensions out makes it clearer:

Patent grant — Explicit clauses: Apache 2.0, MPL 2.0, LGPL v3, EPL 2.0, CDDL, GPL v3, AGPL v3, EUPL 1.2. None: MIT, BSD, ISC, Unlicense, GPL v2. Explicitly excluded: CC0 1.0.

Network triggers open source — Only AGPL v3. No other OSI open source license triggers an open-source obligation just because you deploy it as SaaS.

Trademark restriction — Explicitly not granted: Apache 2.0, MPL 2.0, BSD 3-Clause, EUPL 1.2. Not addressed: MIT, BSD 2-Clause, ISC, Unlicense.

A Decision Tree: From Use Case to License

When you pick a license for a new project, walk this diagram:

flowchart TD
    Q1{"Allow closed-source<br/>derivatives?"} -->|"Yes"| Q2{"Patent issues<br/>or trademark needs?"}
    Q1 -->|"No"| Q4{"Will it be deployed<br/>as a network service?"}

    Q2 -->|"No"| A1["MIT / BSD / ISC"]
    Q2 -->|"Yes"| A2["Apache 2.0"]

    Q4 -->|"Yes"| A5["AGPL v3"]
    Q4 -->|"No"| Q5{"Should closed apps<br/>be allowed to link it?"}

    Q5 -->|"Yes"| Q6{"Library or file-level?"}
    Q5 -->|"No"| A4["GPL v3"]

    Q6 -->|"Library"| A3["LGPL v3"]
    Q6 -->|"File-level"| A6["MPL 2.0 / EPL 2.0"]

    classDef q fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef r fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class Q1,Q2,Q4,Q5,Q6 q
    class A1,A2,A3,A4,A5,A6 r

A few extras:

• Personal tool or demo → MIT. Simple enough to not think about.
• Internal company framework, want business teams to use it without external freeloading → MPL 2.0. File-level contagion preserves your control over modifications without blocking business teams from shipping closed source.
• Foundational library you want widely linked → LGPL v3. Explicitly allows closed apps to link.
• Operating system kernel or compiler → GPL v2 (Linux compatibility) or GPL v3.
• SaaS product core → AGPL v3. But cloud providers can still route around this — the next post covers why MongoDB decided AGPL wasn’t enough and invented SSPL.
• EU government projects → EUPL 1.2; multilingual equivalence and the compatibility mechanism are hard requirements.

Common Misreadings

“MIT doesn’t require keeping the copyright notice” — Wrong. MIT’s only obligation is to retain the copyright notice and license text. You may think MIT means freely deleting author names, but that’s a breach; the original author just isn’t suing you.

“Dynamically linking GPL code doesn’t trigger copyleft” — The FSF’s official position is dynamic linking also constitutes a derivative work, so the whole must be GPL. The legal definition of “derivative work” is indeed fuzzy, but dynamically linking GPL code into a proprietary product is very likely a GPL violation. To stay closed, either use LGPL, go through IPC, or clean-room reimplement.

“AGPL is safe as long as you don’t distribute” — Wrong. AGPL Section 13 specifically triggers on “providing interactive services over a network”. As long as you deploy a modified version as a web service that users access, the open-source obligation triggers.

“Source visible = open source” — Wrong. Source Available is not the same as Open Source. BSL, SSPL, ELv2, RSALv2, and FSL are not open source licenses; OSI has not approved them. The next post is dedicated to this group.

References

• SPDX License List: https://spdx.org/licenses/
• OSI Approved Licenses: https://opensource.org/licenses/alphabetical
• GitHub choosealicense.com: https://choosealicense.com/licenses/
• Apache 2.0 full text: https://choosealicense.com/licenses/apache-2.0/
• MPL 2.0 full text: https://choosealicense.com/licenses/mpl-2.0/
• GPL v3 full text: https://choosealicense.com/licenses/gpl-3.0/
• AGPL v3 full text: https://choosealicense.com/licenses/agpl-3.0/
• LGPL v3 full text: https://choosealicense.com/licenses/lgpl-3.0/
• EPL 2.0 full text: https://www.eclipse.org/legal/epl-2.0/
• EUPL 1.2 full text: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12

The next post, From Redis Switching to BSL to the AGPL Revival: Source Available, AI, and the License Wars, picks up the thread: how BSL/SSPL/ELv2/RSALv2/FSL turn “source visible” into a business model, how the four license wars of MongoDB/Elastic/HashiCorp/Redis played out, and what’s new in AI-era licenses.