Open Source Software Licenses

  • Description: How OSS licenses actually work — permissive (MIT/BSD/Apache) vs weak-copyleft (LGPL/MPL) vs strong-copyleft (GPL/AGPL) — plus practical guidance: which file goes where, what "compatibility" means, what triggers the copyleft, common compliance traps, and how to pick one for your own project.
  • My Notion Note ID: K2B-6-1
  • Created: 2020-06-07
  • Updated: 2026-05-22
  • License: Reuse is very welcome. Please credit Yu Zhang and link back to the original on yuzhang.io

Table of Contents

1. Why Licenses Matter

  • Default is "all rights reserved" under copyright law. Code with no license attached is not open source — you have no legal right to copy, modify, or redistribute it, even if it's on GitHub.
  • A license is a grant: the author says "here are the things you may do, here are the conditions."
  • Two axes that matter:
    • What's required when you redistribute (notice? source? same license?).
    • What counts as "redistribution" (binary copy? linked library? SaaS over the network?).
  • "Open source" in the formal sense = OSI-approved licenses on the Open Source Initiative list. "Free software" (FSF) is the GNU framing of the same idea with different emphasis — overlap is large but not identical.

2. The Three Families

Family Core demand on redistributor Examples Mental model
Permissive Keep the copyright notice. MIT, BSD-2/3, Apache-2.0, ISC, Unlicense "Use it however."
Weak copyleft Modifications to the library itself stay open; your linking code can be proprietary. LGPL-2.1, LGPL-3.0, MPL-2.0, EPL-2.0 "The lib stays open; your app can be closed."
Strong copyleft Any derivative work distributed must ship under the same license, with source. GPL-2.0, GPL-3.0, AGPL-3.0 "If you ship, you open."
  • AGPL extends "ship" to mean "let users interact over the network." A SaaS that modifies AGPL code must publish the modified source to its users. This is the only license in mainstream use that pierces the SaaS loophole.
  • "Copyleft" is a play on copyright — using copyright law to force openness rather than to restrict.

3. Major Licenses at a Glance

License Family Patent grant Notice required Same-license required SPDX ID
MIT Permissive implicit (weak) yes no MIT
BSD-3-Clause Permissive implicit yes no BSD-3-Clause
Apache-2.0 Permissive explicit yes (+ NOTICE) no Apache-2.0
ISC Permissive implicit yes no ISC
LGPL-3.0 Weak copyleft yes yes only the library LGPL-3.0-only / LGPL-3.0-or-later
MPL-2.0 Weak copyleft (file-level) yes yes per-file MPL-2.0
GPL-2.0 Strong copyleft implicit yes yes (entire derivative work) GPL-2.0-only / GPL-2.0-or-later
GPL-3.0 Strong copyleft explicit yes yes GPL-3.0-only / GPL-3.0-or-later
AGPL-3.0 Network copyleft explicit yes yes, including network use AGPL-3.0-only / AGPL-3.0-or-later
Unlicense / CC0 Public-domain equivalent varies no no Unlicense / CC0-1.0
  • SPDX identifiers are the machine-readable license labels. Use them in source files (SPDX-License-Identifier: Apache-2.0) and in package metadata. Tools (REUSE, FOSSA, SPDX SBOM tools) read them.
  • The -only vs -or-later distinction matters: GPL-2.0-or-later lets downstream relicense to GPL-3.0; GPL-2.0-only does not. The Linux kernel is GPL-2.0-only — that's why Linux can't pull GPL-3.0 code.

4. Permissive Licenses

4.1 MIT

  • ~170 words. Two clauses: keep the notice; no warranty.
  • Most-used license on GitHub. JavaScript and Rust ecosystems default to it.
  • Trade-off: no patent grant. If you build something with patentable techniques, contributors retain their patent rights and could theoretically sue users. Apache-2.0 closes this hole.
MIT License

Copyright (c) <year> <author>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND...

