代码之家 › 专栏 › 技术社区 › Emiliano

使用GPL内核模块的非GPL内核模块[关闭]

gpl linux-kernel licensing

10

Emiliano · 技术社区 · 15 年前

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

5 回复 | 直到 15 年前

1

7

vartec 15 年前

有 GPL_ONLY 模块的标志,不应在非GPL模块中使用。所以如果你说的模块不是 仅GPLL ,你可以用它。

但即使是这些 仅GPLL 如果您通过 user-space drivers, which are possible in 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

2

7

stsquad 15 年前

所以你真的应该寻求合格的法律意见。然而这这种做法肯定违背了许可证的精神, 在核心地带不会赢得任何朋友。

然而,你可以考虑另一种分裂。一种方法是一个完整的GPL'ED模块,把你所有的“秘密公司IP”放在一个用户身上。空间驱动器。这是我在公司工作时采用的方法不想向全世界公开我们的FPGA的细节。所有的在用户空间和驱动程序的内核端刚刚在IRQ上加载了值。小心地设计您可以管理任何实时问题,并且关闭的驱动程序和内核之间的清晰分离。我相信新内核支持用户空间更容易实现这一点尽管我认为驱动程序还不支持DMA(我不得不对用户空间DMA内核模块进行编码,以便直接在芯片组和用户空间)。

不过,我还是建议你考虑一下试图保护。对于嵌入式应用程序,关闭的驱动程序可能是正常的。对内核版本和硬件有严格的控制。但是如果这个驱动程序被认为是更通用的(即销售硬件的人会插入自己的系统),然后关闭源驱动因素只会被证明是持续痛苦和维护头痛。

3

4

Douglas Leeder 15 年前

第一:你需要和律师谈谈这个问题,可能是你公司的法律部门。

第二:重要的问题是什么代码是从哪个代码派生出来的。

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

有些人认为所有内核模块都是从内核派生出来的,所以不管头包含什么,都必须是gpled。

或者,关闭的模块派生自gpl模块,而gpl模块派生自内核,因此关闭的模块也必须是gpl。

4

Joshua 15 年前

一些核心开发人员(但不是Linus本人)认为,任何非GPL的模块都违反了内核的许可证。

当一些开发者将Belkin驱动程序从Linksys路由器中剥离,对其进行反向工程,并发布结果时,Belkin无法阻止他们,因为作为一种抗辩,将此许可证解释提交法院。

5

4

MarkR 15 年前

无数其他驱动程序使用开放源代码“填充程序”将封闭源代码对象文件与开放源代码内核桥接起来。大多数内核开发人员都认为这违反了GPL,至少在精神上是这样。

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

把你需要的任何功能移出内核,或者开源你的内核组件。这正是其他人(诚实的)所做的,而且通常不会那么棘手,因为任何拥有大量内核空间“知识产权”的人,要么有一个糟糕的商业模式,要么是一个不称职的工程团队。

*以上是我的意见*