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

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