Loading any non-GPL module will mark the Kernel as tainted, but that’s not the issue here.
The problem is that the ZFS module uses Kernel symbols that are marked as GPL-only, meaning that the Kernel will refuse to load the ZFS module as it isn’t marked as a GPL module. There isn’t any way to bypass this short of recompiling the Kernel to remove this restriction.
The legal status of this is uncertain, since a number of questions naturally arise:
1. Is it acceptable to mark a Kernel module as a GPL module (this is done via a macro in the source) but release it under a license that is not GPL-compatible?
2. Is it acceptable to recompile the Kernel to remove this restriction?
As far as I know neither of these have ever been tested, and there are differing opinions.
The argument goes along the lines that GPL-only symbols are so tightly coupled with the internals of the Kernel that by using them you are forming a derivative work of the Kernel, as opposed to just using interfaces in the same manner (legally-speaking) as a userspace program.
Producing and distributing a module that uses these symbols under a non-GPL compatible license is already an infringement, because you have produced a derivative work and distributed it outside the license conditions.
If you recompile your Kernel to remove the restriction then you may be aiding the module developer in committing a copyright violation.
I’m not sure how much I buy this argument personally, but I have seen it advanced (I think on the LKML).
> I think both them [the lawyers Linus claims he spoke to] said that anybody who were to change a xyz_GPL to the non-GPL one in order to use it with a non-GPL module would almost immediately fall under the "willful infringement" thing, and that it would make it MUCH easier to get triple damages and/or injunctions, since they clearly knew about it.
Again, not endorsing this argument, just pointing out that some people (e.g. Linus) claim this isn’t permitted.
I’m not entirely sure why people think this comment is worth downvoting: I have been very clear that I don’t really buy this argument, but I thought it was interesting and relevant to point out Linus’s take on the matter.
..."you are forming a derivative work of the Kernel"
Which in the case of ZFS is obviously nonsense. ZFS was developed on Solaris and ported to many other OSes. Its certainly not a derivative work of the linux kernel. This is a case of the linux kernel devs being bullies, and trying to make life harder for 3rd party modules.
If they can claim copyright violation for using a GPL-only symbol which didn't used to be GPL-only, then I think ZFS devs can claim an antitrust violation for locking them out of the kernel. Both legal concepts are absurd..
> This is a case of the linux kernel devs being bullies, and trying to make life harder for 3rd party modules.
I’m inclined to agree, but the fact that ZFS was developed on Solaris and ported to Linux is irrelevant in my opinion: the specific Kernel module using the GPL symbols would be the derivative work, not ZFS as a concept.
Your point about symbols being retroactively made GPL-only is very interesting, and I think it really undermines the Kernel developers’ position.
Again, I don’t really buy Linus’s argument at all, but I think it’s relevant to the discussion, which is why I mentioned it.
> Producing and distributing a module that uses these symbols under a non-GPL compatible license is already an infringement
Producing the module is not, on it's own, an infringement. It's only if you distribute or publish the result that you get into trouble with the GPL since you're not in a position to distribute re-licensed ZFS source code[1].
Thus it should be perfectly fine to have a package which downloaded the ZFS code and compiled a kernel module for that machine, as long as the user did not distribute the compiled kernel module to others in any way.
It wouldn't. Moreover I can't see that there is any reason that redistribution of such a kernel would be against GPLv2, the licence under which the kernel is distributed.
TBF, so long as we are arguing from authority, Linus isn't a lawyer either, and has produced heresay ("I talked to some lawyers..."), but no attorney's opinion on the matter.
The reasonably charitable case for your parent comment is -- Linus suggests such linking might show "willful infringement" IF an out of tree module used these symbols, AND, as indicated by the parent, these changes were distributed together implicating the GPLv2 license's Sections 2 and 3.
Otherwise how would this ever be a problem? If I linked to a GPLv2 only interface in the privacy of my own home, never distributing the changes, what section of the license requires me to make available my changes? The GPLv2 gives me explicit permission to modify the sources?
> TBF, so long as we are arguing from authority, Linus isn't a lawyer either, and has produced heresay ("I talked to some lawyers..."), but no attorney's opinion on the matter.
Yes, that’s essentially a rephrasing of my comment that you replied to.
Then perhaps I misunderstood your comment? It went pretty hard at a guy/gal who was simply stating the obvious -- permission to modify sources is already given within the GPLv2 itself. Imagine this colloquy --
Linux devs: "We've created a GPL only interface. Here are the sources."
Downstream user: "Okay I've modified these symbols to be not be GPL only anymore."
Linux devs: "You can't do that!"
Downstream user: "But you've given me permission to modify the sources in your license?!"
Certainly a copyright holder can give special additional permission to use software in contravention of the express terms of the license. The only problem is getting the copyright holders agreement to do so. My understanding of what you have argued is -- a copyright holder can place additional restrictions on the use and modification of software in contravention of the express terms of the license hidden within the software itself. You state:
The legal status of this is uncertain, since a number of questions naturally arise:
1. Is it acceptable to mark a Kernel module as a GPL module (this is done via a macro in the source) but release it under a license that is not GPL-compatible?
2. Is it acceptable to recompile the Kernel to remove this restriction?
As far as I know neither of these have ever been tested, and there are differing opinions.
This line of thought is problematic for several reasons. This most salient of which is -- this is exact argument used against ZFS in the kernel: that the CDDL's additional terms/restrictions are incompatible with the GPLv2.
Imagine again --
Linux devs: "We've created a kernel module that can't be used by Russians invading Ukraine."
Other kernel devs, estates of deceased developers, etc.: "But our understanding was that all our contributed sources would be available under the GPLv2, not some weird hybrid which can be modified willy nilly with new restrictions by any future dev."
When someone says -- "Here is your license to use my software," it is reasonable to believe you can take them at their word, and there aren't additional license restrictions lurking somewhere else.
That isn’t possible as I understand it.
Loading any non-GPL module will mark the Kernel as tainted, but that’s not the issue here.
The problem is that the ZFS module uses Kernel symbols that are marked as GPL-only, meaning that the Kernel will refuse to load the ZFS module as it isn’t marked as a GPL module. There isn’t any way to bypass this short of recompiling the Kernel to remove this restriction.
The legal status of this is uncertain, since a number of questions naturally arise:
1. Is it acceptable to mark a Kernel module as a GPL module (this is done via a macro in the source) but release it under a license that is not GPL-compatible?
2. Is it acceptable to recompile the Kernel to remove this restriction?
As far as I know neither of these have ever been tested, and there are differing opinions.