快速结论
主要风险不是“用了开源就侵权”，而是没有遵守具体开源许可证。不同许可证可能要求保留版权/许可声明、提供源代码、披露修改、对衍生作品采用相同许可证，或包含专利授权与终止条款；还要防范组件来源、版本漏洞和许可证冲突。
规则要点
适用于商业软件、SaaS、嵌入式产品和AI系统中的开源组件使用。
建议处理路径
- 建立SBOM/组件清单
- 识别每个组件及版本许可证
- 按分发/网络服务/静态或动态链接等场景分析义务
- 保留NOTICE和源代码履行材料
- 上线前做许可证冲突与安全检查
建议准备的材料
- SBOM
- LICENSE/NOTICE文件
- 源代码仓库
- 构建依赖清单
适用说明
不能只按“MIT/GPL”标签判断，必须阅读实际版本的许可证文本、例外条款和组件依赖关系；具体结论需要逐许可证核验。
开源合规从发布方式入手
同一组件用于内部测试、向客户交付二进制，或提供网络服务，可能触发不同义务。先确认组件版本、实际许可证、例外条款和使用关系，再讨论静态链接、动态链接、修改或分发。不能用“代码没有直接粘贴”作为所有场景的免责理由。
依赖可能带来其他许可证，应记录直接与间接组件。供应商提供的产品也需要取得清单和履行说明，不能只接受“全部符合开源”的概括保证。
履行证据如何保存
保留交付包中的版权声明、许可证、NOTICE、源代码提供方式及修改记录，并核查链接实际可用。MIT、Apache、GPL和AGPL等标签不足以说明全部条件，必须读具体文本。发现冲突后评估替换、取得其他许可或调整产品结构。违反开源义务的后果与企业自有代码权利是否成立也应分别判断，不能推导一方违约后所有第三人都可任意复制。
检查单位应具体到组件版本与许可证文本。软件升级后许可证或依赖树可能变化，原来的审核结论不能直接覆盖新版本。采购合同中的免责条款也不能替代对实际使用方式的核查。
补充核对要点
组件清单应记录名称、版本、来源、许可证和实际调用方式，特别检查是否修改、链接或向外分发。仅在开发人员电脑上能够使用，不等于企业可以按任意方式商业交付。上线前保留第三方声明和必要源代码等履行记录；更换组件版本后，还应重新核查许可条件而非沿用旧结论。
以下为说明性示例：
| 组件与版本 | 实际许可文本 | 使用方式 | 发布前必须核对的事项 |
|---|---|---|---|
| 组件A v1 | 仓库随附LICENSE及例外 | 修改后交付客户 | 声明、修改告知、源码提供等义务是否被具体条款触发 |
| 组件B v2 | 实际许可证及依赖许可 | 内部运行或对外网络服务 | 不同许可触发条件不同，不能用另一许可证标签替代 |
当前依据
著作权法 + 各开源许可证合同/授权条件。
补充核对资料
补充资料核对日期：2026年10月8日。文中材料组织与管理方法为本站实务经验总结；适用法律按行为发生时期的规范认定。
2026年涉人工智能纠纷意见补充
该意见第13项要求结合具体开源许可条件，依法评价相关方的责任和适当免责安排。开源并不意味着全部用途无条件许可，也不是提供者一律免责；版本、许可文本、修改和分发方式仍需逐项对应。
依据最高人民法院关于依法审理涉人工智能纠纷案件的意见（法发〔2026〕10号，最高人民法院司法规范性文件）。具体争议仍需结合案件事实与法定条件分析。
办理要点
- 逐项梳理许可证或协议的版本、条款、修改与分发方式。
办理要点按事实、主体、时间与规范分别组织，并形成对应的资料清单和程序节点。
来源
- https://www.ncac.gov.cn/xxfb/flfg/flfg_532/202103/t20210309_50530.html
- https://www.court.gov.cn/fabu/xiangqing/254751.html
- https://www.court.gov.cn/zixun/xiangqing/233181.html
- 最高人民法院涉人工智能纠纷意见（法发〔2026〕10号，司法规范性文件）：
相关主题
- 开源软件合规开源软件 · 开源许可证 · 软件合规
- 企业出口前知识产权七联检企业出海IP检查 · 出口知识产权风险 · 跨境FTO
- OEM/ODM海外知识产权合同OEM合同知识产权 · ODM合同 · 海外代理合同