先聊一个现象开源社区里当你看到“××× is in clear violation of the GPLv2”这种标题时第一反应往往不是激动而是好奇——它到底违反了哪一条是源码没公开还是许可证声明缺失还是衍生作品边界不清晰这篇文章不打算变成法庭辩论而会把它当作一个切入 GPLv2 合规体系的技术案例来拆解。我们会从 GPLv2 的核心义务开始讲到 Linux 内核、内核模块与衍生作品的关系再延伸到 Android 生态里那个长期存在的争议最后给出一套企业可落地的合规自查流程。无论你是内核开发者、Android 系统工程师还是只是在自己的项目里引用了开源代码这部分知识都值得收藏。1. 什么是 GPLv2一次讲清核心义务1.1 GPLv2 到底是什么GPLv2 的全称是 GNU General Public License version 2由自由软件基金会FSF于 1991 年发布。它是一份 copyleft 许可证核心思想是允许你自由使用、修改、分发代码但如果你把代码或基于它修改的作品分发出去就必须把修改后的源码也按 GPLv2 授权给接收方。这句话听起来简单真正落地时会衍生出很多问题比如我只要用了 GPL 代码就必须开源吗我写的程序和 GPL 代码之间是什么关系我把 GPL 代码跑在服务器上需要公开源码吗我的内核模块算不算 GPL 的衍生作品后两个问题尤其容易引起争论。先记住一个前提GPLv2 约束的是“分发”distribution / conveyance如果你只是内部使用、不对外分发GPLv2 一般不要求你公开源码。1.2 copyleft 机制为什么叫“传染性”很多人把 copyleft 理解为“传染”这是一种通俗但不够准确的说法。准确的描述是GPLv2 要求你在分发包含 GPL 代码的作品时必须以 GPLv2 作为整个集成作品的许可证。例如你把一段 GPLv2 的排序算法源码编译进自己的命令行工具然后把工具二进制发布给用户。这时你发布的是一个“基于 GPLv2 作品的衍生作品”整个工具就需要按 GPLv2 授权并且向用户提供完整、机器可读的源码。这里的“机器可读源码”不是说贴一个 GitHub 链接就够了而是必须让接收者能够通过该源码实际构建出你发布的那个二进制版本。这是一个很容易被忽略、也经常被合规审查找出来的点。1.3 GPLv2 三大核心义务用一句话概括 GPLv2 对分发者的要求保留许可声明副本必须保留原有版权声明、许可声明。提供完整源码如果以目标码/二进制形式分发必须同时提供完整、对应的机器可读源码。按相同许可授权修改后的作品整体必须继续按 GPLv2 授权且不得增加额外限制。同时还有一条容易被忽略的规则修改过的文件需要带有明显的变更说明记录修改日期和修改者。这些义务本身很清晰真正的争议往往集中在“你的程序是否构成 GPLv2 作品的衍生作品”这个界定问题上。Linux 内核模块就是最典型的例子。2. Linux 内核与 GPLv2为什么会牵扯到 Google2.1 Linux 内核的许可模式Linux 内核采用 GPLv2 作为主许可证用开发者社区的话说就是GPL-2.0-only。内核源码树中的大部分 C 代码都带有“GPL-2.0-only”或相关 SPDX 标识面向用户空间导出的 UAPI 头文件带有“GPL-2.0 WITH Linux-syscall-note”例外允许用户程序正常引用这些头文件。这种许可结构导致了两个结果内核主体代码必须按 GPLv2 分发。当第三方开发者向内核提交补丁时补丁默认也遵循 GPLv2 授权。因此如果你基于 Linux 内核做定制然后把这个定制内核分发到设备上你就必须按照 GPLv2 提供完整、对应的内核源码。这本来是没有任何争议的。2.2 Android 与 Linux 内核的关系Android 系统使用 Linux 内核作为底层内核这几乎是所有人都知道的事实。Google 在 Android 早期阶段对内核做了大量个性化修改包括 Binder IPC、Wakelock、Ashmem、Logger 等特性。从许可证角度看这些修改都是对 Linux 内核的修改。只要 Android 设备把编译出的内核镜像分发出去Google 和硬件厂商就面临 GPLv2 的源码提供义务。公开的长期争议点并不是“内核要不要开源”而是“通过内核模块或用户态进程实现的功能究竟算不算内核的衍生作品”。这部分我们放到第 3 章详细说。2.3 “违反 GPLv2”通常是哪种行为当一个项目被指责“违反 GPLv2”时常见的情况通常是以下三类之一违规类型具体表现源码不公开设备发行了内核镜像但下载不到对应源码或源码不完整、不能构建出镜像许可声明缺失二进制或源码中删除了 COPYING、版权声明、作者信息衍生作品未按 GPL 授权以模块、插件、shim 层形式绕开 GPL使原应成为 GPL 衍生作品的代码以专有许可证发布而“Google is in clear violation of the GPLv2”这种说法指向的往往就是第三类通过架构设计规避 GPL使原本应当遵循 copyleft 的代码变成闭源专有代码。3. 内核模块 vs 派生作品合规判断的关键3.1 内核模块的工作方式Linux 内核模块是运行在内核空间的独立二进制文件可以动态加载到内核中。常见模块包括文件系统驱动、网络协议、硬件驱动等。模块通过内核导出的符号EXPORT_SYMBOL调用内核函数并访问内核头文件中定义的数据结构。从技术上讲内核模块不是独立编译的普通用户态程序。它必须使用内核源码树中的头文件链接到内核导出的符号表匹配内核版本与配置linux/version.h、module.symvers等遵循内核模块加载规则init_module/cleanup_module或module_init/module_exit。正因为这种紧密结合开源界普遍认为设备驱动模块通常属于 Linux 内核的衍生作品因此应受 GPLv2 约束。3.2 衍生作品判定为什么困难法律上“衍生作品”的定义在不同法域有差异GPL 的条款也并未精确到“调用哪个函数就算衍生”。因此出现了一个灰色地带一个独立的驱动模块是否因为调用了内核导出函数就变成 GPL 作品Linux 社区的实际操作倾向和知名内核开发者尤其是文件系统和存储子系统维护者的观点是只要模块针对内核接口编写、以加载进内核的方式运行并且使用了内核符号和头文件就应当被视为 GPL 衍生作品。这不是因为内核开发者喜欢找茬而是因为内核本身是 GPL 作品模块被设计为与内核一起工作形成单个集成程序如果允许闭源代码加载进 GPL 内核等于变相允许“二进制封闭驱动”绕开 copyleft。3.3 两种常见的“绕着 GPL 走”的设计在实际工程中经常见到下面两类架构它们也是合规争议的高发区。第一种内核只留“shim 层”。厂商先把一个极小的内核模块放入内核这个模块只负责搬运数据不实现业务逻辑真正的驱动逻辑全部放在用户态通过/dev设备节点或 netlink 与内核传递数据。这样看起来用户态程序是独立于内核的普通应用从而回避“衍生作品”认定。这种架构在技术上可行但开源社区普遍持否定态度如果用户态程序实际上在承担设备驱动职责并且与内核 shim 有紧密耦合那么它很难被认为是独立作品。第二种动态加载闭源二进制模块。厂商编译一个.ko文件但不提供源码只在设备上动态加载。这种情况在 Android 生态中非常常见尤其是厂商定制 GPU、Wi-Fi、基带驱动时。对于这种做法GPLv2 合规审查通常关注三个问题该.ko是否基于内核源代码编写它是否使用了内核导出的 GPL 符号厂商分发设备时是否提供了对应的完整内核源码如果.ko与内核存在明显耦合却未按 GPL 提供源码就有较高合规风险。3.4 为什么二进制接口ABI也重要Android 生态里还有一个特别点Google 曾推动所谓稳定的内核 ABI让厂商可以预编译的内核模块在多个内核版本之间复用。这种设计对厂商运维很友好但会进一步拉开我提供的只是一块标准硬件固件与我的模块深度依赖 GPL 内核之间的距离。从 GPL 合规角度看稳定性本身不是问题问题在于模块开发者不能因为接口稳定就宣称自己不依赖内核、不构成衍生作品。合规判断要看的是是否使用了内核源码、符号、头文件以及耦合程度而不只是接口变化频率。4. 争议复盘公开讨论里到底发生了什么4.1 内核开发者为何公开质疑在 Linux 内核邮件列表和开发者峰会的公开讨论中曾有内核开发者针对 Android 的驱动/内核策略提出尖锐批评。标题中直接用到 “clear violation of the GPLv2” 这种表述正是来自这类技术讨论。这类声音的核心逻辑是Android 在内核之外实现了部分原本属于内核的功能或者在厂商驱动上采取闭源模块化策略导致 GPL 义务没有被充分履行。这不是一个孤立的“Google 问题”而是 Android 生态中广泛存在的合规问题的体现。需要说明的是这类指控更多是技术社区基于 GPL 条款的理解不意味着已经有司法判决认定 Google 违约。开源许可证纠纷的司法实践在不同司法辖区差异很大。因此更准确的说法是这是一场长期存在的、有技术依据的合规争议而不是一个已经被法院定性的结论。4.2 争议涉及的技术点综合公开讨论争议集中在这几个技术环节Android 内核树中包含部分 Google 维护的驱动和特性这些补丁长期没有完整合入上游 Linux 内核部分功能实现从内核态迁移到用户态形成“内核线程 用户守护进程”的分层架构设备厂商以预编译.ko形式分发大量专有驱动且不公开对应源码Android 的构建流程、内核版本分支多导致“对应源码”很难精确定位用户从设备上拿不到完整构建对应的内核源码。这些问题单独看似乎只是工程习惯组合起来就构成 GPL 合规审查最关注的模式。4.3 这件事给我们什么启示对外行来说这个争议是新闻对内核/系统工程师来说它是一堂公开课的案例。我们从中至少可以学到三点许可证问题不是法务专属而是架构问题。在系统设计阶段就要评估“我引入的组件是什么许可证”“我的代码和它是什么关系”。用户态与内核态的隔离可以降低耦合但无法自动规避 GPL。只要你的用户态程序在配合内核完成原本属于内核驱动的工作合规风险并不会因为隔离而消失。“提供源码”不是给个仓库地址而是要给出能构建出交付物的完整源码。这是企业最容易在实际审查中翻车的地方。5. 企业 GPLv2 合规清单从自查到整改如果你所在团队正在基于 Linux 内核做发行版、路由器固件、Android ROM或者在自己的产品里引入了 GPLv2 组件下面这套自查流程建议按顺序执行。5.1 静态自查扫描许可证第一步是盘清代码库里到底用了哪些开源组件、它们各自是什么许可证。只靠人工翻README不现实建议用自动化工具扫一遍。常见工具包括licensecheckPerl 脚本很多 Linux 发行版自带ScanCode ToolkitFOSSologyBlack Duck / WhiteSource商业工具下面是一个简单的扫描示例针对源码树找出疑似 GPLv2 的文件头声明# 在当前目录下递归扫描所有 .c/.h/.ko 文件打印前 8 行用于检查 LICENSE 标识 find . -type f \( -name *.c -o -name *.h -o -name *.ko \) -exec sh -c echo $1 head -n 8 $1 echo _ {} \;实际项目中建议直接用 ScanCode它能把每个文件的许可证路径、版权声明、匹配的许可证文本输出成 JSON 或 CSV# 安装 scancode-toolkit 后对源码目录生成合规报告 scancode --license --copyright --json-pp scancode-report.json ./src拿到报告后重点关注两类结果明确标记为 GPL-2.0-only / GPL-2.0-or-later 的文件无法识别许可证的文件这类文件需要人工确认。5.2 动态自查构建脚本与源码对应关系仅有文件扫描还不够你还需要确认“源码能否构建出你分发的二进制”。这是 GPLv2 合规最硬核的一条。推荐做法是在每次发版时保留完整的构建映像描述。# 记录当前源码版本和构建环境信息 git rev-parse HEAD BUILD_INFO.txt git diff --stat HEAD BUILD_INFO.txt echo build date: $(date -u) BUILD_INFO.txt md5sum out/target/product/*/boot.img BUILD_IMAGE_HASHES.txt把BUILD_INFO.txt和BUILD_IMAGE_HASHES.txt一并放入源码发布包。这样用户在拿到固件后可以根据版本号定位到对应源码再校验哈希确认源码与二进制确实对应。5.3 源码发布方案发布源码时不要只把 git 仓库地址放到页面上至少要提供一个可下载的源码归档。建议用以下命令生成# 以当前 tag 导出对应源码排除构建产物等无关文件 git archive --formattar.gz -o kernel-src-v1.0.tar.gz v1.0遇到有多个子仓库、未合入主仓库的补丁时统一用一个SOURCE_MANIFEST.md列出所有仓库地址、commit ID 和补丁路径。# 源码清单 - 主内核仓库gitgithub.com:your-project/kernel.gittag: v1.0 - 厂商驱动仓库gitgithub.com:vendor/drivers.gitcommit: abc123 - 发布时应用的补丁patches/0001-fix-usb.patch重点提醒如果产品里使用了厂商闭源二进制模块而它又被认定为 GPL 衍生作品那么仅提供内核主源码仍然不够。此时要么推动厂商公开模块源码要么更换方案否则合规风险会一直存在。5.4 常见违规场景与改正方法场景问题改正思路只提供内核源码不提供用户态监控进程源码用户态进程与内核 shim 耦合可能被认定为衍生作品审查耦合度必要时开源对应用户态代码源码包能解压但按文档构建不出镜像未满足“完整对应源码”要求用干净环境执行构建修正补丁和构建脚本.ko文件未附带源码也不在源码清单中闭源模块合规风险联系模块厂商提供源码或替换为 GPL 兼容驱动删除了内核 COPYING 文件违反保留许可声明义务恢复COPYING和文件头 SPDX 标识6. 常见问题与排查思路GPLv2 合规排查中最常见的问题集中在下面这些场景。这里整理成一张速查表问题现象常见原因解决思路扫描到 GPLv2 文件但没人知道它从哪来依赖传递引入未记录来源通过 git log、仓库元数据追踪来源建立 license 台账项目里用了MODULE_LICENSE(Proprietary)厂商默认设置实际仍依赖内核符号审查模块符号依赖联系厂商确认法律意见构建脚本依赖不公开的工具链源码不完整无法复现构建把工具链版本、Dockerfile、补丁纳入源码发布流程想用 GPL 库做商业软件又不想开源不理解 copyleft 边界评估替换许可证、改用用户态协议、或单独进程隔离分发了二进制固件但官网只放了个 GPL 链接没有提供完整源码包参照 5.3 节生成源码归档内核源码有多分支用户拿到乱套源码地址和二进制版本无法对应在固件中写入内核版本号并把版本号回填到发布页如果遇到的是“不知道某闭源模块会不会连累整个项目”建议按下面顺序排查找出该模块加载时链接了哪些内核符号nm module.ko | grep U 查看模块源码或反编译信息判断是否使用了内核头文件中的结构体评估模块是否只通过标准设备接口工作还是深度依赖内核内部接口保留排查记录提交给法务或开源合规负责人作进一步判断。# 查看内核模块依赖的未定义符号 nm vender_driver.ko | grep U 如果输出里有大量内核 GPL 导出符号说明该模块与内核耦合很深作为 GPL 衍生作品的风险较高。7. 最佳实践与工程建议7.1 许可证台账要从小做起很多公司都是到了产品要出海、客户要求合规审查时才临时梳理许可证。结果发现组件清单缺失、来源不明、补丁版本混乱整改成本远高于一开始就建立台账。建议在项目初始化时就维护一份THIRD_PARTY_LICENSES.md至少记录组件名称与版本许可证类型源码获取地址引入日期负责维护的团队是否修改过、修改了哪些文件。这份文件应该随代码评审一起更新而不是发布前补写。7.2 构建流程里加入合规检查把许可证扫描放进 CI 流水线效果远比年度检查好。以 GitLab CI 为例可以在流水线里增加一个任务compliance: stage: test script: - scancode --license --copyright --json-pp build/scancode-report.json src/ - python scripts/check_denylist.py build/scancode-report.json artifacts: paths: - build/scancode-report.jsoncheck_denylist.py里可以定义“禁止引入”的许可证列表或“需要人工确认”的列表一旦发现问题就让流水线失败强制开发人员处理。7.3 从架构上降低合规风险架构设计阶段优先考虑许可证宽松的组件。例如用户态通信、独立工具链、数据格式库尽量选择 MIT、BSD、Apache-2.0 等宽松许可组件对于需要深度定制系统能力、必须与内核紧密耦合的部分提前评估 GPL 义务。一个常见建议是驱动逻辑能放用户态就放用户态但这不是为了规避 GPL而是为了减少对内核内部接口的依赖。前者是合理性架构设计后者是明显规避行为。两者在合规判断上的差异非常大。7.4 保留证据及时寻求法律意见GPLv2 的最终解释权不在社区手里也不在本文手里而在于具体司法辖区的法律实践。企业做到位的是留存扫描报告、源码归档、构建记录对高风险模块形成书面评估在无法自行判断时请专业开源合规律师审核。不要等到收到侵权通知才开始收集证据。合规证据应该和代码版本同步产生。8. 总结与延伸学习回到标题那个问题“Google is in clear violation of the GPLv2”它真正值得关注的地方不在于对某家公司的判断而在于它把 GPLv2 的三个复杂问题推到了台前内核模块是不是 Linux 内核的衍生作品用户态 内核 shim 的架构能不能规避 copyleft提供“完整源码”到底要完整到什么程度这些问题没有一两句话的简单答案但每个内核开发者、Android 系统工程师、嵌入式设备厂商都应该理解背后的判断逻辑。如果你希望继续深入可以从这几个方向入手阅读 GPLv2 全文重点关注第 2 节、第 3 节阅读 Linux 内核源码树中的Documentation/process/license-rules.rst学习 SPDX 标识规范掌握如何给文件添加正确的许可证头用 ScanCode 实际扫描一个 Linux 内核源码包观察输出的许可证分布。开源合规不是一件“出事再补救”的事它应该像代码规范一样融入日常开发流程。如果这篇文章里的排查清单和最佳实践能帮你在项目中少踩一个坑那就是最有价值的收获了。收藏备用也欢迎在评论区聊聊你在内核驱动合规上踩过的坑。