Not sure what's to gain here really. NVIDIA are free to remove this check and just ship their own Linux distro to their profitable customers.
It's desktop users with NVIDIA GPUs who will end up shafted.
It's desktop users with NVIDIA GPUs who will end up shafted.
That said, part of the reason nvidia is so popular is that it's easy to buy their cards, spin up a system, and let a researcher play with it. If people had to buy the dgx workstations for this it would limit them to only the high level cards. There are a lot of benefits to giving every researcher in a company their own hardware for experimenting and debugging before they send their models off to the big clusters for training.
Will it be enough to force them to stop fucking around? Probably not, but it's one more paper cut, and perhaps in the process of their fork they violate the GPL in a more openly and legally actionable way
Nvidia obviously has the resources and ability to make a Debian/Ubuntu derivative (or whatever) that can offer increased usability, performance, etc with their hardware. Nvidia may even save effort and cost internally by primarily focusing AI/CUDA driver development on their own distro as opposed to what I'm sure is currently a significant amount of patchwork, workarounds, etc for the bewildering array of variability currently present in the Linux ecosystem.
These users/customers aren't using a given Linux distro out of idealistic passion/preference for the distro like many users here - they just want to do AI. They're going to use the best tools available to achieve that goal.
Needless to say these massive thousands of Nvidia GPU deployments are highly orchestrated and if an Nvidia distro can offer even 1% improvement on the usability, performance, etc with their hardware these customers are going to deploy an Nvidia distro immediately. These customers are also likely effectively supporting a distro variant already and they would absolutely rather let Nvidia take on as much of this effort as possible. I'd venture to guess many Nvidia customers have actually been asking Nvidia for it - Nvidia may already effectively be doing it for them.
Lambda Labs (for example) already does this - shipping and supporting an Ubuntu derivative that does whatever you want with AI within seconds of booting their hardware. Even Oracle already does this and the recent issues with RHEL/Cent are yet another reason this makes sense to Nvidia. Nvidia also already does this with their Jetson line of hardware.
You're absolutely correct that it is the desktop users who will get shafted by this.
I've been a Linux desktop user since 1997. I love Linux. However, for something like this not even the might and influence of Linux/Linus/etc will "win" going up against Nvidia on this.
It stems from a "nerdy" interpretation of "linking" that considers as relevant the fact that the monolithic proprietary blob (encrypted, protected, unmodifiable) has some sort of internal interface that mirrors the way a user might use a hypothetical free version of the product (running proprietary processes on a free kernel/userland). But it ignores the fact that the user cannot in practice disentangle the product in any way. It is the user experience that should legally be the deciding factor.
I realize this may be a controversial stance, but consider - what if I released a proprietary and closed source desktop application that bundled into its binary a copy of the Linux kernel? Are the specifics of how it interacts internally with this code really relevant? Is this really a different situation than code that runs bare metal?
TiVo-ization is, releasing your code as FOSS, but enforcing in your hardware that you can only run vendor signed builds on the device, preventing users from running their own modifications to the software.
Most enterprise linux derivatives do not bundle proprietary linux modules with a modified linux kernel.
Similarly, the loader, BIOS, etc, are not encumbered by the kernel license.
The FSF gently disagrees with me. Tellingly, they won't commit to a clear distinction between "derived" and "mere aggregate", calling it a "legal question", but suggest that "a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)." I say this is a classic nerd mistake of reaching for technical solutions to social problems - the true criterion should be something more like "can the user run these components independently?".
If you wrote the firmware on your own before, and it works on multiple operating systems, and you didn't refer to Linux to use it... I don't understand how one would think it's a "derived work". How does it "derive" from Linux?
2. to trace from a source or origin
I don't really see the difference-- as long as you have tools to pull apart the disk image.
Can you modify the Linux part, and if so does the proprietary software still run?
If those two criteria are satisfied I think you could probably successfully argue that they are cleanly separable components within a "mere aggregate". If not, they pretty clearly are bound together into a larger combined work.
Generally, yes. Of course, some people have a custom init, and I don't think this really breaks things.
> Can you modify the Linux part, and if so does the proprietary software still run?
Yup, generally. Of course, the device itself may prohibit you from loading arbitrary software on it without rooting it or modifying the bootloader. You may not have a license to run the proprietary software with modified Linux, though.
You mention android smartphones above. The existence of LineageOS, etc, is evidence enough that you can do these things.
LineageOS proves nothing. It's a separate work.
In fact I will expect that one (cough Ubuntu cough) may do it on their own just to get a bigger slice of people working with Cuda
In the past they prevented people from running consumer GPUs on Xen systems.