使用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,您可以使用它.

但是,GPL_ONLY如果您通过用户空间驱动程序访问它们,即使是这些也可以使用,这在2.6.23中是可能的.这正是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).

然而(再次)我真的建议你考虑一下你试图保护的是什么.对于可以严格控制内核版本和硬件的嵌入式应用程序,封闭的驱动程序可能没问题.但是,如果这个驱动程序被考虑用于更通用的东西(即销售硬件人员将插入他们自己的系统),那么封闭的源驱动程序将只会被证明是持续的痛苦和维护问题的根源.