主流开源协议的权限与限制对比，开源协议到底怎么选

697次阅读

共计 3805 个字符，预计需要花费 10 分钟才能阅读完成。

大家好，我是星哥。如果把开源项目比作一栋精心建造的房子，那么开源协议就是这栋房子的房产证——它不仅明确了 ” 房子 ” 的归属权，更规定了谁能住、怎么改、能不能转租，甚至拆了重建后要不要公开图纸。在开源世界里，这个 ” 房产证 ” 的法律意义和技术约束，远比很多开发者想象的更关键。

本文将带你盘点最常见的开源协议，解析它们允许与禁止的行为，帮助你快速甄别最佳选型。

从法律层面看，开源协议在中国被明确视为受《合同法》保护的 ” 合同 ”。

开源许可证（License）中规定的权利与义务具有法律约束力，违反协议而从技术角度，它更像一份 ” 技术契约 ”，定义了代码传播、使用的规则，平衡着自由与权益、开放与商业的微妙关系。

简单说，你写的代码能不能被商用、改了之后要不要公开、别人侵权了能不能追责，全靠这份协议来定。

核心定义：麻省理工学院发布的极简协议，允许几乎无限制地使用、修改、分发开源代码，仅要求保留原始版权声明和许可声明。
关键条款：
- 可商用：允许将代码集成到闭源商业软件中，无需开源整个产品；
- 无专利约束：不强制贡献者授予专利许可；
- 免责声明：明确作者不对软件瑕疵承担法律责任。
适用场景：追求最大自由度的场景，如小型工具、前端组件、个人项目。典型案例：Vue.js、React、jQuery。

核心定义：与 MIT 类似的宽松协议，核心差异在于早期“4 条款”包含“广告 clause”（要求宣传中提及原作者），现主流为3 条款 BSD（移除广告条款，更简洁）。
关键条款：
- 保留版权声明：修改或分发时需包含原始版权、许可和免责声明；
- 无“传染性”：允许闭源商用，无需公开修改后的代码；
- 专利无强制：同 MIT，不绑定专利许可。
适用场景：注重简洁性且需避免广告义务的场景，如操作系统组件、底层库。典型案例：FreeBSD（操作系统）、Django（Python Web 框架，早期用 BSD，后转 BSD 变体）。

核心定义 ：Apache 软件基金会发布，在 MIT/BSD 基础上强化 专利保护 和贡献者责任，是商业公司最青睐的协议之一。
关键条款：
- 专利授权：要求贡献者授予使用者“与代码相关的专利许可”，避免后续专利诉讼；
- 明确修改声明：修改代码后需标注“修改部分”，但无需开源整个产品；
- 兼容闭源：允许商用闭源，但需在软件文档中说明使用了 Apache 协议代码；
- 禁止商标滥用：不得用原项目商标宣传衍生产品。
适用场景：商业软件集成、企业级开源项目（需规避专利风险）。典型案例：Apache Hadoop、Android（核心框架）、TensorFlow。

核心定义：Mozilla 基金会发布，属于“弱 copyleft”协议，平衡“开源协作”与“商业闭源需求”，核心特点是 “文件级传染性”（区别于 GPL 的“项目级传染性”）。
关键条款
：
- 仅开源“修改的 MPL 文件”：若修改了 MPL 协议下的代码文件，需将该文件开源；但调用该文件的其他闭源文件无需开源；
- 专利保护：贡献者需授予专利许可，且禁止“专利报复”（即使用者因维权专利而被终止许可）；
- 兼容 GPL：MPL 代码可与 GPL 代码合并（合并后整体需遵循 GPL）。
适用场景：需部分闭源、但核心模块需开源协作的项目。典型案例：Firefox（浏览器）、Thunderbird（邮件客户端）。

核心定义：由 Eclipse 基金会主导，基于 MPL 2.0 优化，更适配企业级开发场景，同样属于“文件级弱 copyleft”。
关键条款：
- 与 MPL 2.0 核心一致：仅开源修改的 EPL 文件，闭源文件可调用；
- 强化“贡献者透明”：要求公开代码的获取路径（如仓库地址）；
- 禁止“附加限制”：不允许在 EPL 代码上添加额外的使用限制（如禁止商用）。
适用场景：企业级 IDE、中间件、开发工具。典型案例：Eclipse IDE（开发工具）、Spring Cloud Stream（部分模块）。

