我最近在搓一个自动化知识库处理工具，用来处理飞书收集群里的增量消息。起因很简单：平时习惯睡前刷技术博客，顺手把链接丢进微信或飞书——但忙起来根本没空整理；偶尔读完会随手记几句想法，一旦拖着就全忘了。所以就想做个工具，自动帮我汇总内容、归纳知识、顺带把那些随手写下来的东西也存住。

有些时候这些内容会包含 PDF 文件，需要能自动提取里面的内容。调研之后，发现 MinerU 比较合适，可以从 PDF 里自动提取文本。我最开始是在 B 站上刷到这个工具的，然后从评论区注意到有位用户提到它用的是传染性开源协议——也就是用了这个项目，就必须开源自己的代码。不过我发现最新的项目 README 里写着：

2026/04/18 3.1.0 Released

This release focuses on licensing openness, parsing accuracy, and full-format native support. The main updates include:

License upgrade MinerU has officially moved from AGPLv3 to the MinerU Open Source License, a custom license based on Apache 2.0. This change significantly reduces adoption friction for both community users and commercial deployments, making MinerU easier to integrate into real-world workflows.

正是这个事情，让我打算了解一下各个常见的开源协议，以及它们的区别和联系，避免以后在用开源项目时因为协议问题踩坑。

常见开源协议的理解

理解开源协议，核心不是"能不能看代码"，而是拿来之后能不能改、能不能商用、改完之后要不要公开、需不需要带上原作者声明、有没有专利授权。很多纠纷其实不是因为代码本身，而是因为把协议条款想得太简单了。

如果只是粗粗地分类，可以分成下面几类：

  1. 宽松型协议（Permissive License）
  2. 弱传染型协议（Weak Copyleft）
  3. 强传染型协议（Strong Copyleft）
  4. 自定义协议（Custom License）

其中真正最容易踩坑的，往往是后两类，因为它们对"修改后怎么分发"“是否需要开源"“是否涉及网络服务"这些问题限制更强。

速记表

协议商用修改闭源集成修改后是否可能要求开源专利条款
MIT可以可以可以通常不要求弱
Apache 2.0可以可以可以通常不要求强，写得较清楚
BSD可以可以可以通常不要求一般
GPL可以可以风险高分发衍生作品时要求较强一般
LGPL可以可以相对可以主要针对库本身修改一般
AGPL可以可以风险更高对网络服务场景也要求较强一般
MPL 2.0可以可以可以文件级开源要求一般

这个表只能拿来做第一层筛选，不能直接代替正式合规判断，因为真正有争议的地方往往在"是否构成衍生作品"“只是调用还是深度集成"“是否发生分发"“SaaS 是否触发条款"等边界问题上。

1. MIT License

MIT 应该算是 GitHub 上最常见、也最好理解的协议之一。

它的核心特点可以概括为：

  • 允许商用
  • 允许修改
  • 允许再分发
  • 允许闭源使用
  • 只要求保留原始版权声明和许可声明

如果一个项目是 MIT，通常可以比较放心地集成进自己的系统里，哪怕是商业项目也一般问题不大。它的优点就是简单、传播阻力小，很多库作者选 MIT，就是希望别人尽量少受限制地使用。

不过 MIT 也不是"完全没要求”，至少原作者的版权和许可文本不能删。另外它一般不强调专利条款，所以如果项目涉及比较强的专利风险，通常会更倾向于看 Apache 2.0。

2. Apache License 2.0

Apache 2.0 也是非常常见的宽松型协议，但比 MIT 更完整一些。

它的关键点可以记成：

  • 允许商用
  • 允许修改
  • 允许闭源分发
  • 要保留版权声明和 License
  • 如果项目里有 NOTICE 文件，分发时通常也要一起带上
  • 明确给出了专利授权和专利终止条款

所以 Apache 2.0 可以理解成"更工程化的 MIT”。
如果一个项目来自大公司、基金会或者成熟社区，看到 Apache 2.0 往往会更安心，因为它把专利问题写得更清楚。

像这次 MinerU 从 AGPLv3 切到一个基于 Apache 2.0 的自定义协议，这件事本身就说明了一个问题：项目如果想让更多企业和真实业务接得进来，通常会尽量降低协议阻力，而 Apache 2.0 这类协议就比较适合作为基础。

3. BSD License

BSD 也属于宽松型协议，常见的有 BSD 2-Clause 和 BSD 3-Clause。

