许可和使用Linux内核

时间:2020-03-06 14:33:37  来源:igfitidea点击:

我想编写自己的OS,并希望暂时跳过编写内核的复杂任务,并在以后通过使用Linux内核返回到它。但是,我现在想将OS作为封闭源提供。 Linux内核拥有什么许可证?是否可以将其用于封闭源OS的发行版?

编辑:我对关闭Linux内核的源不感兴趣,我仍将其作为开源提供。我想知道是否可以将开放源代码内核与封闭源代码操作系统一起使用。

进一步的编辑:所谓OS,是指在内核之上运行并用于启动其他程序的系统。我当然不是要在封闭源代码语句中包含内核。

解决方案

Linux内核是在GPLv2下发布的,我们可以将其用作封闭源OS的一部分,但是我们必须保留该内核和所有修改后发布的GPLv2.

编辑:顺便说一句,我们可能想改用类似OpenSolaris的工具。在我看来(显然很主观),使用起来要容易得多,而且只要我们遵循CDDL的规定,就可以选择不公开修改。

它是GPL版本2,我们肯定不会关闭其源代码。

这是GPL。简短答案-不。

Linux拥有GPL(v2)许可证,这意味着我们必须开源任何衍生作品。

我们可能要使用BSD,它的许可在衍生作品上有很多限制

我认为我们将必须更加具体地说明"操作系统"的含义。这绝不是一个清晰的概念。有人会说内核就是所有操作系统。其他人会说外壳程序和核心实用程序(例如" ls")是操作系统的一部分。其他人甚至会说标准应用程序(例如记事本)是操作系统的一部分。

IANAL,但我不认为有什么可以阻止我们将Linux内核与我们自己的封闭源代码程序捆绑在一起的。但是请注意不要使用任何GPL库代码(LGPL可以)。

我确实质疑你的动机。

我们始终可以将所有扩展(模块)和/或者应用程序保持为封闭源代码,但内核本身仍需要保持开放源代码。

我们可以在测试系统时利用GPLv2的一个不太明显的方面:我们只需要将源代码发布给有权访问系统的人员即可。 GPLv2指出,需要向有权访问该程序的二进制/编译发行版的任何人授予对源代码的完全访问权限。因此,如果我们只打算在公司内部使用付费来开发它的软件,则无需将源代码分发到世界其他地方,而只需将它们分发到世界其他地方。

我们必须保持源代码开放,并且任何源于代码的工作都必须保持打开状态,但是,如果我们使用内核,则在此之上编写我们自己的应用程序堆栈(几乎所有GNU东西),则不必打开。

GPL表示"派生"有效……因此,如果我们正在编写新代码,而不是扩展代码,那很好。实际上,例如,我们甚至可以使用GNU工具链,Linux内核,然后在封闭源代码之上(或者仅是DE)拥有自己的系统。

当我们修改/派生某些内容时,必须使其保持打开状态!

一般来说,只要我们提供内核的源代码,就可以允许我们这样做,但是我不确定一点:

在(GPL)内核和不兼容GPL的应用程序之间的普通Linux系统上,总是存在GNU libc,它是LGPL,因此允许派生的作品是非免费的。现在,如果我们有一个非自由的libc,则可以将其视为派生作品,因为我们可以直接调用内核,也可以使用内核头文件。

正如许多其他人之前所说,使用* BSD可能会更好。

当然,只要我们与链接的组件的许可兼容,就可以在Linux内核上编写任何喜欢的封闭源OS。

当然,其中可能包括gnu C库(或者其他一些C库)。我们可能还需要一些命令行实用程序,这些实用程序可能是GPL来执行诸如文件系统维护,网络设置等工作。但是,如果我们将它们留为独立的程序,那应该没有问题。

我们链接到内核本身的所有内容(例如自定义模块,补丁程序)都应作为开源GPL发布,以符合内核许可证。

如果我们要使用的文件系统链接到内核本身,并且打算将其分发给其他人,则GPL明确要求将文件系统也进行GPL处理。

话虽这么说:使Linux与GPL不兼容的文件系统合法接口的一种方法是通过FUSE(用户空间中的文件系统)。例如,它已用于在Linux之上运行GPL不兼容的ZFS文件系统。但是,在用户空间中运行文件系统确实会带来很大的性能损失。

如果我们认真地开发新的操作系统,并且想要一个可以正常工作的内核作为开始,我建议我们研究一下FreeBSD内核。它的许可证比Linux宽松得多,我认为我们可能会觉得值得。

只是我的2美分...

我同意MarkR的观点,但没有人对我们说清楚。如果我们是认真的人,则需要咨询在这方面有专长的律师。