By now you’ve probably heard about Spectre/Meltdown, a series of CPU bugs that affect CPUs with aggressive speculation capabilities. For better or for worse, the Raspberry Pi’s CPU doesn’t feature the performance optimisations that trigger these bugs, so Raspberry Pi users are safe – today. However, the public backlash triggered against many CPU makers highlights a double-standard in open source that threatens transparency in the hardware world.
Open source software developers benefit from licences that absolve them of any liability whatsoever. Should a buggy library you develop be used in a home automation appliance that later causes a house to catch fire, you get to walk away scot-free, thanks to the expansive limited-liability clauses that are baked into every open source software licence.
Unfortunately, hardware makers don’t get to enjoy that same luxury. Beyond guaranteeing a product free from workmanship or material defects, consumer protection law often requires an implied or express ‘fitness for purpose’ guarantee – that a piece of hardware is capable of doing what it’s advertised to do. The latest controversy over Spectre/Meltdown indicates that more people than not feel CPU makers like Intel should be liable for these bugs, under the ‘fitness for purpose’ theory.
Open hardware makers should be deeply concerned. Consider if the Raspberry Pi were found vulnerable, and the only fix was to recall hardware units and replace them with a new board. If you had baked a Raspberry Pi into your product, what would happen to your business?
Now consider that open review of documentation greatly increases the rate of bug discovery. Does it make business sense to share documentation with a customer base that will surely sue you for the favour?
There’s no right answer to this situation. We need transparency to make more secure, trustworthy, bug-free systems, but consumers also need to make sure they are not being sold a lemon. The Spectre/Meltdown question merely begs the question, but offers no guidance on the correct answer.
If you think transparency is important to safety and security, rewarding hardware makers for sharing documentation by voluntarily reducing their liability can create a measurable economic incentive, thus encouraging more sharing. On the other hand, if you feel a guarantee for fitness is paramount, then you must accept that what you don’t know can’t hurt you – until it does. In other words, if your policy is to sue developers over bugs, you can’t in the same breath blame them for making bugs harder to find by closing their source.