5 ms·

Why shouldn't a proprietary driver be able to interact with a free kernel? Linux is literally implementing kernel level DRM, the thing free software swore to d

Why shouldn't a proprietary driver be able to interact with a free kernel? Linux is literally implementing kernel level DRM, the thing free software swore to destroy. Or at least the requirement that proprietary drivers do not interact with GPL-only code would in my opinion be considered an EULA.

jeroenhd 3y ago
> Why shouldn't a proprietary driver be able to interact with a free kernel? Because the kernel is licensed under GPL, that's kind of the whole point of Linux. The intention of the license is that anything linked and loaded into the kernel is released under a compatible copyleft license.
- linuxftw 3y ago
  Technically that's wrong. Anything you distribute to another person needs to be GPL. You can link and load anything you want into the kernel for your own purposes. Personally, I'm not persuaded that a loadable proprietary kernel module would constitute a derivative work, I don't see how the GPL could be enforced on a 3rd party like that. I think the courts and juries would be very sympathetic to Nvidia.
  - jeroenhd 3y ago
    If the GPL status wasn't a problem, Nvidia wouldn't be so nice to Linux. They could just as easily patch out the GPL symbol routines in a malware like fashion, yet the billion dollar company decides to play nice. All Linux would need is for one court in one relevant jurisdiction to interpret GPL like they do. If a French court forces Nvidia to stop making selling data centre products in France, that'd be enough to seriously hurt Nvidias's bottom line. Maybe the Texas it Hamburg courts will side with Nvidia, but Nvidia needs to win everywhere and Linux only needs to win once.
  - grotorea 3y ago
    IANAL, but I suspect you're right. The GPL restricts redistribution, but does it impose any restriction on someone who downloads and compile their own kernel and downloads and links the NVIDIA driver against it, then never redistributes it? However the Linux devs are still allowed to do whatever they want to make it harder on NVIDIA. Also I assume the distros count as redistributors so they probably can't combine NVIDIA and GPL parts of the kernel.
    - linuxftw 3y ago
      Nvidia wants to distribute their proprietary driver separate from the kernel. GPL is a copy-left license, meaning any derivative works are subject to the GPL. Currently Nvidia creates a proprietary driver that is not specific to linux, thus is not a derivative work. Then, they create a 'shim' layer that links their driver into the kernel. While the shim is a derivative work, the driver is not, thus copy-left doesn't apply to the driver. I think many/most would consider the ability to write loadable kernel modules an "API". Google v Oracle decided in the US Supreme court that APIs are not copyrightable. From [1]: > Supreme Court ruled in a 6–2 decision that Google's use of the Java APIs fell within the four factors of fair use, bypassing the question on the copyrightability of the APIs. IMO, Nvidia doesn't even need a shim layer, they're just playing nice. If push comes to shove, I think Nvidia will win in court. 1: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
      - cmeacham98 3y ago
        > Google v Oracle decided in the US Supreme court that APIs are not copyrightable. This is not true. The appeals court ruled that the API was copyrightable, and the Supreme Court opted not to rule on whether or not APIs are copyrightable. What the Supreme Court actually ruled on is that in this specific instance, Google's use of the API would qualify as fair use - and thus it didn't matter if the API is copyrightable or not.
        linuxftw 3y ago
        My mistake, thanks for the clarification. Anyway, Google re-implemented the Java API in many areas, not just wrote code to interact with it. Either way, I think a loadable module would fall under similar treatment.
