开源许可证解释：好的一面，坏的一面，以及“等等，我真的能用吗？”

Source: Dev.to

引言

你已经做了一个很酷的项目，想要开源。当你在 GitHub 上点击 “Choose a license” 时，会看到一大堆选项：MIT、Apache 2.0、GPL v3、AGPL、BSD、MPL、ISC、Unlicense 等等。面对如此多的选择，尤其是你只想让别人使用你的代码时，可能会感到不知所措。

下面是一份通俗易懂的指南，介绍最常见的开源许可证，它们到底允许什么，以及在什么情况下使用它们最合适。

---

许可证光谱：宽松 ↔ copyleft

Permissive  ←--------------------------→  Copyleft
(do whatever)                         (share improvements)

MIT / BSD → Apache 2.0 → MPL → LGPL → GPL → AGPL

• 宽松许可证 允许你几乎对代码做任何事，甚至可以把它整合进专有产品。
• Copyleft 许可证 要求对修改后的代码也使用相同的许可证，确保改进保持开源。

---

许可证概览

MIT（以及 BSD‑style）

简化版声明

“随意使用这段代码，只要保留我的版权声明。如果代码出问题，我不负责。”

关键要点

• 允许商业使用、修改、分发、再授权。
• 没有强制共享修改的要求。
• 文字简短，广为人知。

典型项目
React（最初的 BSD‑style）、Node.js、jQuery、Tailwind CSS。

何时选择

• 你希望最大程度的采用。
• 你不介意公司从你的工作中获利。
• 你需要一个简单、宽松的许可证。

---

Apache 2.0

相较于 MIT 的新增内容

• 专利保护 – 贡献者授予永久、全球、免版税的专利许可。
• 商标保护 – 项目名称未经许可不得用于背书。

示例条款（专利授权）

3. Grant of Patent License.  Each Contributor hereby grants to You a
   perpetual, worldwide, non‑exclusive, no‑charge, royalty‑free patent
   license to make, use, sell, offer for sale, import, and otherwise
   transfer the Work, where such license applies only to those patent
   claims licensable by such Contributor that are necessarily infringed
   by their Contribution(s) alone or by combination of their
   Contribution(s) with the Work to which such Contribution(s) was
   submitted.

典型项目
Kubernetes、TensorFlow、Android、Swift。

何时选择

• 你拥有专利或可能申请专利。
• 你希望为贡献者提供专利侵权保护。
• 你在构建基础设施，专利风险是一个关注点。

---

BSD（2‑clause / 3‑clause）

声明内容 – 与 MIT 几乎相同，但增加了一条禁止使用作者姓名来背书衍生作品的条款。

示例条款（背书）

3. Neither the name of the copyright holder nor the names of its
   contributors may be used to endorse or promote products derived
   from this software without specific prior written permission.

典型项目
FreeBSD、OpenBSD、nginx。

何时选择

• 目标与 MIT 相同，但你想避免“背书混淆”。

---

GPL v3（通用公共许可证）

简化版声明

• 你可以使用、修改、分发软件。
• 如果你分发了修改后的版本，必须 以 GPL v3 同样的方式 发布源码。
• 必须提供编译后二进制的安装说明。

典型项目
Linux 内核、Git、WordPress、GIMP。

何时选择

• 你认同自由软件的理念。
• 你希望改进能够回馈社区。
• 你接受其“病毒式”特性，即可能阻止专有使用。

注意点： SaaS 提供商可以通过不 分发 软件（只在服务器上运行）来规避共享修改。

---

AGPL v3（Affero GPL）

新增内容 – 如果用户通过网络与软件交互，你也必须共享你的修改源码。

典型项目
MongoDB（最初的 AGPL）、Grafana、GitLab CE、Mastodon、Nextcloud。

何时选择

• 你在构建数据库、后端服务或其他基础设施。
• 你想防止云服务商“剥离”你的工作。
• 你愿意在一定程度上限制商业采用。

---

LGPL v2.1 / v3（较宽松的 GPL）

