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.
> 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.
There's clearly a continuum between two independent programs distributed on the same DVD through to a pre-linked static binary combining two pieces of code together.
I believe the OSI point is aiming towards the first part of that continuum (and of course the GPL itself specifically disclaims "mere aggregation"). The line here is somewhat fuzzy, but for example if you were selling NAS boxes based on linux-on-ZFS, it seems to me that it would be hard to explain that away as "mere aggregation", since the essential functionality of the product relies on both those parts working together.
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.
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.