kmeisthax 3y ago
Linux's license is GPLv2 plus a syscall exception. If it was GPLv2 alone, proprietary modules would probably be infringing. However, since Linus specifically said syscalls don't trip GPL copyleft, kernel symbols that are syscall equivalents also don't trip GPL copyleft. So they have to have a loader that checks license data to know what symbols can and can't be linked to avoid a license violation under Linus's interpretation of their GPL exceptions. You are correct that this is kernel level DRM[0], and Linus might even have a legal claim against Nvidia for circumvention of copy protection here. GPLv3 explicitly disclaims any form of copy protection in covered code, which would at least theoretically prevent this kind of lawsuit, except the clause isn't court-tested and Linus specifically hates GPLv3 for adding the TiVo clause[1]. This was implemented decades ago, and the original goal was actually just to stop getting bug reports relating to crashes in the Linux kernel caused by proprietary modules they can't fix. Enforcing the GPL was a side benefit. [0] Not to be confused with the other DRM in the kernel, the Direct Rendering Manager. [1] He doesn't hate the TiVo clause itself, he just doesn't like retroactively adding it to v2 software and changing the deal, because he doesn't like what he feels is Linux being co-opted by the FSF.
- nextaccountic 3y ago
  > Linux's license is GPLv2 plus a syscall exception. Did Linus really sought to have every contributor of Linux that licensed their contribution as GPLv2 agree to this specific exception, and relicense it as GPLv2 plus syscall exception? This sounds unbelievable. When one checks the wording of the "exception", https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note https://github.com/torvalds/linux/blob/master/LICENSES/excep... it says > NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work". This just seems like a legal opinion of Linus that states that userland programs are not derivative from the kernel (and thus don't need to be licensed as GPLv2 themselves), but this is kind of obvious and expected, right? I mean, userland Windows programs aren't derivative from the Windows kernel either, or macOS programs from XNU, or etc. Also note that at the moment Linux was created, all Linux programs were originally made for other operating systems. Programs like bash and gcc predate Linux. They couldn't be derivative works of the kernel, even if they wanted to, because the kernel didn't exist when they were created. I highly doubt that any kernel developer could successfully sue authors of userland programs for copyright infringement, regardless of what Linus thinks about it. So this isn't really an exception of the GPLv2 but just a _clarification_ that the wording of the GPLv2 shouldn't be interpreted in a way to make userland programs infringing (because they aren't, and wouldn't be even if Linus didn't clarify) This means that Linux is free to incorporate any GPLv2 code it wishes without asking people to relicense it as "GPLv2 plus syscall exception" because Linux itself is just GPLv2.
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 ago
  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?
pjc50 3y ago
This isn't DRM, it's regular old software licensing. > the requirement that proprietary drivers do not interact with GPL-only code would in my opinion be considered an EULA. The requirement that proprietary code does not ""incorporate"" GPL code is the GPL, and the entire point of it. However, it might be reasonable to argue to what extent merely linking against an API is infringing. I can see that going in either direction, and such a ruling would have a big impact on GPL either way.
- jesprenj 3y ago
  While this requirement may really be in the GPL, there is no way to enforce it if the party creating a proprietary driver does not distribute the Linux kernel itself. In other words, as far as I understand, Nvidia does not exercise the rights of distribution that GPL provides, so they do not have to follow any additional rules of the GPL. GPL regulates distribution, not _use_ of software (see free software freedom 0).
  - tremon 3y ago
    I think the core argument is that distributing a proprietary driver that's obviously meant to be loaded into the Linux kernel to be useful is distributing a derived work -- since the Linux kernel has a syscall exception, but not a linking exception. So the problem isn't that Nvidia may or may not be distributing the kernel itself; it is distributing a derived work of the Linux kernel, and that must be licensed accordingly. But I may have misunderstood/misremembered the details. It's been years since I cared enough to do a deep dive on this.
    - dragonwriter 3y ago
      > I think the core argument is that distributing a proprietary driver that’s obviously meant to be loaded into the Linux kernel to be useful is distributing a derived work Whether functional elements needed for interoperability are not covered by copyright (so that a work that seems “derived” through its use of them is not a “derivative work” at all) or whether using them is Fair Use (such that while a work using them might be a derivative work that would, but for Fair Use, require a license, it is nonetheless legal without a license due to Fair Use) seems to be a bit of a mixed bag, but either way using copyright to prevent functional interaction (except when you get into DMCA coverage of technical anti-circumvention measures, which is also part of copyright law, but not really applicable here) seems to be a difficult battle for copyright holders, in US law, at least.
Matl 3y ago
> Linux is literally implementing kernel level DRM, the thing free software swore to destroy. Free software enforcing its own principles is in no contradiction of free software. Why should proprietary software be able to get all the benefits of free software and play by none of its rules and free software is supposed to just take it? Even democratic societies have mechanisms to protect themselves that are restrictions of some kind on expression. There are plenty of proprietary OSes out there that give zero shits. Why there can't be some that do? Or does everything need to be just cold, industry serving tool without any human care behind it?

