开源协议快速上手

1. 引言

开源协议（License）是开源生态的法律基石。它决定了你能如何使用、修改和分发代码，也决定了你的商业项目能否安全地集成某个开源组件。面对数百种协议，开发者无需全部掌握，只需理解主流协议的核心逻辑与边界。

本文按宽松程度从高到低，梳理最常见的开源协议及其关键约束。

2. 宽松许可证（Permissive）

宽松许可证对代码的使用限制极少，允许你将代码嵌入闭源商业软件，只需保留版权声明即可。这是商业友好度最高的一类。

2.1 MIT License

MIT 许可证是最简单、最宽松的协议之一。

MIT 赋予你使用、复制、修改、合并、发布、分发、再许可和销售软件的权利，唯一实质要求是在所有副本中保留版权声明和许可文本。

特点：商业友好，无专利明示条款，使用门槛极低。React、Node.js、.NET Core 等知名项目均采用 MIT。

风险提示：MIT 未明确涉及专利授权，若代码涉及专利，存在潜在模糊性。

MIT License 名称来自它的诞生地——麻省理工学院（Massachusetts Institute of Technology，简称 MIT）。严格来说，它并非由某个标准化组织正式发布，早期常被称为 “X11 License” 或 “Expat License”，因此存在多个措辞略有差异的版本，但核心条款一致。

2.2 Apache License 2.0

Apache 2.0 同样是宽松协议，但比 MIT 多了一层关键的专利保护。它明确授予贡献者的专利权，并包含“专利报复”条款：如果你对贡献者发起专利诉讼，你的专利授权将自动终止。

通俗解释：你可以把 Apache 2.0 想成一份“专利互不侵犯条约”。

• 它给你什么：项目作者承诺——“我手里跟这份代码相关的专利，你可以放心用，我不会拿专利来卡你。”这就是“授予专利权”。
• 它要你承诺什么：作为交换，你也得答应——“我也不会拿专利去告这个项目或它的贡献者。”
• “专利报复”就是违约后果：一旦你违反了上面这条、真的去起诉，那么你之前从项目里得到的专利授权立刻作废。相当于你先撕毁了条约，条约对你的保护也就同时失效。

举个例子：公司 A 用了 Apache 2.0 的 Kubernetes，它仅仅因为使用这份代码，就已经自动获得了相关专利授权（即：Kubernetes 项目方承诺，不会拿自己手里与这份代码相关的专利去起诉公司 A）。后来公司 A 又顺手给项目贡献了代码，于是它同时成为“贡献者”，对自己贡献的那部分内容也获得了对等的专利授权保障。再后来，公司 A 拿自己的专利去起诉 Kubernetes 社区侵权——这时“专利报复”条款触发，公司 A 手里的专利授权当场失效，它继续使用、分发这些代码就失去了法律依据，还可能被反诉。

注意：专利授权并不是“贡献代码”才有的奖励，而是只要你使用、分发这份 Apache 2.0 代码，就已经自动获得。贡献代码只是让公司 A 同时成为“贡献者”，从而反过来承担起向他人授予专利许可的义务。

具体来说，“自己贡献内容”指的是公司 A 亲手提交给项目的那部分代码（比如它提的一个 PR、修的一个 bug）。Apache 2.0 规定：每个贡献者都要为自己提交的内容，向所有使用者授予专利许可。所以当公司 A 成为贡献者后，它对自己写的那部分代码也负有同样的义务——不能日后拿与这部分代码相关的专利去起诉别人。这就是“对等”：你享受了别人给你的专利授权，也要为你的贡献给出同样的承诺。

换句话说：不贡献代码，你只是“被授权方”；贡献了代码，你同时成了“授权方”，双方的权利义务才真正对等起来。

一句话总结：“你不告我，我授权你用；你一告我，授权立刻收回。”这条款的作用是让贡献者敢把专利技术放进开源项目，而不用担心被人“白用之后反咬一口”。

