On Sat, May 04, 2019 at 04:28:17AM +0200, Sebastian Gottschall wrote:
Am 04.05.2019 um 02:47 schrieb Ingo Molnar:
- 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 fpu code in kernel space in a kernel module is a derived work of the kernel itself? dont get me wrong, but this is absurd. i mean you limit the use of cpu instructions. the use of cpu instructions should be free of any licensing issue. i would even argument you are violating the license of the cpu ower given to the kernel by executing it, by restricting its use for no reason
Now you are just being crazy, please go talk to a lawyer about how the GPL actually works.
If Andy wants to change the symbol of what he wrote from EXPORT_SYMBOL_GPL() to EXPORT_SYMBOL(), that's fine, it's his option. Any loony discussion about if this is actually a licensing issue or not needs to just go to /dev/null
As homework, everyone please go read this: http://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed... and remember that the license of the Linux kernel is GPLv2.
Now where's the "kill this thread" option on mutt so I don't have to see any more of this nonsense...
greg k-h