我为什么偏爱 BSD-2-Clause 和 Apache 2.0：一份开源许可证选择心得

大多数开源项目在用 GPL 或 MIT。这两个我都不喜欢。

这些年，我不再盲目追主流。GPL 的“父爱式管制”让我不舒服——它通过限制开发者来保护用户。MIT 的“毫无节制的宽容”也不对味——说“随便用”等于放弃所有责任。我的原则很简单：只留最基本的约束，把最大的自由给用户。这自然把我引向 BSD，尤其是 BSD-2-Clause。

这篇文章不讲法律条文，只讲我这些年选许可证的思路：为什么是这个原则、几个主流许可证分别代表什么立场、不同类型的项目我会怎么选。但既然要讲清楚，免不了要涉及一些法律和历史——理解这些，才能真正理解为什么许可证的选择本质上是一个工程决策和价值观表达。

一条光谱，两个极端

许可证从限制性到宽松性，像一条光谱。GPL 和 MIT 站在两端，我都避开。

理解许可证，先要理解它们各自回答的问题不一样。宽松许可证（MIT、BSD、Apache）回答的是“别人拿你的代码能做什么”，答案基本是“什么都能做”；Copyleft 许可证（GPL 系列）回答的是“别人拿你的代码之后，还能不能把它闭源”，答案是“不能，你的修改必须继续开源”。弱 copyleft 许可证（LGPL、MPL）则介于两者之间——它们要求特定层级的修改继续开源，但不传染整个作品。比如 MPL 2.0 是文件级 copyleft，修改过的 MPL 文件必须继续以 MPL 发布，但你可以把 MPL 代码和自己的专有代码组合在同一个更大的作品中。

根据 OSI 2025 年度报告，最受关注的许可证依次是 MIT（150万次）、Apache 2.0（34.4万次）、BSD-3-Clause（21.4万次）、BSD-2-Clause（12.8万次）、GPL 2.0（7.6万次）和 GPL 3.0（5.5万次）。MIT 的领先幅度是惊人的——它的浏览量是 Apache 2.0 的四倍多，是 GPL 3.0 的近三十倍。这反映了一个趋势：在开发者社区中，宽松许可证正在压倒性地占据主导。GitHub 2025 年的调查也显示，约 70% 的仓库使用宽松许可证。但流行不等于正确，至少不意味着适合每一个人。

许可证光谱全景

下面这张 Mermaid 图（已替换为数学公式，下同） 展示了主流许可证从宽松到严格的光谱分布：

\[\underbrace{\text{MIT/BSD-2}}_{\text{最宽松}} \prec \text{BSD-3} \prec \text{Apache 2.0} \prec \text{MPL 2.0} \prec \text{LGPL} \prec \text{GPL} \prec \text{AGPL} \prec \underbrace{\text{SSPL/BSL}}_{\text{非开源}}\]

如果按“是否要求开源衍生作品”来看，可以粗略分成四段：

• 宽松：MIT、BSD-2、BSD-3、Apache 2.0。允许闭源分发，不要求公开修改。
• 弱 copyleft：MPL 2.0、LGPL。只要求开放特定层级的修改，通常是文件级或库级。
• 强 copyleft：GPL、AGPL。要求整个衍生作品继续开源；AGPL 还把网络服务纳入触发条件。
• 源码可用：SSPL、BSL。源代码可见，但附加使用领域限制，不属于 OSI 定义的开源许可证。

常见许可证速查表

我把七个最常用的许可证放在一张表里对比。这是理解许可证格局最快的入口。

许可证	类型	Copyleft强度	专利授权	源码披露要求	可否用于专有软件
MIT	宽松	无	无	无	是
BSD-2/3-Clause	宽松	无	无	无	是
Apache 2.0	宽松	无	有	无	是
MPL 2.0	弱 copyleft	文件级	有	仅修改的 MPL 文件	是
LGPL	弱 copyleft	库级	有（v3）	库及其修改	是（需可重链接）
GPL	强 copyleft	整个作品	有（v3）	分发时	否（若作为衍生作品分发）
AGPL	强 copyleft	整个作品+网络	有	含网络使用	否（若修改并通过网络提供服务）