jeroenhd 3y ago

> Why shouldn't a proprietary driver be able to interact with a free kernel? Because the kernel is licensed under GPL, that's kind of the whole point of Linux. The intention of the license is that anything linked and loaded into the kernel is released under a compatible copyleft license.

linuxftw 3y ago
Technically that's wrong. Anything you distribute to another person needs to be GPL. You can link and load anything you want into the kernel for your own purposes. Personally, I'm not persuaded that a loadable proprietary kernel module would constitute a derivative work, I don't see how the GPL could be enforced on a 3rd party like that. I think the courts and juries would be very sympathetic to Nvidia.
- jeroenhd 3y ago
  If the GPL status wasn't a problem, Nvidia wouldn't be so nice to Linux. They could just as easily patch out the GPL symbol routines in a malware like fashion, yet the billion dollar company decides to play nice. All Linux would need is for one court in one relevant jurisdiction to interpret GPL like they do. If a French court forces Nvidia to stop making selling data centre products in France, that'd be enough to seriously hurt Nvidias's bottom line. Maybe the Texas it Hamburg courts will side with Nvidia, but Nvidia needs to win everywhere and Linux only needs to win once.
- grotorea 3y ago
  IANAL, but I suspect you're right. The GPL restricts redistribution, but does it impose any restriction on someone who downloads and compile their own kernel and downloads and links the NVIDIA driver against it, then never redistributes it? However the Linux devs are still allowed to do whatever they want to make it harder on NVIDIA. Also I assume the distros count as redistributors so they probably can't combine NVIDIA and GPL parts of the kernel.
  - linuxftw 3y ago
    Nvidia wants to distribute their proprietary driver separate from the kernel. GPL is a copy-left license, meaning any derivative works are subject to the GPL. Currently Nvidia creates a proprietary driver that is not specific to linux, thus is not a derivative work. Then, they create a 'shim' layer that links their driver into the kernel. While the shim is a derivative work, the driver is not, thus copy-left doesn't apply to the driver. I think many/most would consider the ability to write loadable kernel modules an "API". Google v Oracle decided in the US Supreme court that APIs are not copyrightable. From [1]: > Supreme Court ruled in a 6–2 decision that Google's use of the Java APIs fell within the four factors of fair use, bypassing the question on the copyrightability of the APIs. IMO, Nvidia doesn't even need a shim layer, they're just playing nice. If push comes to shove, I think Nvidia will win in court. 1: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
    - cmeacham98 3y ago
      > Google v Oracle decided in the US Supreme court that APIs are not copyrightable. This is not true. The appeals court ruled that the API was copyrightable, and the Supreme Court opted not to rule on whether or not APIs are copyrightable. What the Supreme Court actually ruled on is that in this specific instance, Google's use of the API would qualify as fair use - and thus it didn't matter if the API is copyrightable or not.
      - linuxftw 3y ago
        My mistake, thanks for the clarification. Anyway, Google re-implemented the Java API in many areas, not just wrote code to interact with it. Either way, I think a loadable module would fall under similar treatment.

kmeisthax 3y ago

Linux's license is GPLv2 plus a syscall exception. If it was GPLv2 alone, proprietary modules would probably be infringing. However, since Linus specifically said syscalls don't trip GPL copyleft, kernel symbols that are syscall equivalents also don't trip GPL copyleft. So they have to have a loader that checks license data to know what symbols can and can't be linked to avoid a license violation under Linus's interpretation of their GPL exceptions. You are correct that this is kernel level DRM[0], and Linus might even have a legal claim against Nvidia for circumvention of copy protection here. GPLv3 explicitly disclaims any form of copy protection in covered code, which would at least theoretically prevent this kind of lawsuit, except the clause isn't court-tested and Linus specifically hates GPLv3 for adding the TiVo clause[1]. This was implemented decades ago, and the original goal was actually just to stop getting bug reports relating to crashes in the Linux kernel caused by proprietary modules they can't fix. Enforcing the GPL was a side benefit. [0] Not to be confused with the other DRM in the kernel, the Direct Rendering Manager. [1] He doesn't hate the TiVo clause itself, he just doesn't like retroactively adding it to v2 software and changing the deal, because he doesn't like what he feels is Linux being co-opted by the FSF.

