[MathMonkeyMan]

I'm well out of my realm of expertise here, but I had a gut reaction to:

> Libreboot, being FSF-recommended, also has this policy of disallowing firmware blobs in the source tree, despite it being a source of nothing but problems.

Later the author points out how there isn't any contemporary libre hardware that would satisfy users (vaguely but reasonably described), and so "free" solutions utilize loopholes in the legal language that defines the FSF's "libre."

What I'm reading is that capable libre hardware does not exist, or at least has not existed for many years.

Why accuse the FSF of hypocrisy?

Later,

> At this point, total blob-free computing is a fool’s errand, so there are a lot of AMD Ryzen-based machines that will give you decent performance and GPU acceleration without the need for proprietary drivers.

Indeed, I don't use truly libre hardware either. I buy whatever The Man makes available. Libre hardware is still a worthy goal. There is no harm here on account of the FSF.

[giantrobot]

> Why accuse the FSF of hypocrisy?

If I ship some piece of hardware on a PC with its firmware burned into a ROM and do not provide the source (a binary blob), the FSF will happily say my hardware is RYF-certified.

If I ship the exact same hardware with the exact same firmware as a binary blob but in Flash RAM or loaded at init by a driver they'll accuse me of not "respecting freedom".

Same hardware. Same firmware. Same vendor. The FSF is hypocritical because their RYF certification allows me to get certified so long as I make my hardware impossible to update. I don't have to provide any source or actually respect anyone's freedom to get in their good graces, I just need to burn my binary blob into a ROM.

If I save a dollar per unit by loading the same firmware blob through a driver into the device's RAM, I'm an evil freedom disrespecting jerk.

Besides being hypocritical it also makes for extremely poor security practice and affects longevity and e-waste. If I can't update a device firmware it might have some security flaw that can't be patched and maintain the RYF certification. If I roll an updated firmware and have the driver push it to the device I lose my previous certification unless the new blob is open sourced.

Devices that can't be updated are also more likely to be discarded. An updated OS might be incompatible with my old firmware in ROM so needs to be tossed when upgrading. Same if a security fix can't be pushed out.

So the FSF doesn't seem to actually care about freedoms, just whether a vendor technically meets their requirements. They also engender a poor security posture with their policy. Libre hardware is a worthy goal but the FSF's policies and technicalities around certification don't really lead to that goal.

[oshiar53-0]

See https://www.fsf.org/campaigns/free-bios.html for the rationale.

Basically, FSF had to make a compromise here. If you use Flash ROM (or other writable medium), the firmware counts as a nonfree software. However, if you use actual ROM, the firmware might as well have been a circuit baked right in the product, so it counts as hardware; nevertheless, it counts as non-free.

FSF's ultimate goal would of course be to be able to certify that every component (hard or soft) of the system is actually free. However, this isn't very practical, since no consumer-grade computers will be considered free due to proprietary CPUs (e.g. Intel, AMD, ARM), which is why FSF is stuck in a weird situation. (How would you make exceptions for the CPU stock microcode and not the BIOS, for example?)

For that matter, I hope RISC-V helps us go a step forward...

[not2b]

Yes, they have a rationale, but it's a poor one. Followed to its logical conclusion, I can make any program free. All I have to do it put it in ROM. Then I can pretend it is part of the hardware. Software in ROM is not hardware, it's just software that can't be improved or fixed.

The other point they ignore that if some part is programmable but currently requires proprietary firmware, it's possible (and this has happened) that people reverse-engineer it and produce free software that runs on it. BUt if you bought the FSF-blessed version of that device you're then stuck with the proprietary version of that program forever, and worse, you can't get any updates for that program. You can't get a security fix, and you can't replace it with the free program.

[csande17]

> The other point they ignore that if some part is programmable but currently requires proprietary firmware, it's possible (and this has happened) that people reverse-engineer it and produce free software that runs on it.

If this is possible, then device makers should do it, ship the free-software firmware on the device, and then get it RYF-certified. No blobs needed, ROM or otherwise! Problem solved!