特点：适合企业级项目，法律确定性更高。Kubernetes、TensorFlow、Kafka 等均使用 Apache 2.0。注意，它与 GPL v3 兼容，但与 GPL v2 不兼容。

2.3 BSD License

BSD 系列（2-Clause、3-Clause）与 MIT 类似，属于宽松协议。

BSD License 的全称是Berkeley Software Distribution License（伯克利软件发行版许可证），简称 BSD License。它的由来可以追溯到 20 世纪 70 年代末的加州大学伯克利分校（University of California, Berkeley）。当时伯克利正在开发自己的 UNIX 衍生系统 BSD（Berkeley Software Distribution），为了让这套系统能被自由地分发和再开发，学校需要一份既能保留版权声明、又尽量少加限制的许可文本，BSD License 便由此诞生。

它最初只是一份为 BSD UNIX 服务的简短声明，后来随着 4.4BSD-Lite 等版本的传播被广泛沿用，并逐渐演化出不同变体：早期的 4-Clause 版本包含一条“广告条款”，要求所有宣传材料中必须致谢加州大学伯克利分校；这条款因使用不便后来被弃用，形成了今天常见的 2-Clause（Simplified BSD）和 3-Clause（New/Revised BSD）版本。

这里的“2-Clause”“3-Clause”指的是协议条款（Clause）的数量：数字越大，附加的限制越多。

2-Clause BSD（又称 Simplified BSD）只保留两条核心条款——保留版权声明、免责声明；3-Clause BSD（又称 New/Revised BSD）在此基础上多出第三条“禁止背书条款”：未经许可，不得使用版权持有者的名称来为衍生产品背书。FreeBSD、部分 macOS 组件使用此协议。

值得一提的是，BSD License 与 MIT License 在条款上高度相似，二者常被并称为“宽松许可证双雄”。由于 BSD 的措辞更早成型，MIT 的早期文本也受到其影响，这也是为什么两者在商业友好度上几乎难分伯仲。

3. Copyleft 许可证（传染性/互惠性）

Copyleft 协议的核心是“保持开放”：如果你修改并分发了基于该协议的代码，你的衍生作品也必须以相同协议开源。它分为“强 Copyleft”和“弱 Copyleft”。

“强”与“弱”的区别，在于传染范围不同：

• 强 Copyleft：只要你的程序与协议代码结合成一个整体作品并对外分发，整个作品都必须以相同协议开源。GPL、AGPL 属于这一类。
• 弱 Copyleft：只要求“协议代码本身及其修改”保持开源，不强制调用它的整个程序开源。LGPL、MPL 属于这一类，更适合被商业软件集成。

理解这条分界线，是读懂后面所有 Copyleft 协议的前提。

注意：Copyleft 的义务只在“对外分发”时触发——自己内部使用、修改后不发布，通常无需开源；一旦分发，就必须把同样的自由传递下去。

这里的“分发（Distribute）”到底指什么？简单说，就是你把软件（或它的衍生作品）以任何形式交给第三方——无论是发布到 GitHub 供人下载、打包进产品卖给客户、预装到硬件设备里出货，还是通过镜像站、应用商店、U 盘拷贝等方式提供给他人，都算分发。判断的关键是“有没有把代码/程序交到别人手里”，而不是“有没有收钱”：免费发布同样构成分发，收费与否不影响定性。反过来，只在公司内部部署、自己修改自己用、不对外提供，就不构成分发，Copyleft 的开源义务也就不会被触发。

3.1 强 Copyleft：GPL v2 / v3

GPL 是最著名的 Copyleft 协议，全称GNU General Public License（GNU 通用公共许可证），由自由软件基金会（Free Software Foundation，FSF）发布。

一旦你的软件包含了 GPL 代码（或与之链接），整个软件在分发时必须以 GPL 开源。Linux 内核使用 GPL v2，GCC、Bash 使用 GPL v3。

关键区别：GPL v3 增加了专利授权条款和“防 Tivoization”条款（禁止通过硬件限制阻止用户运行修改后的软件），并且与 Apache 2.0 兼容。GPL v2 则不与 Apache 2.0 兼容。

