使用GPL的非GPL内核模块

Question

我工作的公司正在开发一个闭源内核模块（.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头文件。

Answer 1

模块有 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

Answer 2

IANAL所以你真的应该寻求合格的法律意见。不过这个 方法肯定违背了许可证的精神 不会在核心土地上赢得任何朋友。

但是你可以考虑不同的分裂。一种方法是拥有 一个完全GPL模块，并将所有“秘密公司IP”放入用户 太空司机。这是我在公司工作时采用的方法 我并不热衷于向全世界公开FPGA的细节。一切 在用户空间和用户空间决定的决定和注册设置 驱动程序的内核端只是在IRQ上加载了值。小心翼翼 设计你可以管理你可能拥有的任何实时问题 封闭的驱动程序和内核之间的干净分离。一世 相信使用支持用户空间的新内核会更容易 驱动程序，虽然我不认为他们正确支持DMA（我不得不 代码用户空间DMA内核模块直接支持DMA 芯片组和用户空间）。

然而（再次）我真的建议你考虑一下它是什么 试图保护。封闭的驱动程序可能适用于嵌入式应用程 您可以严格控制内核版本和硬件。 但是如果这个驱动程序被考虑用于更通用的东西（即 卖硬件的人会插入自己的系统）然后关闭 源驱动程序只会被证明是持续疼痛的源头 维修头痛。

Answer 3

第一：你需要和律师谈谈这件事;可能是贵公司的法律部门。

第二：重要的问题是从哪个代码派生出来的代码片段。

不幸的是，这个问题几乎有很多答案。

有人会认为所有内核模块都是内核的派生工作，因此无论是否包含头文件都必须是GPL。

或者你的封闭模块来自GPL模块，而GPL模块来自内核，所以封闭模块也必须是GPL。

Answer 4

一些关键内核开发人员（但不是Linus本人）认为任何非GPL模块都违反了内核的许可证。

当一些开发人员从Linksys路由器上撕下Belkin驱动程序，对其进行反向设计并公布结果时，Belkin无法阻止他们，因为他们将这种许可证解释作为辩护方提交给法院。

Answer 5

无数其他驱动程序使用开源“填充程序”来使用开源内核桥接闭源目标文件。大多数内核开发人员认为这是GPL的违规行为，至少在精神上是这样。

在我看来，这取决于您是否分发软件。如果您纯粹在软件即服务上运行，则应该允许这样做。如果您要分发嵌入式设备或盒装产品，那就是禁忌。

从内核中移出您需要的任何功能，或者开源内核组件。这就是其他所有人（诚实）所做的事情，而且通常并不那么棘手，因为任何拥有大量内核空间“知识产权”的人，或者都有糟糕的商业模式或无能的工程团队。

*以上是我的意见*