3. 软件发布前的知识产权尽职调查

软件发布前的知识产权尽职调查，目标不是“证明没有问题”，而是在代码、文档、依赖和合同四个层面，把权属链条、许可义务和潜在冲突查清楚，并形成可追溯的记录。它通常发生在版本冻结之后、正式对外发布之前，输出物是一份可复核的调查报告和风险台账，而不是一句“已确认无风险”。

一、调查清单：先确定查什么、查到什么粒度

清单的作用是防止遗漏，而不是替代判断。一份可执行的调查清单至少覆盖四类对象：

• 代码与仓库：主仓库、子模块、构建脚本、CI 配置、生成代码、示例代码、测试数据。
• 第三方组件：直接依赖、传递依赖、容器基础镜像、前端打包产物中的库、二进制 SDK。
• 文档与素材：用户手册、界面图标、字体、音视频、截图、演示数据、商标与 Logo。
• 合同与权属文件：劳动合同中的知识产权条款、外包开发合同、委托开发协议、贡献者许可协议（CLA）、采购合同中的授权范围。

清单要落到“可核查的粒度”。例如第三方组件不能只写“使用了开源库”，而应记录组件名、版本、来源仓库、引入方式（直接/传递）、许可证标识、是否修改、是否随产品分发。下面是一份可直接使用的调查清单示例，字段按实际发布场景裁剪：

二、权属核查：把“谁拥有”落到证据上

权属核查的核心是回答三个问题：代码由谁写、在什么关系下写、权利如何转移给发布主体。对内部员工，重点看劳动合同或专门的知识产权归属协议是否约定职务开发成果归公司所有；对外部贡献者，重点看是否签署 CLA 或贡献者协议，明确贡献内容的许可与再许可权利；对外包与委托开发，重点看合同是否写明“成果归委托方所有”以及“开发方保证不侵犯第三方权利”。

实际操作中，权属核查常借助版本历史与文件头信息交叉验证。例如，对每个源文件检查版权声明与许可证头是否一致；对提交记录按作者聚合，识别是否存在未签署 CLA 的外部提交；对引入的第三方代码片段，确认是否有来源标注和原始许可证。若发现某模块由已离职员工在无明确约定的情况下开发，应将其列为高风险项，补充取得权利转让或替换实现。

三、第三方组件审查：从“有没有用”到“怎么用、怎么发”

第三方组件审查不能停留在“扫出许可证名称”。同一许可证在不同使用方式下义务不同：动态链接、静态链接、修改后分发、SaaS 提供、仅内部使用，触发的义务差别很大。审查时应先建立软件物料清单（SBOM），再按组件逐项判断。

一个可复用的判断路径是：先确认组件是否随产品分发；若分发，再看许可证是否要求提供源代码、保留版权声明、或以相同许可证发布衍生作品；若不分发（如仅服务端内部使用），则重点转向专利授权、出口管制和商标条款。对于 GPL、AGPL、LGPL、MPL、Apache-2.0、MIT、BSD 等常见许可证，应分别记录其关键义务，而不是统一标注为“开源可用”。

下面这张图展示第三方组件从引入到发布判断的信号链关系，帮助把“组件—许可证—使用方式—义务—结论”串起来：

四、风险识别与记录方法：把判断变成可追踪的台账

风险识别不是把所有不确定项都标红，而是按“可能性 × 影响”分级，并给出处置动作和责任人。常见风险类型包括：许可证冲突（如将 GPL 代码静态链接进闭源产品）、权属不清（外包成果未约定归属）、素材侵权（字体、图标、图片未获商用授权）、商标冲突（产品名与在先商标近似）、专利风险（组件含专利条款或已知专利纠纷）。

记录方法建议采用风险台账，每条风险至少包含：风险编号、关联组件或模块、风险描述、触发条件、影响范围、等级、处置措施、责任人、截止时间、状态。台账要与 SBOM、许可证清单、合同档案建立引用关系，确保任何一条结论都能回溯到证据。对于发布前无法彻底解决的风险，应明确是否接受、是否降级发布、是否需要法务出具意见，而不是留空。

最后，把调查清单、权属证据、第三方组件清单和风险台账合并为一份发布前知识产权尽职调查报告，随版本归档。这样在后续版本迭代、客户审计或争议发生时，团队能够快速定位当时的判断依据，而不是重新排查一遍。