I'm on mobile so I can't give you more details but you can probably find more if you look in that direction
I'm on mobile so I can't give you more details but you can probably find more if you look in that direction
Kernel is GPL, so only GPL modules can touch its internal APIs. For non-derived works, there is a subset of APIs, that are declared to be fine if used by non-GPL code. ZFS had a problem, where they were using something that should not be used (fp in kernel), which got removed and they had to find a replacement, which was GPL-only.
It is also necessary to say, that this is honor-based. Any module declares its license and the linker either allows or not allows resolving a symbol. There are no checks whether the module is really GPL or not, it is to show intent, and if you want to cheat, you must do it willfully, not by accident.
All that symbol did was tell the kernel to save the fpu registers.
It's dishonorable of the relevant kernel developers to pretend that's something relevant to the GPL.
And what's more pressing is, that it is an internal implementation details. Preserving it for ZFS would mean that they have to keep internal implementation detail for an external project, that does not care to cooperate!
These two symbols were obsolete for almost two decades. Should they keep them just for ZFS? Or should ZFS switch? If it were GPL project, or better, part of the kernel, it would be already fixed and everyone would go on with their lives.
The only meaningful difference was that one was marked GPL and the other wasn't.
Removing the one with __ can be justified pretty easily.
Insisting that the ones they kept should still be marked 'GPL' is where it gets ridiculous. Going in and out of FPU mode is not something that makes your code derivative of the kernel code.
Linus Torvalds, Mon, 10 Mar 2003 20:12:34 GMT
It would not... unless it becomes derived work.