四种开源协议，哪个最宽松，哪个要求贡献回流
2026年7月16日 10:30
专 题 04 · 第 3 篇
四种开源协议，
哪个最宽松，哪个要求贡献回流
GitHub 系列第 3 篇｜MIT / Apache / GPL / AGPL
文 / 不折腾的刘律
◆ ◆ ◆
案件看板开源那会儿，我自己就碰到了一个问题：选哪个协议？
当时也不太懂，就跟 AI 说了一句"我要个人免费用，商用需要授权"。AI 给我推荐了 PolyForm Noncommercial。我看了一眼觉得意思对，就用了。
后来才发现，这个协议跟 GitHub 上大家常用的 MIT、Apache 那些并不一样——它甚至不算严格意义上的"开源协议"。那些常见的到底在说什么、跟我选的有什么区别？这就是这篇要聊的事。
先抓住五个判断点：
1. 能不能商用？
2. 改了之后必须开源吗？
3. 有没有专利授权？
4. 商标能不能一起用？
5. 做 SaaS 会不会触发源代码公开义务？
下面每个协议我都围绕这几个问题讲。先建立风险地图，别急着把自己训练成许可证专家。
先给一张大白话速记表：
MIT：最宽松，保留版权和许可声明。
Apache 2.0：也宽松，但多了明确专利授权、修改标注和 NOTICE 规则。
GPL：你分发基于 GPL 的衍生作品时，要把相应源代码带回社区。
AGPL：把网络服务这个场景也纳入了源代码提供义务。
◆ ◆ ◆
01MIT——最宽松，署名就行
MIT 是目前 GitHub 上使用最广泛的协议。它的全文只有几行字，核心意思就一句话：
你随便用、随便改、随便卖——但得把我的版权声明保留着。
四个问题的答案：
- 能商用吗？能。
- 改了必须开源吗？不用。
- 有专利授权吗？没有明确写。
- 做 SaaS 有坑吗？一般不是协议本身的核心坑。
适合：个人项目、小工具、不想管太多的作者。法律人自己做小工具，如果想降低别人使用门槛，MIT 是很常见的选择。
◆ ◆ ◆
02Apache 2.0——MIT + 专利保护 + 商标限制
Apache 2.0 比 MIT 长很多，但核心思路差不多——也很宽松。区别在于它多了两件事：
第一，明确给你专利授权。作者持有的相关专利，你在使用这份代码时也一并获得许可。不用担心"用了代码但被作者用专利告你"这种事。
第二，商标不跟着走。你用了 Apache 协议的代码，不代表你可以用原项目的名字、Logo 或商标。品牌归品牌，代码归代码。
还有两点很容易被忽略：如果你修改了代码再分发，需要在修改的文件里标注"这里改过了"；如果原项目带 NOTICE 文件，你也要按协议保留相应的归属信息。
四个问题的答案：
- 能商用吗？能。
- 改了必须开源吗？不用。但分发时要保留许可、版权声明和必要 NOTICE，并标注修改。
- 有专利授权吗？有。
- 商标能用吗？不能当然使用。
- 做 SaaS 有坑吗？通常不是它的核心风险。
适合：公司级项目、涉及专利的场景。Android、Kubernetes、很多大厂开源的东西都用 Apache 2.0。
◆ ◆ ◆
03GPL v3——Copyleft 开源
GPL 跟前面两个画风完全不同。它不是不让你商用，也不是不让你赚钱。它的核心逻辑更像一个交换：
你拿社区代码继续分发，
社区也要求你把对应自由带回去。
这就是所谓的 Copyleft。很多中文文章会把它叫"传染性"，但这个词容易把事情讲得太吓人。简单说就是：你在 GPL 代码基础上改出来的东西，如果要分发给别人用，你也得把源代码一起给出去。
注意关键词：分发。GPL 的触发条件是你把软件给了别人（卖也好、送也好）。如果只是自己内部用，不分发出去，不触发这个义务。
四个问题的答案：
- 能商用吗？能。GPL 不禁止收费。
- 改了必须开源吗？分发对应作品时通常要提供相应源代码。
- 有专利授权吗？GPL v3 有相关专利条款。
- 商标能用吗？不能当然使用。
- 做 SaaS 有坑吗？GPL v3 本身主要盯分发，不是专门盯网络服务。
适合：希望社区贡献必须回流的项目。很多基础软件项目都选择 GPL 系许可证。注意，不同项目用的是不同版本，不能把 GPL v2、GPL v3、LGPL、AGPL 混在一起说。
⚠️ "传染性"的边界有争议：什么算"衍生作品"、动态链接算不算、独立模块算不算——技术圈和法律圈至今没有完全统一的答案。遇到具体场景建议具体分析，不要一刀切。
◆ ◆ ◆
04AGPL v3——网络服务场景的源代码义务
AGPL 可以理解为 GPL 在网络服务时代的加强版。它盯住的是一个很现实的场景：软件不再打包发给用户，而是跑在服务器上，用户只通过网页或接口使用。
传统 GPL 主要盯"分发"。但很多公司做的是 SaaS——软件跑在自己的服务器上，用户通过网页或 App 访问。用户从来没有拿到软件副本，这就让 GPL 的分发触发点变得不够好用。
AGPL 加了一条更强的网络交互义务：如果你修改了 AGPL 程序，并通过网络让用户和它交互，用户应当能拿到对应的修改版源代码。
这意味着：如果你用了 AGPL 代码做在线服务，尤其还修改了它，不能只说"我又没把软件发给用户"。这就是很多 SaaS 公司对 AGPL 代码格外谨慎的原因。
四个问题的答案：
- 能商用吗？能。
- 改了必须开源吗？分发或网络交互触发时，要提供对应源代码。
- 有专利授权吗？有。
- 商标能用吗？不能当然使用。
- 做 SaaS 有坑吗？有，这是 AGPL 最需要注意的地方。
这就是为什么很多做 SaaS 的公司对 AGPL 代码非常谨慎——用了以后，可能不只是保留声明这么简单，而是要重新评估自己的服务架构、修改范围和源代码提供义务。
反过来说，如果你自己做了一个工具，希望别人即使做成在线服务也要把修改回馈出来，AGPL 确实是一种可考虑的策略。但它会提高别人采用你项目的心理门槛，所以不是所有项目都适合。
顺手补一个中国语境：木兰宽松许可证 Mulan PSL v2 是中英双语的 OSI 认证许可证，风格接近宽松协议，也包含专利授权和无商标授权等安排。法律人以后如果看到国产开源项目使用 Mulan PSL，不要误以为它是"自定义小作文"，它是正式开源许可证。
◆ ◆ ◆
05选协议不是信仰，是工具
没有"最好的协议"，
只有最适合你当下场景的协议。
不同场景适合不同协议：
- 个人小项目、不想管太多 → 可以考虑 MIT
- 公司项目、重视专利授权和归属信息 → 可以考虑 Apache 2.0
- 希望社区改进必须回流 → 可以考虑 GPL
- 担心别人改一改就做成闭源 SaaS → 可以研究 AGPL
- 面向国内外开发者、希望中文文本更友好 → 可以了解 Mulan PSL v2
这里故意都写成"可以考虑"，不是直接替你决定。协议是法律工具，不是技术信仰。
回到我自己的案件看板。我当时选了 PolyForm Noncommercial，后来才意识到它跟上面说的四个协议有本质区别：
PolyForm Noncommercial 不算严格意义上的"开源协议"。
MIT、Apache、GPL、AGPL 都允许商用——区别只是条件不同。但 PolyForm Noncommercial 直接禁止了商业用途，除非另行授权。它属于"源码可见"（source available），但不满足开源社区对"开源"的定义。
这意味着什么？个人学习、研究、自用——没问题。但如果有人想拿去做商业产品，得先来找我拿授权。这恰好是我想要的：让同行律师用着方便，但不想被人白嫖了拿去卖钱。
当时我不懂这些区别，随手跟 AI 说了需求它就给我推荐了。现在回头看，选得其实还算对路——但如果我事先知道这些协议的差异，选择会更踏实。
下一篇要聊一个更现实的问题：AI 时代别人用 AI 快速复刻了你的产品——法律上到底算什么？
协议不是信仰，是法律工具。
想清楚自己要什么，再选。
◆ ◆ ◆
如果这篇文章对你有帮助或者觉得还不错。
帮忙点个「👍」和「❤️」，对我来说真的很重要。
平台会因为这些反馈把文章推给更多人看，我也更有动力继续写下去。
如果愿意转发给身边的朋友或者朋友圈，那就更感谢了。