4.2 BSD

  • BSD-3-Clause ("New BSD") = MIT + "no endorsement using author's name." Used by NumPy, Go's own toolchain, FreeBSD.
  • BSD-2-Clause drops the endorsement clause. Effectively == MIT.
  • BSD-4-Clause ("Original BSD") has the infamous advertising clause requiring you to mention the author in ads. Causes incompatibility with GPL. Deprecated — don't use.

4.3 Apache-2.0

  • Permissive but explicit about patents: contributors grant patent rights to users; if you sue them over a patent in the code, your grant terminates (patent retaliation clause).
  • Requires a NOTICE file in distributions if the original has one. Edits to a file must be marked. Slightly more bureaucratic than MIT/BSD.
  • Default for big-company OSS (Apache Foundation, Google, Microsoft).
  • Compatible with GPL-3.0 but not GPL-2.0 — the patent clause conflicts with GPL-2.0's "no further restrictions" rule.

4.4 ISC, Unlicense, CC0

  • ISC — functionally MIT, simpler wording. OpenBSD, npm.
  • Unlicense / CC0 — "public domain or as close as your jurisdiction allows." Some countries (Germany, France) don't recognize voluntary entry into the public domain — these licenses include a fallback license grant for those jurisdictions. Avoid for projects that need patent clarity.

5. Weak Copyleft

5.1 LGPL

  • Designed for libraries. The library is GPL: modifications to it stay open. Code that uses the library (typically by dynamic linking) is not derivative.
  • Practical effect: ship a proprietary app that dynamically links an LGPL lib → you must let users replace the lib (so they can swap in their own modified version). Static linking + bundling triggers stronger obligations.
  • Original GNU C library uses LGPL — that's how proprietary apps can link libc on Linux without becoming GPL themselves.
  • LGPL-2.1 vs LGPL-3.0: 3.0 adds explicit patent terms and Tivoization protection (mostly inherited from GPL-3.0).

5.2 MPL-2.0

  • File-level copyleft. Modifications to MPL files must be open and stay MPL. Files you add can be under another license.
  • Result: you can mix MPL code into a larger proprietary codebase as long as you publish your edits to the MPL files.
  • Used by Mozilla (Firefox), Rust's tooling repos, much of the OpenStack ecosystem.
  • Explicitly compatible with both GPL and Apache — a deliberate design improvement over MPL-1.x.

5.3 EPL-2.0

  • Eclipse Public License. Similar shape to MPL: file-level. Adds an explicit patent retaliation clause.
  • Common in Java OSS: Eclipse IDE, JUnit, Jenkins. Not compatible with GPL-2.0; compatible with GPL-3.0 via a secondary-license clause.

6. Strong Copyleft and Network Copyleft

6.1 GPL

  • Any derivative work, when distributed, must:
    • Be released under the same GPL version (or later, if the original allows).
    • Ship with complete corresponding source.
    • Carry the same license + copyright notices.
  • Distribution = shipping binaries to someone. Internal use within an organization does not trigger source-disclosure — that's the famous "private use" loophole.
  • "Derivative work" is the legal grey zone. Static linking → almost certainly derivative. Dynamic linking → contested (the FSF says yes; some courts and lawyers disagree). Subprocess/IPC → almost certainly not.

GPL-2.0 vs GPL-3.0

GPL-2.0 GPL-3.0
Patents implicit (weak) explicit grant + retaliation
Anti-Tivoization no yes — must provide install info for consumer devices
Apache-2.0 compatibility no yes
License termination on violation immediate 30-day cure period
  • Linux kernel: GPL-2.0-only — deliberately, to keep kernel modules and userspace-tooling boundaries clear.

6.2 AGPL-3.0

  • Closes the SaaS loophole. If a user interacts with modified AGPL code over a network, you must provide them the modified source.
  • Used by MongoDB (until they switched to SSPL), Grafana (later relicensed), Ghostscript.
  • Avoid pulling AGPL code into a closed SaaS — even if you never "ship" a binary, hosting it triggers source-disclosure. Many companies have a blanket ban on AGPL dependencies.

