Hacker News Reader

> This is a clear violation of the Free Software license that Linux is made available under.

I don't see why. The "Linux-only APIs" are a feature imposed by the Linux kernel developers, not by the GPL. Trying to circumvent it is of course contrary to the wishes of the Linux kernel developers, but that doesn't mean it's a violation of the GPL. The GPL does not say that no program that interfaces with a GPL-licensed work can do anything the authors of the GPL-licensed work don't like.

It would be a violation of the GPL if NVidia tried to ship its own Linux distro including its proprietary drivers. But it's not doing that. NVidia doesn't ship Linux at all. Linux users install NVidia's drivers alongside the Linux that they install.

> This is a clear violation of the Free Software license that Linux is made available under.

This is your opinion.

My opinion is that it is a clear violation of the GPL if a program provides two sets of interfaces, one set to be used by other GPL programs and one set with crippled performance for non-GPL programs.

This is a restriction on use that has nothing to do with GPL, which says: "This License explicitly affirms your unlimited permission to run the unmodified Program.".

Crippling the performance for the users who choose to use the GPL program together with a non-GPL program is definitely incompatible with "unlimited permission to run".

Whoever has written the original GPL program has no right to impose limits on the users of the program. If they want to impose limits, they must choose a different license, not GPL.

The restrictions imposed by GPL are based on copyright, i.e. they refer to transferring copies of the covered work, but not to how it should be used.

It's not a restriction on use.

The GPL does not prevent users from running the Linux kernel in any manner they choose.

What it does disallow is for users to write code which is "based on" Linux code, and then distribute that code to other users on terms which are incompatible with the GPL.

You can run whatever mix of GPLd and non-GPLd code you want. You can even edit your Linux sources in a way that removes the GPL license checks for modules and build your own kernel, and run it, and no-one can legally stop you - not even Linus himself.

But you're not allowed to distribute work-based-on-GPLd-code-that-isn't-licensed-under-the-GPL to anyone else. And neither is Nvidia.

Unfortunately, suing Nvidia over this would cost millions, if not tens of millions, if not hundreds of millions, of dollars. So creating a technological barrier to fuck with them and their bullshit business model instead is a much more achievable goal.

Writing a program "based on" an API, i.e. which invokes the provided functions, is not a derivative work.

If this theory would be accepted almost all the existing programs that have been written since the first electronic computers would be derivative works and no software companies would have ever existed, because they could never have claimed copyright protection.

NVIDIA has never distributed any derivative of the Linux kernel in their GPU drivers. They distribute their own kernel modules, which are loaded by the end user and this is perfectly compatible with the GPL.

Some kernel developers try to cripple the NVIDIA modules by preventing them to find the symbol addresses that must be used, but this is a use restriction imposed by these developers on the Linux users and which has nothing to do with what is written in the GPL.

> Writing a program "based on" an API, i.e. which invokes the provided functions, is not a derivative work.

If that were the case, the LGPL would never have been needed.

Indeed, the LGPL should never have been needed, because LGPL is the correct variant of GPL and the standard GPL should have been identical to what LGPL is now.

Even with its illogical theory about the coverage of "combined" works, not even the GPL covers the programs that use an interface provided by a GPL program, but which are distributed only separately from it, like a shared library or a kernel module.

So the NVIDIA kernel modules have never been incompatible with the GPL.

The fight against non-GPL kernel modules has nothing to do with the GPL, but it is strictly the creation of certain kernel developers.

With static linking you take someone elses code and put it into your own artifact and then distribute that to users. This means that you need a license to distribute their code. Not just that, because of the way static linking works, you need a license to distribute modified version of the code.

With dynamic linking you never distribute someone else's code so you don't need a license to distribute it.

> Crippling the performance for the users who choose to use the GPL program together with a non-GPL program is definitely incompatible with "unlimited permission to run".

How so? It says "run the unmodified Program". The checks the Linux kernel does are part of the unmodified program. If that unmodified program doesn't meet a particular user's needs, they can go find some other program. The GPL does not impose any requirement that the unmodified Program must meet all of the needs of all users. Nor does it impose any requirement that the unmodified Program must treat all other programs equally. Nor does it impose any requirement that the unmodified Program cannot have any restrictions on use that are not explicitly imposed by the GPL.

> Proprietary drivers can interact with the Linux kernel.

> Provided they only use fairly generic OS-functions, which are to be found in many similar kernels. Such drivers, which do not rely on Linux-specific functions, cannot be considered "derived works" of the Linux kernel, and are therefore free to choose whatever license they like.

> However, any driver which makes use of Linux-kernel-specific interfaces, which are not found in other OSs (even in other Unix-like kernels) are, pretty much by definition, a "work based on the program" of the kernel and therefore must be licensed similarly.

Now given that, can you explain why the "save the FPU state" function is marked as one of those special interfaces?

The marking on symbols cannot be trusted.

> However, any driver which makes use of Linux-kernel-specific interfaces, which are not found in other OSs (even in other Unix-like kernels) are, pretty much by definition, a "work based on the program" of the kernel and therefore must be licensed similarly

GPLv2 defines a "work based on the program" thusly: "a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language"

To be a derivative work of another work under US copyright law the work must contain sufficient copyrightable elements copied from that other work to require permission from the owner of that other work's copyright owner.

If all you've copied is a few function names and data structure layouts in order to call those functions that seems unlikely to be enough to make your work a derivative work. It doesn't really matter whether or not those functions do things found in many other works or just one, because you aren't copying the functions themselves.

> Note that the LGPL exists specifically to allow the linking of separate Free and proprietary software, which is forbidden by the GPL.

