Calling what you describe DRM is pretty deceptive. Can you get access to DRM-ed materials by promising to share them freely under an open license?
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.
Under the GPL, a "combined work" must also be distributed under the GPL. Given that use of certain kernel APIs requires the inclusion of large GPL'd header files, the kernel developers require that any modules that include this GPL'd code be also released under the GPL.
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.
Under DMCA 1201, this sort of measure would probably be legally considered DRM. All you need is a technical mechanism that controls access to a copyrighted work. You do not need obfuscation or encryption in order to make 1201 claims.
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.
The zfsonlinux developers complained a while ago that some API they were using became GPL only and I think they had to write a wrapper in GPL to get around it.
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.
> 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.
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.
It was more complicated than that. Some architectures do not support that.
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.
There were two sets of exports. __kernel_fpu_begin/end and kernel_fpu_begin/end.
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.
it seems quite clear ZFS is not a derived work of the Linux kernel, given it was developed for and extracted from Solaris, and that same code works on FreeBSD and Illumunos
> In other words: it's still very much a special case, and if the question was "can I just use FP in the kernel" then the answer is still a resounding NO, since other architectures may not support it AT ALL.
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.