1 is incorrect. Only the ath9k driver is blob free. The more open drivers such as mt76 and he ath10k and ath11k have blobs. Especially the marvell (wrt1900, etc) drivers. The company decided to move development elsewhere and has left a buggy binary blob that there is nothing anybody can do to fix.
IMO we'll never see open source drivers due to the US's FCC. The FCC has limits on which channels a device can use and power limits for those channels. If a user can purchase a US device and change the country to something with different regulations or create their own custom country with whatever regulations they like then it becomes trivial for every customer to flash to OpenWrt and break the law.
Now virtually all routers are a SoC that runs linux we can flash plus a completely separate radio running its own OS provided by the driver binary blob. The linux driver just communicates with the other independent computer to transmit and receive and has no control over things that could lead to breaking laws.
I read about an open source radio in development a few months ago you might be interested in following. Unfortunately I cannot find the link. IIRC @dtaht shared the original link to the project, maybe it can be posted again?
dana44 i am glad you mention that #1 is incorrect this brings up another point I would like to add to the mix.
Besides OpenWRT being associated with open source, why and how do they get to join the Free Software Conservacy if OpenWRT has non free parts? Is FSC aware of this?
I don't intent to crap on OpenWRT. I use it too, but these contradictions bother me. Id love to gently nudge OpenWRT devs into the thought pattern of "gee if we already use bits of closed source in the drivers now then whats stopping us from using a !00% closed-source driver?"
Id bet money if OpenWRT devs went to broadcom and asked politely, they would be given permission to use broadcom drivers similarly to how DD-WRT does it. But they won't do it even though OpenWRT already has closed source parts.
OpenWrt does not use closed source drivers, those blobs mentioned above contain firmwares only.
This is a bit confusing if you think of your router as a device. However, if you think of it as a (specialized) computer, then OpenWrt (and the drivers) is an open source operating system, that loads some blobs to the devices (wireless chipsets) connected to it.
OpenWrt is executed on the "main" CPU, firmwares are executed on the "external" CPUs.
And hasn't been for a long time, st least not by the strictest of definitions... Think BIOS and/or kernel loaded microcode blobs in x86 CPUs for example.
I think @eduperez's approach of looking where code is executed is helpful here... but keep the microcode example in mind.
Yes ideally all of this 'auxulliary' code should be open as well, but as I understand such code often contains crown-jewel level parts of a proprietary chip/firmware combo's 'value'. The closest we come is the ath10k where a secondary closed firmware exists that can be used interchangeably to the official blobs.
But IMHO a number of external chips use fixed ROMs for their own microcode, and just because that might not be field upgradable and as obvious as blobs that need to be loaded at run time, they still require the same level of trust, let's not think about what nefarious instructions might be hard coded directly into CPUs.
This is the point in the discussion where a reference to 'Reflections on trusting trust' seems relevant: https://dl.acm.org/doi/10.1145/358198.358210