* Jiri Kosina jikos@kernel.org wrote:
On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
Please don't start this. We have everything _GPL that is used for FPU related code and only a few functions are exported because KVM needs it.
That's not completely true. There are a lot of static inlines out there, which basically made it possible for external modules to use FPU (in some way) when they had kernel_fpu_[begin|end]() available.
I personally don't care about ZFS a tiny little bit; but in general, the current situation with _GPL and non-_GPL exports is simply not nice. It's not really about licensing (despite the name), it's about 'internal vs external', which noone is probably able to define properly.
But that's exactly what licensing *IS* about: the argument is that 'internal' interfaces are clear proof that the binary module is actually a derived work of the kernel.
(Using regular exported symbols might still make a binary module derived work, but it's less clear-cut.)
So don't be complicit with binary module authors who try to circumvent the GPL by offloading the actual license violation to the end user ...
If it would be strictly about license compatibility, that'd at least make us somewhat deterministic.
License compatibility is rarely deterministic to begin with, there's a lot of grey area. Adding _GPL increases the likelihood that the module using it has to be covered by the GPL too. In fact behavior of binary modules seems to confirm that legal expectation: very few binary modules are trying to circumvent _GPL symbols by ignoring the _GPL attribute.
Anyway, in terms of _GPL exports the policy has always been that if a major author of the code asks for a symbol to be _GPL, then it should be so, even if other authors have a different judgement.
Thanks,
Ingo