Take a look into the kernel-firmware repo, and you will see a tremendous amount of binary firmware blobs. For example the Intel micro-code blobs are protected by ~7 layers deep of encryption, wifi drivers may have government regulatory issues with sharing firmwares in anything but binary form. So let's please drop the evil binary blob nonesense...
The kernel does in fact accept small or large binary blobs, and some of them even come with source code...So I guess the key takeaway is to look at what separate the Nvidia driver/firmware from all those other binary firmware loading drivers.
Hint, it has more to do with hiding the program interface, and using abstractions within abstractions.
GP is likely referring to the userspace component of nvidia's driver, not the actual blob that gets loaded onto the gpu. If it is indeed true that you need to run proprietary userland code, then this open-source release is nothing but a way to circumvent the GPL issues that lead to nvidia's driver partially breaking in Linux 5.??.
While not ideal, I like many don't have a hard stance against loading proprietary hardware firmware blobs. I, however, absolutely take issue with running opaque user-space programs.
With a security-strengthened operating system, or with a VM/container/sandbox, it is possible to ensure that any opaque user-space program is no security risk.
I prefer very much open-source user-space programs for 2 reasons:
1. I am only seldom content with a program conceived by someone else, because usually I want to do something else than they had in mind and their program is suboptimal for my use case. When the program is open-source, that does not matter. I can modify it and combine it with other programs, to do whatever I like.
2. Whenever there are problems due to bugs, incomplete documentation or misconfigurations, if the program is open source any problem can be solved sooner or later, usually sooner. With proprietary programs, typically one gets only some incomprehensible error messages and it may happen that entire departments of IT professionals try for weeks to solve the problem, without any progress. (I had such a case last year; after upgrading an old company laptop with a new one, MS Teams stopped working; 4 or 5 IT support people distributed over 3 continents attempted to discover the cause over 2 weeks, but they all failed).
These 2 reasons make the open source programs much more desirable, but if you have to also use some opaque user-space programs for specific tasks, e.g. a Synopsys Verilog/VHDL synthesis program for designing with a FPGA, that is no big deal.
On the other hand, using an opaque kernel module which may contain either an intentional back-door or just an unintentional bug which may cause your computer to freeze exactly before saving some large piece of work, or which may corrupt you file buffers before being saved, this is much worse than the use of any opaque user-mode program.
This is absolutely not true.
It is possible to restrict an opaque user-space program to the minimal set of permissions it requires.
In this particular case, the program needs to manipulate system hardware in undocumented ways, via vendor code which is extending the kernel.
In theory this may be true. But the particular opaque user-space program is talking to a driver authored by the same team. That driver is talking to hardware that has access to all of the memory in your computer.
The odds are high that a userspace program talking to this kind of driver could make your computer do something you don't want it to do in a way that is very difficult to suss out just by reviewing the driver source code.
(I agree that an open driver is a great improvement over a closed one. But I don't think you can make any strong guarantees about the safety of the closed userspace portions of this one, yet.)
But I would prefer if the code I run in userspace or kernelspace is FOSS.
Personally I would try to decide on blob size and scope. With nvidias driver I suspect that require massive firmware and userspace blobs, and the kernel driver is probably just a pass-through API. I would argue that this doesn't really move the community forward.
However if the blobs are small and simple, and have specific scope and a reason, like legislation or security, maybe even calibration data blobs, are useful independent of the OS itself, then I would give them a pass, since it allows the community to build upon.
If trust is the issue, you would have to open source the hardware/the silicon as well.
If trust isn't the issue, but being able to do your own things with the hardware you own, this is sth. different.
Talking about strawman arguments... that's a doozie!
Instead of ignoring your strawman, staying focused on the topic...I'm going to address this nonesense...
Firstly Nvidia is not in violation of the GPL. Secondly, nobody cares about GPL violations, most certainly not the mainline kernel community. They do not pursue blatant GPL violations, because litigation is not productive in terms of improving the kernel, but keep in mind Nvidia is not violating the GPL. Thirdly, user space libraries that interface with a kernel API are not violating the GPL. Folks are allowed to run proprietary software on Linux. Do I like that, no... I certainly don't love it. However, Nvidia running user space graphics libraries is not much different than Radeon drivers using Mesa in userspace, it's how graphics architectures work in 2022.
So it's kidna ironic you're arguing about something separate (straw-man), and even then that argument fails...
Now then, putting your tangent aside... The whole point here is to start with the kernel, and get the kernel wrapper driver that interfaces with the hardware's firmware binary interface open sourced. The whole point is to get the driver into mainline, someday... Once we have that, we can untangle the the spaghetti of graphics API libraries, perhaps even port them to Mesa. Nvidia most certainly uses an intermediary low-level graphics representation for their graphics cards, so they can support all the various graphics APi's, or what not... it's a very common pattern for graphics cards... one Radeon even fell into not long ago. So it's just a matter of time before we decode this stuff.
But you're not wrong in terms of Nvidia's overall stack being proprietary, at least for now. But that's not important, what's important is Nvidia users wont' have so much drama when their distro kernel upgrades, and they screen goes blank thanks to Nvidia's driver not being compatible with the changed kernel ABI, and the AKMOD not being able to handle it.
Easily changed likely means there's a physical knob somewhere that you could accidentially poke as a layperson.
Not that you get a three year CS education, figure out how your distribution packages dependencies, install the correct embedded toolchain (good luck), find out exactly which chip is in your device, fetch the proper firmware source code in the right version, build the thing, figure out how to flash the result onto the chip / read the Linux kernel sources to figure out the filename inside /lib/firmware. That's not easy.
Even if this entire process was packaged (it is--see <https://packages.debian.org/sid/firmware-linux-free>), it probably still doesn't count (or at least shouldn't count) as "easily" changed.
