4. 许可证基础与义务解析

在第三方组件治理中，许可证不是法律部门的专属文件，而是研发、测试、发布、运维都必须能快速判读的工程约束。一个组件能不能用、怎么用、发布时要附带什么、修改后要不要开源，取决于许可证条款。本节围绕 MIT、Apache-2.0、BSD、GPL、LGPL、AGPL、MPL、EPL 八类常见许可证，建立“条款—义务—传染边界—兼容性”的判读框架。

一、先分清四类核心条款

所有开源许可证的差异，最终落在四个条款维度上：

• 署名与版权声明保留：MIT、BSD、Apache-2.0 都要求保留版权声明和许可证文本。这是最低义务，几乎所有许可证都有。
• 专利授权：Apache-2.0 明确授予贡献者专利许可，并含专利报复条款；MIT、BSD 不含明示专利授权，这是企业选型时的重要差异。
• Copyleft（传染性）：GPL、AGPL 要求衍生作品整体以相同许可证开源；LGPL 仅要求对库本身的修改开源，允许闭源程序动态链接；MPL、EPL 是文件级 copyleft，只传染被修改的文件。
• 网络分发触发：AGPL 在 GPL 基础上增加“通过网络交互即视为分发”，SaaS 场景下也会触发开源义务。

把许可证按“传染强度”排序，可以形成一条从宽松到强 copyleft 的谱系：MIT/BSD → Apache-2.0 → EPL/MPL → LGPL → GPL → AGPL。这条谱系是快速判读的起点。

二、传染性边界：链接方式决定义务范围

GPL 与 LGPL 的差异，核心在“链接方式”。假设闭源程序 A 使用库 L：

• 静态链接：L 的代码被复制进 A 的可执行文件，形成单一作品。若 L 是 GPL，A 整体必须 GPL 开源；若 L 是 LGPL，静态链接通常也要求提供目标文件以便重新链接，实践中风险较高。
• 动态链接：A 与 L 在运行时通过动态库调用交互。LGPL 明确允许闭源程序动态链接，只要不修改 L 本身；GPL 则仍可能被认定为衍生作品，需谨慎评估。
• 进程隔离：A 与 GPL 程序通过独立进程、命令行或网络协议通信，通常不构成衍生作品，这是常见的隔离手段，但需避免共享复杂数据结构导致“紧密结合”。

MPL 与 EPL 的边界更细：它们只要求“被修改的文件”以相同许可证开源，新增文件可以用其他许可证。这意味着企业可以修改 MPL 文件后开源该文件，同时保留新增模块闭源。

三、兼容性规则：许可证能否合并

兼容性指两个许可证的代码能否合并成一个作品并合法分发。判读时抓住两条规则：

1. 宽松许可证可并入强 copyleft：MIT、BSD、Apache-2.0 代码可以放入 GPL 项目，整体按 GPL 分发。反向则不成立。
2. 强 copyleft 之间常不兼容：GPL-2.0 与 Apache-2.0 存在专利条款冲突，GPL-2.0 与 GPL-3.0 也不自动兼容。GPL-3.0 与 Apache-2.0 兼容，因为 GPL-3.0 的专利条款与 Apache-2.0 对齐。

实际判读时，先看目标项目的许可证，再看引入组件的许可证，最后查兼容性矩阵。若不确定，优先选择宽松许可证组件，或通过进程隔离降低耦合。

四、合规义务落地：从判读到交付物

判读完成后，必须把义务转化为可交付物。以下是一份可直接使用的许可证合规检查表，按组件逐个填写：

对于 GPL/LGPL/AGPL 组件，检查表需增加“是否修改”“链接方式”“是否网络服务”“源码提供方式”四个字段。例如，某服务使用 AGPL 组件提供网络 API，即使不分发二进制，也需向用户提供完整对应源码，包括修改后的版本。

五、快速判读四步法

面对一个陌生组件，按以下四步可在几分钟内形成初步结论：

1. 找许可证：查看 LICENSE、COPYING、包元数据。若缺失，视为“保留所有权利”，不可直接使用。
2. 定谱系：对照传染强度谱系，判断属于宽松、文件级 copyleft、库级 copyleft 还是强 copyleft。
3. 看用法：是否修改、静态还是动态链接、是否通过网络提供服务。用法决定义务是否被触发。
4. 查兼容：与目标项目许可证比对，确认能否合并分发；不确定时走法务评审或替换组件。

把四步法固化为研发流程中的准入检查，配合 SBOM 工具自动识别许可证，可以显著降低供应链知识产权风险。许可证判读不是一次性的法律审查，而是每次引入、修改、发布组件时都要执行的工程动作。