声明内容 – 你可以 链接 该库到专有软件，但对库本身的任何修改必须以 LGPL 方式发布。

典型项目
Qt、FFmpeg、GStreamer。

何时选择

• 你发布的是一个库，希望包括专有应用在内的其他人使用。
• 仍希望库本身的改进保持开源。

---

MPL 2.0（Mozilla 公共许可证）

声明内容 – copyleft 只适用于 每个文件。被修改的文件必须保持 MPL，但你可以在项目中添加任意许可证的新文件。

典型项目
Firefox、Thunderbird、LibreOffice。

何时选择

• 你想在宽松和强 copyleft 之间找到折中。
• 你能够接受混合许可证的代码库。

---

Unlicense（公共领域）

声明内容 – “这是公共领域。可以随意使用。我放弃所有权利。”

典型使用场景 – 小工具、教学示例。

警示 – 某些司法管辖区不允许完全放弃版权，因此 Unlicense 并非在所有地方都具备法律效力。MIT 是一个更安全的、效果相同的替代方案。

---

选许可证——决策树

├─ “我想要最大采纳率”
│   └─ MIT 或 Apache 2.0
│
├─ “我想要改进回馈”
│   ├─ 库 → LGPL 或 MPL
│   ├─ 应用 / 服务 → GPL
│   └─ SaaS → AGPL
│
├─ “我想阻止云巨头获利”
│   └─ AGPL
│
└─ “我根本不在乎”
    └─ MIT 或 Unlicense

---

兼容性矩阵

经验法则

• 宽松许可证（MIT、Apache） 可以与任何其他许可证组合。
• GPL 会 “感染” 整个项目——一旦引入 GPL 代码，整个发行必须采用 GPL。
• AGPL 最为严格，额外加入网络使用条款。

---

真实案例中的坑与教训

1. 没有许可证 = 法律真空

一位开发者发布了一个 npm 包，却没有附带许可证。某初创公司使用了它，开发者随后起诉。法院判决 没有许可证即“保留所有权利”，双方都无法主张自己的权利。

教训： 必须始终附带许可证；“没有许可证” 并不等同于 “免费使用”。

2. 专利条款可能适得其反

Facebook 最初以 BSD‑style 许可证发布 React，并加入了专利报复条款（“如果你起诉我们的专利，你将失去 React 许可证”）。社区强烈反弹，最终 Facebook 将 React 改为 MIT 许可证。

教训： 专利条款虽强大，却可能疏远用户。

3. 项目中途加入限制性条款会削弱采纳

Redis Labs 为某些模块添加了 “Commons Clause”（“不得出售此软件”），这违反了开源定义，导致社区分叉出 Valkey 项目。

教训： 在发布后改为更限制的许可证会导致社区分裂。

4. 云服务商与 AGPL

MongoDB 的 AGPL 仍然让 AWS 能够提供兼容的 “DocumentDB” 服务而不回馈代码，促使 MongoDB 改为服务器端公共许可证（SSPL）。

教训： 即使是 AGPL，也未必能阻止大型云厂商提供托管版；需考虑其他商业模式。

5. GPL 与 SaaS

Linksys 在路由器中使用了修改后的 Linux 内核（GPL），但未发布源码。GPL 社区提起诉讼，Linksys 被迫遵守，随后出现了 DD‑WRT、OpenWRT 等社区固件项目。

教训： GPL 的强制执行可以迫使分发二进制的厂商公开源码，但对纯 SaaS 并不适用。

---

快速推荐

---

最终检查清单

1. 明确目标 – 采纳率、回馈改进、专利保护、阻止云端剥离等。
2. 挑选最简洁的许可证 – 不要把事情弄得过于复杂。
3. 在仓库根目录添加 LICENSE 文件。
4. 在每个源码文件顶部加入简短头部（例如 “© 2025 Your Name – SPDX‑License‑Identifier: MIT”）。
5. 记录任何额外政策（如贡献指南、行为准则）。

选对许可证，你的项目就能在你舒适的控制范围内茁壮成长。祝开源愉快！