Linux 驱动许可证合规要点
一 核心规则与内核符号访问
- 声明模块许可证：在内核模块源码中使用 MODULE_LICENSE(“GPL”) / “GPL v2” / “Dual BSD/GPL” / “Dual MIT/GPL” / “Dual MPL/GPL” 等标识。未声明或声明为 “Proprietary” 会使内核被标记为 tainted（被污染），社区通常不再提供支持。只有 GPL 兼容 的许可证才能访问通过 EXPORT_SYMBOL_GPL() 导出的符号；使用 EXPORT_SYMBOL() 导出的符号对“任何模块”可见。内核社区对专有内核模块长期持否定态度，提交到主线的基本前提也是 GPL 许可。以上机制直接决定了驱动能否调用核心内核服务与接口。
二 提交到主线内核的许可要求
- 许可与版权：提交到 Linux 内核源码树的驱动代码必须采用 GPL 许可（可与其它许可证“共存发布”，如 Dual BSD/GPL 等），且需确保 版权所有者同意以 GPL 许可。这是驱动被主线接受的硬性条件之一。
- 合规实践：在源文件显式添加 MODULE_LICENSE；避免使用专有或未声明许可的代码片段；若与第三方代码共用，确保整体发布仍满足 GPL 兼容 要求。
三 用户空间驱动与接口选择
- 倾向用户态实现：若希望保持专有性，可将驱动的主要逻辑放在 用户空间，通过 ioctl / sysfs / netlink / configfs 等现有稳定接口与内核交互。内核社区更偏好“使用现有接口、行为与其他同类驱动相似”的实现，不鼓励为驱动单独发明新接口。
- 关于“通用驱动接口”：若目标是同时支持 Linux 与 Windows，应在 用户空间 实现通用接口，而非在内核中新增通用内核接口。
四 常见合规风险与规避
- 未声明许可证的后果：加载模块时出现 “module license ‘unspecified’ taints kernel” 警告，内核被标记为 tainted，影响问题定位与社区支持。应在模块源码中加入正确的 MODULE_LICENSE 宏。
- 专有模块的限制：专有或未声明许可的模块无法使用 EXPORT_SYMBOL_GPL 导出的符号，功能会受限；且因内核被 tainted，社区支持意愿显著降低。
- 版本兼容与声明：注意 GPLv2 与 GPLv3 不兼容；若希望与更高版本兼容，发布时应使用 “GPL v2 or later” 等表述，避免后续组合时出现合规障碍。
五 快速检查清单
- 在模块源码中加入并核对：MODULE_LICENSE(“GPL” 或 “GPL v2” 或合适的 Dual 形式)。
- 仅调用与你许可证匹配的接口：需要 GPL 兼容才能用 EXPORT_SYMBOL_GPL；避免使用仅 GPL 可见的符号路径。
- 若需闭源：将策略/算法放在 用户空间，通过现有 ioctl/sysfs/netlink 等接口与内核交互，减少内核暴露面与合规风险。
- 准备进入主线：确保 版权同意 且整体发布满足 GPL 兼容；遵循代码风格、可移植性与电源管理等要求。
注意：以上为一般性的开源合规信息，不构成法律意见。涉及具体产品发布、合规审计与法律争议，请咨询专业律师或合规专家。