4 ms·

> Finally, the response explains that vmkernel and vmklinux don't “communicate over an interface”, rather they run in the same process as a single computer prog

> Finally, the response explains that vmkernel and vmklinux don't “communicate over an interface”, rather they run in the same process as a single computer program. Thus, VMK API, as used by vmklinux, is not an “interface” as set forth in the EU Directive 2009/24/EC. The directive does not make such a distinction. If running in the same memory space would be a criteria then everything running on a MMU-less system would be a derivative work of everything it uses.

kuschku 11y ago
The argument is that they are literally the same process, with no API or interface between them. It’s instead used like a library, loaded by the linker.
- jahewson 11y ago
  But a library is the textbook definition of an API. I presume you mean to say that there's no IPC being used, such as a socket.
  - deleted 11y ago
    [deleted]
- poizan42 11y ago
  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.
  - 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.

kuschku 11y ago

The argument is that they are literally the same process, with no API or interface between them. It’s instead used like a library, loaded by the linker.

jahewson 11y ago
But a library is the textbook definition of an API. I presume you mean to say that there's no IPC being used, such as a socket.
- deleted 11y ago
  [deleted]
poizan42 11y ago
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.
- 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.