Today most of the wireless manufacturers (Intel, Broadcom, TI, Marvell, Realtek, Silicon Labs) now release FOSS drivers for Linux, but some of the older WiFi/BT cards have community developed drivers. MediaTek/Ralink and Infineon don’t collaborate well with the community, but most of the manufacturers do (I think the arrival of Android changed this).
For a list of the FOSS drivers, see:
No WiFi/BT manufacturer releases their firmware as FOSS, and it is unlikely to ever happen because releasing the firmware would make it easier for others to discover how they implemented their WiFi/BT, which would open them up to more patent lawsuits. Wireless communications have thousands of patents and many of them overlap, so the manufacturers are very fearful of getting sued for patent violations.
The big difference today is whether the WiFi/BT manufacturer works with the community to get their FOSS drivers included in the mainline Linux kernel, and whether they try to get their proprietary firmware to be included in mainline’s linux-firmware project. If the manufacturer doesn’t work to get their FOSS drivers included in mainline Linux, then volunteers from the community have to do it. Another question is whether the manufacturer releases their proprietary firmware with a license that allows the distros to redistribute it, or requires it to be directly downloaded from their website.
Intel is one of the better manufacturers, and its developers do the commits to get its iwfwifi FOSS driver included in mainline Linux and its iwlwifi/linux-firmware proprietary firmware included in linux-firmware.
The ath9k doesn’t have an embedded CPU like the later Atheros cards, so its WiFi can function without any firmware, but it generally functions better with the proprietary firmware. Its Bluetooth, however, requires the proprietary firmware in order to function.
It might be possible to reverse engineer some of the WiFi firmware that runs the WiFi card’s operating system, similar to what is being done with the Quectel modem in the PinePhone, but they haven’t figured out how to reverse engineer the radio functions. This article has some discussion of the legal and tech issues:
Its hard to know how difficult it will be until someone makes the attempt and starts figuring out all the issues involved. If the WiFi/BT card is running a stripped-down version of Linux, there is probably a lot that can be reversed engineered. From what I understand, the radio functions are likely to be harder to reverse engineer than the WiFi/BT’s operating system.
But isn’t the real issue for Purism whether the device requires firmware at all to reside within Linux?
Realistically, noone expects the manufacturer to release firmware as FOSS but as long as the firmware hides permanently inside the WiFi device (e.g. on board flash storage or e.g. on board non-flashable storage), it should be OK for Purism.
Conversely, if the WiFi device requires firmware to be loaded at boot time then that is not something that can be fixed in software (probably?!?). So in this scenario the only option would be to reverse engineer the firmware until it could be considered open source (and then it would be OK for it to reside within Linux).
So my understanding is that these Intel cards may well work fine on the Librem 14 but you have to compromise a little if you want to use one.
This is not entirely true. The ATH9k is based around a Tensilica Xtensa core and has a firmware, but this firmware resides on chip and not as blob in userspace. The Ar3k, which is the Bluetooth part, does not require a firmware but a rather small parameter blob. It can also use an external firmware to update parts of the built-in ROM (often called “RAM patch”) but that’s not strictly necessary. Also the parameter block is not strictly necessary. I once patched the load of it out of the kernel and Bluetooth will then work with the hardwired parameters instead - though YMMV since some Bluetooth modules (I do not know if the QCNFA222 does) use such kind of parameters to e.g. control WIFi/Bluetooth coexistence, which could result in only either one of the two working at a given time.
I am not so sure about this patent argument. This was one that was also given for years for GPUs and why manufacturers would not create free drivers for them. Look what happened - nothing. By now we have blob free drivers for quite a bunch of GPUs, for some others free drivers with blobs and no huge patent litigation has happened.
Yes, all radio stuff is a heavy patent mine field area but these firmware or drivers do not contribute much to proofs for or against patent infringement in practice, it seems.
I have talked to many manufacturers over the course of the past years and in most cases not releasing more as open source has more to do with unproven fear of everything and less concrete risk assessment. Very often you also encounter the “Oh, then we loose our business advantage!” argument, which IMHO is plain false. I do not know of any case in the industry where open source would have been detrimental for a chip maker’s business. Not happening.
But there are more profound reasons one could give, especially for radios. The firmware is usually the last barrier before full control over the radio, especially the transmitting part. All radio is regulated, especially radio transmissions are pretty heavily regulated. Even the 2.4GHz and 5GHz spectrums are ISM spectrums for free use they are not unregulated. Manufacturers must make sure that regulations are met. In the recent years more regulations and laws or law like regulations have been passed that require manufacturers to make sure that users can not bypass anything that prevents them from regulatory compliance. Since you do not and in most cases can not safely prevent this in hardware, you do this in software, namely the firmware.
As far as I know all the radio parts are still not open and there is also little intention to do so. What was done is to hack open the Linux system that is actually running on the modem module - which is cool! But this is still far from “reverse engineering the firmware”. All the radio and a lot of other parts are still used as-is with blobs and that likely not to change.
WiFi cards in contrast are much more primitive / simpler than a cellular modem so IMHO that can not be really compared.
The only free radio “firmware” implementation I know of is the NIMBLE BLE Bluetooth stack which implements everything for the Nordic semiconductor nRF52xxx chips, including full radio control - in contrast e.g. to the famous ESP chips where SDKs like Arduino or the Espressif native IDK/ADK include larger binary only libraries which implement the radio engine and AFAIK there is no open source re-implementation for these yet.
I think we have to arrange ourselves with binary blob firmares somehow. I frankly do not mind them, as long as some requirements are met:
firmware blobs must not be executed on the main CPU that also runs the operating system - that would be a string security concern
firmware blobs must come with a perpetual license to redistribute the blob as part of anything without any limitation - else OS distributions get a problem
If these two are met, I have no problem with putting a firmware blob onto my SSD and have the kernel load it into the hardware before using it. I would even prefer this over any solution with the firmware hidden in some obscure piece of hardware which I eventually can not update - and also not have a look at that blob, it’s hidden away from my eyes. I have seen firmware licenses that I would not accept, that e.g. limit redistribution to only as part of a bundle with the manufacturer’s hardware. That’s ridiculous and would severely harm distributions, that’s unacceptable. I even think that some of the firmware files in kernel.org’s firmware repo have such a license though no one cares. But it is a dangling sword over everyone’s head and I do not like that. There is also no good reason to limit distribution like that.