11

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

4

5 回答 5

8

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

于 2009-04-10T08:15:08.337 回答
7

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

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

但是（再次）我真的建议您考虑一下您要保护的内容。对于您对内核版本和硬件有严格控制的嵌入式应用程序，封闭的驱动程序可能是可以的。但是，如果这个驱动程序被考虑用于任何更通用的东西（即销售硬件的人将插入他们自己的系统），那么闭源驱动程序只会被证明是持续痛苦和维护头痛的根源。

于 2009-04-13T11:38:11.537 回答
4

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

第二：重要的问题是哪一段代码是从哪一段代码衍生而来的。

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

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

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

于 2009-04-10T08:02:05.900 回答
4

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

当一些开发人员从 Linksys 路由器上拆下 Belkin 驱动程序，对其进行逆向工程并发布结果时，Belkin 无法阻止他们，因为将这种许可证解释提交法庭作为辩护的反威胁。

于 2009-04-15T19:18:01.147 回答
4

无数其他驱动程序使用开源“shim”将闭源目标文件与开源内核桥接。大多数内核开发人员认为这至少在精神上违反了 GPL。

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

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

*以上是我的看法*

于 2009-04-15T19:22:19.313 回答