在（GPL）内核和非内核之间的普通 Linux 系统上-GPL 兼容的应用程序，总是有 GNU libc，它是 LGPL，因此允许非自由的派生作品。 现在，如果您有一个非自由的 libc，则可能会被视为派生作品，因为您直接调用内核，并且还使用内核标头。
正如许多其他人之前所说，使用 *BSD 可能会更好。
Generally I would say that you're allowed to do such a thing, as long as you provide the source for the kernel, but there's one point where I'm unsure:
On a normal Linux system between the (GPL) kernel and a non-GPL compatible application, there is always the GNU libc, which is LGPL and thus allows derived works that are non-free. Now, if you have a non-free libc, that might be considered a derived work, since you are directly calling the kernel, and also using kernel headers.
As many others have said before, you might be better off using a *BSD.
You can always keep any extensions (modules) and/or applications you write closed source, but the kernel itself will need to remain open source.
There's a not-so-obvious aspect of the GPLv2 that you can exploit while testing the system: you only need to release source code to those who have access to the system. The GPLv2 states that you need to give full access to the source code to anyone with access to the binary/compiled distribution of the program. So, if you are only going to use the software inside of the company that is paying to develop it, you don't need to distribute the source code to the rest of the world, but just them.
If the filesystem you use is to be linked into the kernel itself, and if you plan to distribute it to others, the GPL pretty unambiguously requires that the filesystem be GPL'ed as well.
That being said: one way to legally interface Linux with a GPL-incompatible filesystem is via FUSE (filesystem in userspace). This has been used, for example, to run the GPL-incompatible ZFS filesystem on top of Linux. Running a filesystem in userspace does, however, carry a performance penalty that may be significant.
你必须保持源代码开放，以及从代码派生的任何作品，但是，如果你使用内核，在其之上编写你自己的应用程序堆栈（几乎所有 GNU 的东西），那么你就不必打开它。
GPL 说“派生”是有效的……所以如果您正在编写新代码，而不是扩展代码，那就没问题。 事实上，例如，您甚至可以使用 GNU 工具链、Linux 内核，然后在其之上拥有自己的闭源系统（或只是一个 DE）。
当你修改/派生某些东西时，你必须保持它打开！
You must keep the source open, and any works derived from the code, however, if you use the Kernel, write your own application stack on top of that (pretty much ALL the GNU stuff) then you don't have to open that up.
The GPL says that "derived" works... so if you're writing new code, instead of expanind on, then that's fine. In fact, you could even, for example, use the GNU toolchain, the Linux Kernel, and then have your own system on top of that (or just a DE) that is closed source.
It's when you modify/derive from something that you have to keep it open!
IANAL，但我不认为有什么可以阻止您将 Linux 内核与您自己的闭源程序捆绑在一起。 但请注意不要使用任何 GPL 库代码（LGPL 也可以）。
我确实质疑你的动机。
I think you're going to have to be more specific about what you mean by 'OS'. It's by no means a clear concept. Some would say that the kernel is all of the OS. Others would say that the shell and core utilities such as 'ls' are part of the OS. Others would go as far as to say that standard applications such as Notepad are part of the OS.
IANAL, but I don't believe there's anything to stop you from bundling the Linux kernel with a load of closed-source programs of your own. Take care not to use any GPL library code however (LGPL is OK).
The Linux kernel is released under the GPLv2 and you can use it as part of a closed-source OS but you have to keep the kernel and all modifications released GPLv2.
Edit: Btw, you may want to use something like OpenSolaris instead. It's much easier to work with, in my opinion (obviously very subjective), and you can keep modifications closed-source if you so choose, so long as you follow the terms of the CDDL.
当然，这可能包括 gnu C 库（或其他一些 C 库）。 您可能还需要一些命令行实用程序，这些实用程序可能是 GPL 来执行文件系统维护、网络设置等操作。但是，如果您将它们保留为自己的独立程序，那么这应该不是问题。
链接到内核本身的任何内容（例如自定义模块、补丁）都应该作为开源 GPL 发布，以符合内核的许可证。
You can of course write whatever closed-source OS over the Linux kernel that you like provided you are compatible with the licensing of components you link against.
Of course that's likely to include the gnu C library (or some other C library). You may also need some command line utilities which will probably be GPL to do things such as filesystem maintenance, network setup etc. But provided you leave those as their own standalone programs, it should not be a problem.
Anything that you link into the kernel itself (e.g. custom modules, patches) should be released as open source GPL to comply with the kernel's licence.
如果您认真地开发一个新的操作系统并希望从一个可用的内核开始，我建议您研究一下 FreeBSD 内核。 它的许可证比 Linux 宽松得多，我想你可能会发现它值得。
只是我的2分钱...
If you're serious in developing a new operating system and want a working kernel to start with I suggest that you look into the FreeBSD kernel. It has a much more relaxed license than Linux, I think you might find it worthwhile.
发布评论
评论（12）
一般来说，我会说你可以做这样的事情，只要你提供内核的源代码，但有一点我不确定：
在（GPL）内核和非内核之间的普通 Linux 系统上-GPL 兼容的应用程序，总是有 GNU libc，它是 LGPL，因此允许非自由的派生作品。 现在，如果您有一个非自由的 libc，则可能会被视为派生作品，因为您直接调用内核，并且还使用内核标头。
正如许多其他人之前所说，使用 *BSD 可能会更好。
Generally I would say that you're allowed to do such a thing, as long as you provide the source for the kernel, but there's one point where I'm unsure:
On a normal Linux system between the (GPL) kernel and a non-GPL compatible application, there is always the GNU libc, which is LGPL and thus allows derived works that are non-free. Now, if you have a non-free libc, that might be considered a derived work, since you are directly calling the kernel, and also using kernel headers.
As many others have said before, you might be better off using a *BSD.
您始终可以保留您编写的任何扩展（模块）和/或应用程序的闭源代码，但内核本身需要保持开源状态。
GPLv2 有一个不太明显的方面，您可以在测试系统时利用：您只需向有权访问系统的人发布源代码。 GPLv2 规定，您需要向任何有权访问该程序的二进制/编译发行版的人授予对源代码的完全访问权限。 因此，如果您只想使用付费开发的公司内部的软件，则无需将源代码分发给世界其他地方，而只需分发给他们即可。
You can always keep any extensions (modules) and/or applications you write closed source, but the kernel itself will need to remain open source.
There's a not-so-obvious aspect of the GPLv2 that you can exploit while testing the system: you only need to release source code to those who have access to the system. The GPLv2 states that you need to give full access to the source code to anyone with access to the binary/compiled distribution of the program. So, if you are only going to use the software inside of the company that is paying to develop it, you don't need to distribute the source code to the rest of the world, but just them.
它是 GPL。 简短的回答——不。
It is GPL. Short answer -- no.
如果您使用的文件系统要链接到内核本身，并且如果您计划将其分发给其他人，则 GPL 非常明确地要求文件系统也必须采用 GPL。
话虽这么说：将 Linux 与不兼容 GPL 的文件系统合法连接的一种方法是通过 FUSE （用户空间中的文件系统）。 例如，这已用于在 Linux 上运行与 GPL 不兼容的 ZFS 文件系统。 然而，在用户空间中运行文件系统确实会带来严重的性能损失。
If the filesystem you use is to be linked into the kernel itself, and if you plan to distribute it to others, the GPL pretty unambiguously requires that the filesystem be GPL'ed as well.
That being said: one way to legally interface Linux with a GPL-incompatible filesystem is via FUSE (filesystem in userspace). This has been used, for example, to run the GPL-incompatible ZFS filesystem on top of Linux. Running a filesystem in userspace does, however, carry a performance penalty that may be significant.
Linux 有 GPL (v2) 作为其许可证，这意味着您必须开源任何衍生作品。
您可能想使用 BSD，它的许可证对于您可以对派生作品执行的操作有很多限制
Linux has the GPL (v2) as its licence, which means you have to open source any derivative works.
You may want to use BSD, its license is a lot les restrictive in what you can do with derived works
你必须保持源代码开放，以及从代码派生的任何作品，但是，如果你使用内核，在其之上编写你自己的应用程序堆栈（几乎所有 GNU 的东西），那么你就不必打开它。
GPL 说“派生”是有效的……所以如果您正在编写新代码，而不是扩展代码，那就没问题。 事实上，例如，您甚至可以使用 GNU 工具链、Linux 内核，然后在其之上拥有自己的闭源系统（或只是一个 DE）。
当你修改/派生某些东西时，你必须保持它打开！
You must keep the source open, and any works derived from the code, however, if you use the Kernel, write your own application stack on top of that (pretty much ALL the GNU stuff) then you don't have to open that up.
The GPL says that "derived" works... so if you're writing new code, instead of expanind on, then that's fine. In fact, you could even, for example, use the GNU toolchain, the Linux Kernel, and then have your own system on top of that (or just a DE) that is closed source.
It's when you modify/derive from something that you have to keep it open!
它是 GPL 版本 2，您当然不会关闭它的源代码。
It's GPL version 2 and you may certainly not close its source.
我认为您必须更具体地说明“操作系统”的含义。 这绝不是一个明确的概念。 有人会说内核就是操作系统的全部。 其他人会说 shell 和核心实用程序（例如“ls”）是操作系统的一部分。 其他人甚至会说记事本等标准应用程序是操作系统的一部分。
IANAL，但我不认为有什么可以阻止您将 Linux 内核与您自己的闭源程序捆绑在一起。 但请注意不要使用任何 GPL 库代码（LGPL 也可以）。
我确实质疑你的动机。
I think you're going to have to be more specific about what you mean by 'OS'. It's by no means a clear concept. Some would say that the kernel is all of the OS. Others would say that the shell and core utilities such as 'ls' are part of the OS. Others would go as far as to say that standard applications such as Notepad are part of the OS.
IANAL, but I don't believe there's anything to stop you from bundling the Linux kernel with a load of closed-source programs of your own. Take care not to use any GPL library code however (LGPL is OK).
I do question your motives.
Linux 内核是在 GPLv2 下发布的，您可以将其用作闭源操作系统的一部分，但您必须保留 GPLv2 发布的内核和所有修改。
编辑：顺便说一句，您可能想使用 OpenSolaris 之类的东西。 在我看来，它更容易使用（显然非常主观），并且如果您选择的话，您可以将修改保留为闭源，只要您遵循 CDDL 的条款。
The Linux kernel is released under the GPLv2 and you can use it as part of a closed-source OS but you have to keep the kernel and all modifications released GPLv2.
Edit: Btw, you may want to use something like OpenSolaris instead. It's much easier to work with, in my opinion (obviously very subjective), and you can keep modifications closed-source if you so choose, so long as you follow the terms of the CDDL.
当然，您可以在您喜欢的 Linux 内核上编写任何闭源操作系统，前提是您与所链接的组件的许可兼容。
当然，这可能包括 gnu C 库（或其他一些 C 库）。 您可能还需要一些命令行实用程序，这些实用程序可能是 GPL 来执行文件系统维护、网络设置等操作。但是，如果您将它们保留为自己的独立程序，那么这应该不是问题。
链接到内核本身的任何内容（例如自定义模块、补丁）都应该作为开源 GPL 发布，以符合内核的许可证。
You can of course write whatever closed-source OS over the Linux kernel that you like provided you are compatible with the licensing of components you link against.
Of course that's likely to include the gnu C library (or some other C library). You may also need some command line utilities which will probably be GPL to do things such as filesystem maintenance, network setup etc. But provided you leave those as their own standalone programs, it should not be a problem.
Anything that you link into the kernel itself (e.g. custom modules, patches) should be released as open source GPL to comply with the kernel's licence.
我同意 MarkR 的观点，但没有人向你阐明显而易见的事实。 如果你是认真的，你需要咨询有这方面专业知识的律师。
I agree with MarkR but nobody has stated the obvious to you. If you are serious, you need to consult a lawyer with expertise in this area.
如果您认真地开发一个新的操作系统并希望从一个可用的内核开始，我建议您研究一下 FreeBSD 内核。 它的许可证比 Linux 宽松得多，我想你可能会发现它值得。
只是我的2分钱...
If you're serious in developing a new operating system and want a working kernel to start with I suggest that you look into the FreeBSD kernel. It has a much more relaxed license than Linux, I think you might find it worthwhile.
Just my 2 cents...