If a Windows program is not a derivative of the Win32 libraries owned by Microsoft, what use does it serve once separated from the Microsoft libraries?
If an Android application is not a derivative of the Android OS owned by Google, what use does it then serve once separated from the Android base system?
If any C program that has ever been written (except those written for freestanding environments) is not a derivative of the C Standard Library, what use does it serve once separated from libc?
If your argument were right, with the exception of the very small number of programmers who write programs for bare-metal embedded systems, all the other programmers have written all their lives only derivative programs, so none of them (or of their employers) has any right to claim copyright ownership on what they have written.
> They are completely unlike user space applications.
Why?
I cannot see any difference from the POV of copyright. There is no difference between the loading of a kernel module that must discover the addresses of the kernel symbols that it must use and the loading of a user-mode executable that must discover the addresses of the symbols that it needs from the libc shared library.
Also the GPL does not allow the bundling of non-GPL kernel modules with the Linux kernel but it cannot restrict in any way the right of any Linux users to use the kernel by loading any kernel modules they want.
These attempts made periodically by some kernel developers to cripple the performance of the non-GPL kernel modules by hiding the useful kernel symbols when such modules are loaded by the end users have nothing to do with the GPL.
They also do not hurt NVDIA or other hardware vendors, but only the Linux end users, whose systems become broken after kernel updates.
1. the copyright holder used a license that specifically exempts system provided libraries such as libc. User space applications therefore have zero licensing requirements imposed on them by using, for example, libc.
2. Yes, a kernel module will have to discover the address of kernel symbols in the kernel. And a user space application will have to discover the address of symbols in the libraries it dynamically links against. But neither the kernel module nor the application cross the OS/user-space boundary. The kernel module is derived from the kernel, and the user space application is derived from the libraries that it uses. But the user space application is not derived from the kernel.
3. Yes, users can do whatever they want. So sure, an enterprising coder could write their own NVidia driver module, have it use GPL symbols from the kernel, and nobody could stop them. What they cannot do is distribute that, and that is what NVidia does.
These claims are based on a non-careful reading of the GPL.
First, the "System Libraries" exemption also names explicitly the kernel.
More importantly, this exemption has nothing to do with determining whether some work is covered by GPL or not.
The "System Libraries" exemption allows a GPL program to be distributed together with "System Libraries", without providing the source code for those "System Libraries".
The GPL only claims to cover a work that is distributed to others ("conveyed") and which includes a GPL program that is "combined with it such as to form a larger program".
The GPL is not applicable to programs that use interfaces provided by a GPL program, but which are distributed independently of it to the end users, for instance kernel modules or shared libraries.
I've been in the libre software movement for about 30 years, and what you're not really coherently talking about has been thrashed to death for a bit longer than that.
You're going to get nowhere trying to claim that a user space application and a kernel module have the same relationship to the kernel. Actually, less than nowhere.
Isn’t the complaint all along that nvidia is just wrapping their windows code in a shim layer?
So the answer is it’s still a library of functions that provides a substantial portion of a display-driver, even separated from the kernel. a windows driver module/library backend for such is at least as useful as any other code!
