3. 软件供应链知识产权风险地图

软件供应链的知识产权风险并不只发生在“把开源库写进代码”这一刻。一个组件从被引入、被修改、被链接、被打包进容器，到最终以镜像或 SaaS 服务对外交付，每一个环节都可能改变它的法律状态与合规义务。本节的目标是建立一张“风险地图”：先按环节识别典型风险，再用统一的分类与优先级方法，判断哪些风险必须在发布前解决。

一、六个环节的典型知识产权风险

引入环节是风险的起点。典型问题包括：组件许可证与产品商业模式冲突（如 AGPL 用于闭源商业产品）、许可证标识与实际代码不一致（元数据写 MIT，实际文件头是 GPL）、来源不可信（非官方仓库、个人 fork、来源不明的二进制包）。这一环节的核心判断依据是“来源可信度 + 许可证类型 + 使用方式”。

分发环节的风险来自“把软件交给别人”。若产品以二进制形式交付，GPL/LGPL 类组件会触发源码提供义务；若以静态库形式分发，LGPL 的“允许替换库”要求可能被破坏。典型风险是：只提供了自己的源码，却遗漏了第三方组件的许可证文本与版权声明。

修改环节的风险最容易被低估。对 Apache-2.0 代码打补丁需保留 NOTICE 文件；对 GPL 代码修改后分发，修改部分同样受 GPL 约束；把开源代码片段复制进自研文件，可能使整个文件被“传染”。判断关键是“是否形成衍生作品”以及“修改是否对外分发”。

链接环节决定传染范围。动态链接通常被视为独立进程边界，静态链接则更可能被认定为衍生作品。示例判断：某产品静态链接了 GPL-3.0 库，即使只调用一个函数，也通常需要按 GPL-3.0 发布整个可执行文件；若改为动态链接并单独分发该库，义务范围会显著缩小。

容器化环节的风险在于“镜像即分发”。基础镜像中的 Debian 包、构建阶段拉取的依赖、多阶段构建残留的源码，都会随镜像一起分发。常见问题是：镜像里包含 GPL 工具链，但产品只提供自己的源码，未附第三方许可证清单。

SaaS 交付环节的风险来自“网络交互是否触发分发”。AGPL-3.0 明确规定：用户通过网络与修改后的程序交互，即视为分发，必须提供对应源码。若 SaaS 后端使用了 AGPL 组件并做了修改，却未开放源码，就构成高风险违规。

二、从来源到发布的风险分类方法

把上述风险归为四类，便于统一管理：许可证冲突类（组件许可证与产品分发模式不兼容）、义务履行类（应提供源码、声明、NOTICE 却未提供）、来源可信类（组件来源不明、版本被篡改、元数据与代码不一致）、衍生边界类（修改、链接、复制导致传染范围扩大）。分类之后，用“许可证强度 × 使用方式 × 交付模式”三个维度打分，即可得到优先级。

一个可操作的评分示例（示例参数，非实测）：许可证强度：MIT/Apache-2.0 记 1 分，LGPL 记 2 分，GPL 记 3 分，AGPL 记 4 分；使用方式：动态链接记 1 分，静态链接记 2 分，修改后分发记 3 分，网络交互记 4 分；交付模式：内部使用记 1 分，二进制分发记 2 分，容器镜像分发记 3 分，SaaS 对外记 4 分。三项相乘，得分 ≥ 24 为高优先级，12～23 为中优先级，< 12 为低优先级。例如“AGPL 组件 + 修改后 SaaS 交付”得分为 4×4×4=64，属于必须在发布前解决的高风险项。

三、落地：把风险地图变成发布门禁

风险地图要真正起作用，需要嵌入研发流程。建议在 CI 流水线中加入三步检查：第一步，用 SBOM 工具生成组件清单，记录每个组件的名称、版本、许可证 SPDX 标识与来源仓库；第二步，按上述评分规则自动计算优先级，对高优先级组件阻断构建并通知法务；第三步，在发布产物中自动附带第三方许可证清单与 NOTICE 文件，确保分发环节的义务被覆盖。

最后，风险地图不是一次性文档，而应随组件版本、许可证变更和交付模式变化持续更新。每次引入新组件、修改链接方式或新增 SaaS 交付通道时，都应重新走一遍“识别—判断—定级—处置”的路径，确保从组件来源到产品发布的每一环都有明确的责任人与处置结论。