【Linux内核模块】使用模块绕开“GPL“

在 Linux 内核模块开发中，GPL 许可证就像一道绕不开的红线。不少开发者好奇：有没有办法让模块不遵循 GPL？如何绕开许可证限制？今天咱们不聊歪门邪道，而是从许可证本质、内核机制和法律风险三个维度，聊聊模块与 GPL 的正确相处方式 —— 毕竟，合规使用比耍小聪明更能长久。​

一、先搞懂：GPL 到底对内核模块说了啥？​

1.1 GPL 的核心要求：共享 alike

GPL（GNU 通用公共许可证）的核心原则是「Copyleft」（著佐权）：基于 GPL 作品衍生的作品，必须以相同许可证发布。这和 BSD 等宽松许可证不同，后者允许闭源商用。​

具体到 Linux 内核（采用 GPLv2），如果你的模块满足以下任一条件，就必须遵循 GPLv2：​

• 直接链接了内核中用EXPORT_SYMBOL_GPL导出的符号（函数 / 变量）​
• 模块功能被认定为内核的衍生作品（法律上的判断）​
• 模块与内核结合紧密，形成一个不可分割的整体​

1.2 内核符号的双重出口机制​

Linux 内核通过两种方式导出符号，直接影响模块的许可证选择：​

• EXPORT_SYMBOL：无许可证限制，任何模块（包括闭源）都能使用​
• EXPORT_SYMBOL_GPL：仅允许 GPL 兼容许可证的模块使用（约占内核符号的 70%）​

打个比方：​

• EXPORT_SYMBOL像公共公园，谁都能进​
• EXPORT_SYMBOL_GPL像会员制俱乐部，只有持 GPL会员卡才能进​

1.3 模块是否算衍生作品的争议​

法律上对内核模块是否属于衍生作品存在争议：​

• 内核社区观点：多数核心开发者认为，功能复杂的模块（如文件系统、驱动框架）属于衍生作品，必须开源​
• 部分厂商实践：简单的硬件驱动常以闭源形式发布（如 NVIDIA 显卡驱动）​
• 法律边界模糊：至今没有统一的司法判决，不同地区可能有不同解读​

但有一点明确：使用EXPORT_SYMBOL_GPL符号的模块，必须开源（GPLv2 强制要求）。​

二、所谓绕开 GPL的方法：看似可行，实则埋雷​

网上流传一些绕开 GPL的技巧，但大多存在法律风险或功能限制，咱们逐一分析。​

2.1 只使用EXPORT_SYMBOL导出的符号​

这是最合规的闭源方式 —— 仅调用EXPORT_SYMBOL导出的符号，不碰EXPORT_SYMBOL_GPL的符号。​

可行吗？ 技术上可行，但有严重限制：​

• 可用符号少：EXPORT_SYMBOL导出的多是基础功能（如内存分配），高级功能（如网络协议栈、文件系统接口）多是 GPL-only​
• 硬件支持受限：现代硬件驱动常需要调用 GPL 符号（如 DMA 映射、中断处理）​
• 实例：简单的 LED 驱动可能只用基础符号，但 WiFi 驱动几乎必然依赖 GPL 符号​

风险：即使只使用非 GPL 符号，仍可能被认定为衍生作品（法律风险）。​

2.2 用包装层间接调用 GPL 符号​

有人想出中间层方案：​

1. 写一个 GPL 许可证的包装模块，调用 GPL 符号​
2. 闭源模块通过某种方式（如共享内存）与包装模块通信​

可行吗？ 技术上能实现，但：​

• 违反 GPL 精神：GPLv2 第 2 条规定，修改作品整体必须以 GPL 发布，这种绕开方式被社区视为规避条款
• 性能损失：跨模块通信比直接调用慢 10-100 倍，不适合高性能场景​
• 实例：早年某些闭源驱动用此方法，但后来多数厂商放弃（性能太差）​

风险：法律上可能被认定为规避许可证，面临诉讼（已有先例）。​

2.3 动态生成代码调用 GPL 符号​

更极端的方法：闭源模块在运行时动态生成代码片段，间接调用 GPL 符号（避免编译时依赖）。​

可行吗？ 几乎不可行：​

• 技术复杂：动态代码生成需处理内存保护、指令对齐等问题​
• 极不稳定：内核会检测异常内存访问，可能直接 Oops​
• 明显规避许可证：法律上属于故意绕过，风险极高​

典型案例：早年 MPlayer 尝试动态调用 GPL 符号，被内核社区强烈反对后放弃。​

2.4 二进制 blob与用户态助手​