这张表的信息来源于多份许可证对比研究。有几个要点：三种宽松许可证都允许专有使用且不要求源码披露；Apache 2.0 的独特性在于显式专利授权和 NOTICE 文件要求；弱 copyleft 的义务限定在开放组件本身；强 copyleft 则覆盖整个衍生作品，AGPL 更进一步把网络服务也纳入触发条件。

提示：这张表只是速查工具，实际选许可证时建议逐条阅读 LICENSE 全文，或使用 FOSSA、ScanCode 等自动化合规工具审查依赖链。

GPL：用强制实现自由

一个打印机引发的革命

1983 年，Richard Stallman 在麻省理工学院的实验室里，打印机卡纸了。他想修改打印机驱动程序，但厂商拒绝提供源代码。那一刻，他决定创建一个完全自由的操作系统——GNU。GPL 就这样诞生了。Stallman 创造性地提出了“copyleft”的概念——利用版权法来确保软件的自由，而非限制它。1989 年，他与一群律师共同起草了 GNU 通用公共许可证，将黑客伦理中的核心价值铸造成了法律文本。

Stallman 的理想是崇高的，但他的方法是通过法律强制来实现自由。这就像一个父亲，为了保护孩子制定了一整套规则，限制孩子的行为。孩子确实安全了，但也失去了探索的自由。

传染性的工程后果

具体到工程实践，GPL 的“传染性”是很多人绕开它的直接原因。“传染性”并非 GPL 协议中的正式术语，而是业界对其特性的概括：在 GPL 约束下，基于该协议授权的软件进行修改、扩展或与其他代码结合形成衍生作品时，衍生作品也必须遵守 GPL 协议，以 GPL 许可方式发布和分发源代码。GPL v2 中涉及传染性的条款为第一条至第三条，GPL v3 中为第四条至第六条，核心逻辑一致——只要你的程序链接了 GPL 代码，整个作品在分发时通常就要按 GPL 开源。这对商业使用、闭源集成几乎是一票否决。

但 GPL 的传染性并非无限的。司法实践中，法院需要区分主张权利的代码是否为 GPL 协议许可下批准的受版权保护的程序以及基于该程序的衍生产品或修订版本。在“数字天堂诉柚子案”中，法院从涉案插件的文件夹位置、许可文本位置和插件独立性进行判断，认为三个插件并不当然因其他目录中存在 GPL 文本而被纳入 GPL 范围。在 (2019) 最高法知民终 663 号案中，法院明确指出：A 公司虽在前端代码中使用了开源代码，但其后端代码程序并非前端程序的衍生品或修订版本，故 GPL 协议对涉案权利代码并无拘束力。这些判例说明，GPL 的适用范围有明确的边界，但对希望代码被尽可能多地使用、又不希望面对法律不确定性的作者来说，这个边界的存在本身就增加了成本。

GPL v2 vs v3：一场没有赢家的分裂

GPL 家族内部最大的裂痕是 v2 与 v3 的不兼容。GPL v2 和 GPL v3 是两个独立的许可证，它们之间没有合法的组合方式——你不能在一个程序中同时使用 GPL v2 代码和 GPL v3 代码。这在开源社区造成了实质性的分裂。Linux 内核至今坚持 GPL v2，Linus Torvalds 本人对 GPL v3 的态度是“overreaching”。Alan Cox 在 Linux 内核邮件列表中曾深入讨论过这个问题，他指出大量贡献者是基于 GPL v2 的协议框架参与内核开发的，GPL v3 改变了这个协议，“无论好坏，取决于你是谁以及你做什么”。对于内核社区而言，变更许可证意味着改变了与数万名贡献者之间的契约，这个代价不可接受。

GPL v3 增加了哪些引发争议的内容？主要是反 Tivoization 条款（要求分发者提供安装修改后软件所需的信息）和更明确的专利授权条款。这些条款在 FSF 看来是保护用户自由的必要手段，但在部分开发者看来是对分发者权利的过度干预。这场争论至今没有定论，但它清楚地说明了一件事：许可证不仅是一个法律工具，也是一个社区契约。改变契约需要极高的共识成本。

MIT：宽容到放弃主张

