打开技术社区，一句标题就能把气氛拉满：Google is in clear violation of the GPLv2。转发的人里，有的人把它当成确凿事实，有的人把它当成媒体炒作，但没有多少人能回答一个问题：这句话的依据是什么？是 Google 没有公开源码，还是它公开的源码不完整，又或者是它分发 GPLv2 软件时没有附上授权声明？这些情况在 GPLv2 下意味着完全不同的后果。把一次指控翻译成工程问题，比单纯站队有用得多。
真正让人不适的地方在于，GPLv2 合规从来不是一个“是或否”的开关。它不是“我开源了”或“我没开源”这么简单，而是一整套围绕分发、源码对应关系、构建脚本、授权链路和许可证文本的工程检查。很多团队在收到开源合规投诉时，第一反应是找法务，但真正能救命的往往是找到当年负责打包的工程师。
1. 一句“清晰违规”背后，至少藏着四层问题
1.1 先确认：到底是不是“分发”
GPLv2 的义务不是只要用了就要开源。协议第一条就把适用范围限定在“复制、修改、分发”这些行为上。你在内部服务器上部署一个 GPLv2 程序，不给别人提供副本，通常不会触发源码交付义务。真正让义务出现的，是分发：比如把程序预装到设备上卖出去、向用户提供安装包下载、给第三方提供编译后的二进制。
一个很好的判断习惯是，先问自己：我到底有没有把“受 GPLv2 保护的软件”交给协议对象以外的人。如果没有分发，后面很多讨论都不成立。很多人一开始就在争论“我们改了代码算不算衍生作品”，却忽略了更前置的问题：这个组件是不是真的到了外部。分发这个动作一旦发生，后续的源码提供义务才会被激活。
1.2 “相应源码”不是随便打一个包
如果确实发生了分发，GPLv2 第 3 条的要求是：对于以可执行形式分发的程序，分发方要么一起提供完整且机器可读的对应源码，要么提供一份有效期至少三年的书面要约，愿意向任何第三方按不超过传递源码的实际成本提供完整源码。
很多人觉得“把源码传到网上”就够了，但 GPLv2 对“完整对应”的定义比想象中细。它要求包含所有模块的源码、相关的接口定义文件，以及用于控制可执行文件编译和安装的脚本。换句话说，不是一个 README 加一个 tar 包就完事。实践里最容易缺的，不是主程序源码，而是那些“看起来不重要”的脚本：编译内核用的 defconfig、生成固件镜像的 mkimage 步骤、打补丁的顺序、依赖的预编译工具链说明。
1.3 授权声明和许可证副本同样会被检查
第 3 条之外，第 1 条和第 2 条还要求不得移除或修改版权声明，修改过的文件要带明显的修改说明，分发程序时必须附上 GPLv2 协议副本。很多项目在合规检查时只关注源码包，却忘了检查二进制启动界面、关于页面、README 或安装目录里是否保留了 NOTICE。
这类问题不会让程序立刻失去版权，但会成为争议里最容易指出的漏洞。一个看起来很“开源友好”的项目，可能因为把 LICENSE 文件从某个子目录里删掉，就让自己陷入被动。尤其是多个开源组件混合时，不同许可证的声明需要被单独保留。合并 NOTICE 时不小心覆盖了原作者信息，也是常见的遗漏。
1.4 大多数违规不是“藏代码”，而是分发链路断裂
在真实产品里，GPLv2 违规很少是“程序员故意把源码藏起来”。更常见的场景是：A 公司提供 SoC 的 BSP，B 团队改动内核，C 团队打包固件，D 团队负责售后。到了发布日，没有人能回答“我们发布的内核二进制到底对应哪个 repo、哪个 branch、哪次 commit”。厂商意识停在“我们已经给过源码了”，但每次给的都可能不是最终出货版本。于是从外部看，就是 clear violation。
这里要分清两件事：协议上是否违规是一回事，能否向外界证据化地证明自己合规是另一回事。即使你的交付实际满足要求，如果发布记录混乱、源码包对不上二进制，面对质疑时也很难自证。开源合规争议发展到最后，往往不是“有没有违规”，而是“你有没有能力证明自己没有违规”。
2. GPLv2 的真正义务：不是“开源”，而是“让接收者能改写”
2.1 GPLv2 给了两种交付姿势
GPLv2 的源码交付给了两条路线，但目的是同一个：让接收者有能力修改这个程序，再在同样的许可证下重新发布。
第一种是源码随二进制一起分发，也就是把源码包放进发布物里。第二种是附带一份有效期至少三年的书面要约，注明索取方式。第二种方式看起来更省事，但它不是一句“源码可向公司索取”的口头承诺，而是一个明确、可执行、包含期限的联系方式和获取路径。要约里没写清楚联系方式、获取成本、版本信息，那它很难被视为有效的替代方案。
从工程经验看，最稳妥的实践是把源码包放进每次发布产物里，并同时在产品文档里给出下载地址和版本信息。这样即使对方没有主动索取，也能在拿到二进制的同时看到源码入口，争议空间最小。
2.2 构建脚本和接口定义文件，是“对应源码”的骨架
关键点在于构建脚本。对 Linux kernel 场景来说，一个合理源码包至少要包含：
linux/ ├── Makefile ├── Kconfig ├── arch/arm64/configs/your_product_defconfig ├── drivers/.../product_patches ├── include/... └── scripts/...如果实际生成固件时还用了build.sh、mkimage或定制生成设备树（dtb）的步骤，这些脚本也应当出现在源码包里，或者在文档中准确指向独立可获取的开源版本。GPLv2 原文用的是“scripts used to control compilation and installation of the executable”，所以至少用于编译、打包、安装流程的脚本不能被丢掉。
实际检查时，可以做一个很简单的测试：把源码包交给一个不熟悉项目的同事，只看源码包里的内容，能不能还原出发布物。如果在 README 之外还需要私下问“defconfig 在哪”“编译命令是什么”，那说明源码包还没有达到“对应源码”的标准。
2.3 链接边界、内核模块与聚合作品的模糊地带
GPLv2 不会自动覆盖“与我的代码放在一起的所有东西”。协议里有一个“独立且不是基于该程序的作品”概念，当它和 GPLv2 程序放在同一个存储介质上时，不一定要一并按 GPL 开源。
但什么算独立作品，什么算衍生作品，在动态链接、静态链接、内核模块、插件机制这些场景里一直有争议。这里不要只依赖技术分类判断，而要看组件之间的耦合程度、通信方式、是否共同构成一个程序的整体。普通团队至少应该记录每个组件的接入方式，而不是在检查时临时争论。
比如内核模块是否属于衍生作品，社区和司法实践都有过大量讨论，没有一个简单的万能答案。但有一点很确定：如果你修改了 Linux 内核并对外分发，却只提供一份未修改的上游内核源码，这就很容易被认定交付不完整。不管模块的边界怎么划线，至少你自己改过的那部分要能被对应上。
2.4 从“能运行”到“能重建”，中间缺的是工程能力
合规的真正验收标准，不是第三方能不能看到源码文件，而是第三方能不能用这份源码重建出功能等价的产物。若少了 defconfig、patch、地址映射、编译工具链版本，第三方虽然能看到代码，却无法把修改后的代码变成可运行的固件。
这里不是要求每次发布都做到完全可复现构建，那是另一层工程目标。但至少要保留足够信息，让接收者在不求助原厂的情况下，有合理机会重建出一个可运行的版本。把这个要求想清楚之后，很多团队会发现：他们缺的并不是合规意识，而是版本记录、构建记录和打包规范。
3. 用工程化思维做 GPL 合规：五步检查法
很多团队知道要合规，但不知道从哪里开始。以下五步是一个可复用的检查框架，适用于大多数涉及 GPLv2 组件的软件发布场景。
3.1 Inventory：先有一张许可证清单
不要从“这个目录好像是外部的”开始。先做全量扫描，建立 SBOM，也就是软件物料清单。粗略的字段至少包括：组件名、版本、许可证声明、分发形式、源码引用、是否被修改。
以 Linux kernel 为例，一行记录可以是这样：
| 组件 | 版本 | License | 分发形式 | 源码来源 | 是否本地修改 |
|---|---|---|---|---|---|
| Linux kernel | 5.10.120 | GPL-2.0 | 固件内预编译 | git tag 5.10.120 + local patches | 是，3 个补丁 |
这张表的价值在于，把抽象合规问题转化成可追踪的数据。如果没有这张表，后面所有判断都建立在“我记得这个开源项目应该没问题”上，这在发布物很多时会很快失控。
3.2 Trace：从二进制回追到源码
license 声明只是开始。发布包里的每个 ELF、固件镜像、压缩包，都应该能回溯到构建记录：用了哪个 repo、哪个 commit、哪个编译参数。
CI 里建议把这些信息写进 build manifest。比如内核产物可以附带一份文本：
kernel_repo=git.example.com/kernel/product kernel_commit=1234abcd kernel_defconfig=product_defconfig kernel_build_script=build/build-kernel.sh toolchain_version=clang-14.0.0没有 manifest 的旧发布包，最晚也要在做定期合规审查时补上。这个动作不仅为了合规，也能解决一个更实际的痛点：半年后用户反馈某个驱动异常，团队需要知道当时用了哪版本内核。这种“考古”任务靠的是构建记录，不是记忆。
3.3 Compare：本地修改要能对应到补丁
从 repo 拉下来的源码未必等于最终源码。对比的重点是：源码树里能否找到本地补丁；修改过的文件是否有声明；没有修改的部分是否被原样保留。
如果为了适配硬件改了几十个文件，却没有把修改整理成可复现的补丁，相当于源码包里只有原始上游，缺少产品对应的部分。更麻烦的是，有些团队把修改直接提交到私有 fork，却没有记录每个 fork 从上游哪个 commit 分出。等到发布时，很难说清楚“这份源码和上游差了多少”。
一个较好的习惯是，每个本地修改都应该能被打成一个或多个 patch，并在源码包里保留patches/目录。这既能让审核者清楚看到改动，也能在版本升级时复用。
3.4 Package：按许可证要求生成源码包
确认版本后，从 repo 导出对应 commit，把本地 patch、defconfig、build 脚本和许可证文件一起打包。目录结构要清晰，最好附带一个README.compliance，记录组件版本、获取地址、修改内容、构建方式。
源码包不要使用那种自动生成的临时目录，最好由构建流程自动产出。比如 CI 阶段在编译完成后，自动拉取 source archive，复制配置文件，生成 checksum。这样每次发布都会有一个新鲜生成的合规源码包，而不是靠手工从某个旧目录里拷贝。
3.5 Verify：在干净环境重建
合规包做完后，在空容器或虚拟机里按文档执行一次完整构建。这一步能把大部分“版本不对、缺文件、脚本路径写死”的问题暴露出来。
如果完全重建后的产物和正式发布物相比有差异，要能在文档里解释差异来源，比如时间戳、证书签名、工具链 hash。把这次构建的日志和产物 hash 存档，作为该发布版本的合规证据。
注意：这里说的“重建”，不是要求每次发布都做全量隔离构建。至少要在完成 license 扫描和源码打包后，用一次最小构建验证脚本可用。很多合规投诉的最后一句往往是“我按你说的步骤编译不了”，一次验证就能堵住这个口子。
4. 实际落地时最容易踩坑的四个位置
4.1 版本号对不上：源码包是旧 tag
见过很多团队的 compliance 目录里放着一个linux-5.10.tar.gz，但产品里用的其实是 5.10 加几十个 backport。用户拿到旧源码，既无法复现，也无法找到产品的安全修复。
版本对不上的原因通常是：发布时从 release branch 拉包的负责人与当初出二进制的不是同一人，而构建记录里没有记 commit。解决办法是把 commit id 写进构建产物文件名，或至少写进version文件。宁可文件名长一点，也不要让“版本对不上”成为争议焦点。
4.2 只有源码，没有构建脚本
GPLv2 不是只要求你能编译，还要求接收者能控制编译和安装。对内核而言，至少要有.config或defconfig；对应用软件而言，至少要有 Makefile、build script、依赖说明。
很多项目会把源码包做得非常“干净”，把所有脚本拆掉，这是好心办坏事。干净是指没有临时文件，而不是丢掉构建入口。你在上传前删掉的那个build.sh，往往就是第三方重建时最需要的东西。
4.3 把“上传到 GitHub”等同于完成义务
GitHub 公开仓库是一种很常见的源码提供方式，但它的可用性并不能自动满足协议里“对应源码”的要求。若公开仓库里的版本比最终出货版本旧，或者缺少本地 patch，它只是“一份源码”，不是“对应的源码”。
另外，如果只提供网上链接而没有在分发物里附协议副本和声明，拒绝看到链接的人仍可能认为交付不完整。最稳妥还是把源码包和产品一起发布或一起存档。公开仓库可以作为补充渠道，但不能替代发布物中的交付物。
4.4 扫描工具的结果不等于合规结论
license 扫描能告诉我这个文件里有 GPLv2 字样，但不会告诉我这个库和主程序是不是同一个作品，也不负责判断内核模块算不算衍生作品。工具只能减少遗漏，不能替代工程判断和合规审查。
拿到扫描报告后，要结合“是否分发、如何链接、谁写的代码、有没有改过”去判断。那种“扫描没有 GPL 输出就通过”的流程，早晚会在某个预编译二进制上出问题。扫描工具更像是一张地图，地图上标出来的地方不一定都是雷区，但你没标注过的地方很可能才是真正的雷区。
5. 回到 Google 争议：它能告诉我们什么
5.1 这个标题不是结论，而是检查的起点
Google 是一家有专门开源合规团队的公司，这条标题依然能把社区分成两派。如果我们不掌握具体的分发物、源码包、构建脚本和声明文件，这句话就只是争论素材。
真正要问的是：指控人是否拿到了一个具体的固件或安装包？对应的源码包是否包含最终 commit、defconfig、build 脚本？Google 给出的解释是否回应了这些点？没有这些信息，任何“确认违规”或“这不可能”的结论都只是情绪。与其急着站队，不如把标题当成一次开源合规知识测试：你知道该检查哪几个文件吗？
5.2 对普通团队：把合规当成发布特性
从工程经验看，最该学的不是去评价 Google，而是建立自己的流程。GPLv2 合规不应等法务函到了再做。建议把“合规源码包可重建”作为每个版本发布的 Definition of Done。
哪怕项目很小，也至少要把 license 清单、源码来源、构建命令写进 README。它的价值不只是降低法律风险，更是让接手的工程师能复现过去任何一个版本。很多团队到后期会发现，合规整理的产物就是一个高质量的“交接手册”，对人员流动、版本迭代、故障定位都有帮助。
5.3 下一步行动：从最小的发布物开始
与其等着看完整个行业的是非，不如回到自己手头最有代表性的那个发布版本，做一次演练：
- 找一份最近发布的产物，列出里面所有二进制或固件镜像。
- 对每个二进制做 license 扫描，记录来源和许可证声明。
- 回溯构建记录，确认对应的 repo、commit、编译参数。
- 按 GPLv2 要求整理源码、构建脚本、defconfig、补丁和许可证文本。
- 在干净环境里按文档重建一次，保存日志和产物 hash。
- 把这条流程写进发布检查表，以后每个版本都执行一遍。
一件开源合规争议，最坏的结果不是被批评，而是暴露“团队实际上不知道自己发的是什么”。从这个角度看，那句标题更像是一盏信号灯：它未必说明了 Google 一定违规，但它提醒所有人，GPLv2 不是开源圈用来喊口号的抽象概念，而是每个发布流程里必须能回答的一组具体问题。
下一次有人说某某违反了 GPLv2，先不要急着站队，问一句：分发了什么，对应源码在哪里，能重建吗。这三个问题问完，你大概已经知道问题出在哪一层了。