还有两种变种方案：​

• 二进制 blob：将闭源代码打包成二进制固件，内核模块仅负责加载（如某些网卡驱动）​
• 用户态助手：核心逻辑放用户态程序，模块仅做简单转发（如通过 netlink 通信）​

问题：​

• 二进制 blob 通常只允许用于固件（硬件必需的代码），不能包含驱动逻辑​
• 用户态助手会导致性能损失，且无法处理内核态特有的操作（如中断响应）​

三、为什么不建议绕开 GPL？风险远大于收益​

3.1 法律风险：可能面临诉讼​

• 历史案例：2003 年 SCO 起诉 IBM，声称 Linux 内核包含 SCO 专利（虽然后来 SCO 败诉，但耗时数年）​
• 社区态度：内核社区有专门团队（如 Software Freedom Conservancy）监督 GPL 合规，可能发起维权​
• 企业代价：诉讼可能导致产品禁售、品牌受损（尤其欧美市场）​

3.2 功能限制：闭源模块问题多​

• 无法升级内核：新内核版本可能改变符号接口，闭源模块常因不兼容无法使用​
• 稳定性差：闭源模块崩溃时难以调试，可能导致整个系统死机​
• 安全隐患：漏洞无法及时修复（无开源社区审计）​

3.3 社区排斥：失去开源生态支持​

• 闭源模块作者无法参与内核开发讨论​
• 问题反馈被忽视（内核开发者优先支持开源驱动）​
• 难以享受社区迭代红利（新功能、性能优化）​

四、合规方案：既能满足需求，又不踩红线​

如果确实需要发布闭源模块，或必须使用 GPL 符号，有几种合规方案可供选择。​

4.1 完全开源：最推荐的方式​

将模块以 GPLv2 许可证开源，享受：​

• 无限制使用所有内核符号​
• 社区反馈和漏洞修复​
• 与内核版本同步升级（减少兼容性问题）​

适合场景：通用驱动、功能模块、开发者工具。​

4.2 双许可证策略​

模块同时提供 GPL 和商业许可证：​

• 开源用户：免费使用 GPL 版本​
• 商业用户：付费获取闭源授权（需确保不依赖 GPL-only 符号）​

成功案例：Qt 库（应用程序领域，内核模块较少见）。​

4.3 硬件抽象层（HAL）方案​

将模块分为两部分：​

• 开源层：调用 GPL 符号，实现基础功能​
• 闭源层：仅与开源层通信，包含核心算法（需通过合理的抽象接口）​

关键：两层之间的接口必须足够通用（如标准 IOCTL），不能是为规避 GPL 设计的「假抽象」。​

4.4 利用 GPL 例外条款​

内核有少量 GPL 例外场景：​

• 系统调用接口：通过syscall与用户态通信的程序，即使调用内核功能也无需开源​
• 固件加载：纯硬件固件（如 BIOS、FPGA 配置）可闭源（内核firmware_class支持）​

注意：这些例外有严格限制，不可滥用。​

五、普通开发者该怎么做？遵循这 3 条原则​

5.1 优先开源：利人利己​

• 个人开发者：发布 GPL 模块，加入开源社区（如 GitHub、内核邮件列表）​
• 企业开发者：评估开源收益（节省维护成本、社区贡献），多数情况利大于弊​

5.2 明确依赖：避免无意违规​

开发时检查模块依赖的符号类型：

# 查看模块使用的符号及许可证要求
nm my_module.ko | grep ' U ' | while read a b c; do
  grep $c /proc/kallsyms | grep -i gpl
done

如果输出包含符号，说明模块使用了 GPL-only 符号，必须开源。​

5.3 谨慎闭源：评估法律风险​

• 简单硬件驱动（如 LED、按钮）：闭源风险较低（但仍有争议）​
• 复杂功能模块（如文件系统、网络过滤）：强烈建议开源​
• 商业产品：咨询专业律师，避免大规模部署闭源模块​

Linux 内核能成为全球最成功的开源项目之一，GPL 许可证功不可没 —— 它确保了内核的开放性和兼容性，让无数开发者能自由贡献代码。​

对于模块开发者：​

• 个人学习：无需纠结许可证，大胆使用 GPL 符号（反正开源）​
• 商业产品：权衡闭源的短期收益与开源的长期价值​
• 法律底线：不碰EXPORT_SYMBOL_GPL符号的闭源模块风险较低，但功能受限；使用 GPL 符号的模块必须开源​

记住：真正的技术实力，不在于绕开规则，而在于在规则内做出优秀产品。开源生态的活力，正来自于对许可证的共同尊重。