Linking GPL and proprietary software together is not forbidden by the GPL. If you do so though GPL imposes requirements on you if you distribute the result, and those requirements will likely be impossible to meet.

If you are just linking the GPL and proprietary software for you own use GPL does not care.

i am all for promoting GPL code and i prefer that non-free kernel modules would not exist, but is there any reason other than promoting the GPL why a non-free module should not use linux-only APIs?

or the reverse, if getting rid of non-free modules is the goal, why even have a syscall exception? why not force all modules to be GPL?

The "syscall exception" is there to make clear that userspace acting on the defined ABI/API boundary between userspace and the kernel doesn't need to be GPL, even if it is using linux specific userspace APIs that might otherwise plausibly cause such a binary to be a derived work.

That is, yes, you're allowed to port non-GPL code to Linux.

On the other hand: the real practical concern that kernel developers have is needing to debug NVidia's closed source code, or people developing an expectation that such code (or the code of a hundred other vendors) won't be broken between kernel releases.

the exception for userspace obviously makes sense. but why and how are non-free kernel modules allowed at all? i'd think that userspace is a boundary that is easy to define, so it should have been possible to allow non-free userspace without allowing non-free kernel modules.

The non-free kernel modules are never included in the kernel. They are loaded by the end user, so they are not covered by GPL.

Except for the fact that the CPU is in privileged mode, there is no difference between loading a kernel module and launching a dynamically-linked user-mode executable file.

Not all non-GPL modules or executables are non-free. Many have licenses that are more permissive than GPL, e.g. BSD or MIT, but they are still affected by these anti-non-GPL measures.

If non-GPL kernel modules were not permitted, then by the same reasoning no non-GPL executable files should be permitted, so in such Linux computers absolutely all programs, libraries and modules would have to be GPL.

Perhaps there are people who dream to use such a computer. I have been using Linux for decades and I have never seen a single computer that would have remained useful for anything after the instant when all the non-GPL programs would have been deleted from it.

ah yes, of course. kernel developers can not control what modules i load, they can only control if the module violates the GPL which it only does if it is a derivative work which is only the case if linux specific APIs are used.

I have been using Linux for decades and I have never seen a single computer that would have remained useful for anything after the instant when all the non-GPL programs would have been deleted from it.

if that includes any non-GPL FOSS, sure, but most such software would have switched to GPL very quickly if that would have been the case.

> is there any reason other than promoting the GPL [...]

Isn't that reason enough?

> why even have a syscall exception?

Because Linus is more pragmatic than RMS.

Also, syscalls are generally not Linux-specific, so it would be hard to argue that programs that use them are "works based on" Linux. Making the syscall exception explicit is, IMO, mostly a historic reassurance for proprietary driver/program vendors that code they wrote for AIX/Solaris/HP-UX/etc... can be recompiled for Linux without risking any compliance issues.

> Because Linus is more pragmatic than RMS.

he probably is, but that is not the reason here. even RMS fully agrees that using it in the normal USING fashion does not trigger copyleft. This is why you can compile proprietary software with gcc, and similarly, when gcc had a java class library project, it was GPL+classpath exception

> but is there any reason other than promoting the GPL why a non-free module should not use linux-only APIs?

I think this question illustrates something of an invisible generation gap in software. GPL is not a utilitarian license. There is no materialistic value in choosing to use the GPL whatsoever. The text of the GPL is itself a legal edifice specifically designed to dismember the very framework in which it exists, rendering it anti-utilitarian.

This is all to say that the GPL is politics. One chooses the GPL specifically for political reasons. In politics, you do not go out of your way to aid your ideological adversaries; you either convert them or destroy them.

> if getting rid of non-free modules is the goal, why even have a syscall exception? why not force all modules to be GPL?

Despite what I just said about GPL as ideology, the GPL is simultaneously a legal construct which necessarily must bend to the rules of the framework it exists within. The logic of GPL extending through syscalls is based in a legal argument similar to that used in the Google vs. Oracle debacle -- we created the "shape" of this API, so we have certain rights regarding it. The "shape" of the Unix syscalls predate Linux and are therefore beyond the project's reach, legally speaking.

The best analogy for the GPL that I've seen is to consider what happens with a typical for-profit corporation. If you join the company (they have to agree to hire you for this to happen), then in the work you do for the company, you have free access to all the IP of the company, to whatever extent is it useful in the tasks you are undertaking within the company. You must, of course, promise not to leak the IP outside the company.

Now consider that there is a similar organization: a not-for-profit organization of programmers for which the only qualification for entry is that you agree to use the same license as everybody else. Once you do, you are free to use all the IP of the organization. You may not, however, use the IP of the organization for things you might do under different licenses, since that is not considered to be within the scope of the organization.

In short: if you don't want to join the GPL "organization", don't. But just as you don't expect to get access to Nvidia's internal IP unless you join Nvidia, don't expect to get access to the GPL organization's IP.

> However, any driver which makes use of Linux-kernel-specific interfaces, which are not found in other OSs (even in other Unix-like kernels) are, pretty much by definition, a "work based on the program" of the kernel and therefore must be licensed similarly. See the text of the GPL-2, which the kernel is licensed under

Does that follow? If someone makes a program that uses an API that's only found in NT or XNU, does that program become a derivative work of those kernels?

Surely this argument could also apply to hardware. A piece of hardware's interface would be its API, which would surely mean that any software written to use that interface (drivers) would be a derivative work.

Which in the case of proprietary hardware, using non-standard interfaces, would mean that software would need a license from the manufacturer to be distributed.