使用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，那么您可以使用它。

但是，如果您通过 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

所以你真的应该寻求合格的法律意见。然而，这种方法肯定与许可证的精神背道而驰，并且不会在内核领域赢得任何朋友。

但是，您可以考虑不同的拆分方式。一种方法是拥有一个完全GPL的模块，并将所有“秘密公司IP”放在一个用户空间驱动程序中。当我工作的公司不热衷于将我们的FPGA的细节公之于众时，我采取了这种方法。所有的决定和寄存器设置都是在用户空间中决定的，而驱动程序的内核端只是在IRQ上加载值。通过仔细的设计，你可以管理你可能遇到的任何实时问题，并在你封闭的驱动程序和内核之间有一个很好的干净的分离。我相信使用支持用户空间驱动程序的较新内核会更容易，尽管我认为它们还不能很好地支持DMA (我不得不编写一个用户空间DMA内核模块来直接在芯片组和用户空间之间支持DMA )。

然而(再一次)我真的建议你考虑你想要保护的是什么。封闭的驱动程序可能适合嵌入式应用程序，因为您可以严格控制内核版本和硬件。但是，如果这个驱动程序被认为是更通用的(例如，销售硬件的人将插入他们自己的系统中)，那么封闭源代码驱动程序只会被证明是持续痛苦和维护头痛的来源。

Answer 3

1:你需要和律师谈谈这件事，可能是你公司的法律部。

2:重要的问题是哪段代码是从哪些其他代码派生而来的。

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

有些人会认为所有的内核模块都是内核的衍生作品，所以无论头部是否包含，都必须是GPLed的。

或者，您的封闭模块派生自GPL模块，而GPL模块派生自内核，因此封闭模块也必须是GPL。