关于 GPL 的起源可以追溯到 20 世纪 80 年代：当时理查德·斯托曼（Richard Stallman）发起 GNU 计划，目标是构建一套完全自由的操作系统，但仅有自由软件还不够——如果代码一旦被他人修改后闭源分发，自由就会“流失”。为此，斯托曼于 1989 年发布了 GPL 第一版，用版权法反过来保障用户的四项自由（运行、研究、修改、再分发），这也是“Copyleft”理念的首次落地。此后 GPL 于 1991 年推出 v2、2007 年推出 v3，逐步补齐专利、硬件锁定等新问题，成为今天开源世界影响力最大的许可证之一。

3.2 网络时代的补丁：AGPL v3

AGPL 的全称是Affero General Public License（Affero 通用公共许可证），由 Affero 公司于 2002 年首次发布，后由自由软件基金会（FSF）接手维护，并于 2007 年随 GPL v3 一同推出 AGPL v3。

它是 GPL v3 的增强版，专门堵住一个漏洞：SaaS 场景。在普通 GPL 下，如果你修改了代码但只在服务器上运行、不分发软件，就没有开源义务。AGPL 规定：如果用户通过网络与该程序交互，你也必须向他们提供源代码。

适用场景：如果你不希望自己的服务端修改被闭源，AGPL 是最强的保护。但对于想基于开源代码构建闭源 SaaS 的公司，AGPL 是明确的红线。

4. 弱 Copyleft：平衡开放与商业

弱 Copyleft 协议试图在“保护开源”和“允许商业集成”之间取得平衡。它们通常只要求对协议代码本身的修改保持开源，而不“传染”到调用它的整个程序。

4.1 LGPL（GNU Lesser GPL）

LGPL 主要面向库（Library）。如果你只是动态链接LGPL 库，你的主程序可以保持闭源；但如果你修改了库本身并分发，修改部分必须以 LGPL 开源。这允许商业软件使用 LGPL 库，同时确保库的改进回馈社区。

4.2 MPL 2.0（Mozilla Public License）

MPL 是“文件级”的弱 Copyleft。它要求：你对 MPL 代码文件的任何修改，必须以 MPL 公开；但你可以将 MPL 代码与自己的新文件组合成一个更大的作品，并以其他协议（包括闭源）分发，只要新文件不受 MPL 约束。

适用场景：适合希望核心文件保持开放、但允许周边生态自由发展的项目。

5. 源码可用（Source-Available）与特殊协议

5.1 BSL（Business Source License）

BSL 严格来说不属于 OSI 定义的开源协议，而是“源码可用”。它允许你查看、修改代码，但限制将软件作为托管服务或嵌入商业产品提供给第三方。每个 BSL 版本都包含一个“变更日期”，到期后自动转换为真正的开源协议（如 Apache 2.0）。

典型案例：EMQX 从 5.9 版本起采用 BSL 1.1，单节点生产环境可免费使用，但多节点集群或商用 SaaS 需要商业许可。

5.2 公共领域奉献（Unlicense / CC0）

Unlicense 试图将软件完全奉献给公共领域。但需注意：部分国家（如德国）不承认“放弃版权”的概念，且 CC0 明确保留专利权利，因此 OSI 未批准 Unlicense，认为其法律效力存在不确定性。对于追求极致宽松的项目，更稳妥的选择是 MIT 或 Apache 2.0。

6. 选型速查表

7. 小结

开源协议的选择本质是对“自由”的定义不同：宽松协议保护的是“使用自由”，Copyleft 保护的是“代码持续开放的自由”。

对于大多数企业项目，MIT 和 Apache 2.0 是最安全、最省心的选择；如果涉及修改开源库并对外分发，需仔细评估 LGPL/MPL 的边界；而 AGPL 在 SaaS 场景下是一道需要严肃对待的红线。在集成任何开源组件前，花几分钟确认其协议类型，远比事后补救成本更低。