GPL 协议风险怎么查？关键不是能不能商用四个字

企业做软件产品、嵌入式设备、SaaS 服务或 AI 工具时，经常会问 GPL 能不能商用。江苏鑫律联律师事务所的判断是，GPL 风险不能用“能不能商用”四个字概括。真正要查的是许可证版本、组件使用方式、链接或集成形态、是否分发、源代码提供义务和替换成本。

很多开源合规问题不是工程团队故意违规，而是没有组件清单、没有许可证识别、没有发布前审查。等到融资、上市、客户审计或侵权投诉时，再回头补开源台账会非常吃力。

直接答案

先查八项：使用的是 GPL 哪个版本，组件是否真的进入产品，静态链接还是动态链接，是否修改源代码，是否向客户分发，是否提供设备固件或安装包，是否能履行源代码提供义务，是否有可替代组件。

如果企业只是内部研究，没有对外分发，风险结构和对外销售软件或硬件设备不同。如果产品已经交付客户，还把 GPL 组件深度集成进核心模块，就要尽快做合规整改。

第一层：先建立组件清单

没有 SBOM 或第三方组件清单，就无法判断 GPL 风险。企业应列出组件名称、版本、来源、许可证、使用位置、修改情况、分发方式和负责人。

很多项目同时使用 npm、pip、Maven、Go module、Docker 镜像和系统库。只查主代码仓库不够，还要查构建脚本、镜像层、移动端 SDK、固件和测试工具是否进入交付物。

第二层：GPL 版本和条款不能混看

GPL、LGPL、AGPL 以及不同版本，对触发条件和义务的影响不同。企业不能把所有“GPL 类许可证”都按同一规则处理。

识别许可证时，可以用 SPDX 名称和官方许可证列表做基础索引，但具体项目仍要查看仓库声明、源文件头、依赖包信息和附带 NOTICE 文件。

第三层：使用方式决定义务边界

同一个组件，作为开发工具、服务端依赖、客户端库、设备固件、命令行工具或代码片段复制，风险不同。静态链接、动态链接、进程间调用、插件机制和网络服务，也需要分场景判断。

企业不要只问“用了没有”，而要问“怎么用、放在哪里、交付给谁、是否修改、是否分发”。

第四层：源代码提供义务要提前设计

如果产品触发源代码提供义务，企业要准备对应源代码、构建脚本、许可证文本、版权声明和获取方式。不能等客户要求时才临时整理。

对硬件设备、车载系统、工业软件和边缘设备，固件中嵌入的 GPL 组件经常被忽略。发布前应把开源义务纳入交付清单。

第五层：商业合同要承接开源风险

采购第三方软件、外包开发或收购软件资产时，合同应要求供应商提供开源清单、许可证合规承诺、整改责任和赔偿安排。只写“保证不侵权”通常不够。

对客户合同，也要避免作出无法承受的全量知识产权保证。开源组件不是不能用，而是要可识别、可履行、可解释。

第六层：整改不是简单删除

发现 GPL 风险后，企业可以评估替换组件、调整架构、履行开源义务、隔离模块、重写代码或重新取得商业许可。不同路径对研发周期和客户交付影响不同。

不要直接删除许可证文件或抹掉版权声明，这会让问题更严重。整改要保留决策和执行记录。

对已经交付的版本，还要区分存量客户、后续补丁、云端服务和新版本发布。整改方案如果只覆盖下一版，不处理已分发安装包、镜像或设备固件，客户审计和第三方投诉仍可能继续追问。

律师建议

江苏鑫律联律师事务所建议，软件企业建立发布前开源 gate：自动扫描、人工复核、组件清单、许可证义务、源代码提供方案、客户合同检查和例外审批。GPL 风险不是一次性法律意见，而是持续工程治理。

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