MIT 走向另一个极端，太天真了。

把代码扔出去说“随便你怎么用”，听起来开放，实则是放弃所有作为作者的道德主张。按 MIT 的规则，别人能把你名字完全抹掉，能用你的作品干坏事，甚至能用专利攻击别人——MIT 根本没有专利保护条款。根据微软官方培训文档中的分类，MIT 和 BSD 许可证“不包括明确的专利授予，从而对专利权产生潜在的歧义”。这意味着如果你在一个使用了 MIT 许可代码的产品中被第三方以专利侵权起诉，MIT 许可证本身不能给你任何保护。

MIT 只有一个要求：保留版权声明和许可声明。但实践中连这一点都经常被忽略，而作者除了主张署名，也没有更多可依据的条款。对只想把代码扔进公共空间的人来说它够用；对希望“既被广泛使用、又保留基本底线”的人来说，它给得太干净了。

值得注意的是，MIT 许可证的简洁性在某些场景下是优势。对于一个只有几十行的工具脚本，引入 Apache 2.0 的专利条款和 NOTICE 文件要求反而增加了不必要的管理负担。但正如下面要讨论的，当项目涉及专利或者有商业公司参与贡献时，专利条款的缺失就是一个实质性风险。

BSD-2-Clause：中间地带

从 BSD Unix 到简化许可证

BSD 许可证的历史可以追溯到加州大学伯克利分校的 BSD Unix 项目。加州大学伯克利分校以仅收取介质成本的方式向任何人提供 BSD，这成为了后来被称为“BSD 许可证”的规则。原始的 BSD 许可证包含四个条款，其中第三条（广告条款）要求在使用该代码的产品的广告中声明使用了加州大学伯克利分校的代码。这个条款在实践中造成了巨大的合规负担——想象一下，你需要在每一份产品宣传材料中列出所有使用了 BSD 代码的组件。1999 年 7 月 22 日，加州大学技术许可办公室主任正式宣布该条款“全部删除”。

BSD-2-Clause 于 2008 年 1 月 9 日获得 OSI 董事会批准，去掉了“禁止背书”条款，实质上与 MIT 许可证等价。但它比 MIT 更明确地保留了版权声明和免责声明两个核心要求，在文本结构上更清晰。

它给了什么，留了什么

BSD-2-Clause 就两个要求：保留版权声明，加个免责声明。就这么多，没有更多法律条款要读。

它给的自由很惊人：

• 你可以把代码用在任何地方：商业、个人、教育。
• 随便改。可以闭源分发，不用开源自己的修改。
• 可以整合到完全不同许可证的项目里。
• 没有专利报复条款的麻烦。
• 不像 GPL，没有“传染性”要求逼你把自己的代码也开源。

但 BSD-2-Clause 仍保留基本标准：用户必须通过署名承认你的工作，不能假装是他们写的；你也受责任保护，有人用你代码出问题，那是他们的事，不是你的。自由给足，底线留住。这正是我想要的平衡点。

一个被低估的优势：许可证兼容性

BSD-2-Clause 还有一个常被忽视的优势：它几乎与所有其他许可证兼容。你可以把 BSD-2 代码整合进 GPL 项目，也可以整合进 Apache 2.0 项目，甚至可以整合进专有软件。这在大型项目中极其重要——当你依赖了十几个不同许可证的库时，如果核心代码是 BSD-2 许可的，你就少了一个需要处理的兼容性约束。相比之下，Apache 2.0 与 GPL v2 不兼容，GPL v2 与 GPL v3 不兼容，这些限制在复杂的依赖链中会产生连锁反应。有研究分析了超过 3,500 个活跃项目和 756 个项目中的 1,012 次许可证变更，发现 7.38% 的许可证变更导致了法律冲突，主要集中在 copyleft 和宽松许可证之间。

信息：Apache 2.0 与 GPL v3 兼容，但与 GPL v2 不兼容。原因是 Apache 2.0 的专利终止条款在 GPL v2 看来属于“额外限制”，而 GPL v2 不接受这种限制。FSF 在设计 GPL v3 时专门接受了 Apache 2.0 的条款。

为什么不用 BSD-3-Clause

