开源许可证怎么选：从 BSD-2 到 GPL 的决策指南｜技术笔记

大多数开源项目里，许可证不是 GPL，就是 MIT。这两个我都没用。

年轻些的时候我会跟着主流走，现在不太会了。GPL 靠限制开发者来保护用户，这种”我替你好”的姿态让我不舒服；MIT 又是另一头，一句”随便用”几乎把作者的责任和主张全推干净，读着也别扭。我的标准其实很朴素：约束留到最少，自由给到最大。顺着这条线找，答案就落在 BSD 上，尤其是 BSD-2-Clause。

下面不谈法条怎么咬文嚼字，只讲我这些年挑许可证的思路：为什么是这个原则，几个主流许可证各自站什么立场，不同类型的项目我会怎么取舍。不过真要讲清楚，法律和历史绕不开。不理解 copyleft 是怎么来的、v2 和 v3 为什么翻脸，就理解不了许可证选择为什么本质上既是工程决策，也是一种价值观的表达。

一张光谱，四个问题

许可证按限制的多少排开，就是一条光谱。GPL 站在最紧的一头，MIT 站在最松的一头，两头我都躲。

要读懂这条光谱，先得知道上面每个点各自在回答什么问题。宽松许可证（MIT、BSD、Apache）回答的是”别人拿你的代码能干什么”，答案基本是”什么都能干”；copyleft 许可证（GPL 那一脉）回答的是”别人拿走了，还能不能把它关起来”，答案是”不能，你的改动必须继续开源”。这两问之间还夹着弱 copyleft（LGPL、MPL），它们只要求某一层的改动回流，不传染整个作品。举个例子，MPL 2.0 是文件级 copyleft：你改过的 MPL 文件必须继续按 MPL 发布，但它可以和你的专有代码待在同一个更大的作品里。

把主流许可证从松到紧排开，大致是这样：

