Hacker News new | past | comments | ask | show | jobs | submit login

I do not agree with the theory that linking one program to another makes the former a derivative of the latter, therefore I do not agree that a kernel module is a derivative of the kernel, when it just uses the interfaces that must be used to accomplish its function.

If this theory, which is the only point of disagreement between me and Richard M. Stallman, would be accepted to be true, then what would stop Microsoft to claim that every program that has ever been written to run on Windows is the property of Microsoft?

When there are two hardware vendors, one who offers open-source device drivers and one that offers proprietary drivers, I would always choose the one with open-source device drivers.

Unfortunately, in the case of NVIDIA there are applications for which no other vendor attempts to provide competitive products, so there is no alternative choice. Therefore it does not matter if I would be "mad" at NVIDIA, as that could change nothing.

On the other hand, I am "mad" at this kind of kernel developers, because I do not accept that they have any right to dictate to the Linux users what kind of hardware they should buy. Obviously, they should not support NVIDIA, but inventing methods to sabotage the Linux users that have NVIDIA GPUs is not a justifiable activity.




If a kernel module is not derivative of the kernel, what use does it then serve once separated from any Linux GPL code?


This argument is lame.

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.


The OS/user-space boundary has always been defined by Linux (and by Linus) as a license boundary.

And the GPL has always noted exceptions for system-provided libraries.

Kernel modules run inside kernel-space. They are completely unlike user space applications.


> 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!




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: