最近开源社区出现了一个讨论度很高的标题“Google is in clear violation of the GPLv2”。这类声明很容易变成口号但真正值得做的不是站队而是把背后的问题落到代码层面GPLv2 到底要求什么一个二进制分发出去之后怎么判断它有没有履行“提供对应源码”的义务如果你的项目里用到了 GPLv2 代码又该怎么自查和整改这篇文章不打算复述新闻而是给你一套可以照做的GPLv2 合规检查路径。我们会先拆解 GPLv2 的关键条款再分析 Google 相关争议里最常见的几种技术场景然后从操作系统、工具链、二进制扫描、源码对应、自动化批量检测几个环节把验证方法写清楚。适合开源项目维护者、嵌入式开发、Android 系统工程师、法务技术对接人以及所有要在生产环境里分发二进制的人。1. GPLv2 合规检查能力速览先把话题当成一个“工具域”来看。下面这个表不是某个软件的规格而是GPLv2 合规审查这件事的能力边界能力项说明约束对象复制、分发、再分发 GPLv2 程序及其派生作品核心义务向收件人提供对应源代码、保留版权声明、提供书面要约派生作品判断静态链接、动态链接、修改源码后发布通常都可能触发聚合作品判断独立程序通过命令行或 IPC 调用不一定触发但边界模糊典型违规场景二进制分发不附源码、修改代码不公开、移除版权声明、闭源驱动与 GPL 内核联动检测手段源码扫描、二进制字符串扫描、动态依赖分析、SBOM 核对自动化能力可接入 CI按目录批量扫描输出 JSON/CSV 报告适合场景发布前合规审计、第三方库引入检查、供应链风险排查不适合场景直接替代法律意见自动扫描不能证明“已合规”从表格可以看出GPLv2 合规不是“有源码就行”而是“源码和二进制要对应”同时版权声明、书面要约都要留底。这也是很多争议的根源。2. GPLv2 许可条款核心解析在写检测命令之前先把 GPLv2 文本里最容易被误解的几条过一遍。下面内容基于 GPLv2 公开文本具体条文名称以官方许可证为准。2.1 分发行为是触发条件GPLv2 的源代码开放义务是在“收到副本并分发副本”时触发的。如果代码只在你自己的服务器上运行没有对外分发那么 GPLv2 的“提供源码”义务通常不会立刻触发。这一点经常被误读成“用了 GPL 就必须开源”。多数互联网公司的产品属于“SaaS 场景”也就是服务端运行不发生二进制分发所以 GPLv2 的源码提供义务确实不一定被触发。但如果你的产品是手机固件、路由器镜像、SDK、嵌入式设备、硬件出厂镜像那么每一次向客户或公众分发一个包含 GPLv2 代码的二进制就要注意配套源码义务。2.2 必须提供对应源代码GPLv2 说得很直接无论以目标码还是可执行形式分发都必须向收件人提供对应的、可读的源码副本或者至少提供一份有效期不少于三年的“书面要约”。这里的关键词是“对应”。很多项目把源码包丢到一个网站上就认为合规了但源码版本必须和二进制版本保持一致同时要能通过源码和构建脚本重现出那个二进制。版本对不上仍然会被认为不合规。2.3 派生作品与聚合作品的边界GPLv2 对“基于本程序的作品”要求继续以 GPL 授权。但独立且非派生的作品如果和 GPL 程序一起分发给用户不要求也不应该用 GPL 覆盖。实际工程里边界在哪里很不确定。常见判断对 GPL 源码进行修改再发布修改版几乎必然触发 GPL。程序动态加载 GPL 库当前司法实践中一般倾向视为派生作品但也有争议。独立程序通过命令行调用 GPL 程序交换数据通常不算派生。争议性最强的往往是内核模块。Linux 内核是 GPLv2如果闭源驱动通过 /proc、/sys、内核导出符号等接口与内核深度耦合它到底算不算“派生作品”这正是很多针对 Android 设备厂商投诉的技术背景。2.4 自动终止条款GPLv2 第 4 条类似“违约即终止”。只要你在分发副本时违反 GPLv2你对许可证的授权就自动终止。也就是说侵权者不再拥有复制、修改、再分发该 GPLv2 程序的许可除非重新获得版权方授权。这也是为什么“明确违反 GPLv2”是非常严重的指控。一旦被认定不仅是补一份源码的问题而是后续所有基于该代码的复制和分发都可能失去合法前提。2.5 专利保护与 GPLv3 的差异GPLv2 比 GPLv3 少了很多针对“专利授权”和“反 Tivoization”的专门条款但 GPLv2 第 7 条仍然处理了专利导致的附加限制问题如果分发者在某国被指控其发布的程序侵犯了特定专利导致该程序无法自由再分发版权方可以自动延展 GPL 条款以外的商业授权。GPLv3 和 GPLv2 最大的区别在于GPLv3 更明确地规定了“不允许用专利协议阻止用户自由使用”并且增加了关于防锁定、兼容 Apache License 2.0 等条款。很多现代项目选择 GPLv2 原因之一是它更短、更稳定而执法争论也更集中在“源码是否提供”上。3. Google “违反 GPLv2”争议点拆解标题里点名了 Google但真正的技术争议并不只在某一家公司。把它当成一个案例来拆通常绕不开下面四个场景。下面只做技术分析不构成法律结论。3.1 Android 内核与闭源驱动Android 设备的核心是 Linux 内核而 Linux 内核采用 GPLv2 授权。Google 作为 Android 生态的主导方会发布 Android 开源项目AOSP也会为 Pixel 等设备提供内核源码。设备厂商拿到内核源码后通常还需要闭源的显卡、Wi-Fi、基带驱动这些驱动以内核模块形式存在。问题在于如果闭源模块加载进 GPLv2 内核并且调用了内核导出的 GPL 符号那么它是“独立程序”还是“内核的派生作品”业界一直有两种看法。从合规审计角度看只要设备固件里包含了“Linux 内核 闭源模块”的组合就要逐一定位内核模块的二进制再检查对应的源码和构建说明是否存在。如果厂商只给了内核源码但闭源模块没有对应源码这就会成为“clear violation”的争议点。3.2 二进制分发与源码包版本不对应另一个常见争议是源码和二进制“版本漂移”。Google 发布工厂镜像时有时会同步提供内核源码 tag但设备厂商自己为某个型号生成的内核二进制改动可能没有回传到源码仓库。用户拿到的设备里运行的内核版本和公开 kernel 仓库里的提交并不能一一对应。要验证这种问题不能只看源码仓库有没有代码而要把设备里的/proc/version、编译指纹、uname -a与源码仓库中的提交哈希进行比对。如果设备上的磁盘unextracted无法完整匹配到源码里已知构建产物就可能被认定为“没有提供对应源码”。3.3 聚合与派生程序之间的扫描盲区Google 有很多产品是中间件层面的二进制比如 Bionic 库、libutils、libbinder。有些库是 Apache 2.0 或 BSD 的有些模块则可能包含来自 GPLv2 项目的代码片段。聚合分发时如果只是把 GPLv2 程序和非 GPL 程序放在同一个文件系统里通常不会有太大问题但如果有静态链接、符号引用、代码复制就构成派生作品。自动化扫描经常把这些情况混在一起导致误报或者漏报。正确做法是把“同目录分发”和“链接引用”分开对链接引用做更严格的判断。3.4 版权声明和书面要约GPLv2 第 2 条要求所有副本都保留版权声明和免责声明。很多项目在发布二进制时会把这些信息写在单独的copyright文件里或者放在strings输出里。合规审查时最容易被忽略的是“书面要约”的有效期。如果你的项目通过官网页面提供源码下载地址但没有写明这个要约至少保持三年有效就可能被质疑。把这一项加到检测清单里是为了避免“有源码下载页但没满足要约形式”的低级风险。真正的合规不只是“能给源码”还包括“在分发物里告诉收件人怎么要源码”。4. 环境准备与前置条件现在进入可执行部分。下面给出一套通用检测环境系统以 Debian/Ubuntu 系 Linux 为例。如果你想检查 Android 分区的二进制可以先把固件解包到目录再执行同样的扫描。4.1 操作系统和基础工具建议准备一台至少 4 核 CPU、8GB 内存的 Linux 机器。扫描大型固件目录时磁盘占用会迅速增大建议保留至少 50GB 可用空间并单独准备一个输出目录。sudo apt update sudo apt install -y build-essential binutils file unzip tree python3 python3-pip curl gitbuild-essential用于编译示例 GPL 程序binutils里的readelf、strings用于分析二进制file用于识别文件类型。Python 环境用来跑批量扫描脚本。4.2 安装许可证扫描工具这里介绍两个不依赖商业平台的工具scancode-toolkit扫描源码目录识别许可证声明。license-checker适合 Node.js 项目的依赖许可证检查。安装scancode-toolkit推荐用 Python 虚拟环境python3 -m venv /opt/scancode-venv /opt/scancode-venv/bin/pip install scancode-toolkit ln -s /opt/scancode-venv/bin/scancode /usr/local/bin/scancode安装license-checker需要 Node.jssudo apt install -y nodejs npm npm install -g license-checker如果只是临时检查一个二进制也可以不用安装扫描工具只靠系统的strings和readelf完成第一步。4.3 准备测试样例为了验证整套流程我建议你准备两个样例一个小型 GPLv2 程序比如hello-gpl.c编译成二进制。一个不含 GPL 的普通程序编译成二进制作为对照。先写一个带 GPL 声明的 C 文件/* hello-gpl.c * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2. */ #include stdio.h int main(void) { printf(hello gpl\n); return 0; }编译gcc -o hello-gpl hello-gpl.c再用同样的方法编译一个不写任何许可证声明的普通程序/* hello-plain.c */ #include stdio.h int main(void) { printf(hello plain\n); return 0; }gcc -o hello-plain hello-plain.c这样就有了两个可执行文件一个是明确 GPLv2 源码编译来的一个没有任何许可证声明。接下来所有检测逻辑都可以先在这两个文件上验证。5. 功能测试与效果验证检测二进制是否违反 GPLv2现在开始做实际验证。下面每个步骤都能独立运行你也可以直接用这些命令检查自己项目里的二进制。5.1 用 strings 检查版权声明和 GPL 标识GPLv2 要求在二进制中保留版权声明但版权声明不一定出现在二进制文件的可见字符串里。先看两个文件的差异strings hello-gpl | grep -i GNU strings hello-plain | grep -i GNU预期输出hello-gpl大概率会输出版权声明和 GPL 文本相关字符串。hello-plain如果没有链接系统库中的 GPL 字符串可能什么都不显示。注意很多二进制链接了glibc其中也可能包含 GPL 相关字符串。因此strings的结果只适合做初步筛选不能直接作为“是否 GPL”的唯一标准。5.2 用 readelf 检查动态依赖和符号引用如果某个程序通过动态链接依赖了一个 GPL 库那么它是否算派生作品需要通过符号引用进一步判断。先看依赖列表readelf -d hello-gpl | grep NEEDED readelf -d hello-plain | grep NEEDED再看符号表里是否引用了可疑的 GPL 库符号nm -D hello-gpl | grep -i my_gpl_symbol如果你的项目里有一个闭源可执行文件却动态依赖了/usr/lib/libfoo.so而libfoo.so来自一个 GPLv2 项目那么你就需要判断该可执行文件是否与 libfoo 存在“紧密集成”。通常建议把这类依赖列进合规清单。5.3 用 file 确定二进制类型确认文件架构和打包格式避免扫描到文本文件或压缩包就停止file hello-gpl file hello-plain输出类似hello-gpl: ELF 64-bit LSB executable, x86-64, dynamically linked, ...如果是固件目录file还能帮你识别固件镜像、文件系统、内核 Image 等结构方便后续针对vmlinux、*.ko、.so做细化检查。5.4 检查源码包与二进制是否对应这一步是 GPLv2 合规里最核心的验证给定一个二进制你必须能找到“能够重新生成该二进制”的源码和构建脚本。通用做法是记录二进制的哈希。记录源码仓库的 commit 号。使用相同环境变量、编译选项重新编译。比较新生成二进制的哈希或至少比较.comment段中的编译器信息。sha256sum hello-gpl在源码目录里重新编译后再次计算哈希如果哈希不一致要检查是否因为构建时间戳、路径、随机生成符号导致差异。很多项目会使用SOURCE_DATE_EPOCH实现可重现构建。5.5 扫描整个目录的许可证声明当二进制变成数千个文件时可以用scancode做批量扫描scancode --license --copyright --json-pp scan-result.json /path/to/your/distribution执行完成后查看scan-result.json里出现GPL-2.0-only或GPL-2.0-or-later的文件路径和版权声明再逐项确认源码包是否存在。如果被扫描的是 Node.js 项目可以用license-checkercd /path/to/node/project license-checker --json --production --out license-output.json它会读取package.json里的依赖信息输出每个依赖的许可证类型。这个工具适合做模块级检查但无法替代二进制层面的源码对应检查。5.6 验证结果判断表检测项判断标准通过二进制含有 GPL 版权声明strings能找到 GPL 声明正常保留声明是被要求的动态依赖 GPL 库readelf -d显示 NEEDED需进一步分析不直接等于违规源码仓库存在仓库里能找到项目名和 tag只是必要条件源码版本与二进制匹配构建后哈希一致或高度近似核心标准书面要约分发物中包含源码获取方式书面要约需保留三年版权声明保留二进制和源码中均保留必须闭源模块与 GPL 内核联动lsmod和导出符号检查高风险项需逐案分析6. 接口 API 与批量合规检测手动检查适合一两个二进制如果你负责一个持续交付的软件平台就需要把合规检查做成自动化和批量化。下面给出一套通用设计。6.1 批量扫描脚本先写一个 Python 脚本对给定目录里的所有 ELF 文件执行strings和readelf把可疑文件输出成 CSV#!/usr/bin/env python3 import os import subprocess import csv import sys def is_elf(path): try: with open(path, rb) as f: return f.read(4) b\x7fELF except Exception: return False def scan_dir(root_dir): results [] for dirpath, _, filenames in os.walk(root_dir): for name in filenames: full_path os.path.join(dirpath, name) if not is_elf(full_path): continue output subprocess.run( [strings, full_path], capture_outputTrue, textTrue, timeout60, ).stdout if GPL in output or General Public License in output: results.append((full_path, GPL string found)) return results if __name__ __main__: root sys.argv[1] csv_path sys.argv[2] rows scan_dir(root) with open(csv_path, w, newline) as f: writer csv.writer(f) writer.writerow([path, reason]) writer.writerows(rows) print(ffound {len(rows)} files, report written to {csv_path})运行方式python3 scan_elf.py /path/to/distribution report.csv这个脚本只是最简单的一层。生产环境建议加入文件哈希、elf 类型、链接库列表等字段。6.2 做成 HTTP 接口如果团队不希望在每台机器上安装工具可以封装一个最小 Web 服务接受待扫描目录返回 JSON 报告。下面是一个 FastAPI 示例需要先安装pip install fastapi uvicorn python-multipartfrom fastapi import FastAPI, UploadFile, File import tempfile, os, zipfile from scan_elf import scan_dir app FastAPI() app.post(/scan) async def upload_and_scan(file: UploadFile File(...)): with tempfile.TemporaryDirectory() as tmpdir: zip_path os.path.join(tmpdir, upload.zip) with open(zip_path, wb) as f: f.write(await file.read()) extract_path os.path.join(tmpdir, extract) os.makedirs(extract_path, exist_okTrue) with zipfile.ZipFile(zip_path, r) as zf: zf.extractall(extract_path) rows scan_dir(extract_path) return {count: len(rows), reports: rows}启动接口uvicorn api:app --host 127.0.0.1 --port 8000请求时用 curl 上传 zip 包curl -F fileyour_package.zip http://127.0.0.1:8000/scan这个接口适合在发布流水线里用但要注意扫描结果只能定位“出现 GPL 字符串”的文件不能自动证明项目违反 GPL更不能证明合规。6.3 集成到 CI在 GitHub Actions 里增加一个合规扫描 job让每次发版前自动跑一遍。下面是一个 YAML 示例name: compliance-scan on: push: tags: - v* jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Setup Python uses: actions/setup-pythonv5 with: python-version: 3.11 - name: Install scancode run: | pip install scancode-toolkit - name: Run license scan run: | scancode --license --copyright --json-pp scan-result.json . - name: Upload report uses: actions/upload-artifactv4 with: name: license-scan-report path: scan-result.jsonCI 扫描的意义在于“兜底”至少保证发版时有一份扫描报告。真正的人工审计仍然需要人在发布前处理高优先级项。7. 资源占用与性能观察批量许可证扫描并不是轻量操作。如果被扫描的是一个包含 Android 系统镜像的解包目录文件数量很容易达到几万甚至几十万这时要关注资源占用。7.1 显存与内存许可证扫描主要吃 CPU、内存和磁盘不吃显存。如果你的电脑有 GPU扫描过程不会用到 CUDA。因此不要用“显存占用”来衡量许可证扫描而是观察CPU 平均负载内存占用磁盘 IO临时文件大小7.2 扫描过程中的资源观察可以用htop或nvidia-smi查看系统负载。对于纯 CPU 扫描htop如果内存压力大可以限制 Python 进程并发数。scancode自带--processes参数新版有的版本是-n可以控制并行度scancode --license --copyright --json-pp scan-result.json --processes 4 /path/to/distribution7.3 大目录扫描时间扫描时间取决于文件总数、文件大小、是否启用--copyright以及磁盘速度。稳妥的做法是先在一个子目录做小规模测试比如扫描 1000 个小文件再推算全量扫描时间。不要一开始就直接扫整个镜像否则日志会非常难排查。7.4 降低资源占用的小技巧先用find排除非二进制文件比如.git、图片、视频。不启用所有检测项只启用--license时速度更快。分模块扫描例如先扫/system/bin再扫/vendor/lib。结果输出到单独磁盘避免和目标目录共用 IO。find /path/to/distribution -type f \ ! -path */.git/* \ ! -name *.png \ ! -name *.jpg \ ! -name *.mp4 \ filelist.txt然后让扫描工具优先读取文件列表可以提高效率。8. 常见问题与排查方法下面整理一份实战排查表。遇到“扫描不到 GPL 字符串”不代表绝对安全遇到“扫描到 GPL”也不代表一定违规关键是判断“是否构成派生作品以及是否提供对应源码”。问题现象可能原因排查方式解决方案strings找不到 GPL 声明编译器把字符串放在不可见区域或版权声明被移除使用readelf -p .comment、objdump -s -j .rodata保留可见版权声明更新构建配置扫描报告大量出现 GPL-2.0源码目录里有第三方库和文档打开 JSON 报告按路径区分针对第三方库单独维护许可证清单二进制动态依赖 GPL 库闭源程序调用了 GPL 库readelf -d file查看 NEEDED联系法务评估是否构成派生作品源码包存在但版本对不上构建脚本未固定 commit 或 tag对比二进制构建时间与 git 提交时间为每个发布版本记录源码 commit 和构建参数用自动扫描判断“未违反”自动扫描只能证明“没有找到特征”人工审计派生判断引入代码归属分析和 SBOM固件里有闭源.ko模块但内核是 GPLv2可能涉及派生作品争议modinfo xxx.ko查看 license 字段记录模块 license 字段制定风险说明书面要约缺失只在网站上提供源码没有在分发物里声明检查二进制目录下有没有COPYING或offer.txt在压缩包内增加源码获取说明API 扫描接口超时上传 zip 太大扫描耗时过长调整接口超时改用异步任务队列拆包后分批扫描返回任务 ID误报太多扫描到/usr/share/doc下的许可证文件在文件列表里排除COPYING*、LICENSE*对许可证文件做“归纳计数”而不是逐文件判断多个项目共用同一台构建机环境依赖污染二进制不可重现保存构建环境 Dokerfile/镜像使用可重现构建脚本固定工具链版本9. 最佳实践与合规整改建议无论你是项目维护者还是负责集成第三方组件的开发负责人下面这些建议都可以直接落到流程里。9.1 先做“最小可运行配置”合规审查最容易犯的错误是一上来就扫描整个代码仓库。建议先准备一个最小可运行配置一个编译产物、一份源码包、一个构建脚本、一个许可证清单。在这个小配置上验证合规流程跑通了再放大。9.2 每次发布都生成 SBOM用 SPDX 格式或 CycloneDX 格式记录下每个二进制组件、版本、来源和许可证信息。有了 SBOM至少能回答“这个二进制用了哪些许可证”这个问题。生成 SBOM 的通用方式之一scancode --spdx-tv spdx.spdx /path/to/your/distribution如果团队没有专门工具也可以用dpkg在 Debian 系系统里生成已安装包的清单但这对自研二进制帮助有限。9.3 源码和二进制建立对应关系建议在每个二进制旁边放一个source-info.txt记录源码仓库地址git commit hash构建命令编译器版本构建时间戳二进制 SHA256这样审计方不需要先从固件里猜“用的什么版本”可以直接定位到源码。这也是证明合规最有力的材料。9.4 对高风险动态链接单独审查在工程实践中如果二进制动态链接了 GPLv2 库但不能确定是否属于“聚合”还是“派生”最稳妥的做法是保留该库对应的源码包。在发布清单里明确写出libfoo.so来源于哪个 GPLv2 项目源码地址是什么。不要试图通过“运行时才加载”来回避义务因为很多地区法律对动态链接的态度并不统一。9.5 避免“内部使用”陷阱有一种常见误判只要二进制的使用者是“内部人员”就认为不需要提供源码。但如果你把产品设备给了客户哪怕客户不是公众只要该分发属于“再分发出现场副本”就可能触发义务。越是嵌入式设备、行业终端越容易因为“内部测试机”而忽略这一点。9.6 版权声明不要清理很多自动化重构工具会删除注释导致 GPL 声明被移除。建议把版权声明写入构建插件或版本控制 hook禁止删除以下内容原始版权声明免责声明GPLv2 许可证全文引用修改版本的作者身份说明如果项目允许也可以使用 SPDX 头来标准化// SPDX-License-Identifier: GPL-2.0-only9.7 考虑“书面要约”模板如果你分发 GPLv2 二进制但不想把源码直接打包进每一个压缩包可以提供一个书面要约模板。需要注意要约必须明确、可达并且自首次分发起至少有效期三年。下面是个参考写法This product contains software licensed under the GNU General Public License v2. The complete corresponding source code is available at: https://example.com/source/?packageyourappversion1.0.0 This offer is valid for at least three years.这段内容应该随二进制分发不能只在官网上出现。9.8 自动扫描与人工审计结合自动扫描的价值是高效率覆盖“已知许可证文本”但它不能回答“这个模块是否被修改过”“这个链接是否为派生”。因此建议发布门禁采用两级一级扫描失败则禁止发布。二级人工审计扫描到的高风险项由工程师和法务共同确认。你可以在发布流水线里加一个“人工确认”状态未经确认不能上传到生产仓库。10. 总结与下一步“Google is in clear violation of the GPLv2”这个标题值不值得关注值得。但更值得的是我们从中看到一套通用的 GPLv2 合规验证方法从许可证条款出发对二进制做字符串扫描和动态依赖分析再通过源码对应、版权声明、书面要约三个维度判断是否履行了义务。如果你负责的项目需要对外发布二进制第一件可以做的事是把你发出去的某个二进制放到strings、readelf和sha256sum下面跑一遍。先搞清楚它到底依赖了什么许可证再决定源码包和构建脚本要不要补。最容易踩的坑有两个一是只扫描源码目录而不扫描最终二进制二是只保留“能下载源码”的页面却没有把书面要约写进分发物。这两点都很容易出现也最容易在审计中被质疑。后续可以继续扩展的方向包括把 SPDX/SBOM 接入 CI、对固件镜像做自动解包扫描、建立第三方依赖许可证白名单、在编译阶段加入源码哈希生成插件。每一步都能让“是否违反 GPLv2”这件事从口号变成可验证的证据链。 GPLv2合规检查实战：从许可证条款到二进制扫描路径
最近开源社区出现了一个讨论度很高的标题“Google is in clear violation of the GPLv2”。这类声明很容易变成口号但真正值得做的不是站队而是把背后的问题落到代码层面GPLv2 到底要求什么一个二进制分发出去之后怎么判断它有没有履行“提供对应源码”的义务如果你的项目里用到了 GPLv2 代码又该怎么自查和整改这篇文章不打算复述新闻而是给你一套可以照做的GPLv2 合规检查路径。我们会先拆解 GPLv2 的关键条款再分析 Google 相关争议里最常见的几种技术场景然后从操作系统、工具链、二进制扫描、源码对应、自动化批量检测几个环节把验证方法写清楚。适合开源项目维护者、嵌入式开发、Android 系统工程师、法务技术对接人以及所有要在生产环境里分发二进制的人。1. GPLv2 合规检查能力速览先把话题当成一个“工具域”来看。下面这个表不是某个软件的规格而是GPLv2 合规审查这件事的能力边界能力项说明约束对象复制、分发、再分发 GPLv2 程序及其派生作品核心义务向收件人提供对应源代码、保留版权声明、提供书面要约派生作品判断静态链接、动态链接、修改源码后发布通常都可能触发聚合作品判断独立程序通过命令行或 IPC 调用不一定触发但边界模糊典型违规场景二进制分发不附源码、修改代码不公开、移除版权声明、闭源驱动与 GPL 内核联动检测手段源码扫描、二进制字符串扫描、动态依赖分析、SBOM 核对自动化能力可接入 CI按目录批量扫描输出 JSON/CSV 报告适合场景发布前合规审计、第三方库引入检查、供应链风险排查不适合场景直接替代法律意见自动扫描不能证明“已合规”从表格可以看出GPLv2 合规不是“有源码就行”而是“源码和二进制要对应”同时版权声明、书面要约都要留底。这也是很多争议的根源。2. GPLv2 许可条款核心解析在写检测命令之前先把 GPLv2 文本里最容易被误解的几条过一遍。下面内容基于 GPLv2 公开文本具体条文名称以官方许可证为准。2.1 分发行为是触发条件GPLv2 的源代码开放义务是在“收到副本并分发副本”时触发的。如果代码只在你自己的服务器上运行没有对外分发那么 GPLv2 的“提供源码”义务通常不会立刻触发。这一点经常被误读成“用了 GPL 就必须开源”。多数互联网公司的产品属于“SaaS 场景”也就是服务端运行不发生二进制分发所以 GPLv2 的源码提供义务确实不一定被触发。但如果你的产品是手机固件、路由器镜像、SDK、嵌入式设备、硬件出厂镜像那么每一次向客户或公众分发一个包含 GPLv2 代码的二进制就要注意配套源码义务。2.2 必须提供对应源代码GPLv2 说得很直接无论以目标码还是可执行形式分发都必须向收件人提供对应的、可读的源码副本或者至少提供一份有效期不少于三年的“书面要约”。这里的关键词是“对应”。很多项目把源码包丢到一个网站上就认为合规了但源码版本必须和二进制版本保持一致同时要能通过源码和构建脚本重现出那个二进制。版本对不上仍然会被认为不合规。2.3 派生作品与聚合作品的边界GPLv2 对“基于本程序的作品”要求继续以 GPL 授权。但独立且非派生的作品如果和 GPL 程序一起分发给用户不要求也不应该用 GPL 覆盖。实际工程里边界在哪里很不确定。常见判断对 GPL 源码进行修改再发布修改版几乎必然触发 GPL。程序动态加载 GPL 库当前司法实践中一般倾向视为派生作品但也有争议。独立程序通过命令行调用 GPL 程序交换数据通常不算派生。争议性最强的往往是内核模块。Linux 内核是 GPLv2如果闭源驱动通过 /proc、/sys、内核导出符号等接口与内核深度耦合它到底算不算“派生作品”这正是很多针对 Android 设备厂商投诉的技术背景。2.4 自动终止条款GPLv2 第 4 条类似“违约即终止”。只要你在分发副本时违反 GPLv2你对许可证的授权就自动终止。也就是说侵权者不再拥有复制、修改、再分发该 GPLv2 程序的许可除非重新获得版权方授权。这也是为什么“明确违反 GPLv2”是非常严重的指控。一旦被认定不仅是补一份源码的问题而是后续所有基于该代码的复制和分发都可能失去合法前提。2.5 专利保护与 GPLv3 的差异GPLv2 比 GPLv3 少了很多针对“专利授权”和“反 Tivoization”的专门条款但 GPLv2 第 7 条仍然处理了专利导致的附加限制问题如果分发者在某国被指控其发布的程序侵犯了特定专利导致该程序无法自由再分发版权方可以自动延展 GPL 条款以外的商业授权。GPLv3 和 GPLv2 最大的区别在于GPLv3 更明确地规定了“不允许用专利协议阻止用户自由使用”并且增加了关于防锁定、兼容 Apache License 2.0 等条款。很多现代项目选择 GPLv2 原因之一是它更短、更稳定而执法争论也更集中在“源码是否提供”上。3. Google “违反 GPLv2”争议点拆解标题里点名了 Google但真正的技术争议并不只在某一家公司。把它当成一个案例来拆通常绕不开下面四个场景。下面只做技术分析不构成法律结论。3.1 Android 内核与闭源驱动Android 设备的核心是 Linux 内核而 Linux 内核采用 GPLv2 授权。Google 作为 Android 生态的主导方会发布 Android 开源项目AOSP也会为 Pixel 等设备提供内核源码。设备厂商拿到内核源码后通常还需要闭源的显卡、Wi-Fi、基带驱动这些驱动以内核模块形式存在。问题在于如果闭源模块加载进 GPLv2 内核并且调用了内核导出的 GPL 符号那么它是“独立程序”还是“内核的派生作品”业界一直有两种看法。从合规审计角度看只要设备固件里包含了“Linux 内核 闭源模块”的组合就要逐一定位内核模块的二进制再检查对应的源码和构建说明是否存在。如果厂商只给了内核源码但闭源模块没有对应源码这就会成为“clear violation”的争议点。3.2 二进制分发与源码包版本不对应另一个常见争议是源码和二进制“版本漂移”。Google 发布工厂镜像时有时会同步提供内核源码 tag但设备厂商自己为某个型号生成的内核二进制改动可能没有回传到源码仓库。用户拿到的设备里运行的内核版本和公开 kernel 仓库里的提交并不能一一对应。要验证这种问题不能只看源码仓库有没有代码而要把设备里的/proc/version、编译指纹、uname -a与源码仓库中的提交哈希进行比对。如果设备上的磁盘unextracted无法完整匹配到源码里已知构建产物就可能被认定为“没有提供对应源码”。3.3 聚合与派生程序之间的扫描盲区Google 有很多产品是中间件层面的二进制比如 Bionic 库、libutils、libbinder。有些库是 Apache 2.0 或 BSD 的有些模块则可能包含来自 GPLv2 项目的代码片段。聚合分发时如果只是把 GPLv2 程序和非 GPL 程序放在同一个文件系统里通常不会有太大问题但如果有静态链接、符号引用、代码复制就构成派生作品。自动化扫描经常把这些情况混在一起导致误报或者漏报。正确做法是把“同目录分发”和“链接引用”分开对链接引用做更严格的判断。3.4 版权声明和书面要约GPLv2 第 2 条要求所有副本都保留版权声明和免责声明。很多项目在发布二进制时会把这些信息写在单独的copyright文件里或者放在strings输出里。合规审查时最容易被忽略的是“书面要约”的有效期。如果你的项目通过官网页面提供源码下载地址但没有写明这个要约至少保持三年有效就可能被质疑。把这一项加到检测清单里是为了避免“有源码下载页但没满足要约形式”的低级风险。真正的合规不只是“能给源码”还包括“在分发物里告诉收件人怎么要源码”。4. 环境准备与前置条件现在进入可执行部分。下面给出一套通用检测环境系统以 Debian/Ubuntu 系 Linux 为例。如果你想检查 Android 分区的二进制可以先把固件解包到目录再执行同样的扫描。4.1 操作系统和基础工具建议准备一台至少 4 核 CPU、8GB 内存的 Linux 机器。扫描大型固件目录时磁盘占用会迅速增大建议保留至少 50GB 可用空间并单独准备一个输出目录。sudo apt update sudo apt install -y build-essential binutils file unzip tree python3 python3-pip curl gitbuild-essential用于编译示例 GPL 程序binutils里的readelf、strings用于分析二进制file用于识别文件类型。Python 环境用来跑批量扫描脚本。4.2 安装许可证扫描工具这里介绍两个不依赖商业平台的工具scancode-toolkit扫描源码目录识别许可证声明。license-checker适合 Node.js 项目的依赖许可证检查。安装scancode-toolkit推荐用 Python 虚拟环境python3 -m venv /opt/scancode-venv /opt/scancode-venv/bin/pip install scancode-toolkit ln -s /opt/scancode-venv/bin/scancode /usr/local/bin/scancode安装license-checker需要 Node.jssudo apt install -y nodejs npm npm install -g license-checker如果只是临时检查一个二进制也可以不用安装扫描工具只靠系统的strings和readelf完成第一步。4.3 准备测试样例为了验证整套流程我建议你准备两个样例一个小型 GPLv2 程序比如hello-gpl.c编译成二进制。一个不含 GPL 的普通程序编译成二进制作为对照。先写一个带 GPL 声明的 C 文件/* hello-gpl.c * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2. */ #include stdio.h int main(void) { printf(hello gpl\n); return 0; }编译gcc -o hello-gpl hello-gpl.c再用同样的方法编译一个不写任何许可证声明的普通程序/* hello-plain.c */ #include stdio.h int main(void) { printf(hello plain\n); return 0; }gcc -o hello-plain hello-plain.c这样就有了两个可执行文件一个是明确 GPLv2 源码编译来的一个没有任何许可证声明。接下来所有检测逻辑都可以先在这两个文件上验证。5. 功能测试与效果验证检测二进制是否违反 GPLv2现在开始做实际验证。下面每个步骤都能独立运行你也可以直接用这些命令检查自己项目里的二进制。5.1 用 strings 检查版权声明和 GPL 标识GPLv2 要求在二进制中保留版权声明但版权声明不一定出现在二进制文件的可见字符串里。先看两个文件的差异strings hello-gpl | grep -i GNU strings hello-plain | grep -i GNU预期输出hello-gpl大概率会输出版权声明和 GPL 文本相关字符串。hello-plain如果没有链接系统库中的 GPL 字符串可能什么都不显示。注意很多二进制链接了glibc其中也可能包含 GPL 相关字符串。因此strings的结果只适合做初步筛选不能直接作为“是否 GPL”的唯一标准。5.2 用 readelf 检查动态依赖和符号引用如果某个程序通过动态链接依赖了一个 GPL 库那么它是否算派生作品需要通过符号引用进一步判断。先看依赖列表readelf -d hello-gpl | grep NEEDED readelf -d hello-plain | grep NEEDED再看符号表里是否引用了可疑的 GPL 库符号nm -D hello-gpl | grep -i my_gpl_symbol如果你的项目里有一个闭源可执行文件却动态依赖了/usr/lib/libfoo.so而libfoo.so来自一个 GPLv2 项目那么你就需要判断该可执行文件是否与 libfoo 存在“紧密集成”。通常建议把这类依赖列进合规清单。5.3 用 file 确定二进制类型确认文件架构和打包格式避免扫描到文本文件或压缩包就停止file hello-gpl file hello-plain输出类似hello-gpl: ELF 64-bit LSB executable, x86-64, dynamically linked, ...如果是固件目录file还能帮你识别固件镜像、文件系统、内核 Image 等结构方便后续针对vmlinux、*.ko、.so做细化检查。5.4 检查源码包与二进制是否对应这一步是 GPLv2 合规里最核心的验证给定一个二进制你必须能找到“能够重新生成该二进制”的源码和构建脚本。通用做法是记录二进制的哈希。记录源码仓库的 commit 号。使用相同环境变量、编译选项重新编译。比较新生成二进制的哈希或至少比较.comment段中的编译器信息。sha256sum hello-gpl在源码目录里重新编译后再次计算哈希如果哈希不一致要检查是否因为构建时间戳、路径、随机生成符号导致差异。很多项目会使用SOURCE_DATE_EPOCH实现可重现构建。5.5 扫描整个目录的许可证声明当二进制变成数千个文件时可以用scancode做批量扫描scancode --license --copyright --json-pp scan-result.json /path/to/your/distribution执行完成后查看scan-result.json里出现GPL-2.0-only或GPL-2.0-or-later的文件路径和版权声明再逐项确认源码包是否存在。如果被扫描的是 Node.js 项目可以用license-checkercd /path/to/node/project license-checker --json --production --out license-output.json它会读取package.json里的依赖信息输出每个依赖的许可证类型。这个工具适合做模块级检查但无法替代二进制层面的源码对应检查。5.6 验证结果判断表检测项判断标准通过二进制含有 GPL 版权声明strings能找到 GPL 声明正常保留声明是被要求的动态依赖 GPL 库readelf -d显示 NEEDED需进一步分析不直接等于违规源码仓库存在仓库里能找到项目名和 tag只是必要条件源码版本与二进制匹配构建后哈希一致或高度近似核心标准书面要约分发物中包含源码获取方式书面要约需保留三年版权声明保留二进制和源码中均保留必须闭源模块与 GPL 内核联动lsmod和导出符号检查高风险项需逐案分析6. 接口 API 与批量合规检测手动检查适合一两个二进制如果你负责一个持续交付的软件平台就需要把合规检查做成自动化和批量化。下面给出一套通用设计。6.1 批量扫描脚本先写一个 Python 脚本对给定目录里的所有 ELF 文件执行strings和readelf把可疑文件输出成 CSV#!/usr/bin/env python3 import os import subprocess import csv import sys def is_elf(path): try: with open(path, rb) as f: return f.read(4) b\x7fELF except Exception: return False def scan_dir(root_dir): results [] for dirpath, _, filenames in os.walk(root_dir): for name in filenames: full_path os.path.join(dirpath, name) if not is_elf(full_path): continue output subprocess.run( [strings, full_path], capture_outputTrue, textTrue, timeout60, ).stdout if GPL in output or General Public License in output: results.append((full_path, GPL string found)) return results if __name__ __main__: root sys.argv[1] csv_path sys.argv[2] rows scan_dir(root) with open(csv_path, w, newline) as f: writer csv.writer(f) writer.writerow([path, reason]) writer.writerows(rows) print(ffound {len(rows)} files, report written to {csv_path})运行方式python3 scan_elf.py /path/to/distribution report.csv这个脚本只是最简单的一层。生产环境建议加入文件哈希、elf 类型、链接库列表等字段。6.2 做成 HTTP 接口如果团队不希望在每台机器上安装工具可以封装一个最小 Web 服务接受待扫描目录返回 JSON 报告。下面是一个 FastAPI 示例需要先安装pip install fastapi uvicorn python-multipartfrom fastapi import FastAPI, UploadFile, File import tempfile, os, zipfile from scan_elf import scan_dir app FastAPI() app.post(/scan) async def upload_and_scan(file: UploadFile File(...)): with tempfile.TemporaryDirectory() as tmpdir: zip_path os.path.join(tmpdir, upload.zip) with open(zip_path, wb) as f: f.write(await file.read()) extract_path os.path.join(tmpdir, extract) os.makedirs(extract_path, exist_okTrue) with zipfile.ZipFile(zip_path, r) as zf: zf.extractall(extract_path) rows scan_dir(extract_path) return {count: len(rows), reports: rows}启动接口uvicorn api:app --host 127.0.0.1 --port 8000请求时用 curl 上传 zip 包curl -F fileyour_package.zip http://127.0.0.1:8000/scan这个接口适合在发布流水线里用但要注意扫描结果只能定位“出现 GPL 字符串”的文件不能自动证明项目违反 GPL更不能证明合规。6.3 集成到 CI在 GitHub Actions 里增加一个合规扫描 job让每次发版前自动跑一遍。下面是一个 YAML 示例name: compliance-scan on: push: tags: - v* jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Setup Python uses: actions/setup-pythonv5 with: python-version: 3.11 - name: Install scancode run: | pip install scancode-toolkit - name: Run license scan run: | scancode --license --copyright --json-pp scan-result.json . - name: Upload report uses: actions/upload-artifactv4 with: name: license-scan-report path: scan-result.jsonCI 扫描的意义在于“兜底”至少保证发版时有一份扫描报告。真正的人工审计仍然需要人在发布前处理高优先级项。7. 资源占用与性能观察批量许可证扫描并不是轻量操作。如果被扫描的是一个包含 Android 系统镜像的解包目录文件数量很容易达到几万甚至几十万这时要关注资源占用。7.1 显存与内存许可证扫描主要吃 CPU、内存和磁盘不吃显存。如果你的电脑有 GPU扫描过程不会用到 CUDA。因此不要用“显存占用”来衡量许可证扫描而是观察CPU 平均负载内存占用磁盘 IO临时文件大小7.2 扫描过程中的资源观察可以用htop或nvidia-smi查看系统负载。对于纯 CPU 扫描htop如果内存压力大可以限制 Python 进程并发数。scancode自带--processes参数新版有的版本是-n可以控制并行度scancode --license --copyright --json-pp scan-result.json --processes 4 /path/to/distribution7.3 大目录扫描时间扫描时间取决于文件总数、文件大小、是否启用--copyright以及磁盘速度。稳妥的做法是先在一个子目录做小规模测试比如扫描 1000 个小文件再推算全量扫描时间。不要一开始就直接扫整个镜像否则日志会非常难排查。7.4 降低资源占用的小技巧先用find排除非二进制文件比如.git、图片、视频。不启用所有检测项只启用--license时速度更快。分模块扫描例如先扫/system/bin再扫/vendor/lib。结果输出到单独磁盘避免和目标目录共用 IO。find /path/to/distribution -type f \ ! -path */.git/* \ ! -name *.png \ ! -name *.jpg \ ! -name *.mp4 \ filelist.txt然后让扫描工具优先读取文件列表可以提高效率。8. 常见问题与排查方法下面整理一份实战排查表。遇到“扫描不到 GPL 字符串”不代表绝对安全遇到“扫描到 GPL”也不代表一定违规关键是判断“是否构成派生作品以及是否提供对应源码”。问题现象可能原因排查方式解决方案strings找不到 GPL 声明编译器把字符串放在不可见区域或版权声明被移除使用readelf -p .comment、objdump -s -j .rodata保留可见版权声明更新构建配置扫描报告大量出现 GPL-2.0源码目录里有第三方库和文档打开 JSON 报告按路径区分针对第三方库单独维护许可证清单二进制动态依赖 GPL 库闭源程序调用了 GPL 库readelf -d file查看 NEEDED联系法务评估是否构成派生作品源码包存在但版本对不上构建脚本未固定 commit 或 tag对比二进制构建时间与 git 提交时间为每个发布版本记录源码 commit 和构建参数用自动扫描判断“未违反”自动扫描只能证明“没有找到特征”人工审计派生判断引入代码归属分析和 SBOM固件里有闭源.ko模块但内核是 GPLv2可能涉及派生作品争议modinfo xxx.ko查看 license 字段记录模块 license 字段制定风险说明书面要约缺失只在网站上提供源码没有在分发物里声明检查二进制目录下有没有COPYING或offer.txt在压缩包内增加源码获取说明API 扫描接口超时上传 zip 太大扫描耗时过长调整接口超时改用异步任务队列拆包后分批扫描返回任务 ID误报太多扫描到/usr/share/doc下的许可证文件在文件列表里排除COPYING*、LICENSE*对许可证文件做“归纳计数”而不是逐文件判断多个项目共用同一台构建机环境依赖污染二进制不可重现保存构建环境 Dokerfile/镜像使用可重现构建脚本固定工具链版本9. 最佳实践与合规整改建议无论你是项目维护者还是负责集成第三方组件的开发负责人下面这些建议都可以直接落到流程里。9.1 先做“最小可运行配置”合规审查最容易犯的错误是一上来就扫描整个代码仓库。建议先准备一个最小可运行配置一个编译产物、一份源码包、一个构建脚本、一个许可证清单。在这个小配置上验证合规流程跑通了再放大。9.2 每次发布都生成 SBOM用 SPDX 格式或 CycloneDX 格式记录下每个二进制组件、版本、来源和许可证信息。有了 SBOM至少能回答“这个二进制用了哪些许可证”这个问题。生成 SBOM 的通用方式之一scancode --spdx-tv spdx.spdx /path/to/your/distribution如果团队没有专门工具也可以用dpkg在 Debian 系系统里生成已安装包的清单但这对自研二进制帮助有限。9.3 源码和二进制建立对应关系建议在每个二进制旁边放一个source-info.txt记录源码仓库地址git commit hash构建命令编译器版本构建时间戳二进制 SHA256这样审计方不需要先从固件里猜“用的什么版本”可以直接定位到源码。这也是证明合规最有力的材料。9.4 对高风险动态链接单独审查在工程实践中如果二进制动态链接了 GPLv2 库但不能确定是否属于“聚合”还是“派生”最稳妥的做法是保留该库对应的源码包。在发布清单里明确写出libfoo.so来源于哪个 GPLv2 项目源码地址是什么。不要试图通过“运行时才加载”来回避义务因为很多地区法律对动态链接的态度并不统一。9.5 避免“内部使用”陷阱有一种常见误判只要二进制的使用者是“内部人员”就认为不需要提供源码。但如果你把产品设备给了客户哪怕客户不是公众只要该分发属于“再分发出现场副本”就可能触发义务。越是嵌入式设备、行业终端越容易因为“内部测试机”而忽略这一点。9.6 版权声明不要清理很多自动化重构工具会删除注释导致 GPL 声明被移除。建议把版权声明写入构建插件或版本控制 hook禁止删除以下内容原始版权声明免责声明GPLv2 许可证全文引用修改版本的作者身份说明如果项目允许也可以使用 SPDX 头来标准化// SPDX-License-Identifier: GPL-2.0-only9.7 考虑“书面要约”模板如果你分发 GPLv2 二进制但不想把源码直接打包进每一个压缩包可以提供一个书面要约模板。需要注意要约必须明确、可达并且自首次分发起至少有效期三年。下面是个参考写法This product contains software licensed under the GNU General Public License v2. The complete corresponding source code is available at: https://example.com/source/?packageyourappversion1.0.0 This offer is valid for at least three years.这段内容应该随二进制分发不能只在官网上出现。9.8 自动扫描与人工审计结合自动扫描的价值是高效率覆盖“已知许可证文本”但它不能回答“这个模块是否被修改过”“这个链接是否为派生”。因此建议发布门禁采用两级一级扫描失败则禁止发布。二级人工审计扫描到的高风险项由工程师和法务共同确认。你可以在发布流水线里加一个“人工确认”状态未经确认不能上传到生产仓库。10. 总结与下一步“Google is in clear violation of the GPLv2”这个标题值不值得关注值得。但更值得的是我们从中看到一套通用的 GPLv2 合规验证方法从许可证条款出发对二进制做字符串扫描和动态依赖分析再通过源码对应、版权声明、书面要约三个维度判断是否履行了义务。如果你负责的项目需要对外发布二进制第一件可以做的事是把你发出去的某个二进制放到strings、readelf和sha256sum下面跑一遍。先搞清楚它到底依赖了什么许可证再决定源码包和构建脚本要不要补。最容易踩的坑有两个一是只扫描源码目录而不扫描最终二进制二是只保留“能下载源码”的页面却没有把书面要约写进分发物。这两点都很容易出现也最容易在审计中被质疑。后续可以继续扩展的方向包括把 SPDX/SBOM 接入 CI、对固件镜像做自动解包扫描、建立第三方依赖许可证白名单、在编译阶段加入源码哈希生成插件。每一步都能让“是否违反 GPLv2”这件事从口号变成可验证的证据链。