自然有人问：BSD 家族里还有个 BSD-3-Clause，差别只在第三条，为什么不用它？

第三条款说未经许可不能用作者名字为产品背书。理论上合理，实际中却很少被违反——会拿作者名字做虚假背书的人，本来也不会因为多一条许可证就收手。它给大多数小项目添了不必要的法律复杂性，而且真想滥用你代码的人总会找到办法绕开。BSD-2 更干净，更贴合“最小约束”的原则。少一条几乎用不上的条款，作者和使用者都更轻松。

不过需要客观地说，BSD-3-Clause 在大型项目和组织中仍有其价值。当一个项目有多个贡献者、涉及品牌声誉时，“禁止背书”条款提供了一层额外的法律保障。Apache 2.0 也包含了类似的条款。所以这个选择不是对错问题，而是权衡——对小项目来说，简洁优先；对大项目来说，保障优先。

Apache 2.0：专利时代的务实选择

为什么需要专利条款

在讨论我为什么在大型项目中选择 Apache 2.0 之前，需要先理解一个背景：专利风险在现代软件中不是一个理论问题，而是一个现实问题。

当一个贡献者向项目提交了含有专利的代码，他可能在当时没有意识到，也可能有意保留了日后主张专利的权利。Apache 2.0 的专利条款解决了这个问题：每个贡献者通过提交代码，同时授予了一个“永久的、全球范围的、非排他性的、免费的、不可撤销的（除本条款规定外）专利许可”。这个许可的范围覆盖了贡献者的贡献单独或与其提交的作品结合时必然侵权的专利权利要求。

更重要的是 Apache 2.0 的专利报复条款：如果你对任何实体提起专利诉讼，声称该作品或作品中包含的贡献构成直接或共同专利侵权，那么根据该许可证授予你的专利许可将自诉讼提起之日起终止。这是一个“弱报复”条款——它的触发条件限定为针对本作品的专利诉讼，而非任何专利诉讼。这种设计在保护贡献者免受专利攻击的同时，避免了对许可证使用者的过度限制。

Apache 2.0 的工程实践

我根据不同场景用不同许可证，基本是三套：

• 个人项目——脚本、小库、实验代码——一律 BSD-2-Clause。简单，鼓励使用和分享。这类项目体量小、生命周期短，许可证越轻越好，别人复制粘贴走一段代码也不必有心理负担。
• 大项目，尤其是框架或涉及专利的代码，用 Apache 2.0。现代软件里专利风险是真实存在的：贡献者把含有专利的代码提交进来，日后再主张专利侵权，整个项目都会受影响。Apache 2.0 在这方面处理得好——它有明确的专利授权条款，一旦贡献代码就意味着同时授予了专利使用权，同时还保持宽松。Kubernetes、Airflow、Kafka、Swift 等基础设施项目都选择了 Apache 2.0。
• 文档和创意作品用 CC BY 4.0，署名要求清楚，且和代码许可证的适用范围区分开，不混用。CC BY 4.0 是最宽松的 Creative Commons 许可证之一，允许在署名前提下进行任何形式的再利用，包括商业用途。

刻意避开的许可证也有几类：

• GPL 和“最大自由”原则冲突。
• MIT 太宽松，放弃太多。
• SSPL、BSL 之类的“源码可用”许可证不是真正的开源。

源码可用不等于开源

关于最后一类，值得多说几句，因为近年来越来越多的公司选择从开源许可证切换到“源码可用”许可证，而这个选择的代价常常被低估。

SSPL（Server Side Public License）和 BSL（Business Source License）是两类最常被误认为开源许可证的源码可用许可证。它们的共同特征是：源代码公开可读，但附加了“使用领域限制”——比如 SSPL 第 13 条要求，如果将 MongoDB 作为服务提供给第三方，你必须将整个服务基础设施（包括负载均衡器、API、管理工具等一切）以同样许可证开源。这比 GPL 的 copyleft 要求更进一步：GPL 只要求衍生作品开源，SSPL 要求运行该服务的所有组件都开源。

BSL 则更为灵活但也更为限制性——它的基础版本通常限制生产环境使用，但 HashiCorp 的 BSL 实现包含一个“附加使用授权”，允许生产使用，只要不构建与 HashiCorp 商业产品竞争的产品。