It seems like a feature, not a bug, that the RYF certification process makes it more painful and expensive to release devices that rely on proprietary software.

[comex]

> If this is possible, then device makers should do it, ship the free-software firmware on the device, and then get it RYF-certified. No blobs needed, ROM or otherwise! Problem solved!

The device maker could ship with programmable proprietary firmware and have the possibility of being RYF-certified in the future if someone writes free firmware. Or they could ship with proprietary firmware in ROM and be guaranteed RYF certification immediately. The rules encourage them to pick the second option, and it's no surprise that companies such as Purism have done so.

Yet that option is never better for user freedom, since making software un-upgradeable does not make it any more free. And occasionally it is worse, in the event free firmware becomes available later on.

[csande17]

It sure sucks that device makers just have to wait and hope someone writes free firmware. If only they had some way to cause the firmware to be written, perhaps involving things like "money" or "employees" or "contracts with vendors".

The alternatives to this policy are allowing all blobs, in which case the RYF certification isn't actually verifying anything, or not allowing any blobs, in which case RYF cannot certify any devices made after 2009 (something the author also takes issue with). Making it expensive and risky for device makers to rely on blobs is the only middle ground that makes sense.

[tedunangst]

Whether it's loaded into RAM or ROM is the most useless distinction to make. It's functionally identical. Now whether a driver requires executing proprietary code on the host CPU, that is a useful distinction to make, because it allows independent OS implementations to create free drivers.

[kevin_thibedeau]

It isn't identical. With a fixed ROM, every user is denied an opportunity to upgrade rather than just those without an anointed OS. It's about equal access.

[tedunangst]

Sounds like a good reason to certify hardware that puts firmware in RAM.

[kevin_thibedeau]

Most peripheral ICs have an on board micro with internal RAM and flash. Their RAM isn't typically accessible.

[erosenbe0]

RISC-V is foremost about freedom from licensing rather than open-source so I'd hold my breath

[wmf]

The FSF had to make a compromise, but many people think they drew the line in the wrong place. When no reasonable hardware can meet the "compromise" version of RYF it just causes users to bounce off.

[zauguin]

I think the issue isn't that much that no reasonable hardware can archive it, but that the "compromise" actively encourages not just insecure systems, but also making systems even less free.

It's a bit like saying that a Windows notebook is only "free" if you can't install other systems and updates are disabled. There probably is more or less reasonable hardware which could implement these restrictions, but such hardware would in no way be more "free" than a notebook where you could just install Linux.

[orlp]

I think a good analogy is the parable of the cobra problem. A city suffers from too many cobras so the government puts a bounty on each dead cobra you hand in. The result? People massively breed cobras to hand them in. The government realizes this and stops the program. Subsequently all breeders lose interest and dump the cobras, leading to an even bigger problem.

[kmeisthax]

So first off, putting something in mask ROM[0] does not make it equivalent to a circuit. Circuits cannot be copyrighted[1] but mask ROM programs can be; meaning the latter is just as non-Free as rewritable software. It is legally silly to distinguish between read-only and rewritable software, even if it might have a small engineering upside of prohibiting the imposition of new antifeatures.

That doesn't mean that mask ROM is free of antifeatures, though - in fact, often times mask ROM is the highest privilege level in the system and thus the best place to put antifeatures. In the case of x86 PCs, the BIOS gets it's own privilege level above the kernel; ARM PSCI also runs in EL3 above normal kernels or hypervisors. These can still actively damage user freedom even if it's "technically hardware" and non-updatable.

Also, the fact that it's not rewritable means that...

1. Security bugs[2] will never be fixed[3], rendering the hardware unsafe to use over time.

2. We cannot practically replace the firmware with a Free equivalent.

It should not be understated that the vast, vast majority of hardware did not come Free. We had to open it ourselves through painstaking reverse-engineering and reimplementation work. This is an ongoing burden that the community must meet for the foreseeable future. Manufacturers are not going to stop shipping hardware with proprietary firmware or drivers anytime soon. Ergo, anything that stands in the way of firmware or driver reimplementation is, in my opinion, bad. This includes making it more difficult to update or replace firmware by putting it into a mask ROM.

