2. 开源许可证基础与分类
在企业开源治理中，许可证不是法律部门的专属议题，而是研发、发布、采购和对外合作都必须理解的基础约束。一个项目能不能把第三方组件合入自研产品、能不能以闭源方式分发、能不能把修改后的代码放到网络服务中而不公开，往往在选型阶段就已经被许可证决定了。本节围绕 MIT、Apache-2.0、BSD、GPL、LGPL、AGPL 六类常见许可证，讲清它们的核心条款、兼容性判断方法以及企业适用场景。
一、先建立两个判断维度：宽松与传染
理解许可证，最有效的方式不是背条款，而是抓住两个维度：是否要求衍生作品继续开源，以及开源义务在什么条件下被触发。前者区分宽松型与 Copyleft 型，后者决定义务是“分发时触发”还是“网络交互时触发”。
宽松型许可证（MIT、BSD、Apache-2.0）允许你把代码用于闭源产品，只要保留版权声明和许可证文本。Copyleft 型许可证（GPL、LGPL、AGPL）则要求衍生作品在特定条件下以相同许可证开放源代码。LGPL 是 GPL 的弱化版本，主要针对库的链接场景；AGPL 是 GPL 的强化版本，把触发条件从“分发”扩展到了“通过网络提供服务”。
二、宽松型许可证：MIT、BSD、Apache-2.0
MIT 是最简短、限制最少的许可证之一。它只要求保留版权声明和许可声明，不要求公开修改后的源代码，也不提供专利授权。企业把 MIT 代码合入闭源产品，通常只需在产品的开源声明文件（如 NOTICE 或第三方许可证清单）中保留原始版权与许可证文本即可。
BSD 常见 2-Clause 和 3-Clause 两个版本。2-Clause 与 MIT 接近；3-Clause 多了一条“不得使用原作者名义为衍生品背书”的限制。企业使用时要注意区分版本，因为部分项目只声明“BSD”，实际可能是 4-Clause，后者带有广告条款，兼容性更差。
Apache-2.0 比 MIT/BSD 更完整。它明确授予贡献者专利许可，并要求衍生作品保留 NOTICE 文件、标注修改内容。这一专利授权条款对企业非常重要：它降低了使用该组件时遭遇专利诉讼的风险。但 Apache-2.0 与 GPLv2 不兼容，因为 GPLv2 没有专利授权条款，而 Apache-2.0 附加了额外限制。若企业产品中同时存在 Apache-2.0 组件和 GPLv2 组件，需要谨慎评估，通常不能简单地把两者链接进同一 GPLv2 作品。
三、Copyleft 型许可证：GPL、LGPL、AGPL
GPL 的核心是“分发触发”。只要企业把包含 GPL 代码的软件分发给外部用户，就必须以 GPL 兼容许可证提供完整对应源代码，并允许接收者自由修改和再分发。GPLv2 与 GPLv3 还有差异：GPLv3 增加了反 Tivoization 条款和更明确的专利授权，且与 Apache-2.0 兼容。企业若把 GPL 代码用于纯内部使用、不对外分发，通常不触发开源义务；但一旦随产品交付给客户，义务即被触发。
LGPL 主要面向库。它允许闭源程序通过动态链接方式使用 LGPL 库，只要不修改库本身，且用户能够替换该库版本。若企业修改了 LGPL 库，则修改部分仍需以 LGPL 开放。LGPL 的合规关键在于“链接方式”和“可替换性”：静态链接通常要求提供目标文件或可重链接材料，动态链接则相对宽松。
AGPL 是 GPL 的网络版强化。它把触发条件从“分发”扩展到“通过网络与用户交互”。也就是说，企业即使不分发软件，只是把 AGPL 代码部署为在线服务，也可能需要向用户提供源代码。对于 SaaS 企业，AGPL 是最需要警惕的许可证之一。若企业希望把 AGPL 组件用于对外服务，通常需要评估是否愿意开放整个服务端代码，或选择商业授权版本。
四、兼容性判断：能不能放在一起
许可证兼容性判断的核心是：把 A 代码和 B 代码合并成一个作品后，能否同时满足 A 和 B 的义务。若不能，则两者不兼容。常见结论如下：
| 组合 | 是否兼容 | 说明 |
|---|---|---|
| MIT / BSD → GPL | 兼容 | 宽松代码可被 GPL 作品吸收，整体按 GPL 分发 |
| Apache-2.0 → GPLv3 | 兼容 | GPLv3 含专利条款，可接受 Apache-2.0 附加要求 |
| Apache-2.0 → GPLv2 | 不兼容 | GPLv2 无专利授权，无法满足 Apache-2.0 的专利条款 |
| GPLv2 → GPLv3 | 单向兼容 | GPLv2-only 代码不能升级到 GPLv3；GPLv2-or-later 可以 |
| GPL → 闭源产品 | 不兼容 | 分发即要求开源，闭源分发无法满足 |
| LGPL → 闭源产品 | 有条件兼容 | 动态链接、不修改库、允许替换时可闭源 |
需要特别注意的是，兼容性判断不能只看许可证名称，还要看项目的具体声明。例如某项目写“GPLv2 only”还是“GPLv2 or later”，结果完全不同；某项目写“BSD”但实际是 4-Clause，也会影响兼容性。企业应建立组件级许可证清单，记录每个组件的许可证版本和附加条款。
五、企业适用场景与选型建议
对于希望快速集成、闭源分发的商业产品，MIT、BSD、Apache-2.0 是首选。其中 Apache-2.0 因专利授权明确，更适合对专利风险敏感的企业。对于自研基础库并希望被广泛采用的项目，MIT 或 Apache-2.0 能降低使用者的合规负担，有利于生态扩散。
对于希望确保衍生作品持续开源的社区项目，GPL 是常见选择。企业若使用 GPL 组件，应将其隔离在独立进程或独立分发单元中，避免与闭源核心代码形成“单一作品”。LGPL 适合库作者希望被商业软件使用、又要求修改回馈的场景。AGPL 适合那些希望防止云厂商“只使用不回馈”的项目，但企业使用 AGPL 组件时必须评估自身服务是否需要开源。
最后，许可证管理不是一次性动作。企业应把许可证识别纳入组件引入流程：记录组件名称、版本、许可证、来源、是否修改、分发方式，并定期扫描依赖树。只有把许可证信息变成可查询、可审计的数据，才能在发布前快速判断风险，而不是等到客户或社区提出质疑时才被动应对。