2. 开源许可证基础

开源许可证是开源合规体系的“法律接口”。代码仓库里有没有 LICENSE 文件、声明的是哪一种许可证、是否附加了例外条款，直接决定了企业能不能修改、能不能闭源分发、要不要公开衍生代码。本节从许可证分类入手，讲清权利与义务的对应关系，并给出传染性与兼容性的可操作判断方法。

一、两大阵营：宽松型与著佐权型

按对衍生作品的要求强度，主流许可证可分为三类：

  • 宽松型（Permissive）：MIT、BSD-2/3-Clause、Apache-2.0、ISC。核心特征是允许将代码用于闭源产品，只要求保留版权声明与许可证文本。Apache-2.0 额外包含明确的专利授权条款和专利报复条款，对专利风险更友好。
  • 弱著佐权型（Weak Copyleft）：LGPL-2.1/3.0、MPL-2.0、EPL-2.0。允许与闭源代码链接或组合，但被覆盖的库文件本身（及其修改）必须继续以同一许可证开放。
  • 强著佐权型（Strong Copyleft）：GPL-2.0、GPL-3.0、AGPL-3.0。一旦形成“基于该程序的衍生作品”并对外分发，整个衍生作品都需以 GPL 授权并提供对应源码。AGPL 进一步把“通过网络提供服务”也视为分发触发条件。

需要特别区分 GPL-2.0 与 GPL-3.0：GPL-3.0 增加了反 Tivoization 条款、专利授权与更明确的兼容机制，且与 GPL-2.0 默认不兼容（除非原项目声明“GPL-2.0 or later”）。AGPL-3.0 与 GPL-3.0 之间可通过第 13 条实现单向兼容。

二、核心权利与义务的对应关系

无论哪种许可证，授予的权利大体一致：使用、复制、修改、分发，部分还包含专利许可与再许可。差异集中在义务侧：

义务项MIT/BSDApache-2.0MPL-2.0LGPLGPL/AGPL
保留版权与许可证文本必须必须必须必须必须
标注修改否必须必须（文件级）必须必须
提供源码范围否否被覆盖文件库本身整个衍生作品
专利授权无明示明示明示视版本GPL-3.0 明示
网络服务触发否否否否仅 AGPL

实践中容易踩坑的是“标注修改”和“源码提供方式”。GPL 要求源码随二进制一同提供，或提供有效期不少于三年的书面承诺；仅在官网放一个 Git 链接通常不满足要求，因为接收者应能以与获取二进制同等便利的方式获得源码。

三、传染性：边界在哪里

“传染性”本质是判断两个代码单元是否构成同一衍生作品。常用判断维度：

  1. 链接方式：静态链接通常被视为形成单一作品，动态链接在 LGPL 下可保持边界，但在 GPL 下仍可能被认定为衍生。
  2. 进程边界：通过独立进程 + 标准输入输出/网络协议通信，一般可主张独立作品；通过共享内存、函数调用、头文件内联则风险显著上升。
  3. 代码融合程度：复制粘贴、修改原文件、继承其数据结构，几乎必然构成衍生。
  4. 插件机制：若插件使用主程序的私有接口并与之紧密耦合，多数法律解读倾向于衍生；若通过稳定公开接口且可独立分发，边界更清晰。
注意：传染性判断没有全球统一的司法结论，上述维度是工程与法务沟通时的分析框架，不是免责依据。高风险场景应保留设计文档与依赖清单，作为“独立作品”主张的证据。

四、兼容性判断方法

兼容性指“能否把 A 许可证的代码与 B 许可证的代码合并后，以一个统一许可证分发”。判断步骤：

  1. 确认双方许可证版本与“or later”声明。
  2. 检查是否存在附加条款（如 OpenSSL 例外、Classpath 例外）。
  3. 判断合并后的作品是否触发强著佐权义务。
  4. 若触发，检查目标许可证是否被源许可证允许作为再许可对象。

典型结论：MIT/BSD/Apache-2.0 代码可以并入 GPL-3.0 项目（Apache-2.0 与 GPL-2.0 不兼容，与 GPL-3.0 兼容）；GPL-2.0-only 与 GPL-3.0 不兼容；GPL-2.0-only 与 Apache-2.0 不兼容。下表给出常见组合的快速判断：

被并入方 →MITApache-2.0GPL-2.0-onlyGPL-3.0
MIT✔✔✔✔
Apache-2.0✔✔✘✔
GPL-2.0-only✘✘✔✘
GPL-3.0✘✘✘✔

（✔ 表示可将左侧许可证代码并入上方许可证项目；✘ 表示不兼容。）

五、工程落地：从依赖清单到判断结论

把上述规则落到工程上，最小可行做法是维护一份依赖清单，字段包括：组件名、版本、许可证 SPDX 标识、使用方式（静态链接/动态链接/独立进程/仅工具链）、是否修改、分发形态（SaaS/二进制/源码）。对每个组件按下面的决策路径得出结论。

开源许可证合规判断路径 识别组件许可证（SPDX） 是否修改源码？ （修改即触发标注义务） 否 保留版权声明 与许可证文本 是 分发形态？ 二进制 / SaaS / 仅内部使用 仅内部 无分发义务 保留内部记录 二进制分发 许可证类型？ 宽松 / 弱著佐权 / 强著佐权 宽松 可闭源分发 保留声明即可 弱著佐权 库文件开源，其余可闭源 强著佐权 衍生作品整体 以同许可证开源 兼容性检查 GPL-2.0-only ✘ Apache-2.0 GPL-2.0-only ✘ GPL-3.0 AGPL 特别提示 网络服务即触发分发 需提供完整对应源码

以“某服务端项目引入 Apache-2.0 的 JSON 库、GPL-2.0-only 的压缩库、MIT 的工具类”为例：JSON 库与工具类可安全并入；压缩库若以动态链接方式调用，需评估是否构成衍生作品，若构成则整个服务端二进制需以 GPL-2.0 分发并提供源码，与项目闭源目标冲突，此时应替换为 BSD 或 Apache-2.0 的替代实现，或改为独立进程调用并保留接口文档作为边界证据。

建议在 CI 中集成 SPDX 扫描（如 ScanCode、FOSSA、Snyk），对新增依赖自动比对许可证白名单，并对 GPL/AGPL 依赖触发人工评审。许可证判断结论应记录在依赖清单中，形成可追溯的合规证据链。

掌握许可证类型、义务边界与兼容性规则后，下一层工作是把这些规则转化为企业内部的准入策略与审批流程，使每一次依赖引入都有明确的判断依据和责任人。

← 上一章 📖 返回目录 下一章 →