2. 开源许可证基础与分类
在企业研发中，使用开源组件的第一步不是“能不能用”，而是“用了之后要承担什么”。开源许可证本质上是一份附条件的版权授权合同：版权人授予你复制、修改、分发等权利，但你必须满足它设定的条件。不同许可证的条件强度差异极大，直接决定了你的代码能否闭源、能否与自有代码混合、是否需要公开修改。理解许可证，核心就是抓住三个维度：权利授予范围、义务触发条件、传染性强度。
一、宽松型许可证：MIT、BSD、Apache-2.0
宽松型（Permissive）许可证的共同特点是：允许你将代码用于闭源商业产品，不要求你公开自有代码，传染性极弱。它们之间的差异主要在专利和商标条款上。
MIT 是最简短、最宽松的许可证之一。它只要求你在分发时保留版权声明和许可声明，其余几乎不限制。你可以修改、闭源、再许可、商用，甚至不用说明修改了什么。MIT 没有明确的专利授权条款，这是它在企业法务视角下的一个潜在风险点——如果贡献者后来主张专利，MIT 并未提供明确的专利许可保护。
BSD 有多个版本，最常用的是 BSD-2-Clause 和 BSD-3-Clause。BSD-2 与 MIT 极为接近；BSD-3 多了一条“不得使用版权人名义为衍生品背书”的限制，用于保护机构声誉。BSD 同样没有明确的专利授权条款。
Apache-2.0 是宽松型中条款最完整的。它除了允许闭源商用外，还明确授予贡献者专利许可，并规定如果使用者对项目发起专利诉讼，其获得的专利许可将自动终止。此外，Apache-2.0 要求保留 NOTICE 文件、标注修改过的文件。这意味着：使用 Apache-2.0 组件时，你不仅要保留 LICENSE，还要保留 NOTICE，并在修改源码时做出修改声明。对于企业而言，Apache-2.0 通常比 MIT 更“安全”，因为它把专利风险写清楚了。
二、弱传染型许可证：LGPL、MPL
弱传染（Weak Copyleft）许可证的核心逻辑是：对库本身的修改必须开源，但调用该库的自有代码可以不开源。它试图在“保护开源”和“允许商业闭源”之间取得平衡。
LGPL 主要面向库。以 LGPL-2.1 为例，如果你动态链接 LGPL 库，自有程序可以闭源；但如果你修改了库本身，修改部分必须以 LGPL 开源。LGPL-3.0 进一步要求提供“安装信息”，以便用户能替换修改后的库版本，这对嵌入式设备影响较大。企业常见做法是：动态链接 LGPL 库，避免静态链接，以降低传染风险。
MPL-2.0 是文件级传染。它规定：你修改了哪些文件，这些文件必须以 MPL 开源；但你可以把 MPL 代码与自有闭源代码放在同一个项目中，只要不修改 MPL 文件本身。MPL 还包含专利授权和专利报复条款，比 LGPL 更清晰。对于希望“局部开源、整体闭源”的企业，MPL 是一个可接受的选项。
三、强传染型许可证：GPL、AGPL
强传染（Strong Copyleft）许可证要求：任何分发基于 GPL 代码的衍生作品，整体都必须以 GPL 开源。这里的“衍生作品”边界是法律和技术争议的焦点。
GPL-2.0 是最经典的强传染许可证。它要求分发时提供完整对应源码，并保留许可证和版权声明。GPL-2.0 没有专利授权条款，也没有针对网络服务的特殊规定。Linux 内核采用 GPL-2.0，因此任何基于 Linux 内核修改并分发的代码，都必须以 GPL-2.0 开源。
GPL-3.0 在 GPL-2.0 基础上增加了：明确的专利授权、反规避条款（禁止用 DRM 限制用户修改）、以及“安装信息”要求。GPL-3.0 与 GPL-2.0 不兼容，除非原项目声明“GPL-2.0 or later”。
AGPL-3.0 是 GPL-3.0 的加强版，专门堵住“SaaS 漏洞”。GPL 的触发条件是“分发”，而 AGPL 规定：只要用户通过网络与软件交互，即使不分发二进制，也必须提供源码。这意味着，如果你把 AGPL 代码部署为在线服务，用户通过浏览器或 API 使用它，你就必须向用户提供完整源码。对于企业而言，AGPL 是风险最高的许可证之一，通常应避免在闭源服务中引入。
四、传染性差异的工程判断
在实际研发中，判断传染性不能只看许可证名称，还要看链接方式、调用方式、修改程度和分发方式。以下是一个简化的判断路径：
- 如果组件是 MIT/BSD/Apache-2.0：可闭源商用，保留声明即可。
- 如果组件是 MPL：修改的文件需开源，未修改文件可闭源。
- 如果组件是 LGPL：动态链接可闭源，修改库本身需开源。
- 如果组件是 GPL：分发即触发整体开源，内部使用不分发通常不触发。
- 如果组件是 AGPL：网络交互即触发开源，SaaS 场景需特别警惕。
常见误区：“内部使用不分发就不触发 GPL”在多数情况下成立，但 AGPL 例外。另外，把 GPL 代码复制进自有代码、静态链接、或通过进程间通信传递复杂数据结构，都可能被认定为衍生作品。企业应建立组件准入清单，对 AGPL 和 GPL 组件设置审批门槛。
五、企业落地建议
第一，建立组件准入清单。将许可证分为“白名单”（MIT、BSD、Apache-2.0）、“灰名单”（MPL、LGPL，需审批）、“黑名单”（AGPL、GPL，原则上禁止或需法务特批）。第二，使用自动化工具（如 FOSSA、ScanCode、ORT）扫描依赖树，识别传递依赖中的许可证。第三，保留许可证文本和 NOTICE 文件，在分发产品中附带第三方声明。第四，对 LGPL 组件优先采用动态链接，避免静态链接；对 GPL 组件严格隔离，不复制代码进自有模块。第五，AGPL 组件在 SaaS 场景中必须评估是否触发源码提供义务，必要时替换为宽松许可的替代品。
实操提示：在 package.json 或 pom.xml 中引入依赖时，可用 license-checker 或 mvn license:aggregate-add-third-party 生成许可证清单。例如执行 npx license-checker --summary 可快速查看项目依赖的许可证分布，发现 AGPL/GPL 组件后立即标记并评估替换方案。
许可证合规不是法务部门的单点工作，而是研发流程的一部分。把许可证判断嵌入代码评审和 CI 流水线，才能在早期发现风险，避免产品发布前被迫返工。