My personal opinion is that you can't really draw a line in the sand and say, "this hardware respects your Freedom, but this other hardware doesn't". Hardware manufacturers have zero interest in fully-Free firmware, and I don't expect this to ever change. Not even with RISC-V, which will almost certainly have even more "embedded" fragmentation than ARM does. Whatever standard the FSF writes for "Respects Your Freedom" hardware, someone is going to try and rules-lawyer non-Free software into getting that badge. So they should not provide a strict standard at all.

There's also another question of how much energy we actually want to burn on getting Free firmware into chips. An alternate interpretation of the idea behind the Free BIOS campaign is that the BIOS itself got "interesting" enough to be a Freedom threat. Back when it was still a ROM, Free kernels could ignore it entirely; now it gets it's own privilege level and has to at least be considered. CPU microcode is less of a threat than the BIOS, here - the microcode just lets you patch how certain instructions get decoded, while the BIOS can actively debug and spy on Linux.

[0] I am going to use the term "mask ROM" loosely. Consider one-time programmable memories like PROM or EPROM to be in the same category, as they cannot be electronically erased and then reprogrammed by the same circuit that uses them.

[1] There is a sui generis right for "mask works", but it is far less toxic than software copyright. For one, it has a reasonable term length.

[2] I am assuming security from the standpoint of an end-user, of course. Being able to defeat TiVoization is not a security bug for me.

[3] It is possible to swap ROM chips in some cases, if the part is socketed, or if it is soldered and the user has the appropriate level of soldering skill. However, at this point this is no longer read-only. It's just Flash memory with extra steps. There is no legal or ethical difference between reflashing a chip with proprietary software on it and replacing it with a new chip with new, proprietary software on it.

[dvdkhlng]

> Also, the fact that it's not rewritable means that...

> 1. Security bugs[2] will never be fixed[3], rendering the hardware unsafe to use over time.

But on the other hand: security bugs will never be introduced post-manufacturing. Additional DRM cannot be forced onto you, after you bought the product. Or: DRM bugs that allow you to fully use your hardware cannot later be patched by the vendor.

[giantrobot]

Without the source there could be all sorts of timebombs or tripwires in the firmware. For instance a device refusing to operate unless another device was present or changing behavior after a certain date.

[oshiar53-0]

This is the insight I wanted.

Now I want to hear what FSF has to say about this...

[marcodiego]

Bookmarking it.

[r283492]

The malicious/abusive parts of nonfree software are almost always tied to it's updatability. Avoiding updatable nonfree software prevents users from entering into an abusive relationship with a nonfree software vendor. https://www.gnu.org/proprietary/proprietary.en.html, 550 instances of malicious functionalities, I'd bet all instances are for software where the vendor can update it.

Your argument is like "Banning guns will incentivize people to use knives, people who want to only ban guns for violence sake are hypocrites." There is a kernel of truth, but it's really just ignoring the bigger reality.

[marcan_42]

People keep bringing this up like proprietary software can always be unilaterally updated by the vendor. That's not how it works with firmware blobs, the vast, vast majority of the time. The user has the choice to run whatever firmware version they want, for as long as they want. They have strictly more freedom than if the software were not updatable, since they can choose the least evil version.

I can't believe people are still trying to use this argument. It's plainly evident that mutable software gives you more choice than immutable software. Making the argument that autoupdaters are evil and can be abused doesn't suddenly make all mutable software more evil than immutable software.

[marcan_42]

Incidentally, I'm on their list as a victim:

> 2010-03

> Sony restricted access to the PlayStation 3 GPU, so people who installed a GNU/Linux operating system on the console couldn't use it at full capacity. When some of them broke the restriction, Sony removed the ability to install other operating systems. Then users broke that restriction too, but got sued by Sony.

I'm one of the people who got sued by Sony. And I still think the FSF's take on all this is terrible.

[ndiddy]

The rationale seems to be that if the vendor is able to update the firmware at a later date, then the customer should also have that ability in order for it to be certified.

[thrwawy283]

I just wanted to say I appreciated this comment. You clearly condensed what the problem is, and now I feel like I better understand the situation. It does sound like hypocrisy but in an unworkable, non-starting situation for the FSF.

(Bravo.)

[giantrobot]

Thanks. I understand what the FSF is trying to do. I just think they've gone about it in a stupid way. I see it as an outgrowth if Stallman's old "microwave argument".

He is super zealous about using free software everywhere...until he isn't. His argument being that something like a microwave, despite having some non-Free software, isn't something that can be changed post-sale so he's ok using them.

1. It's actually an outdated example since we're now seeing appliances with Internet connectivity and EULAs.

2. It breaks down almost immediately with modern computer hardware. We're not running big beige towers whose only connectivity is some RS323 ports on the back. Most people are running computers with multiple highly regulated radios, internal batteries, and security subsystems. Fully user programmable functions of these are combinations of impractical, dangerous, and illegal.

I still donate every year to the FSF but these crusades just make me slap my forehead. They're feel good campaigns and encourage more harm than good.

[fsflover]

https://news.ycombinator.com/item?id=30036588

[MathMonkeyMan]

This is what I missed, well put.

[oefrha]

TFA is very specific about the harm done by FSF's policy, unfortunately you either missed the arguments or chose to left them out. E.g.

> The FSF “Respects Your Freedom” certification has a loophole so large you could drive a truck through it called the “secondary processor exception”.

> ...

> This means that users of the Librem 5 phone are objectively harmed in three ways: first, they are unaware of the existence of the blobs to begin with, second they do not have the ability to study the blobs, and third, they do not have the ability to replace the blobs. By pursing RYF certification, Purism released a device that is objectively worse for the practical freedom of their customers.

[seba_dos1]

> that users of the Librem 5 phone are objectively harmed in three ways

That's not true though.

First: things that were done in order to move the blobs out of PureOS weren't hidden in any way, to the contrary - they were loudly announced as "steps towards RYF certification", describing exactly how that's supposed to work in public blog posts[0]. I can't see how that counts as "[users] unaware of the existence of the blobs".

Second: the blobs are perfectly accessible to anyone who wants to study them - not only you can download them from repositories online, but you can even access the flash where they're stored on your device; you can also read and modify the code that loads them. What's more - you can even bypass that loading mechanism and load them directly by yourself from the main CPU if you don't care about keeping the blobs out of your rootfs (and some alternative OSes do that already). Which gets us to...

Third: users do have the ability to replace the blobs. Not only can they run an OS that loads the blobs directly - they can even reflash the storage where the blobs are being stored. And no, no disassembling, special tools or weird hardware tricks are necessary - you can just lift the read-only lock purely in software (it's a one-line change to the device tree), which is there mostly to prevent you from accidentally shooting yourself in the foot than anything else.

You may disagree whether the additional effort that went into creating these solutions was worth it - and that's a valid opinion to have, but nothing's artificially locked out from the user, so nobody is "objectively harmed" by it. That part is just false.

Disclaimer: I work for Purism on the Librem 5.

[0] https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

[ldarby]

How much engineering effort went in to this, instead of other improvements like reducing power consumption / increasing battery life?

I would have bought a Librem 5 but haven't only beceause of the power issues (which is same reason I didn't get a Pinephone).

[seba_dos1]

Compared to other areas, I'd say "negligible" - but I wasn't involved personally (only joined the team later on), so take it with a grain of salt as it's not impossible that I'm missing something.

The M4 core was already there in the SoC sitting unused, it's not like it was added just for firmware loading ;)

[toolcombinator]

The problem of course is that Purism markets the phone for security conscious people.

Not hackers who have the skills and impulse to mess around with binary blobs and microcode.

That’s dishonest.

