2. 第三方组件生态与知识产权形态

在供应链知识产权治理中，第一步不是查许可证，而是先看清“组件从哪里来、以什么形态进入产品、携带哪些权利”。同一个功能模块，可能以源码、二进制、容器镜像三种形态进入构建流程，其权利传递路径和治理动作完全不同。本节围绕开源组件、商业组件、内部复用组件、二进制依赖与容器镜像五类对象，梳理版权、专利、商标、商业秘密与合同权利在供应链中的传递方式。

一、五类组件对象与权利载体

开源组件通常以源码包形式分发，权利载体是许可证文本。版权是核心权利，许可证通过版权授权施加条件，例如署名、披露源码、同许可证分发。专利授权在部分许可证中显式给出（如 Apache-2.0 含专利授权与专利报复条款），部分许可证则沉默。商标权一般不被许可证授予，因此不得使用项目名称暗示官方背书。

商业组件以二进制或源码加商业许可方式交付，权利载体是采购合同与 EULA。版权仍归供应商，使用权通过合同授予；专利通常以“供应商保证不侵权”或“赔偿条款”形式出现；商业秘密通过保密条款保护；商标使用范围由合同限定。商业组件的权利不随代码“传递”，而随合同义务传递。

内部复用组件来自企业自有代码库，权利归企业自身，但风险在于“内部组件可能已混入外部开源代码”。若未做来源登记，内部组件会成为权利盲区，其对外分发时可能触发上游许可证义务。

二进制依赖是只有编译产物、没有源码的依赖，例如 .jar、.dll、.so、.node。版权与专利信息无法从源码读取，只能依赖 SBOM、NOTICE 文件或供应商声明。二进制依赖是权利传递链中最容易断裂的一环。

容器镜像是分层叠加的分发单元，基础镜像、系统包、语言运行时、应用层各自携带不同许可证。镜像把“分发”行为放大：拉取、推送、复制镜像都可能构成再分发，从而触发上游义务。

二、权利在供应链中的传递方式

权利传递不是“代码复制”这么简单，而是三种机制并行：许可证随源码传递，只要分发源码或二进制，许可证义务就附着在分发行为上；合同义务随采购传递，商业组件的限制通过合同约束采购方，而非通过代码本身；镜像分层使多许可证叠加，一个镜像可能同时包含 GPL 系统包、Apache-2.0 运行时、商业中间件和自有应用，分发镜像等于同时触发所有层的义务。

以某企业构建一个 Java 服务为例：应用层使用自有代码（内部复用），依赖 log4j-core-2.17.1.jar（Apache-2.0，二进制依赖），基础镜像为 eclipse-temurin:17-jre（含 GPLv2+Classpath Exception 的 OpenJDK），并采购了某商业 APM 探针（商业组件，合同授权）。当该服务以容器镜像交付给客户时，分发行为同时触发：Apache-2.0 的 NOTICE 保留义务、OpenJDK 的许可证声明义务、商业 APM 合同中的“不得反向工程”与“仅限指定环境使用”条款。若企业只检查了应用层源码许可证，就会遗漏镜像层与商业合同层的义务。

三、治理动作：从形态到权利清单

针对五类形态，治理动作应差异化设计。开源组件：建立许可证白名单与黑名单，对 Copyleft 类许可证做分发场景判断；商业组件：在采购合同中明确专利赔偿、审计权、使用范围与终止后的继续使用权；内部复用组件：强制来源登记，任何进入内部库的代码必须记录原始出处与许可证；二进制依赖：要求 SBOM 交付，无法提供时降级为“高风险依赖”并限制分发；容器镜像：对基础镜像做许可证扫描，区分“构建时依赖”与“分发时依赖”，避免把仅用于构建的工具许可证误判为分发义务。

下表给出一个可直接使用的权利形态登记表示例，字段按“组件—形态—权利类型—传递方式—治理动作”组织，可用于组件入库评审。