3 ms·

Everything in kernel space is "the same process". Using something as a library exactly means that there is an API to use. If the proprietary part of the kernel

Everything in kernel space is "the same process". Using something as a library exactly means that there is an API to use. If the proprietary part of the kernel module directly pokes around in private symbols in the kernel then I can see that there might be a problem, but if only publicly available interfaces are used then it should be under the definition in article 10 as far as I can tell.

jnky 11y ago
The Linux Kernel does not have a public API/ABI apart from the userspace syscall interface.
- amscanne 11y ago
  It does. It exports many symbols for drivers (proprietary or otherwise) to use internally. Some symbols are exported GPL_ONLY, which means that only GPL drivers may call those symbols.
  - jnky 11y ago
    > It exports many symbols for drivers (proprietary or otherwise) to use internally. I fail to see how those symbols being exported makes the relevant functionality public vs. internal to the kernel [1] > Some symbols are exported GPL_ONLY, which means that only GPL drivers may call those symbols. I don't think that is accurate. Drivers are necessarily derivative works of the kernel and have to be licensed under the GPL anyway. In practice closed source driver modules seem to be tolerated, even if they are not strictly compliant with the kernel's license.[2] The purpose behind the GPL_ONLY symbols is that a driver has to declare itself compliant with the license to use the symbols. If a proprietary driver would declare itself GPL compliant to gain access to GPL_only symbols, its author would be in even muddier waters than before. [1] https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt https://www.kernel.org/doc/Documentation/stable_api_nonsense... [2] http://archive.linuxgizmos.com/are-non-gpl-loadable-linux-drivers-really-unot-u-a-problem-a/ http://archive.linuxgizmos.com/are-non-gpl-loadable-linux-dr...
    - amscanne 11y ago
      > I fail to see how those symbols being exported makes the relevant functionality public vs. internal to the kernel [1] It's not stable, but it's an API. I can write and distribute a proprietary module that uses those symbols. I can't do that with symbols that aren't exported. > I don't think that is accurate. Drivers are necessarily derivative works of the kernel and have to be licensed under the GPL anyway. In practice closed source driver modules seem to be tolerated, even if they are not strictly compliant with the kernel's license.[2] The purpose behind the GPL_ONLY symbols is that a driver has to declare itself compliant with the license to use the symbols. If a proprietary driver would declare itself GPL compliant to gain access to GPL_only symbols, its author would be in even muddier waters than before. Now you're just being pedantic. Obviously when I said "GPL drivers" I mean those which explicitly include a MODULE_LICENSE("GPL") directive. What else would I mean? I'm not engaging in legal speculation.
    - monocasa 11y ago
      > Drivers are necessarily derivative works of the kernel and have to be licensed under the GPL anyway. It can be a grey area. Quoting Linus himself > But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). http://yarchive.net/comp/linux/gpl_modules.html http://yarchive.net/comp/linux/gpl_modules.html
  - Aissen 11y ago
    Actually, some kernel developers believe that all exported symbols are contaminating, not just EXPORT_SYMBOL_GPL, see for example: http://thread.gmane.org/gmane.linux.kernel/1390226/focus=1391147 http://thread.gmane.org/gmane.linux.kernel/1390226/focus=139... The test used by the industry for derivative works usually requires a full implementation of the same code with another OS than Linux (e.g the nvidia drivers which shares 95% of the codebase between Linux and Windows). Some ported-over-from-an-RTOS drivers fall into this as well, but there's rarely enough value in them that they shouldn't be opensourced. In the end there are so many nice features hidden behind EXPORT_SYMBOL_GPL that it's rarely worth it to go the proprietary route.
    - amscanne 11y ago
      While I'm sure that's an opinion held by some, it seems unreasonable when you have both EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. If there is no distinction, then why does one exist? I think there's a good argument to be made regarding the intent of the application of the license across the API.
amscanne 11y ago
Reading the examples provided, it seems to be the case that they modified many of the kernel components to call directly into their proprietary component (not via an established abstraction, like driver hooks). That seems damning.
- poizan42 11y ago
  That I agree might be a problem. If the case ends up being decided in favor of Christoph Hellwig based on that then I wonder if what happens isn't just that companies gets a third party to distribute a modified kernel (as source code) with the interfaces they need added and then use that. It may still technically be a violation, but judging intent isn't easy.
  - mikekchar 11y ago
    I think the question is really what resolution you would get. Consider the fictional situation where Company A makes a derived work of the novel Harry Potter without permission. They then sell a license to Company B to make derived works of their work. Company B writes a novel in the Harry Potter world, thinking they have a license to do so. When Company B is sued by the copyright holder of Harry Potter, they hold up their license and say, "See. We have permission". My (very limited) understanding of copyright law is that the court would quickly find the license invalid since Company A never had the ability to grant the license. Company B would lose the lawsuit, pay some money and have an injunction against distributing their work. They would then be invited to sue Company A to recover their costs.