nextaccountic 3y ago
> Linux's license is GPLv2 plus a syscall exception. Did Linus really sought to have every contributor of Linux that licensed their contribution as GPLv2 agree to this specific exception, and relicense it as GPLv2 plus syscall exception? This sounds unbelievable. When one checks the wording of the "exception", https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note https://github.com/torvalds/linux/blob/master/LICENSES/excep... it says > NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work". This just seems like a legal opinion of Linus that states that userland programs are not derivative from the kernel (and thus don't need to be licensed as GPLv2 themselves), but this is kind of obvious and expected, right? I mean, userland Windows programs aren't derivative from the Windows kernel either, or macOS programs from XNU, or etc. Also note that at the moment Linux was created, all Linux programs were originally made for other operating systems. Programs like bash and gcc predate Linux. They couldn't be derivative works of the kernel, even if they wanted to, because the kernel didn't exist when they were created. I highly doubt that any kernel developer could successfully sue authors of userland programs for copyright infringement, regardless of what Linus thinks about it. So this isn't really an exception of the GPLv2 but just a _clarification_ that the wording of the GPLv2 shouldn't be interpreted in a way to make userland programs infringing (because they aren't, and wouldn't be even if Linus didn't clarify) This means that Linux is free to incorporate any GPLv2 code it wishes without asking people to relicense it as "GPLv2 plus syscall exception" because Linux itself is just GPLv2.

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 ago
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?

pjc50 3y ago

This isn't DRM, it's regular old software licensing. > the requirement that proprietary drivers do not interact with GPL-only code would in my opinion be considered an EULA. The requirement that proprietary code does not ""incorporate"" GPL code is the GPL, and the entire point of it. However, it might be reasonable to argue to what extent merely linking against an API is infringing. I can see that going in either direction, and such a ruling would have a big impact on GPL either way.

jesprenj 3y ago
While this requirement may really be in the GPL, there is no way to enforce it if the party creating a proprietary driver does not distribute the Linux kernel itself. In other words, as far as I understand, Nvidia does not exercise the rights of distribution that GPL provides, so they do not have to follow any additional rules of the GPL. GPL regulates distribution, not _use_ of software (see free software freedom 0).
- tremon 3y ago
  I think the core argument is that distributing a proprietary driver that's obviously meant to be loaded into the Linux kernel to be useful is distributing a derived work -- since the Linux kernel has a syscall exception, but not a linking exception. So the problem isn't that Nvidia may or may not be distributing the kernel itself; it is distributing a derived work of the Linux kernel, and that must be licensed accordingly. But I may have misunderstood/misremembered the details. It's been years since I cared enough to do a deep dive on this.
  - dragonwriter 3y ago
    > I think the core argument is that distributing a proprietary driver that’s obviously meant to be loaded into the Linux kernel to be useful is distributing a derived work Whether functional elements needed for interoperability are not covered by copyright (so that a work that seems “derived” through its use of them is not a “derivative work” at all) or whether using them is Fair Use (such that while a work using them might be a derivative work that would, but for Fair Use, require a license, it is nonetheless legal without a license due to Fair Use) seems to be a bit of a mixed bag, but either way using copyright to prevent functional interaction (except when you get into DMCA coverage of technical anti-circumvention measures, which is also part of copyright law, but not really applicable here) seems to be a difficult battle for copyright holders, in US law, at least.

Matl 3y ago

> Linux is literally implementing kernel level DRM, the thing free software swore to destroy. Free software enforcing its own principles is in no contradiction of free software. Why should proprietary software be able to get all the benefits of free software and play by none of its rules and free software is supposed to just take it? Even democratic societies have mechanisms to protect themselves that are restrictions of some kind on expression. There are plenty of proprietary OSes out there that give zero shits. Why there can't be some that do? Or does everything need to be just cold, industry serving tool without any human care behind it?