我工作的公司正在开发一个闭源内核模块（.ko 文件）。 该模块必须调用 gpl2 模块中包含的函数。 基本上我们的情况是这样的：
// GPL 2 kernel module (gpl.c -> gpl.ko)
void a_function(void)
{
// ...
}
EXPORT_SYMBOL(a_function)
// Closed Source module (closed.c -> closed.ko)
a_function();
这合法吗？在这个例子中我们是否违反了 GPL2 许可？ 请注意，closed.c 不包含任何 gpl2 头文件。
【问题讨论】：
标签： licensing linux-kernel gpl
模块有 GPL_ONLY 标志，不应在非 GPL 模块中使用。所以如果你说的模块不是GPL_ONLY，你可以使用它。
但如果您通过user-space drivers, which are possible in 2.6.23 访问它们，即使是GPL_ONLY 也可以使用。这正是 USB 子系统发生的事情。 http://www.linux-magazine.com/online/news/linux_2_6_25_without_closed_source_usb_drivers
不完全解决法律问题，但给你一些想法： http://www.cyberciti.biz/tips/linus-rejects-the-idea-of-non-gpl-kernel-modules.html
【讨论】：
IANAL 所以你真的应该寻求合格的法律意见。然而这 这种做法肯定违背了许可证的精神，而且 在内核领域不会为你赢得任何朋友。
但是，您可以考虑不同的拆分。一种方法是拥有 一个完全 GPL 的模块，并将你所有的“秘密公司 IP”放在一个用户中 太空司机。这是我在我工作的公司时采取的方法 并不热衷于向世界公开我们 FPGA 的细节。一切 决定和寄存器设置在用户空间和 驱动程序的内核端只是在 IRQ 上加载了值。用心 设计您可以管理您可能遇到的任何实时问题并拥有 封闭的驱动程序和内核之间的良好分离。一世 相信使用支持用户空间的新内核会更容易 驱动程序虽然我认为他们还没有正确支持 DMA（我不得不 编写用户空间 DMA 内核模块以直接支持 DMA 芯片组和用户空间）。
但是（再次）我真的建议您考虑一下您的 试图保护。封闭的驱动程序可能适用于嵌入式应用程序 您可以严格控制内核版本和硬件。 但是，如果这个驱动程序被考虑用于更通用的东西（即 销售硬件的人将插入自己的系统）然后关闭 源驱动程序只会被证明是持续痛苦的根源，并且 维护头痛。
【讨论】：
1st：你需要和律师谈谈这件事；可能是您公司的法律部门。
第二个：重要的问题是哪一段代码是从哪一段代码衍生而来的。
不幸的是，这个问题几乎有任意数量的答案。
有些人会认为所有内核模块都是内核的派生作品，因此无论是否包含标头都必须是 GPL。
或者您的封闭模块派生自 GPL 模块，而 GPL 模块派生自内核，因此封闭模块也必须是 GPL。
【讨论】：
一些关键内核开发人员（但不是 Linus 本人）认为任何非 GPL 模块都违反了内核许可。
当一些开发人员从 Linksys 路由器中提取 Belkin 驱动程序，对其进行逆向工程并发布结果时，Belkin 无法阻止他们，因为将这种许可解释提交法庭作为辩护的反威胁。
【讨论】：
无数其他驱动程序使用开源“shim”将闭源目标文件与开源内核桥接。大多数内核开发人员认为这至少在精神上违反了 GPL。
在我看来，这取决于您是否分发软件。如果您纯粹在软件即服务上运行它，则应该允许这样做。如果您要分销嵌入式设备或盒装产品，那就不行了。
将您需要的任何功能移出内核，或开源您的内核组件。这就是其他人（老实说）所做的事情，而且通常并不那么棘手，因为任何拥有大量内核空间“知识产权”的人，要么拥有糟糕的商业模式，要么拥有不称职的工程团队。
*以上是我的看法*
【讨论】：