\[\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 等自动化合规工具审查依赖链。

顺带看一眼流行度。根据 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% 的仓库用的是宽松许可证。宽松阵营正在压倒性地赢得开发者社区。

不过流行不等于合适。多数人用宽松许可证，不代表它对每个人的项目都合适。

先用法律强制换自由：GPL 一脉

从一台卡纸的打印机说起

1983 年，麻省理工学院的实验室里，一台打印机的纸卡住了。Richard Stallman 想改打印机驱动，厂商却不肯给源代码。他后来做的事我们都知道了：发起 GNU，要做一套完全自由的操作系统，GPL 就是这条路上长出来的。Stallman 提了个挺妙的词，copyleft——反过来用版权法来保证软件的自由，而不是限制它。1989 年，他和一群律师把 GNU 通用公共许可证写了出来，把黑客伦理里那套核心价值落成了法律文本。

他的理想无可挑剔，问题出在实现方式：用法律强制来达成自由。这像一位父亲为孩子定下整套规矩，孩子确实安全了，探索的空间也一起被框住。

“传染性”传的到底是什么

落到工程上，GPL 的”传染性”是很多人绕开它的直接原因。”传染性”不是协议里的正式术语，是业界对它特性的概括：在 GPL 之下，你要是把这段代码改一改、扩一扩，或者和别的代码拼成一个衍生作品，那么这个衍生作品也得按 GPL 走，以 GPL 发布并分发源码。GPL v2 里对应的是一到三条，GPL v3 里是四到六条，内核逻辑一致：程序一旦链接了 GPL 代码，分发时整个作品通常都得开源。对商业闭源集成来说，这几乎是一票否决。

但传染并非没有边界。司法实践里，法院要判断的，是主张权利的代码到底是不是 GPL 协议下受保护的程序本身，以及被告作品算不算它的衍生品或修订版。”数字天堂诉柚子案”里，法院从插件所在文件夹的位置、许可文本放在哪、插件是否独立这几点入手，认为那三个插件不会仅因为别的目录里躺着 GPL 文本就被拉进 GPL 范围。(2019) 最高法知民终 663 号案里，法院讲得更直白：A 公司前端用了开源代码，但后端程序并不是前端的衍生品或修订版，所以 GPL 协议对涉案权利代码没有约束力。

这些判例说明 GPL 的适用范围是有明确边界的。可对一个希望代码被尽量多用、又不想踩法律不确定性的作者来说，边界的存在本身就是成本。

v2 与 v3：一道没缝上的缝

GPL 家族内部最大的裂缝，是 v2 和 v3 互不兼容。它们是两个独立许可证，没有合法的组合方式，你不能在一个程序里同时用 GPL v2 代码和 GPL v3 代码。这在社区里造成了实打实的分裂。Linux 内核至今停在 GPL v2，Linus Torvalds 对 v3 的评价是”overreaching”（管得太宽）。Alan Cox 在 Linux 内核邮件列表里认真讨论过这件事：大批贡献者是冲着 GPL v2 的框架来参与内核开发的，v3 把这个契约改了，”无论好坏，取决于你是谁以及你做什么”。对内核社区来说，换许可证等于改动和数万名贡献者之间的约定，这个代价没人愿意背。

那 v3 到底加了什么引发争议的东西？主要是反 Tivoization 条款（要求分发者提供安装修改后软件所需的信息）和更明确的专利授权条款。FSF 觉得这是保护用户自由的必要手段，另一部分开发者觉得这是对分发者权利的过度干预。这场争论到今天也没结论。它至少说明一件事：许可证不只是法律工具，也是一份社区契约，而改契约要付出的共识成本高得惊人。

AGPL：把 copyleft 推到网络边界

如果说 GPL 管的是”分发”场景下的 copyleft，AGPL 管的就是”不分发、只提供服务”那种。AGPL v3 第 13 条规定：用户通过网络和修改过的 AGPL 软件交互，你就得给这些用户提供相应的源代码。这补上了 GPL 在 SaaS 场景下的口子——GPL 之下，一家公司改了 GPL 软件却只在服务器上跑，不向用户分发二进制文件，它就没有开源义务。AGPL 把这条路堵死了。

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

对我来说，AGPL 的毛病和 GPL 一样：用法律强制来保护自由，代价是压缩了开发者的选择空间。但如果你做的是面向 SaaS 的库或框架，希望云厂商的改进能回流社区，AGPL 是个站得住脚的选项，前提是你清楚自己在做什么。

另一头：MIT 把自由给得太彻底

MIT 走向了相反的一端，在我看来过于天真。

把代码丢出去说”随便你怎么用”，听着开放，实际是把作者该有的道德主张一并放弃了。按 MIT 的规则，别人可以把你的名字抹得一干二净，可以拿你的东西干坏事，甚至能用专利反过来打别人，因为 MIT 压根没有专利条款。按微软官方培训文档的分类，MIT 和 BSD 许可证”不包括明确的专利授予，从而对专利权产生潜在的歧义”。也就是说，如果你在一个用了 MIT 许可代码的产品上被第三方以专利侵权起诉，MIT 许可证本身给不了你任何庇护。

MIT 只提一个要求：保留版权声明和许可声明。可这一点在实践中也经常被无视，而作者除了喊一声署名，并没有更多条款可以倚仗。对只想把代码扔进公共空间的人，它够用；对想”既被广泛使用、又守住基本底线”的人，它给得太干净了。

不过也得说句公道话：MIT 的简洁在某些场景下就是优点。一个只有几十行的工具脚本，硬要塞进 Apache 2.0 的专利条款和 NOTICE 文件要求，反而是自找管理负担。只是当项目扯上专利、或者有商业公司进入贡献者名单时，专利条款的缺席就变成一个实打实的风险。

给宽松加上护栏：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 这类”源码可用”许可证不是真正的开源。

被忽略的中间地带：MPL 与 LGPL

讲完两个极端，得把中间那块补上，因为不少开发者选许可证时会直接漏掉它。

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

MPL 2.0 是个想得很周到的现代许可证，一手拿 copyleft 的保护性，一手拿宽松许可证的灵活性。它还跟 GPL 兼容，这在 copyleft 许可证里并不多见。如果你要做一个库或框架，既希望这个组件的改进能持续回流社区，又不希望用户因为用了它就被迫开放自己的代码，MPL 2.0 是比 GPL 更务实的选择。

BSD：我最终停下的地方

从伯克利的广告条款讲起

BSD 许可证的来头要追到加州大学伯克利分校的 BSD Unix 项目。当年伯克利只收介质成本就把 BSD 提供给任何人使用，这套规矩后来就被叫作”BSD 许可证”。最早那版有四个条款，其中第三条（广告条款）要求：凡是在使用该代码的产品广告里，就得声明用到了伯克利的代码。这条在实践中简直是合规噩梦，你可以想象，得在每一份产品宣传材料里列全所有用到的 BSD 组件。1999 年 7 月 22 日，加州大学技术许可办公室主任正式宣布，把这条整个删掉。

BSD-2-Clause 则在 2008 年 1 月 9 日拿到 OSI 董事会批准，去掉了”禁止背书”条款，实质上与 MIT 许可证等价。但它的文本比 MIT 更清楚地把版权声明和免责声明这两条核心要求摆出来，结构上更利落。

BSD-2 给了什么，留了什么

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

它给出来的自由挺惊人：

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

但它也留着基本底线：用的人必须通过署名承认你的工作，不能假装是自己写的；你同时受责任保护，别人用你代码出了事，那是他们的事，不是你的。自由给足，底线留住，这就是我想要的平衡点。

为什么不加第三条

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

第三条款说的是，没经过许可，不能用作者的名字给产品背书。道理没错，可现实中很少被违反。会拿作者名字造假背书的人，本来也不会因为多一条许可证就收手。它给大多数小项目添的是不必要的法律复杂度，而真想滥用你代码的人，不差这一条。BSD-2 更干净，更贴合”最小约束”的原则。少一条几乎用不上的条款，作者和使用者都轻松。

不过话得说回来，BSD-3-Clause 在大型项目和组织里仍有它的价值。项目一旦有多个贡献者、又牵着品牌声誉，”禁止背书”就多一层法律保障。Apache 2.0 里也包含类似的条款。所以这不是对错题，是权衡：小项目，简洁优先；大项目，保障优先。

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

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 的条款。

名不副实的那一类：源码可用

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

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 说成开源，混淆的是开源社区数十年建立的共识，最终损害的是整个生态的信任基础。

如果你刚起步

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

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 简洁，干净。它不试图用法律条文改变世界，也没放弃对基本尊严的主张。它相信使用者的善意，同时把底线划得清清楚楚。有时候，最简单的就是最好的。