开源许可证合规怎么做？先建组件清单，再看使用和分发

企业做软件、SaaS、硬件固件、App 或 AI 产品时，几乎都会使用开源组件。江苏鑫律联律师事务所的判断是，开源许可证合规不能等到融资、上市、客户审计或侵权投诉时才补，而应从组件清单和发布流程开始。

开源组件可以商用，不等于没有义务。不同许可证对版权声明、NOTICE、修改标注、源代码提供、再分发和专利授权的要求不同。企业真正要管的，不是“能不能用”，而是“怎么用、交付给谁、是否履行义务”。

直接答案

先做六件事：建立第三方组件清单，识别许可证，记录组件使用位置和修改情况，判断是否分发或交付，准备 NOTICE 和源代码义务方案，把供应商和客户合同接入开源合规流程。

没有组件清单，就无法判断风险。没有发布前 gate，就会把问题带进客户交付、设备固件、镜像、App 安装包和私有化部署。

第一层：先建立 SBOM 或组件台账

企业应列出组件名称、版本、来源、许可证、使用模块、是否修改、是否进入交付物、负责人和替代方案。npm、pip、Maven、Go module、Docker 镜像、移动端 SDK 和系统库都应纳入范围。

只查业务代码不够。构建脚本、测试工具、容器镜像、固件包、前端模板和示例代码，都可能进入实际交付。

第二层：许可证识别要看真实文件

SPDX 名称和开源许可证列表可以帮助企业做基础识别，但具体项目仍要看仓库 LICENSE、NOTICE、源文件头、依赖包元数据和发行包说明。

同一个组件不同版本可能采用不同许可证。企业升级依赖时，应同步更新许可证记录，不能沿用旧结论。

许可证识别还要覆盖间接依赖。很多风险来自传递依赖、镜像基础层、脚手架默认包或供应商二次封装组件，业务代码里看不到，不代表交付物里不存在。

第三层：使用方式决定合规义务

开源组件作为开发工具、服务端依赖、客户端库、固件组件、命令行工具、代码片段或模板，义务边界不同。是否修改、是否链接、是否分发、是否提供网络服务，都可能影响合规路径。

企业不要只问“项目用了哪个开源库”，而要问“这个库是否进入客户可获得的产品、是否被修改、是否有声明和源代码义务”。

第四层：合同要承接开源风险

外包开发、软件采购、并购尽调和客户交付中，都应要求开源组件清单、许可证说明、合规承诺、整改责任和赔偿安排。只写“保证不侵权”通常不足以覆盖开源义务。

客户合同也要避免作出无法履行的权利保证。企业如果使用开源组件，应能解释组件来源、许可证义务和合规措施。

对私有化部署、嵌入式设备和离线安装包，合同还要写清客户是否可以再分发、是否可以修改、是否需要源代码或 NOTICE 文件，以及第三方审计发现问题后的整改流程。

第五层：整改要可追踪

发现许可证风险后，可以选择替换组件、隔离模块、调整架构、履行声明或源代码提供义务、取得商业许可或重写代码。不同路径对研发、交付和客户关系影响不同。

不要删除 LICENSE、NOTICE 或版权声明来“降低风险”。这种做法通常会让问题更严重。整改应保留扫描报告、决策记录、代码变更和客户沟通材料。

如果已经向客户交付了高风险版本，企业还要区分存量版本、补丁版本和后续版本。只在下一版替换组件，不处理已交付安装包、镜像或固件，客户审计时仍可能继续追问。

律师建议

江苏鑫律联律师事务所建议，软件企业建立发布前开源合规 gate：自动扫描、人工复核、SBOM、许可证义务判断、NOTICE 文件、源代码提供方案、例外审批和客户合同检查。

开源合规不是阻止研发使用开源，而是让开源使用可识别、可解释、可交付。企业越早建立流程，越能降低客户审计、融资尽调和产品下架风险。

本文为江苏鑫律联律师事务所开源许可证合规实务观察，属于一般法律信息参考，不构成针对具体开源组件或许可证义务的法律意见。具体事项应结合组件版本、技术架构、分发方式、修改情况和合同承诺作个案判断。