license.gen

指南 · 07

许可证兼容性基础

整理许可证兼容性是什么、为什么只在一个方向上成立，以及 Apache-2.0 与 GPL、MPL-2.0 的 Secondary License、LGPL 链接条件、AGPL 结合等典型组合。

最后核对：2026-09-23

兼容性就是「能否合并发布」

两个许可证兼容，是指将分别适用各许可证的代码合并成一个程序发布时，能够同时遵守两个许可证的条件。如果其中一方禁止另一方的条件，就不兼容。例如，GPL 要求「不得附加额外限制」，因此带有 GPL 所不允许的附加条件的许可证代码，就不能放进 GPL 程序。

兼容性是有方向的

宽松型代码可以进入著佐权项目，反过来则不行。

所以兼容性表始终要按 「把什么代码 → 放进什么项目」 来阅读。

典型组合

Apache-2.0 与 GPL

FSF 认为 Apache-2.0 与 GPL-3.0 兼容，但与 GPL-2.0 不兼容。因为 Apache-2.0 的专利终止条款和免责条款是 GPL-2.0 中没有的附加条件。GPL-3.0 在设计阶段就解决了这个问题。因此，GPL-2.0-or-later 项目只要将组合作品以 GPL-3.0 发布，就可以使用 Apache-2.0 代码。

MPL-2.0 与 GNU 许可证

MPL-2.0 第 1.12 条将 GPL-2.0、LGPL-2.1、AGPL-3.0 及其以后版本定义为「Secondary License」，第 3.3 条允许将 MPL 代码与这些代码合并而成的 Larger Work 按 GNU 许可证发布。原作者附加了 Exhibit B（「Incompatible With Secondary Licenses」）的情况除外。

LGPL 库与闭源应用

LGPL 库可以在闭源应用中使用。但必须让用户能够替换为修改后的库版本（动态链接最简单），并提供库部分的源代码和许可声明。如果把 LGPL 代码复制混入应用源代码，情况就不同了，组合作品必须遵守 LGPL/GPL 条件。

GPL-3.0 与 AGPL-3.0

这两个许可证通过各自的第 13 条明确允许相互结合。在组合作品中，GPL 部分继续遵守 GPL 条件，AGPL 部分继续遵守包括网络源代码提供条件在内的 AGPL 条件。

EPL-2.0 与 GPL

EPL-2.0 默认与 GPL 不兼容，但如果原作者通过 Exhibit A 将 GPL 等指定为 Secondary License，就可以结合。

引入的代码闭源应用MIT 项目GPL-2.0-onlyGPL-3.0
MIT·BSD·ISC可以（声明）可以可以可以
Apache-2.0可以（声明·NOTICE）可以不可以可以
MPL-2.0有条件（公开文件）有条件有条件（Secondary）有条件（Secondary）
LGPL-3.0有条件（链接）有条件（链接）不可以可以
GPL-3.0不可以不可以不可以可以

「结合」到什么程度

兼容性问题在代码结合成一个程序时产生。FSF 认为，链接成同一个可执行文件或共享复杂的内部数据结构时，视为一个程序；而管道、套接字、命令行参数等独立程序之间的一般通信，通常视为独立程序的「聚合（aggregate）」。不过这一边界并未由法院判例确定，存在解释分歧。在一个发行版中同时收录多个程序本身并不构成结合。

实务步骤

  1. 导出依赖项列表（使用包管理器的许可证报告功能或 SBOM 工具）。
  2. 用 SPDX 标识符整理每个依赖项的许可证。
  3. 用兼容性检查器初步确认它们与我的项目许可证的组合。
  4. 对于「有条件」的组合，对照原文确认其条件（声明、链接方式、是否有 Secondary License）。
  5. 如果存在不可以的组合，就更换依赖项、拆分程序，或调整我的许可证。
本文为一般信息，不构成法律意见。重要决定请咨询专业人士。

参考来源