jnky 11y ago

The Linux Kernel does not have a public API/ABI apart from the userspace syscall interface.

amscanne 11y ago
It does. It exports many symbols for drivers (proprietary or otherwise) to use internally. Some symbols are exported GPL_ONLY, which means that only GPL drivers may call those symbols.
- jnky 11y ago
  > It exports many symbols for drivers (proprietary or otherwise) to use internally. I fail to see how those symbols being exported makes the relevant functionality public vs. internal to the kernel [1] > Some symbols are exported GPL_ONLY, which means that only GPL drivers may call those symbols. I don't think that is accurate. Drivers are necessarily derivative works of the kernel and have to be licensed under the GPL anyway. In practice closed source driver modules seem to be tolerated, even if they are not strictly compliant with the kernel's license.[2] The purpose behind the GPL_ONLY symbols is that a driver has to declare itself compliant with the license to use the symbols. If a proprietary driver would declare itself GPL compliant to gain access to GPL_only symbols, its author would be in even muddier waters than before. [1] https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt https://www.kernel.org/doc/Documentation/stable_api_nonsense... [2] http://archive.linuxgizmos.com/are-non-gpl-loadable-linux-drivers-really-unot-u-a-problem-a/ http://archive.linuxgizmos.com/are-non-gpl-loadable-linux-dr...
  - amscanne 11y ago
    > I fail to see how those symbols being exported makes the relevant functionality public vs. internal to the kernel [1] It's not stable, but it's an API. I can write and distribute a proprietary module that uses those symbols. I can't do that with symbols that aren't exported. > I don't think that is accurate. Drivers are necessarily derivative works of the kernel and have to be licensed under the GPL anyway. In practice closed source driver modules seem to be tolerated, even if they are not strictly compliant with the kernel's license.[2] The purpose behind the GPL_ONLY symbols is that a driver has to declare itself compliant with the license to use the symbols. If a proprietary driver would declare itself GPL compliant to gain access to GPL_only symbols, its author would be in even muddier waters than before. Now you're just being pedantic. Obviously when I said "GPL drivers" I mean those which explicitly include a MODULE_LICENSE("GPL") directive. What else would I mean? I'm not engaging in legal speculation.
  - monocasa 11y ago
    > Drivers are necessarily derivative works of the kernel and have to be licensed under the GPL anyway. It can be a grey area. Quoting Linus himself > But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). http://yarchive.net/comp/linux/gpl_modules.html http://yarchive.net/comp/linux/gpl_modules.html
- Aissen 11y ago
  Actually, some kernel developers believe that all exported symbols are contaminating, not just EXPORT_SYMBOL_GPL, see for example: http://thread.gmane.org/gmane.linux.kernel/1390226/focus=1391147 http://thread.gmane.org/gmane.linux.kernel/1390226/focus=139... The test used by the industry for derivative works usually requires a full implementation of the same code with another OS than Linux (e.g the nvidia drivers which shares 95% of the codebase between Linux and Windows). Some ported-over-from-an-RTOS drivers fall into this as well, but there's rarely enough value in them that they shouldn't be opensourced. In the end there are so many nice features hidden behind EXPORT_SYMBOL_GPL that it's rarely worth it to go the proprietary route.
  - amscanne 11y ago
    While I'm sure that's an opinion held by some, it seems unreasonable when you have both EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. If there is no distinction, then why does one exist? I think there's a good argument to be made regarding the intent of the application of the license across the API.

amscanne 11y ago

Reading the examples provided, it seems to be the case that they modified many of the kernel components to call directly into their proprietary component (not via an established abstraction, like driver hooks). That seems damning.

poizan42 11y ago
That I agree might be a problem. If the case ends up being decided in favor of Christoph Hellwig based on that then I wonder if what happens isn't just that companies gets a third party to distribute a modified kernel (as source code) with the interfaces they need added and then use that. It may still technically be a violation, but judging intent isn't easy.
- mikekchar 11y ago
  I think the question is really what resolution you would get. Consider the fictional situation where Company A makes a derived work of the novel Harry Potter without permission. They then sell a license to Company B to make derived works of their work. Company B writes a novel in the Harry Potter world, thinking they have a license to do so. When Company B is sued by the copyright holder of Harry Potter, they hold up their license and say, "See. We have permission". My (very limited) understanding of copyright law is that the court would quickly find the license invalid since Company A never had the ability to grant the license. Company B would lose the lawsuit, pay some money and have an injunction against distributing their work. They would then be invited to sue Company A to recover their costs.