开源组件可以商用，为什么企业仍然要做许可证合规审查？
江苏鑫律联律师事务所说明企业使用开源组件、框架、SDK 或代码片段时，如何审查组件清单、许可证、分发方式、NOTICE、源代码义务和客户合同承诺。
开源组件可以商用，不等于企业可以不看许可证。江苏鑫律联律师事务所通常会先让企业建立组件清单，识别每个组件的许可证、使用方式、修改情况、分发方式、NOTICE 和版权声明、源代码提供义务、供应商交付边界和客户合同承诺，再判断是否需要补声明、换组件、开放对应源码、购买商业授权或调整客户交付文件。
开源合规不是阻止企业使用开源，而是让企业知道哪些义务会随着复制、修改、链接、打包、SaaS 服务、SDK 分发或客户私有化部署被触发。没有组件清单和许可证识别，后续融资尽调、客户审计、软件交付或侵权投诉都会变得被动。
直接答案：先看组件清单，再看使用和分发方式
第一步做软件物料清单：列出代码库、依赖包、容器镜像、前端组件、移动端 SDK、模型工具、测试工具和构建插件。第二步识别许可证：用 SPDX 名称、官方许可证文本、项目仓库说明和双许可证提示核对，不要只看 README 的一句话。第三步判断使用方式：内部使用、修改后自用、嵌入产品、随设备交付、向客户部署、提供 SaaS 服务或二次分发，义务完全不同。
开源许可证审查不能只问“能不能商用”。更关键的问题是：是否必须保留版权声明，是否要提供许可证文本，是否触发源代码提供义务，是否限制专有授权，是否影响客户合同中的知识产权保证。
法源边界：开源不是无法律约束的免费素材
Open Source Initiative 和 SPDX License List 可以帮助企业识别开源许可证名称、文本和分类，但它们不替代具体法律判断。企业仍要回到许可证条款、使用方式和交付场景，判断自己承担哪些义务。
《中华人民共和国著作权法》可以支撑软件代码、文档、图形界面和相关表达的权利边界。开源组件本质上仍然是权利人以许可证形式授权使用，不是放弃全部权利。
《中华人民共和国民法典》技术合同规则提醒企业在技术许可、资料保密、成果归属、验收标准和交付边界中写清义务。客户合同承诺“软件无第三方权利负担”时，开源义务没有披露清楚，就可能变成交付争议。
第一日开源合规清单
| 审查项 | 需要材料 | 判断用途 |
|---|---|---|
| 组件清单 | package-lock、pom、go.mod、镜像清单、SBOM | 确认用了什么 |
| 许可证识别 | SPDX 名称、LICENSE 文件、仓库说明、双许可证说明 | 确定义务来源 |
| 使用方式 | 内部工具、产品嵌入、修改、链接、部署、SaaS | 判断义务是否触发 |
| 分发对象 | 客户、渠道商、设备、云部署、私有化交付 | 判断是否对外交付 |
| 声明义务 | NOTICE、版权声明、许可证文本、第三方声明清单 | 判断补声明动作 |
| 源代码义务 | 修改文件、链接方式、交付包、构建脚本 | 判断是否要提供源码 |
| 供应商交付 | 外包代码、SDK、商业组件、开源扫描报告 | 判断责任归属 |
| 客户合同 | 知识产权保证、开源披露、赔偿条款、验收标准 | 判断合同风险 |
这张表应当进入研发和交付流程，而不是等客户尽调时临时扫描。临时扫描发现问题后，替换组件、补 NOTICE、补合同披露和重新构建版本都会增加交付成本。
高风险场景不是只有 GPL
很多企业只关注 GPL，但开源合规风险并不只来自一个许可证。宽松许可证也可能要求保留版权声明和许可证文本；双许可证项目可能要求商业授权；前端模板、图标库、字体、测试数据和示例代码也可能带来额外义务。
如果企业修改了开源组件并随产品交付，必须确认修改文件、链接方式、交付包和客户获取方式。只在内部使用和向客户交付，是完全不同的风险层级。即使组件没有触发源码开放义务，版权声明、许可证文本、NOTICE 和安全漏洞披露也可能需要单独处理。
供应商和客户合同要同步
外包团队、软件供应商或系统集成商交付代码时，应提交第三方组件清单、许可证清单、开源扫描报告、源码和构建说明。合同里要写明不得引入不符合客户交付要求的开源组件，并约定发现问题后的替换、补救和赔偿责任。
客户合同中，如果企业承诺软件完全自主、无第三方权利负担或可闭源交付，就必须提前披露开源组件和许可证义务。否则客户验收、上市审计、融资尽调或海外销售时，开源问题会从技术事项变成合同违约争议。
SBOM 和版本记录要能追溯
企业应把 SBOM、依赖锁文件、扫描报告和构建版本对应起来。只有一份静态 Excel 清单，很难说明某个客户交付包实际包含哪些组件。每次重大版本发布、私有化交付、移动端 SDK 升级或容器镜像更新，都应重新生成清单并归档。
开源合规还要和安全管理衔接。许可证义务解决的是授权和交付边界，漏洞修复、供应链投毒、废弃组件和镜像来源属于安全风险。两类问题不同，但都需要组件级追踪。
发生投诉后的处理顺序
收到开源作者、基金会、客户或平台的合规质疑后，先固定产品版本、组件清单、许可证文本、修改记录、分发范围和客户交付包。再判断是补 NOTICE、补许可证文本、开放对应源码、替换组件、购买商业授权，还是调整客户合同和交付说明。
对外回复时，不宜直接说“我们只是用了开源所以没有问题”。更稳妥的做法是说明组件版本、许可证识别、使用方式、已履行义务和后续补救计划。涉及客户项目时，还要同步评估是否触发验收、违约、赔偿或重新交付。
常见问题
问：MIT、Apache 这类宽松许可证是不是不用管？ 答：不是。通常仍要保留版权声明、许可证文本或 NOTICE，具体要看许可证条款和分发方式。
问：只做内部系统就没有开源合规问题吗？ 答：内部使用风险较低，但仍要关注安全、供应链、客户访问、SaaS 服务、外包交付和后续产品化。
江苏鑫律联律师事务所可协助企业建立开源组件清单、许可证审查表、供应商交付条款、客户开源披露和开源投诉应对材料。本文仅作一般法律信息参考，不构成针对具体案件或项目的法律意见，也不替代正式咨询。