GPLv2合规检查指南：从源码分发到构建脚本的工程实践

打开技术社区一句标题就能把气氛拉满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 的 BSPB 团队改动内核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 kernel5.10.120GPL-2.0固件内预编译git tag 5.10.120 local patches是3 个补丁这张表的价值在于把抽象合规问题转化成可追踪的数据。如果没有这张表后面所有判断都建立在“我记得这个开源项目应该没问题”上这在发布物很多时会很快失控。3.2 Trace从二进制回追到源码license 声明只是开始。发布包里的每个 ELF、固件镜像、压缩包都应该能回溯到构建记录用了哪个 repo、哪个 commit、哪个编译参数。CI 里建议把这些信息写进 build manifest。比如内核产物可以附带一份文本kernel_repogit.example.com/kernel/product kernel_commit1234abcd kernel_defconfigproduct_defconfig kernel_build_scriptbuild/build-kernel.sh toolchain_versionclang-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先不要急着站队问一句分发了什么对应源码在哪里能重建吗。这三个问题问完你大概已经知道问题出在哪一层了。