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.
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).
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.
> 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.
> seems to be a difficult battle for copyright holders, in US law, at least.
heh, I wonder if you could argue that the catalog of functions/methods/symbols is a database and should thus be copyrightable under EU law.
it would obviously be hugely destructive if upheld, but, I think "database right" is fairly incoherent as a concept anyway, other than as an attempt to uphold "sweat of the brow doctrine" (ie "anything I worked to make should be mine by law"), which is already discredited in US law.
DRM refers to code which enforces (or attempts to enforce) license restrictions. So, by definition, writing code which attempts to enforce GPL compliance from kernel modules is DRM.
The GPL itself is just an idea. I can download GNU emacs, strip out any reference to freedom, and distribute that to others under my own proprietary license. I would be violating the license, obviously, and a court could prevent me from doing so, but nothing in Emacs itself would.
> 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.