开源许可证兼容性检查器 - 混合项目合规指南

开源许可证兼容性指的是两个或多个不同许可证的代码能否合法地组合在同一个项目中。如果许可证A和许可证B兼容，意味着你可以将使用这两个许可证的代码合并使用，通常最终项目需要以较严格的许可证发布。兼容性问题主要源于不同许可证对代码使用、修改和分发的条款可能存在冲突。例如，GPL要求衍生作品也以GPL发布（Copyleft），而某些许可证（如Apache 2.0的专利条款）可能与GPL 2.0的要求产生冲突。

是的，MIT和GPL是兼容的，但需要注意方向性。如果你在GPL项目中使用MIT许可的代码，完全没问题——GPL项目可以包含MIT代码。但如果你在MIT项目中使用GPL许可的代码，整个项目就必须以GPL许可证发布（因为GPL的Copyleft条款要求衍生作品也使用GPL）。这意味着你的MIT项目将"升级"为GPL项目。如果希望保持MIT许可证，就不能引入GPL代码。

这是开源许可证领域最著名的兼容性问题之一。Apache License 2.0包含了明确的专利授权条款和专利终止条款，这些条款在保护用户免受专利诉讼方面比GPL 2.0更为详细和有力。GPL 2.0的专利条款较为简单，两者在专利处理机制上存在冲突。好消息是，GPL 3.0修订了专利相关条款，与Apache 2.0实现了兼容。因此，如果你的项目使用GPL 3.0（而非GPL 2.0），就可以安全地引入Apache 2.0许可的代码。

取决于许可证类型。宽松型许可证（MIT、BSD、ISC、Apache 2.0等）允许在商业闭源项目中使用，只需保留版权声明即可。Copyleft许可证（GPL、AGPL等）要求衍生作品也以相同许可证开源，因此在闭源商业项目中使用GPL库通常不可行（除非你愿意开源整个项目）。LGPL相对宽松，允许闭源项目动态链接LGPL库，但修改LGPL库本身需要开源。MPL 2.0仅要求修改的MPL文件开源，项目其余部分可以闭源。对于商业闭源项目，推荐使用MIT、BSD、Apache 2.0或LGPL（仅动态链接）许可的库。

LGPL（Lesser General Public License，较宽松通用公共许可证）是GPL的一个宽松变体。主要区别在于：GPL要求任何使用GPL代码的衍生作品都必须以GPL发布（强Copyleft）；LGPL仅要求对LGPL库本身的修改需要开源，但允许非GPL/LGPL的程序通过链接（特别是动态链接）使用LGPL库而无需开源自身代码。LGPL常被用于系统库和框架（如GTK、Qt的某些版本），以便商业软件也能使用这些库。LGPL 2.1和LGPL 3.0的主要差异在于后者增加了对数字版权管理(DRM)的限制和更详细的专利条款。

AGPL（Affero General Public License）3.0是GPL 3.0的加强版，特别针对网络服务场景。GPL的Copyleft条款主要在"分发"代码时触发，但AGPL额外规定：即使只是通过网络提供服务（SaaS），也需要公开源代码。这意味着如果你的Web应用使用了AGPL代码，即使用户不直接下载软件，你也需要提供源代码。这一条款使得AGPL成为限制最严格的开源许可证之一。MongoDB、Grafana等知名项目曾使用AGPL（部分后来转向SSPL）。对于企业来说，使用AGPL代码需要特别谨慎评估合规风险。

选择许可证需考虑以下因素：
1. 希望代码被广泛使用：选择MIT或BSD，门槛最低
2. 希望改进必须回馈社区：选择GPL系列
3. 商业友好但保留一定权利：Apache 2.0（含专利保护）或MPL 2.0（文件级Copyleft）
4. 开发库/框架供他人使用：LGPL或MIT
5. SaaS/云服务产品：如果希望防止竞争对手利用你的代码提供云服务，考虑AGPL
6. 完全放弃权利：CC0或Unlicense（公共领域）
建议在GitHub仓库中明确放置LICENSE文件，并在package.json等配置中声明许可证类型。

确保混合项目合规的最佳实践：
1. 清点所有依赖：使用工具（如npm的license-checker、FOSSA、Snyk）扫描项目依赖及其许可证
2. 检查兼容性：使用本工具或其他兼容性矩阵检查许可证之间是否存在冲突
3. 保留版权声明：所有开源库的原始版权声明和许可证文本都需要保留
4. 明确最终许可证：在项目根目录放置LICENSE文件，说明整体许可证（通常是最严格的许可证）
5. 文档记录：在NOTICE或THIRD-PARTY文件中列出所有第三方依赖及其许可证
6. 法律咨询：对于商业产品，建议咨询专业法律顾问进行最终审核

Copyleft（版权左派）是一种利用版权法来确保作品及其衍生作品保持自由开放的法律机制。强Copyleft（如GPL、AGPL）要求任何包含或使用该代码的衍生作品都必须以相同的许可证发布，即"传染性"较强。弱Copyleft（如LGPL、MPL）仅要求对原始代码的修改部分开源，允许项目的其他部分使用不同许可证，降低了"传染"范围。例如，MPL 2.0仅要求修改过的MPL许可文件保持MPL许可，项目其他文件可以是私有的。了解这个区别对于评估许可证兼容性和合规风险至关重要。

CDDL（Common Development and Distribution License）1.0由Sun Microsystems（现Oracle）创建，用于OpenSolaris等项目。CDDL与GPL不兼容的主要原因是：CDDL要求在分发包含CDDL代码的软件时，CDDL部分必须保持CDDL许可且源码必须可用，这与GPL的"整体必须以GPL发布"的要求产生冲突。CDDL使用"文件级Copyleft"（类似于MPL），而非GPL的"项目级Copyleft"。两种Copyleft机制无法调和，因此CDDL和GPL代码不能合法地组合在同一项目中。这一不兼容性是历史上OpenSolaris代码未能进入Linux内核的主要原因之一。