Hi all,
thank you very much for sharing your views!
And yes, I totally share the sentiment that the FSF is absolutely needed as this idealistic party that represents a strong force everything can gravitate towards! Totally get it and agree. Actually this is also the very exact same point how I found myself defending the FSF and sometimes even RMS in some discussions - it is this uncompromising idealistic force that is needed to be present in the world.
But the reality also is that it makes it close to impossible to make products based only on these idealistic rules. There must be ways to grant exceptions somehow. These may come with penalties or such, totally fine. But they need to be there or else we will shoot ourselves in the knee with a tremendously large gun! We will cut ourselves off from current hardware.
Matter of fact is that more and more silicon’s function these days is determined by software not by silicon hardware design. The software defining it is the firmware. There are some that can be rebuilt in the open, like how we did it with the smartcard reader firmware in the Librem5. In the dev kit we used a proprietary reader chip with its proprietary firmware (though this firmware was in ROM inside the chip), in the final L5 we are using a programmable microcontroller and our free firmware.
But there are also tons of chips where this is either a lot harder or even close to impossible, for several reasons.
Let’s take Bluetooth as an example, since it is also this thread’s topic. As an early Bluetooth adopter I got in touch with pretty much the very first generation of Bluetooth hardware, at that time made by CSR - Cambridge Silicon Radio. These modules were self contained, they included the MCU driving the logic, the DSP for the radio and, last but not least, storage for the firmware. From the outside you had the Bluetooth defined host controller interface (HCI), USB and serial UART at that time. Firmware update on these was a highly proprietary thing, required special tools etc. But you did not really need it, the modules worked in HCI mode and you could develop your stack against it. But also Bluetooth became more and more complex, firmware become more complex and bugs were found, so firmware updates became necessary. Also regulations became fragmented, the 2.4GHz ISM can not be used in all regions in the same way so you need to accommodate for that in your firmware (the Bluetooth stack can not do this). Having all that fixed in silicon quickly becomes a problem, you end up with tons of SKUs of one product. No one wants this. Over the years also flash memory became much more expensive than RAM - expensive in terms of chip size. Mask programmed ROM was not an option, you need to be able to fix bugs, eventually even in the field.
So the quite natural choice for many chip makers was to drop all or most of the built-in-silicon software, add more RAM instead (saves money) and upload what is needed in its most current version right at the start of the system. This solved a lot of the pain points - you can update them easily, just replace the uploaded bits, you can configure them easily in the same way and you save a lot of cost by reducing the silicon die size and the number of SKUs. A strong incentive for the chip makers.
The same is happening in pretty every peripheral chip these days. Only very small and very well defined ones still have their firmware on chip (either masked ROM or flash) like a touchpad controller. But more and more only have a tiny bootloader in ROM that will wait for a firmware and eventually parameter data set to be handed over through the HCI, put in RAM and then being executed.
So this is what’s happening on the hardware side - on the chip level.
The internals of these specialized chips, like Bluetooth or WiFi or even these touchpad controllers, are pretty much proprietary, you do not know how they are made, what kind of CPU core they have, how they work and how they attach to the outside world. Most of them are actually protected against third party hacking by “secure bootloaders”, i.e. they will only accept signed firmware images etc. Which also kind of makes sense when thinking about radios and regulations. But this of course makes it awfully hard to hack such a chip and to put something free in there.
I don’t want to say it is impossible, but it is very very hard and takes a LOT of effort, person years of development time. If you think about Bluetooth or WiFi the radio part alone is already really really complex - modulations, decoding, traffic handling etc.
And now assume for a minute we, i.e. Purism, would heavily invest in such an effort. What would we do? We for sure are not in a position to design our own radio silicon. So we have to take something, reverse engineer it (since the original maker will for sure not give us the internal information), write that firmware with all its bits and pieces (radio handling, protocol, host interface, drivers etc.) and then what?
As soon as we publish and start to sell such a product we are basically legal bait for a hole bunch of lawsuits. First of all for reverse engineering which is not legal in all regions. Second for publishing proprietary information. Third for infringing on a metric ton of patents (by the chip maker and very likely also from hundreds of other stake holders of that technology). And fourth we would very likely by forced to use the same secure bootloader stuff to lock down the firmware loaded into the chip as the original maker due to regulation compliance, for which we, as a company, will be held liable and accountable. We must take precautions that the hardware we sell can not be used in non compliant ways (at least for radios).
This is at least my line of thinking based on what I know right now. The big problem here is that Purism is a company selling products. We are not a free software project. As a company we have additional regulations and rules to follow than a free software project.
So as long as no chip maker makes new chips with fully embedded firmware, I am so sorry, I am afraid we are out of luck. We, i.e. Purism, will not be able to fill this gap with a product. We can not, no matter how much we wished to. It is way beyond our scope - and honestly also beyond our current abilities. I am not saying it’s impossible, but you would need a huge seven figure budget just to create one of these free radio chips. And even then once you are done with that you can start all over again because customers will expect the next generation. We simply do not (yet) sell enough devices to be able to pay for that. Not even close.
So what’s left?
The only way we can continue to advance all our causes and make products is to use chips we can buy on the open market. And here, as I explained above, the definitive trend in the chip industry is not to embed firmware in these chips. Even worse all the chips I looked at, and these were a lot over the years, do no allow to load that firmware through any other channel than the host interface. There used to be some that could load it from an attached serial flash chip with which we could have built our own cards, we would have done that! But these do not exist anymore.
So here we are. There are chips for which there are also free kernel drivers but which need a firmware download through the host interface at startup. And there are no alternatives to these chips. None.
So what shall we do?
Stop selling products?
Cobble together as many (really) old parts as we can find and build outdated hardware? If you want to get an idea what this “outdated” looks like in terms of radios, look at the FSF RYF hardware page for the WiFi radios. Pretty much no 802.11ac radio there:
https://ryf.fsf.org/categories/wireless-adapters?vendor=All&sort_by=created&sort_order=DESC&page=1
The latest is the Atheros9k we are also using in our products, which is quite OK but 802.11abgn only, no 802.11ac. There are no 802.11ac chip without firmware requirement - at least as far as I know. And the Ath9k is being phased out, we already have a lot of difficulties sourcing the QCNFA222 M.2 cards. And this is just the WiFi radio.
We must find a way that
a) does not totally give up the ideals that we all want to reach some glory day and
b) gives us enough breathing room to create actual products today.
And let’s be totally clear about this too, if we do not sell quite a number of products we can not make enough money to advance anything anymore. Compared to a lot of other consumer hardware product makers we already squeeze a lot out of our margin into R&D. And even that is not even close to enough to create what would be necessary to be fully free.
The silicon industry is clearly against us. Not because they don’t like freedom as much as we do but simply because of driving their cost down and because of regulations.
Can we incentivize a maker to make something that is free enough for us? And I am not even talking about us as in Purism but the us as in “freedom lovers”. No, we can’t. Was there, tried that and failed. I talked to many of them and our market and audience is just a very tiny blip on their radar. We do not matter. A company like Qualcomm now owning Atheros owns thousands of patents on all of that and proud themselves for it. They have no intention and also no reason to make any of this “free to use”. The chips they make are made and sold in the millions. Let’s be generous and say we are a strong community of some ten thousand, oh no, be more generous and say hundreds of thousands. And let’s also very unrealistically assume all of them would commit to buy the very same chip. Even then, maybe, but only maybe, you would probably get invited to a meeting.
So not, sorry, not going to happen in the chip industry.
I don’t know how to solve this. And to be very honest with you, I am currently pretty frightened about this future to come. If we stick with the hard “no non-free firmware blobs on OS storage” requirement then we will soon run into a serious problem for which I have no solution to offer. None. The first to fall is WiFi/BT. Next could be the GPU (a reason why we can not use Ryzen and who knows how long Intel GPUs will remain blob free).
I am totally open for suggestions!
But I think we will need some form of blob enclave in userspace. I am just not sure how to make it. Right now we can not create it in any way within PureOS since this would violate the endorsement. We also do not want users to have to enter things manually to enable such a source. And if we create something like it, it needs to be compatible with other OSes too, like Qubes. A conundrum.
Cheers
nicole
