3 ms·

For those of us that can read source code there are a couple of strong indications that the Linux copyright holders still believe that Linux kernel modules may

For those of us that can read source code there are a couple of strong indications that the Linux copyright holders still believe that Linux kernel modules may not necessarily constitute derivative works: 1. Every Linux kernel module can tell the kernel what license regulates its use, using the MODULE_LICENSE() macro. The Linux kernel keeps track of which modules are under GPLv2 (and a few other compatible licenses). When a module under a presumably "proprietary" license is loaded the kernel will mark itself as "tainted". (It could just as well refuse to load the module, but it doesn't.) 2. There are two macros used to export Linux kernel symbols: EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. The former will make the symbol available to all kernel modules, while the latter makes it available only to GPL-licensed kernel modules. The clear purpose and motivation is that a kernel module that needs access to a symbol exported with EXPORT_SYMBOL_GPL must be a derivative work, while a kernel module that only depends on symbols exported with EXPORT_SYMBOL is not necessarily a derivate work. Also, IANAL, but from a purely legal perspective I think it would be difficult to get a court to agree that a user space program that talks to the Linux kernel through system calls is never a derivative work, while a kernel module (even one that accesses only symbols exported with EXPORT_SYMBOL) is always a derivative work. The system call versus dynamic loaded module distinction is simply not very relevant from a purely legal perspective.

tobias3 11y ago
That is why userspace programs are explicitely declared to not be derived work in the Linux kernel license https://www.kernel.org/pub/linux/kernel/COPYING https://www.kernel.org/pub/linux/kernel/COPYING (right at the top)
caf 11y ago
What this kind of analysis, which is very common, misses is this: there's potentially two "works" that need talking about here, not just one. One work is the module, considered in isolation. Is that a derivative of the kernel? Possibly, but that's a reasonably high bar to clear. If it's not, distributing the module by itself can be done entirely without reference to the Linux kernel's license. The other potential work though is the module-and-Linux-kernel (and possibly many other bits too), delivered as one combined work. Is that a separate work as per copyright law? If so, is that work a derivative (of both the kernel and the module)? This is a much lower bar, and means that the combined work can only be distributed in accordance with the licenses of both the kernel and the module.
- bjornsing 11y ago
  > What this kind of analysis, which is very common, misses is this: there's potentially two "works" that need talking about here, not just one. I agree this is only one side of the analysis (does zfs.ko fall under the Linux kernel GPLv2?), but that's also the only question that the OP can credibly address (because SFC is a copyright holder in Linux, not in ZFS). > The other potential work though is the module-and-Linux-kernel (and possibly many other bits too), delivered as one combined work. Is that a separate work as per copyright law? If so, is that work a derivative (of both the kernel and the module)? This is a much lower bar, and means that the combined work can only be distributed in accordance with the licenses of both the kernel and the module. That line of reasoning would upend pretty much all open source licensing as we know it. E.g., paragraph 9 of the OSI's Open Source Definition [1] clearly states that "The license must not place restrictions on other software that is distributed along with the licensed software." The fact that the OSI has accepted the GPLv2 [2] as an open source license implies that they (for one) do not agree. 1. https://opensource.org/osd https://opensource.org/osd 2. https://opensource.org/licenses/alphabetical https://opensource.org/licenses/alphabetical
  - jordigh 11y ago
    SFC isn't a copyright holder of Linux. They are just giving their opinion. Also, as far as combined work, the OSD is not talking about that, but what the GPL calls "mere aggregation". The GPL is quite clear that "mere aggregation" is not under the scope of the GPL, thus OSD consider the GPL to be open source. A module linked to Linux and distributed along with Linux, however, is no longer "mere aggregation", but distributed as a single work.
    - caf 11y ago
      Some Linux copyright holders have assigned their copyrights to the SFC. https://sfconservancy.org/copyleft-compliance/ https://sfconservancy.org/copyleft-compliance/
      - jordigh 11y ago
rdtsc 11y ago
> license is loaded the kernel will mark itself as "tainted". (It could just as well refuse to load the module, but it doesn't.) Why, because they used the word "tainted"? I kind of thought that always meant to be used a flag for "this user loaded some random binary in the kernel and now complains there is bug ". So developers look at the debug output and see "oh, well, it is tained, so, we won't waste time on this, you are on your own" kind of stuff. Which is reasonable. As you said, if they didn't want it to work with non-GPL modules, they could have prevented loading. Unless you think they setup a honeypot of sorts -- "We'll trick them, then sue them!".
- thwarted 11y ago
  I kind of thought that always meant to be used a flag for "this user loaded some random binary in the kernel and now complains there is bug ". So developers look at the debug output and see "oh, well, it is tained, so, we won't waste time on this, you are on your own" kind of stuff. Which is reasonable. I think it's useful to look at it as that if the kernel is flagged as tainted, it means it's in a state that can't be properly debugged, independent of the exact reason. This could be because there's a opaque blob loaded that makes debugging difficult, if not impossible. It could also be because the license of the code that was loaded (even if it isn't an opaque blob) means that even if someone did figure out the problem, they couldn't necessarily get their changes committed upstream (or might have a hard time of it) and then they'd have wasted that time debugging something that legally can't be debugged by anyone or anyone can't use the results of the debugging (the fix), which are freedoms the GPL is designed to protect. There's a lot of bugs to work on, and it's meaningful to consider code that is licensed in a way that is not strictly GPL compatible as lower priority than code that is GPL.

tobias3 11y ago

That is why userspace programs are explicitely declared to not be derived work in the Linux kernel license https://www.kernel.org/pub/linux/kernel/COPYING https://www.kernel.org/pub/linux/kernel/COPYING (right at the top)

caf 11y ago

What this kind of analysis, which is very common, misses is this: there's potentially two "works" that need talking about here, not just one. One work is the module, considered in isolation. Is that a derivative of the kernel? Possibly, but that's a reasonably high bar to clear. If it's not, distributing the module by itself can be done entirely without reference to the Linux kernel's license. The other potential work though is the module-and-Linux-kernel (and possibly many other bits too), delivered as one combined work. Is that a separate work as per copyright law? If so, is that work a derivative (of both the kernel and the module)? This is a much lower bar, and means that the combined work can only be distributed in accordance with the licenses of both the kernel and the module.

bjornsing 11y ago
> What this kind of analysis, which is very common, misses is this: there's potentially two "works" that need talking about here, not just one. I agree this is only one side of the analysis (does zfs.ko fall under the Linux kernel GPLv2?), but that's also the only question that the OP can credibly address (because SFC is a copyright holder in Linux, not in ZFS). > The other potential work though is the module-and-Linux-kernel (and possibly many other bits too), delivered as one combined work. Is that a separate work as per copyright law? If so, is that work a derivative (of both the kernel and the module)? This is a much lower bar, and means that the combined work can only be distributed in accordance with the licenses of both the kernel and the module. That line of reasoning would upend pretty much all open source licensing as we know it. E.g., paragraph 9 of the OSI's Open Source Definition [1] clearly states that "The license must not place restrictions on other software that is distributed along with the licensed software." The fact that the OSI has accepted the GPLv2 [2] as an open source license implies that they (for one) do not agree. 1. https://opensource.org/osd https://opensource.org/osd 2. https://opensource.org/licenses/alphabetical https://opensource.org/licenses/alphabetical
- jordigh 11y ago
  SFC isn't a copyright holder of Linux. They are just giving their opinion. Also, as far as combined work, the OSD is not talking about that, but what the GPL calls "mere aggregation". The GPL is quite clear that "mere aggregation" is not under the scope of the GPL, thus OSD consider the GPL to be open source. A module linked to Linux and distributed along with Linux, however, is no longer "mere aggregation", but distributed as a single work.
  - caf 11y ago
    Some Linux copyright holders have assigned their copyrights to the SFC. https://sfconservancy.org/copyleft-compliance/ https://sfconservancy.org/copyleft-compliance/
    - jordigh 11y ago

rdtsc 11y ago

> license is loaded the kernel will mark itself as "tainted". (It could just as well refuse to load the module, but it doesn't.) Why, because they used the word "tainted"? I kind of thought that always meant to be used a flag for "this user loaded some random binary in the kernel and now complains there is bug ". So developers look at the debug output and see "oh, well, it is tained, so, we won't waste time on this, you are on your own" kind of stuff. Which is reasonable. As you said, if they didn't want it to work with non-GPL modules, they could have prevented loading. Unless you think they setup a honeypot of sorts -- "We'll trick them, then sue them!".

thwarted 11y ago
I kind of thought that always meant to be used a flag for "this user loaded some random binary in the kernel and now complains there is bug ". So developers look at the debug output and see "oh, well, it is tained, so, we won't waste time on this, you are on your own" kind of stuff. Which is reasonable. I think it's useful to look at it as that if the kernel is flagged as tainted, it means it's in a state that can't be properly debugged, independent of the exact reason. This could be because there's a opaque blob loaded that makes debugging difficult, if not impossible. It could also be because the license of the code that was loaded (even if it isn't an opaque blob) means that even if someone did figure out the problem, they couldn't necessarily get their changes committed upstream (or might have a hard time of it) and then they'd have wasted that time debugging something that legally can't be debugged by anyone or anyone can't use the results of the debugging (the fix), which are freedoms the GPL is designed to protect. There's a lot of bugs to work on, and it's meaningful to consider code that is licensed in a way that is not strictly GPL compatible as lower priority than code that is GPL.