OSI 对这两类许可证的态度非常明确。SSPL 于 2019 年被正式提交给 OSI 的许可证审查流程，随后在社区未达成共识的情况下被撤回。OSI 拒绝批准 SSPL 的理由是它违反了开源定义的第六条的“不歧视特定领域”原则。Debian 也拒绝将其认定为符合 DFSG 的许可证，FSF 同样不将其列为自由软件许可证。

这意味着使用 SSPL 或 BSL 的软件——MongoDB、CockroachDB、HashiCorp 的 Terraform 和 Vault——严格来说不能被称为“开源软件”。这不是一个学术争论，它有实际的后果：企业合规团队在审查依赖链时，如果发现 SSPL 或 BSL 组件，通常需要额外的法律审查，因为它们的限制条件是非标准的，在不同司法管辖区可能有不同的解释。

我的立场是：如果你想保护自己的商业模式不被云厂商白嫖，那就诚实地承认你在用“源码可用”而非“开源”许可证。把 SSPL 称为开源，混淆了开源社区数十年建立的共识，最终损害的是整个生态的信任基础。

弱 copyleft：一个被忽视的中间选项

在讨论完极端和中间地带之后，有必要介绍一下弱 copyleft 许可证，因为很多开发者在选许可证时会忽略这个选项。

MPL 2.0 是弱 copyleft 的典型代表。它的核心机制是“文件级 copyleft”：如果你修改了 MPL 许可的文件，修改后的文件必须继续以 MPL 发布；但你可以在同一个项目中保留自己完全专有的文件，只要它们不构成对 MPL 文件的修改。这与 LGPL 不同——LGPL 允许专有代码通过链接方式使用 LGPL 库，但要求对库本身的修改必须开源。LGPL 在链接方式上有更细的规定：动态链接时，你只需要提供 LGPL 库本身的源代码，你的应用程序可以保持专有；静态链接时，你需要额外提供目标代码文件，让接收者可以用更新版本的 LGPL 库重新链接。

MPL 2.0 是一个经过精心设计的现代许可证，兼具 copyleft 的保护性和宽松许可证的灵活性。MPL 2.0 还与 GPL 兼容，这在 copyleft 许可证中并不常见。如果你在做一个库或框架，希望确保这个组件的改进持续回流到社区，但不希望你的用户因为使用了这个库而被迫开放他们自己的代码，MPL 2.0 是一个比 GPL 更务实的选择。

AGPL：SaaS 时代的 copyleft 延伸

如果说 GPL 回答的是“分发”场景下的 copyleft 问题，AGPL 则回答了“不分发、只提供服务”的场景。

AGPL v3 第 13 条规定：如果用户通过网络与修改后的 AGPL 软件交互，你必须向这些用户提供相应的源代码。这填补了 GPL 在 SaaS 场景下的“漏洞”——在 GPL 下，如果一家公司修改了 GPL 软件但只在服务器上运行、不向用户分发二进制文件，它没有义务开源修改后的代码。AGPL 堵住了这条路。

AGPL 的触发条件需要注意：只有当你修改了 AGPL 软件，并且通过网络向用户提供服务时，才需要提供源代码。如果你只是运行未修改的 AGPL 软件来提供服务，不需要开源。这个细节在实际使用中经常被误解。

对于我这样的开发者来说，AGPL 的问题和 GPL 一样：它通过法律强制来保护自由，代价是限制了开发者的选择空间。但如果你做一个面向 SaaS 的库或框架，希望确保云厂商的改进回流到社区，AGPL 是一个合法的选项——只要你清楚自己在做什么。

给刚起步开发者的建议

如果你刚开始维护开源项目，正在为选许可证发愁，我的建议是：