核心定义：自由软件基金会（FSF）发布的“强 copyleft”协议，核心是 “传染性”—— 任何基于 GPL 代码的衍生作品（无论修改程度），必须以相同协议开源，禁止闭源商用。
关键条款：
- 完全传染性：若项目包含 GPL 代码（哪怕仅调用），整个项目必须开源，且允许他人自由修改、分发；
- 专利保护：禁止“专利陷阱”，要求贡献者授予专利许可，且禁止“歧视性授权”（如只给部分企业授权）；
- 禁止“DRM 锁定”：不允许用数字版权管理（DRM）限制 GPL 软件的使用（如禁止用户修改）；
- 硬件限制：若软件预装在硬件中（如路由器），需提供“解锁硬件”的方法（方便用户替换软件）。
适用场景：纯开源项目、追求“完全自由共享”的场景（拒绝闭源商用）。典型案例：Linux 内核（早期用 GPLv2，现部分模块兼容 v3）、GCC（编译器）、Git。

核心定义：由 MongoDB 在 2018 年推出，基于 GPLv3 扩展，专门针对“云服务场景”，核心是 “禁止将开源软件作为闭源云服务提供”。
关键条款
：
- 继承 GPLv3 的“项目级传染性”：衍生作品需开源；
- 新增“服务端义务”：若将 SSPL 协议的软件（如数据库）作为云服务（SaaS）提供，必须开源“整个服务栈代码”（包括运维工具、管理平台等）；
- 争议点：因限制云服务商用，被开源组织（如 OSI）拒绝认定为“开源协议”，但 MongoDB 仍自称开源。
适用场景：数据库、中间件等“服务端软件”（防止大厂“拿来主义”做闭源云服务）。典型案例：MongoDB（3.0 + 版本）、Redis（曾计划采用，后放弃）。

核心定义 ：并非独立协议，而是 附加在 MIT/Apache/BSD 等宽松协议上的“限制条款”，本质是“阉割开源自由度”，常被用于“商业控制”。
关键条款：
- 禁止“商用再分发”：允许个人使用、修改，但禁止将代码（或衍生作品）作为“商业产品”出售或提供服务（如禁止用 Apache+Commons Clause 的代码做 SaaS 服务）；
- 非 OSI 认证：因限制商用，不符合开源定义（开源需允许商用），被视为“伪开源”的常见形式。
适用场景：企业希望“部分开源引流”，但拒绝他人商用获利。典型案例：早期 Elasticsearch、Logstash（后因争议放弃，转回 Apache 2.0）。

协议对照表

协议类型	再分发 + 修改	再发布（放仓库）	宣传 / 推广	特别限制
MIT	✅ 允许	✅ 允许	✅ 允许	保留版权声明
Apache 2.0	✅ 允许	✅ 允许	✅ 允许	说明修改、保留版权
BSD 2-Clause	✅ 允许	✅ 允许	✅ 允许	保留版权声明
BSD 3-Clause	✅ 允许	✅ 允许	✅ 允许	不可用原作者背书
GPLv3	✅ 允许	✅ 允许	✅ 允许	必须继续 GPL 开源
LGPL	✅ 允许	✅ 允许	✅ 允许	修改库要开源
MPL	✅ 允许	✅ 允许	✅ 允许	修改文件需开源
EPL	✅ 允许	✅ 允许	✅ 允许	修改部分需 EPL
SSPL	✅ 允许	✅ 允许	✅ 允许	提供服务需全开源
Commons Clause	⚠️ 有限制	⚠️ 有限制	✅ 允许	禁止商用
BSL	⚠️ 有限制	⚠️ 有限制	✅ 允许	商业化需付费

主流开源协议的权限与限制对比，开源协议到底怎么选

自媒体传播 & 贴仓库链接

主流开源协议的权限与限制对比，开源协议到底怎么选

类别	典型协议	再分发 + 修改	再发布（公开仓库）	宣传 / 推广	关键注意点
宽松	MIT / Apache-2.0 / BSD	✅	✅	✅	保留版权 /NOTICE；BSD-3 & Apache 禁官方背书 / 商标误用
强传染	GPLv3 / LGPL	✅（需继续 GPL/LGPL）	✅（需继续 GPL/LGPL）	✅	提供源码 / 获取途径；勿闭源再分发
文件级传染	MPL-2.0 / EPL-2.0	✅（修改过的文件需开源）	✅	✅	便于与闭源并存；聚焦“被修改文件”
服务侧开源	SSPL	✅	✅	✅	若对外提供服务→需开源整套服务端
限制商业	Commons Clause / BSL	⚠️（非商用 / 延迟开源等）	⚠️	⚠️（宣传可但慎商用导向）	具体条款优先：常限制盈利 / 销售 / 付费服务
自定义 / 伪开源	公司定制（含“基于 GPL+ 限制”）	❌/⚠️	❌/⚠️	⚠️	常见“禁止衍生 / 再分发 / 反编译 / 商用”