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的违规行为，至少在精神上是这样。

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

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

*以上是我的意见*

使用GPL的非GPL内核模块

5 个答案: