My view is that nvidia's hardware can work however they want it to. FOSS firmware would be cool in the same way that FOSS hardware would be cool, but it's not something I expect. I also don't care that much whether the proprietary firmware is stored on on-board flash and programmed from the factory or if it's uploaded by my OS when the driver is loaded.

But I would prefer if the code I run in userspace or kernelspace is FOSS.

> I also don't care that much whether the proprietary firmware is stored on on-board flash and programmed from the factory or if it's uploaded by my OS when the driver is loaded.

Bingo!

Nobody cares about firmware, that's not the issue, never was... but somehow that became the narrative repeated by people who don't know what they are talking about.

Many firmware loading drivers have caused drama over the years. I'm not sure if anybody remembers when Pottering and Sievers re-worked udev to change the ordering of how firmware was loaded from user-space, trying to improve how computers booted, by graphing firmware loads, determining the loading ordering, etc... which sometimes need to happen before it's kernel driver loads, or sometimes the driver itself is able to load the firmware, or the driver begin lazy, expects udev to load the firmware after the kmod is loaded... As a result, the kernel loads firmwares itself.

I'd say the whole firmware thing needs to be put under review, with concrete rules how they are loaded, and what their interfaces has to look like, and what hardware abstraction rules actually apply.

I think this firmwareblob vs. kernelblob vs. userspace blob needs to be decided on a case by case basis, and no strict line that shall not be crossed can be drawn anywhere. The important factor is, does their contribution help the community or not, will it allow the community to fix bugs and port stuff to a new innovative kernel, without it needing to re-implement everything from Linux?

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.

Where do you draw the border? Even if they open source the firmware, they can also do whatever they want provided it runs as hardware.

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.