1. 从 BSD-2 开始。它直截了当，不会用一堆条款把你搞晕。
2. 在 README 开头用白话把许可证说清楚。很多使用者不读 LICENSE 全文，一句“本项目代码可自由使用，只需保留署名”比甩一个协议编号更有效。
3. 项目里保持一致。不要这个文件 MIT、那个文件 GPL，混合许可证会让下游寸步难行。研究表明，许可证变更是项目维护中一个重要但常被忽视的风险点，7.38% 的许可证变更会导致法律冲突。
4. 想清楚你的受众：要广泛传播就用 BSD 或 Apache 这样的宽松许可证；做社区项目可以考虑 MPL 这样的弱 copyleft——它要求修改的文件继续开源，但不传染整个作品，介于 GPL 和 MIT 之间。
5. 有强烈的道德立场？ 去研究研究 Hippocratic License 这类变体，它们在许可证里加入了人权或伦理使用限制。要不要用是另一回事，但至少知道有这种选择。
6. 如果涉及专利，不要用 MIT 或 BSD-2。选择 Apache 2.0。这是少数几个在专利保护方面设计完善的宽松许可证。
7. 定期审查依赖链中的许可证。你的项目可能不是自己写的每一行代码，但你需要为整个分发负责。SBOM（软件物料清单）和自动化合规工具现在比以往任何时候都更容易获取，利用它们。

快速选择指南

如果不想读完整篇，可以先按下面的分段函数粗选。它不覆盖所有法律细节，但能帮你快速定位方向：

\[\text{许可证选择} = \begin{cases} \text{Apache 2.0} & \text{希望广泛采用，且涉及专利风险} \\ \text{BSD-2 / MIT} & \text{希望广泛采用，不涉及专利风险} \\ \text{MPL 2.0 / LGPL} & \text{只希望特定组件的改进回流社区} \\ \text{AGPL} & \text{希望整个衍生作品开源，且涉及网络服务} \\ \text{GPL} & \text{希望整个衍生作品开源，不涉及网络服务} \end{cases}\]

再展开成可执行的检查顺序：

1. 你希望别人能闭源使用吗？
   • 能：进入第 2 步。
   • 不能：进入第 4 步。
2. 你希望只让特定组件的修改回流，而不是整个作品吗？
   • 是：MPL 2.0 或 LGPL。
   • 否：进入第 3 步。
3. 项目涉及专利风险，或者有商业公司参与贡献吗？
   • 是：Apache 2.0。
   • 否：BSD-2 或 MIT。
4. 你的软件会通过网络提供服务吗？
   • 会：AGPL。
   • 不会：GPL。

AI 时代的新挑战

最后，不得不提一个正在改变许可证格局的新因素：AI。

截至 2025 年 4 月，Hugging Face 上超过 130 万个可下载模型使用了 68 种不同的开源许可证。AI 模型带来了许可证框架的全新问题：模型权重是否受版权保护？训练数据的许可证如何影响模型输出？模型的输出是否构成衍生作品？这些问题在现有的开源许可证框架中没有直接答案。

OSI 在 2025 年批准了一个新的许可证——OSC License，旨在减少 MIT 许可证在德国法律下的跨境法律模糊性。同时，OSI 的许可证委员会正在讨论 ModelGo Licenses，这是一个专门为 AI 模型设计的 Creative Commons 风格的许可证框架。这些进展表明，开源许可证体系正在适应 AI 时代的挑战，而这个过程远未完成。

对于今天的开发者来说，这意味着在选择许可证时需要考虑的维度比十年前更多。如果你的项目涉及 AI/ML 组件，你需要额外关注模型权重、训练数据和模型输出三个层面的许可证问题——它们可能适用完全不同的许可证，而它们之间的兼容性是一个尚在探索中的领域。

许可证是价值观的表达

说到底，选许可证不只是技术决定，是价值观的表达。四种许可证像四种说话方式：

• MIT 说“我不管，随便用”。
• GPL 说“你可以用，但得听我的——我定义你的自由”。
• Apache 试图平衡：“自由用，但我们互相保护”。
• BSD 说“这是我送你的礼物。记得谁给的，然后去创造点伟大的东西”。

这四句话里，最后一句最接近我的态度。

BSD-2-Clause 简洁优雅。它不试图用法律条文改变世界，也不放弃对基本尊严的主张。它相信使用者的善意，但也划定了清晰的底线。有时候，最简单的就是最好的。

本文采用 BSD-2-Clause 许可证发布。你可以自由使用、修改、分发，只需保留原始署名和许可证声明。