GPLv2 合规争议在开源社区里从来不少见“Google is in clear violation of the GPLv2”这样的标题一旦出现往往像一颗石子扔进湖面很快就变成大量转发和争论的素材。但真正处理过开源合规问题的人清楚判断一个组织是否违反 GPLv2不能只看声讨文章的措辞而要落到具体证据上它到底用了哪些 GPLv2 代码发布的内容是不是衍生作品有没有交付完整对应源码有没有保留许可证声明。我不打算替这个具体指控下结论因为单凭一个标题拿不到足够证据。我更想做的是把“是否违规”这个问题拆开讲清楚验证过程让读者在遇到类似指控时自己就能判断该信什么、该查什么、该怎么处理。适合读这篇文章的人有三类准备在项目里引入 GPL 组件的开发者、需要做依赖合规审查的技术负责人、以及想搞清楚开源许可证到底怎么约束自己的项目维护者。下面按实际落地顺序拆一遍。1. 先对准义务基线GPLv2 到底要求什么围绕 Google 的这类指控之所以有讨论度一方面是因为公司体量大、产品线多任何一层依赖出问题都会被放大另一方面是因为 GPLv2 是上世纪九十年代初定稿的许可证条款诞生年代远早于现在常见的模块化架构、动态加载机制和容器化分发方式。同一个事实在不同人眼里可能得出完全不同的结论。所以第一步不是争论而是把 GPLv2 的义务基线对准。1.1 开源不等于放弃约束很多人把 GPL 简单理解成“代码公开了随便用”这个理解在个人学习和非分发场景下基本成立可一旦你把代码放入自己的产品再对外发布GPLv2 的约束就变得非常具体。它不是一个“开放态度”的声明而是一份带条件的授权你可以使用、复制、修改、分发但前提是满足许可证规定的义务。GPLv2 最核心的机制是 copyleft也叫“著佐权”。它的逻辑是反闭源化的如果你基于 GPL 代码制作了衍生作品并对外分发那么这个衍生作品整体也必须以 GPLv2 或与之兼容的许可证发布。用一句直白的话解释别人把源码开放给你你改完之后不能把改动关进黑盒再当成私有财产卖出去。理解这一点才知道“违规”到底违在哪里。1.2 四条核心义务GPLv2 全文并不长落到工程交付上可以压缩成一张表义务点对应条款落地含义保留版权声明第1条、第2条复制和分发时不能删除原版权信息、免责声明标注修改文件第2条被修改过的文件要写明修改日期和修改内容摘要提供完整对应源码第3条分发二进制时必须附源码或提供有效期不少于三年的书面要约不附加额外限制第7条不能给接收者增加 GPLv2 之外的新限制这里最容易被忽略也最容易翻车的是“完整对应源码”这六个字。“完整”指构成该程序的全部源码不是抽出来的部分“对应”指与发布的二进制同一个版本“源码”在许可证里的定义是“修改该作品时优先采用的形式”。换句话说如果你分发的是编译后的可执行文件那源码就应该能通过某个构建流程重新得到那个可执行文件如果你在编译前做了混淆或自动生成代码这些处理步骤也应该在源码交付物里能复现。实际审查中很多团队把“放了源码”当成“完成了义务”结果却发现三个问题源码里没有构建脚本源码版本和二进制版本对不上许可证文本和版权声明没有一起给。任何一处出错都可能构成不合规。这也是为什么真正的合规审计不是看某个目录里有没有 LICENSE 文件而是要把整个交付物当作一个可重建的工程来检查。2. 判断是否违规先走三条审计主线判断一个具体案例是否真的违反 GPLv2不能凭感觉也不能只看对方有没有“开源”两个字。我一般会把审计拆成三条主线逐条查完再下结论。顺序也很重要先确认有没有触发义务再检查义务有没有履行最后看有没有附加额外限制。2.1 第一条线确认是否存在衍生作品判断“是否违规”的第一步是确认对方有没有触发 GPL 义务。GPLv2 的条款只约束“复制、修改、分发” GPL 代码以及“基于 GPL 代码制作衍生作品”的行为。如果某个 GPLv2 项目只是被顺带提到或者只被引用了很短的一段函数结论会完全不一样。所以审计永远从“有没有衍生关系”开始。我个人的检查顺序是这样的先导依赖清单。不同语言有不同的清单文件比如 package.json、requirements.txt、go.mod、pom.xml、Cargo.toml全部导出成一份统一清单。扫描许可证字段。现在大多数包管理器都会在元数据里写 license 字段先把字段扫出来再挑选出 GPL、LGPL、AGPL 这类需要重点关注的许可证。在源码里检索版权声明。不要只搜 LICENSE 文件还要搜 “Copyright (C)” 加 GPL 声明、README 中的许可说明、代码注释顶部的许可证头。对二进制做字符串和符号分析。用 strings 或 nm 之类的工具看里面有没有特定 GPL 项目的错误信息、日志前缀或导出符号。看构建脚本的链接方式。一个程序到底是静态链接、动态链接还是独立进程调用了 GPL 组件直接影响“衍生作品”的判断。这一步最容易踩的坑是只扫 LICENSE 文件。很多项目的许可证写在了 README、项目主页或者包元数据里单独搜 LICENSE 会漏掉大量真实情况。我建议把“许可证扫描”和“版权头扫描”当作两件事分开做宁可花十分钟过滤噪声也不要因为少扫一个字段而漏掉关键组件。示例命令只做说明实际以你的环境和依赖管理工具为准# 导出依赖清单便于后续统一检查 npm list --all --json dependencies.json2.2 第二条线检查源码交付物是否完整如果确认对方分发了一个包含 GPL 衍生作品的程序接下来要验证的就是源码有没有给够。这条线按照“从粗到细”的顺序查有没有源码给了全部文件还是只给了核心模块源码和二进制是否对应版本号、提交哈希、构建时间是否一致。有没有构建脚本、依赖清单、配置文件和编译说明有没有修改文件清单GPLv2 要求修改过的文件标注变更信息和日期。如果是通过书面要约提供源码要约是否还在有效期内有没有写明获取方式和地址。我验证源码完整性时会做一个小实验把下载到的源码放进一个干净环境严格按照它提供的构建说明执行。如果中途报错、缺少关键文件、或者需要我反复猜测参数才能继续那这个源码交付物大概率不完整。不需要追求构建产物哈希完全一致但至少不能被未知环境变量和未公开私有工具卡住。这里有一个常见误区构建脚本存在不等于构建可复现。有些团队把源码和构建脚本打包进去了但脚本依赖