本文目录导读：
这是一个非常核心且复杂的开源合规问题。依赖许可证兼容性矩阵用于判断一个项目能否合法地整合不同许可证的开源库。
由于许可证数量众多且解释存在法律灰色地带,不存在一个绝对权威的“万能矩阵”，但基于开源促进会（OSI）、Linux基金会以及Google、Facebook等大厂的合规实践，可以总结出最常用的核心兼容性规则。
以下是针对商业闭源项目和开源项目两种场景的兼容性矩阵。
核心原则：左方依赖（被引用的库） vs 上方宿主（你的项目）
矩阵中的判断逻辑是：如果我的项目（宿主）使用了某个许可证的库（依赖），我的项目必须采用什么许可证？
符号说明
- ✅ 兼容：可以包含，通常无传染性要求。
- ⚠️ 有条件兼容：需要满足特定条件（如保留版权声明、提供源码等）。
- ❌ 不兼容：直接混合通常违反条款。
- 🔗 弱传染性：仅修改该库本身时才需开源，动态链接可能豁免。
- 🪞 强传染性：使用该库可能导致整个项目必须开源。
你的项目是 商业闭源 / 专有软件
这是最常见也是最严格的场景,你需要避免任何“强传染性”许可证。
| 依赖许可证 \ 你的项目 | 商业闭源 | 说明 |
|---|---|---|
| MIT, BSD, Apache 2.0, Unlicense, CC0 | ✅ 兼容 | 最安全，可以任意使用、修改、包含而无需开源你的代码，只需保留版权声明。 |
| LGPL-2.1 / LGPL-3.0 | ⚠️ 有条件兼容 | 核心规则：如果动态链接（.dll/.so/.dylib），通常视为单独作品，无需开源主程序，如果静态链接，需要提供目标文件（.o/.obj）或让用户能够替换该库。 |
| MPL-2.0 | ✅ 兼容 | 安全，对修改过的该库文件本身有传染性，但对整个项目无传染性，可以闭源。 |
| GPL-2.0 | ❌ 不兼容 | 严格禁止，GPL规定任何“衍生产品”都必须以GPL发布，通常认为链接行为已构成衍生。 |
| GPL-3.0 | ❌ 不兼容 | 同上，且对于专利授权和Tivoization有更严格限制。 |
| AGPL-3.0 | ❌ 不兼容 | 极度不兼容，即使通过网络使用（不分发可执行文件），也视为发布，必须提供源码，绝大多数商业项目会规避。 |
| SSPL (MongoDB) | ❌ 不兼容 | 专为打击云服务商设计，几乎等效于AGPL+额外条件，被OSI部分认定为非开源。 |
| BSL (Business Source License) | ⚠️ 有条件 | 不是严格意义上的开源许可证，但有“Change Date”（如4年后变MIT），需要在期限内遵循限制。 |
你的项目是 开源项目
此时你更关心的是多许可证混合时的协议冲突问题。
| 依赖许可证 \ 宿主项目许可证 | MIT/BSD/Apache | LGPL | GPL | MPL |
|---|---|---|---|---|
| MIT/BSD/Apache | ✅ 兼容 | ✅ 兼容 | ✅ 兼容 | ✅ 兼容 |
| LGPL | ✅ 兼容（宿主可继续用MIT） | ✅ 兼容 | ✅ 兼容 | ⚠️ MPL 2.0 Sec 3.3允许，但LGPL要求动态链接 |
| GPL | ❌ 不兼容 | ⚠️ GPL不兼容LGPL，GPL项目不能用LGPL库 | ✅ 兼容 | ❌ 不兼容（GPL禁止额外限制） |
| MPL | ✅ 兼容（MPL文件保持MPL即可） | ✅ 兼容 | ❌ 不兼容（GPL不包容MPL的File-level专利条款） | ✅ 兼容 |
| Apache 2.0 | ✅ 兼容 | ✅ 兼容 | ⚠️ GPL-3.0兼容Apache2，GPL-2.0不兼容 | ✅ 兼容 |
关键“雷区”与例外
-
GPL-2.0 vs Apache 2.0
- 不兼容。
- 原因：GPL-2.0的条款要求任何衍生产品必须满足GPL-2.0的“不得增加额外限制”条款，Apache 2.0的专利授权条款（Section 3）在自由软件基金会（FSF）看来，构成了GPL-2.0不允许的“额外限制”，你不能在GPL-2.0项目里链接Apache 2.0的库。
-
GPL-3.0 vs Apache 2.0
- 兼容。
- 原因：GPL-3.0具有专利兼容性条款（Section 7b），明确允许Apache 2.0的专利授权条款，FSF明确将Apache 2.0列为与GPL-3.0兼容。
-
GPL vs MPL
- 不兼容。
- 原因：MPL-2.0（和更旧的MPL-1.1）对于修改过文件的许可要求与GPL的整体性要求相冲突，虽然MPL-2.0有一个GPL兼容性改进（允许外部类库以GPL发布），但直接在GPL项目中使用MPL库仍被视为不兼容。
-
CC0 (Creative Commons Zero)
- 通常兼容（但有争议）。
- 原因：CC0号称“无版权”，但FSF认为它并没有明确放弃专利权，因此建议谨慎使用，但绝大多数大公司（如Google）视其为与MIT等同。
工具推荐：自动化扫描
手动构建矩阵效率极低,建议使用以下工具自动生成依赖关系图并检查冲突：
| 工具 | 语言/平台 | 特点 |
|---|---|---|
| FOSSA | 多语言 | 企业级，SaaS服务，自动生成合规报告和漏洞扫描。 |
| Snyk (Open Source) | 多语言 | 不仅检查漏洞，也检查许可证兼容性。 |
| LicenseFinder | Ruby | CLI工具，扫描Gemfile、package.json等，生成报告。 |
| FOSSLight | 多语言 | LGPL-2.1，由三星维护，功能全面。 |
| ORT (OSS Review Toolkit) | 多语言 | 由Here Technologies（诺基亚旗下）开源，企业级合规工具链。 |
总结建议
- 商业项目：只看MIT、BSD、Apache 2.0、MPL-2.0，优先选择这些许可证的库，如果需要LGPL，确保动态链接。
- 开源项目：如果你的项目是GPL，只能兼容MIT/BSD/Apache 2.0（GPL-3.0）和LGPL（需注意）。避免在GPL项目中使用Apache 2.0（如果是GPL-2.0）、MPL或任何非GPL兼容的库。
- AGPL/SSPL：除非你的项目也能接受同样的强传染网络协议，否则默认禁止使用。
- “分发”是关键：如果你只是内部使用（不向外部发布可执行文件），通常不受许可证限制，一旦分发，规则立刻生效。
- 法律建议：以上是社区共识和最佳实践。具体法律效力请咨询你的律师或公司法务，尤其是在涉及专利授权（Apache 2.0）或复杂派生定义（GPL）时。