Go take a look at the Purism’s website about the Libre yourself: “Security”, “peace of mind”, “digital privacy”.

You’re openly marketing the phone to regular people and businesses who care about privacy.

Nowhere on the site does it say: “BTW: We’re selling you a crippled phone because we wanted to get a fanatics approval. But if you study computer science you can fix that yourself!”

[seba_dos1]

> Nowhere on the site does it say: “BTW: We’re selling you a crippled phone because we wanted to get a fanatics approval. But if you study computer science you can fix that yourself!”

Which is good, because it's not "crippled" in any way no matter how technical you are, and having a clear boundary between user's operating system and the hardware with potentially nonfree firmware can be useful even when you're not a "fanatic". Thanks to this boundary, whatever you download from PureOS repositories on the phone is known to provide you the four freedoms, with no exceptions.

Of course not everyone needs to value that, but at least that's the value proposition Purism is offering with PureOS.

[MathMonkeyMan]

I referred to that when I mentioned "loopholes."

It's a contradiction for sure, but either you have a "libre" device with non-free components isolated over a serial interface, or you have a less capable device.

Disingenuous, maybe.

[throwaway81523]

I have sometimes thought of ditching my phone plan and getting a wifi hotspot, just to stop the phone carrier from messing with the software in my phone through OTA updates and whatnot. All communication would be through TCP and that would stop the phone carrier from talking to the mobile baseband processor, which could be completely disabled or removed. It would even allow ditching the whole phone and using a wifi-only tablet instead. Both sides (the wifi box and the phone) are hard to make entirely free, but by isolating them from each other, some higher control can be achieved.

[aesh2Xa1]

Another HN user, tptacek, has made comments going back years now that point out how modern Android (at least Pixels) and iPhones all isolate the baseband behind a serial/USB peripheral interface. I'm not sure you would gain anything at all by going with your surmised setup above.

[tata71]

Many carriers do OTA config stuff when you insert their SIM,

cooperated with by your carrier.

[cmeacham98]

> Why accuse the FSF of hypocrisy?

I'm not sure I fully agree with the author, but I think their point is that the FSF makes exceptions for binary blobs in some places because of usability, but then denies similar exceptions elsewhere because they're not libre. The complaint is that the decision on what counts as being included in the loopholes appears largely arbitrary, at least from an outsider's perspective.

[medo-bear]

last time i looked at their guidelines i understood it that proprietry blobs will be tolerated as long as libre alternatives dont exist. for an organisation that values free software above all else (including security) i think this is a principled approach. i fail to see any hypocricy

on the other hand whenever there is some GNU/FSF topic on hn there are always the same people taking the opportunity to throw mud at these organisations. think of this what you will

[throwaway81523]

Is that hypocrisy, or just an oversight / unintended consequence?

[Rd6n6]

There is a very short list of hardware they do endorse here. I’m not sure if it uses those loopholes or not

https://ryf.fsf.org/

[marcan_42]

They do. That bluetooth dongle? Hundreds of kilobytes of proprietary ROM implementing an entire Bluetooth stack (these things always implement at least the lower layers and invariably also support doing the upper layers for HID emulation mode). Those ThinkPads? Embedded microcontrollers with updatable proprietary blobs in Flash memory that you can't audit, and which have direct access to all system RAM via the LPC bus.

[duskwuff]

What's funny about this list is how much of it amounts to a few companies -- ThinkPenguin, Libiquity, and Technoethical -- rebranding commodity hardware like Atheros wireless cards. There's nothing unique about this hardware which makes it more "free" than any other off-the-shelf Atheros cards, and the drivers were open-source long before any of these companies got involved.

[marcan_42]

It has been fairly well established that in practice, some of the companies selling with RYF certification are basically scammers. Lots of people have been charged without orders being shipped. Google around the company names for the horror stories.

https://www.reddit.com/r/libreboot/comments/pqs0g0/technoeth...

https://www.reddit.com/r/linux/comments/4hy9hf/ordered_a_lib...