对 BSD 的粗略理解是：

  • 和 MIT 很像
  • 也是允许商用、修改、闭源
  • 主要义务还是保留版权声明和许可文本
  • 3-Clause 比 2-Clause 多一个"不能用原作者或组织名义做背书宣传"的限制

从实际使用角度看，BSD、MIT、Apache 2.0 经常可以归到一组里理解：整体都比较宽松，适合做基础组件、工具库、SDK 之类的东西。

4. GPL License

GPL 是典型的强传染型协议，也是很多人口中"病毒式协议"“传染性协议"的来源。不过"传染性"这个说法虽然好记，但也容易让人理解过度，更准确的说法是：它要求衍生作品在特定分发条件下继续以 GPL 开源。

GPL 的理解重点是：

  • 允许使用、修改、分发、商用
  • 但如果把基于 GPL 的程序修改后再分发，通常也必须以 GPL 方式开放源码
  • 不能把 GPL 代码拿进去改一改，然后整体闭源卖掉

所以 GPL 的核心思想不是"禁止商业化”，而是"商业化可以，但你不能把自由重新收回去”。

这类协议适合那些希望社区贡献持续回流、不希望别人拿去闭源包装的项目。

5. LGPL License

LGPL 可以看成比 GPL 更宽松一些，常见于类库场景。

LGPL 的理解是：

  • 如果只是动态链接一个 LGPL 库，自己的主程序通常不一定需要整体开源
  • 但如果直接修改了这个 LGPL 库本身，修改部分通常仍然要按 LGPL 公开
  • 它比 GPL 更适合做"希望被广泛调用，但又不想完全放弃回馈要求"的基础库

所以 LGPL 经常被看作"弱一点的 GPL”。
对使用者来说，它比 GPL 友好，但也不像 MIT/Apache 那么随意。

6. AGPL License

AGPL 是这次最关注的一个，因为它跟 SaaS/在线服务的关系很大。

AGPL 的核心理解是：

  • 它基本继承了 GPL 的强 Copyleft 思想
  • 但它额外补上了"网络服务"这个场景
  • 如果我修改了 AGPL 程序，并通过网络向用户提供服务，那么通常也需要向这些用户提供对应的源码

这就是为什么很多人一听到 AGPL 就很紧张。
对传统 GPL 来说，有些公司可能不"分发软件”，而是只把它部署成在线服务，从而绕开开源义务；AGPL 就是专门堵这个洞的。

所以如果一个项目是 AGPL，通常会特别关注：

  • 是只在内部研究使用，还是要对外提供服务
  • 有没有修改原项目
  • 整体系统是否会因此被认定为衍生作品

对于打算商业化部署的工具链来说，AGPL 的采用门槛确实会明显更高。

7. MPL 2.0

MPL 2.0 是一个很值得记住的中间路线。

它属于弱传染型协议，可以这样理解：

  • 允许商用
  • 允许和闭源代码一起组合
  • 但如果修改了 MPL 覆盖的那个文件，这些被修改的文件通常要继续开源
  • 它的开源义务通常是"文件级"的，而不是像 GPL 那样容易扩展到整个项目

所以 MPL 2.0 比较适合那种既想保留一定回馈机制、又不想把限制放得像 GPL/AGPL 那么重的项目。

如果以后自己做工具，希望"别人能商用，但改了核心文件最好回传"，MPL 其实是一个可以重点考虑的方向。

8. The Unlicense

The Unlicense 可以理解成一种非常极端的宽松态度，接近于把代码直接放进公有领域。

对它的印象是：

  • 几乎不设限制
  • 允许任意使用、修改、分发
  • 对某些法域下"公有领域让渡是否绝对成立"可能存在理解差异

所以它虽然很自由，但在一些正式商业场景里，可能不如 MIT/Apache 2.0 那么常见和稳妥。

9. 自定义协议 — 以 MinerU 为例

前面分类里提到了"自定义协议"，MinerU 的新协议就是一个现成的例子，可以拿来具体看看。

自定义协议的常见做法是：在 MIT 或 Apache 2.0 这类宽松协议上，叠加一些附加条款，针对特定场景补充约束。MinerU 的协议底层是 Apache 2.0，但额外加了两条：

条款一：商业规模门槛

免费商用默认可以，但如果你和你的关联公司合并计算，达到以下任一条件，就需要单独向 MinerU 团队获取商业授权才能继续使用：

  • 月活用户（MAU）超过 1 亿；或
  • 单月总收入超过 2000 万美元

