许可和使用Linux内核[关闭]

题

我想编写自己的操作系统，并希望暂时跳过编写内核的复杂任务，稍后再使用Linux内核返回它。但是，我想提供操作系统作为现在的封闭源。 Linux内核有哪些许可证，是否可以将其用于封闭源操作系统的发布？

编辑：我对关闭Linux内核的源码不感兴趣，我仍然会将其作为开源提供。我想知道我是否可以使用带有开源内核的闭源操作系统。

进一步编辑：操作系统，我指的是在内核之上运行的系统，用于启动其他程序。我当然不打算将内核包含在封闭的源语句中。

解决方案

如果您与所链接的组件的许可兼容，您当然可以在Linux内核上编写任何闭源操作系统。

当然，这可能包括gnu C库（或其他一些C库）。您可能还需要一些命令行实用程序，这些实用程序可能是GPL来执行文件系统维护，网络设置等操作。但是如果您将它们作为自己的独立程序保留，它应该不是问题。

您链接到内核本身的任何内容（例如自定义模块，补丁）都应作为开源GPL发布，以符合内核的许可。

其他提示

Linux内核是在GPLv2下发布的，你可以将它作为闭源操作系统的一部分使用，但你必须保持内核和所有修改都发布GPLv2。

编辑：顺便说一句，你可能想要使用像OpenSolaris这样的东西。在我看来，它更容易使用（显然非常主观），只要您遵循CDDL的条款，即使您愿意，也可以保持修改源代码。

我认为你必须更加明确“OS”的含义。这绝不是一个明确的概念。有人会说内核是所有操作系统。其他人会说，诸如'ls'之类的shell和核心实用程序是操作系统的一部分。其他人甚至会说记事本等标准应用程序是操作系统的一部分。

IANAL，但我不相信有任何阻止你将Linux内核与你自己的大量闭源程序捆绑在一起的东西。注意不要使用任何GPL库代码（LGPL没问题）。

我确实质疑你的动机。

Linux将GPL（v2）作为其许可，这意味着您必须开源任何衍生作品。

你可能想要使用BSD，它的许可证对于你可以用衍生作品所做的很多限制

你必须保持源代码打开，以及从代码派生的任何作品，但是，如果你使用内核，在它之上编写你自己的应用程序堆栈（几乎所有GNU的东西）然后你不必打开它。

GPL称“衍生”是指“衍生”。工作...所以如果你正在编写新的代码，而不是扩展，那就没关系。事实上，你甚至可以使用GNU工具链，Linux内核，然后在闭源上使用你自己的系统（或者只是一个DE）。

当您修改/派生某些必须保持打开的时候！

这是GPL第2版，你当然可以不关闭其来源。

如果您使用的文件系统要链接到内核本身，和如果您打算将其分发给其他人，那么GPL非常明确地要求文件系统也是GPL。

话虽这么说：通过，通过合法地将Linux与GPL不兼容的文件系统连接起来的一种方法是FUSE （用户空间中的文件系统）。例如，这已用于在Linux之上运行与GPL不兼容的 ZFS 文件系统。但是，在用户空间中运行文件系统确实会带来很大的性能损失。

您始终可以保留任何扩展（模块）和/或应用程序编写的源代码，但内核本身需要保持开源。

在测试系统时，您可以利用GPLv2的一个不太明显的方面：您只需要向有权访问系统的人发布源代码。 GPLv2声明您需要为有权访问程序的二进制/已编译分发的任何人提供对源代码的完全访问权限。因此，如果您只是使用公司内部开发的软件，那么您不需要将源代码分发给世界其他地方，而只需将它们分发给它们。

一般来说，只要你提供内核的来源，我就会说你被允许做这样的事情，但有一点我不确定：

在（GPL）内核和非GPL兼容应用程序之间的普通Linux系统上，始终存在GNU libc，它是LGPL，因此允许非自由的派生作品。现在，如果你有一个非自由的libc，那可能被认为是派生的工作，因为你直接调用内核，也使用内核头文件。

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

如果您正在认真开发新的操作系统并希望开始使用可运行的内核，我建议您查看FreeBSD内核。它拥有比Linux更宽松的许可证，我认为你可能觉得它值得。

只是我的2美分......

我同意MarkR，但没有人向你表明这一点。如果您是认真的，您需要咨询具有该领域专业知识的律师。

是GPL。简短的回答 - 没有。

许可以下： CC-BY-SA 和归因