6.3 SSPL / "source-available"

  • SSPL (MongoDB's Server Side Public License) — extends AGPL by demanding the entire stack (management, deployment, monitoring) also be open if you offer the software as a service. Not OSI-approved — therefore not "open source" in the formal sense.
  • BSL (Business Source License, used by HashiCorp), ELv2 (Elastic) — time-delayed open source: closed for N years, then auto-converts to a permissive license. Not OSS while under the BSL period.
  • Treat source-available licenses as proprietary for compliance purposes.

7. License Compatibility

Combining code under different licenses produces a combined work under the intersection of their grants. "Compatible" means there exists a license under which the combined work can be distributed.

Common compatibility lines:

  • Permissive → anything: MIT/BSD/Apache code can be embedded in GPL projects, proprietary projects, or other permissive projects. The resulting whole takes on the more-restrictive license.
  • GPL is one-way absorbing: anything compatible with GPL, when combined with GPL, becomes GPL.
  • Apache-2.0 + GPL-2.0: incompatible. Use Apache-2.0 + GPL-3.0 or upgrade.
  • GPL-2.0 + GPL-3.0: incompatible unless the GPL-2.0 code is GPL-2.0-or-later.
  • MPL-2.0: explicitly compatible with both GPL and Apache.
  • EPL-2.0 + GPL-2.0: incompatible.

FSF's compatibility matrix: https://www.gnu.org/licenses/license-list.html

8. Picking a License

Quick decision tree:

  • Want maximum adoption / library use → MIT or Apache-2.0.
  • Want maximum adoption AND care about patents → Apache-2.0.
  • Want to ensure improvements stay open AND prevent closed forks → GPL-3.0.
  • Want to prevent the "SaaS giant runs my code without contributing back" scenario → AGPL-3.0 (accept that it limits corporate adoption).
  • Want to release into public-domain-equivalent → CC0 (data, docs) or Unlicense (code).
  • No license at all — code is unusable for others. Pick something.

Reference: choosealicense.com (GitHub-maintained).

9. Compliance Mechanics

When you ship software that includes OSS, the bookkeeping is:

  • Inventory every component and its license. Tools: SPDX SBOM, FOSSA, ScanCode, REUSE, Black Duck.
  • Preserve notices — copyright lines, license text, NOTICE files. The single most common violation is stripping these from a build.
  • Distribute source when required — for GPL/LGPL/MPL, either bundle source with the binary, or include a written offer valid for 3 years to provide it on request.
  • For embedded products (consumer devices) under GPL-3.0: include installation information (how to build and re-flash). This is the anti-Tivoization clause.
  • Inbound = Outbound rule: contributions to your project come in under the same license you ship, unless you have a CLA (Contributor License Agreement, e.g. Apache Foundation) or a DCO (Developer Certificate of Origin, Linux kernel).
  • Add a LICENSE file at repo root. Add SPDX-License-Identifier: headers to every source file (REUSE specification — https://reuse.software/).

10. Pitfalls

  • "This is open source, I can do anything" — false for copyleft. Distribute a GPL-derived binary closed-source and you're in violation.
  • Stripping headers when you copy a snippet — almost every license requires retaining the copyright notice. Stack Overflow code is CC-BY-SA: technically requires attribution.
  • Tracking via dependencies, not just direct imports. A permissive library that depends on a GPL library transitively carries the obligation.
  • Re-licensing without all contributors' consent is a lot of paperwork. Big projects (Mozilla relicensing to MPL-2, Qt going dual-license) take years. Pick carefully on day 1.
  • CLA vs DCO confusion: CLAs transfer or grant rights to a single entity (lets that entity dual-license). DCO is just a sign-off asserting you have the right to contribute under the project's license — no rights transfer. Many devs refuse CLAs on principle.
  • Putting LICENSE: MIT in a README is not enough — the actual license text must accompany the code. GitHub's license picker handles this; manual setups often skip the full text.
  • License of documentation and assets is separate. Source might be MIT but docs are CC-BY-SA, fonts are OFL, etc. Bundle each with its own LICENSE.
  • AGPL surprise — pulling in an AGPL library to a SaaS without realizing the obligation. Vet new deps for AGPL before adopting.
  • Source-available != OSS. SSPL, BSL, ELv2 look like OSS at a glance but legally aren't. Don't treat them as such in audits.

11. References