Hell, Linux even uses DRM (not the Direct Rendering Manager, Digital Rights Management) to check if your LKM is licensed properly to call those APIs. GPL-incompatible libraries only get to link to functions that are rough equivalents to syscalls.
That said I'm surprised by what you describe as I'm struggling to understand how that works -- you're saying the Linux kernel has a secret API, surely one can read the source and/or documentation and find the API details. Or are you saying calls to kernel APIs are cryptographically protected? Could you give details of what this system is called, thanks.
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.
In order to make it more difficult for developers of kernels modules that break the law by running roughshod over the GPL, the kernel developers decided to only make these available to modules that claim to be under the GPL [10]. Please note that module developers can still easily distribute modules that use the "GPL only" APIs but they have to explicitly state that they are using GPL only code (thereby signalling that any copyright infringement is willful).
Calling this "DRM" seems a little disingenuous to me. Anybody can legally remove these protections from their own kernels without any legal repercussions. Removing DRM protections (in the USA) is a felony that carries up to five years in prison. DRM is intentionally obfuscated and poorly documented. The kernel makes its license clear and obvious.
Whether or not GPLv2 precludes a DMCA 1201 claim is still in question. On one hand, the GPL says you can make whatever changes you like. On the other, the Linux kernel module loader is specifically enforcing GPL's share-alike requirement, which is a predicate of the right to make modifications to the kernel. This is the heart of what DMCA 1201 is trying to do: extend copyright protection to software that enforces copyright.
If Linux had been re-licensed to GPLv3, this wouldn't be an issue, because v3 specifically has a clause intended to disclaim any and all construable technical protection measures under DMCA 1201.