我想编写自己的操作系统，想暂时跳过编写内核这个复杂的任务，同时再用Linux内核回来。 但是，我想现在提供操作系统作为封闭的源代码。 Linux内核下有什么许可证，是否可以在封闭的源操作系统上使用它？
编辑：我不关心closures的Linux内核的来源，我仍然会提供作为开源。 我想知道如果我可以使用一个开源的内核封闭的源操作系统。
进一步编辑：通过操作系统，我的意思是运行在内核之上的系统，用来启动其他程序。 我当然不打算把内核包含在封闭的声明中。
您当然可以在Linux内核上编写任何闭源操作系统，只要您与链接的组件相兼容即可。
当然，这可能包括GNU C库（或其他一些C库）。 您可能还需要一些命令行实用程序，这些实用程序很可能是GPL来执行文件系统维护，网络设置等。但是，如果您将它们保留为独立程序，则不会造成问题。
任何你链接到内核本身的东西（例如自定义模块，补丁）都应该作为开源的GPL发布，以符合内核的许可证。
Linux内核是在GPLv2下发布的，您可以将它用作闭源操作系统的一部分，但是您必须保留GPLv2的内核和所有修改。
编辑：顺便说一句，你可能想要使用像OpenSolaris的东西。 在我看来，处理起来要容易得多（显然是非常主观的），如果你愿意的话，你可以保持修改是闭源的，只要你遵循CDDL的条款。
我想你将不得不更加具体地说明“操作系统”的含义。 这绝不是一个明确的概念。 有人会说内核是所有的操作系统。 其他人会说，诸如'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。 简短的回答 – 不。