7 ms·
> Why shouldn't a proprietary driver be able to interact with a free kernel? Proprietary drivers can interact with the Linux kernel. Provided they only use fa
by Karellen 3y ago
> Why shouldn't a proprietary driver be able to interact with a free kernel?
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. See the text of the GPL-2, which the kernel is licensed under:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
> This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law:
> These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Note that the LGPL exists specifically to allow the linking of separate Free and proprietary software, which is forbidden by the GPL. But Linux is licensed under the GPL-2, so those extra permissions do not apply.
If the Nvidia driver stuck to the generic kernel API, it would be fine. But it doesn't. It tries to use Linux-only APIs, which are marked for use by license-compatible GPLd drivers, without itself being GPLd.
This is a clear violation of the Free Software license that Linux is made available under.
- em-bee 3y agoi 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?
- klempner 3y agoThe "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.
- em-bee 3y agothe 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.
- adrian_b 3y agoThe 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.
- em-bee 3y agoah 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.
- adrian_b 3y ago> 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.
- Karellen 3y agoIt'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.
- adrian_b 3y agoWriting 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.
- Dylan16807 3y ago> 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.
- pdonis 3y ago> 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.
- yjftsjthsd-h 3y ago> 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?
- Measter 3y agoSurely 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.
- tzs 3y ago> 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.