换句话说，对于大多数使用场景——个人研究、内部工具、中小规模商业部署——这个门槛根本不会触发，用起来跟 Apache 2.0 几乎没有区别。只有真正达到平台级体量的公司，才需要单独谈。

条款二：在线服务署名义务

如果把 MinerU 做成面向第三方用户的在线服务，需要在产品界面或公开文档里明确标注使用了 MinerU。

另需注意：部分依赖模型仍是 AGPL

MinerU 里集成的一些模型组件（如基于 YOLO 的检测模型）本身使用的是 AGPL 协议，并不随主协议变化。如果最终部署的服务用到了这部分模型，AGPL 的在线服务开源义务仍然适用。所以使用前，最好把依赖链也一起查清楚。

和 AGPLv3 相比，这个协议温和很多：

  • 不要求公开源代码，闭源商用也没问题
  • 做成 SaaS 也不需要开源，只需要标明"使用了 MinerU"
  • 只有极少数超大规模场景才需要另行授权

这类"宽松协议 + 商业规模限制"的组合，在 AI 工具和数据处理领域越来越常见——作者希望社区可以自由使用，但不想让大公司直接拿去做亿级用户的产品却没有任何回馈或沟通。

这也说明了开头那个分类里"自定义协议"存在的意义：当标准协议不能完全表达作者的意图时，自定义一个反而更直接。

几个关键区别

1. “开源"不等于"随便用”

只要作者没有明确给出许可证，哪怕代码放在 GitHub 上公开可见，也不代表别人就可以随便复制、修改和商用。
所以看到仓库的第一件事，不应该先看 star 数，而应该先看 License。

2. GPL 和 AGPL 的差别，关键在网络服务

这两个很容易混。速记方法：

  • GPL：更关注"分发"软件时的开源义务
  • AGPL：在 GPL 基础上，进一步覆盖"通过网络提供服务"的场景

如果一个工具未来可能做成 Web 服务、SaaS 平台、在线 API，那 AGPL 的影响通常比 GPL 更敏感。

3. 宽松型协议更适合基础设施传播

MIT、BSD、Apache 2.0 之所以流行，一个很大的原因就是它们太适合做生态底座了。
别人拿来就能用，商业公司也容易接，阻力小，扩散快。

4. Copyleft 协议更强调社区回流

GPL、AGPL、MPL、LGPL 这类协议背后的思想，不只是"限制"，更像是在设计一种回馈机制：
你可以拿去用，但你不能只拿走好处、不把改动回馈回来。

所以不能简单说哪种协议更"好"，更多还是取决于项目作者想要什么。

如果以后自己选协议，可以怎么想

目前大概可以这样粗分：

  • 如果希望别人尽量广泛使用，包括公司直接接入商业系统，可以优先考虑 MIT 或 Apache 2.0
  • 如果担心专利问题，或者希望条款更完整，可以更偏向 Apache 2.0
  • 如果希望改动能回流，但又不想强制整个项目一起开源，可以考虑 MPL 2.0 或 LGPL
  • 如果非常强调"改了再分发就必须继续开源"，可以考虑 GPL
  • 如果连 SaaS 场景也想覆盖，不希望别人改完部署成在线服务却完全不回馈，可以考虑 AGPL

一个排查清单

以后在用一个开源项目之前，至少先问下面几个问题：

  1. 这个仓库到底有没有明确 License？
  2. 它是 MIT/Apache 这种宽松协议，还是 GPL/AGPL 这种 Copyleft 协议？
  3. 是只在内部研究，还是要集成到商业项目里？
  4. 是单纯调用，还是会直接修改它的源代码？
  5. 会不会把它做成对外提供服务的在线系统？
  6. 项目里除了代码 License 之外，还有没有 NOTICE、商标、专利、模型权重、数据集等额外限制？

一个很重要的认识

以后看开源项目，不能只盯着"功能强不强"，还得把"协议带来的接入成本"也一起算进去。
有些项目技术上非常合适，但协议不一定适合当前业务形态；有些项目虽然功能略弱，但协议更宽松、接入成本更低，在工程上反而更现实。

所以协议本身，其实也是技术选型的一部分。

备注

以上内容主要适合拿来做技术选型和日常避坑时的第一轮判断，不适合直接替代正式法律意见。真遇到商业化、融资、闭源分发、对外 SaaS 或者二次授权这类场景，还是应该认真看原协议文本，必要时找专业法务确认。