> Wait until the day a security problem in a network card is exploited.
This does not change the fact that the firmware is part of the box we call "network card". Does it matter whether the security issue was on the firmware or for instance a race condition on a hard-coded sequencing logic? In both cases, it is a bug in the network card. And yes, it would be better if we could fix bugs in the firmware ourselves, or enhance it to add new features.
> As somebody else put it elsewhere in the thread, your computer without a software is a "nice brick" as much as your network card without its firmware. Yet, we call it with two different names.
So, let's call it the "network card kernel". The "network card kernel" runs on the network card, the "operating system kernel" runs on the main CPU, or the "application processor" as the smartphone people would call it.
They are still separate, unless your network card can run Linux itself.
Smartphones are an insteresting example: we have the application processor, which often runs Linux nowadays, and the baseband processor, which runs a closed-source GSM stack. Instead of going against the creation of drivers allowing Linux to talk to the closed GSM stack, making it impossible to productively run Linux on smartphones, isn't it better to allow Linux to dominate on the application processor, while separate projects like OsmocomBB focus on freeing the baseband processor (and only it)? An all-or-nothing approach can be very counterproductive.