The FSF’s relationship with firmware is harmful to free software users

https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/

by meithecatte • 4 years ago

170 192 4 years ago

simfree• 4 years ago

Properly isolated accessory non-free hardware is a good thing, and for a user whose threat model requires libre hardware, the security model of the PinePhone or Librem 5 where the LTE modem is isolated with a kill switch to interact via USB (rather than connected via PCIe, which would have direct memory access) is the right choice.

Is a Thinkpad T400 with a Core2Duo and SSD the right choice in 2022? What about a Pinebook Pro? Friends and acquaintances I know are using these computers as their primary devices today.

cjbprime• 4 years ago

Agree with you, but a quick clarification: PCIe IOMMUs exist now, a PCIe device doesn't get DMA access to main memory.

marcan_4219• 4 years ago

FYI, that ThinkPad T400 that the FSF certified has multiple microcontrollers running proprietary updatable blobs on the LPC bus with full access to DMA to all of system memory. I am literally more insulated from blobs with an Apple M1, which runs a dozen blobs none of which can take over my OS (thanks to pervasive IOMMU use), than with hardware that the FSF claims "respects my freedom".

MathMonkeyMan3• 4 years ago

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.

cmeacham98• 4 years ago

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.

throwaway815233• 4 years ago

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

medo-bear• 4 years ago

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

giantrobot3• 4 years ago

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-04• 4 years ago

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...

thrwawy283• 4 years ago

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.)

ndiddy• 4 years ago

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.

r2834929• 4 years ago

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.

MathMonkeyMan3• 4 years ago

This is what I missed, well put.

fsflover• 4 years ago

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

oefrha• 4 years ago

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.

MathMonkeyMan3• 4 years ago

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.

seba_dos17• 4 years ago

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...

Rd6n6• 4 years ago

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/

duskwuff• 4 years ago

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_4219• 4 years ago

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.

roenxi• 4 years ago

...In other words, you can’t microcode update a CPU to add or substantially change capabilities...
... vulnerabilities such as Meltdown and Spectre, which were partially mitigated through a microcode update ...

Of these two snippets, only one can be true. Either opaque microcode updates can substantially change how a system performs, or they can't. These mitigations are major changes to how the processor works.

This post looks to me like a fairly typical "doesn't quite get what they mean by freedom" take, of which there are many (which is cool, freedom isn't everyone's cup of tea). The FSF has been quite consistent that if there is a choice to be made, the user should have a practical way of making that choice. If the manufacturer can change how a CPU works with a microcode update, the user should be able to as well.

The FSF has a clear role here. Their job is to say "this software is free, this software is not". People constantly call on them to compromise on that role in the name of security/convenience/helpfulness/strategic adoption concerns/the impractical nature of their stance. The FSF should and does ignore those people. They are a (slightly quirky, yes) moral lighthouse more than an adoption friendly technical project. This microcode is not free software and someone should be pointing that out and complaining about it. If the FSF isn't taking a stand against non-free microcode, who will?

garaetjjte• 4 years ago

Yet they are fine with running microcode as long you don't update it. It doesn't make sense. Blobs don't disappear just because they are hidden in ROM.

DarylZero2• 4 years ago

Apparently it's OK because both the vendor and the user are prevented from updating it. Thus there's no power differential between them on that specific point.

TT-392• 4 years ago

That one kinda makes sense, because, when you can't update it, there isn't really much of a practical difference between something implemented in hardware or firmware. So not allowing blobs in rom would almost be hypocritical if you don't also mandate that the actual silicon of the chip is completely free.

Jasper_• 4 years ago

A majority of microcode updates aren't actual code, but are programming large swaths of undocumented registers known as "chicken bits" which turn off functionality and affect system operation. You can see what a rough fix looks like in Linux patches for devices that don't get these microcode updates: https://lore.kernel.org/lkml/b4ad7273efbb0c60a6c93ae68f82a44...

No, the details of what these MSR registers do isn't public. But it's far from being code; it's simply rather tweaking a large switchboard of functionality which already existed on your CPU. It is not adding new features or code to the execution pipeline.

Modern process development pipelines are already far too long that a common thing to do is to put an experimental feature in all CPUs and only enable it with the right microcode and chicken bits when it works well enough for general use. It's not uncommon for new processor features to have a 5-6 lag from "first buggy implementation" to "general implementation".

Avamander2• 4 years ago

Their job is to say "this software is free, this software is not".

But if they say "this software is free because the hardware is more locked down" then I don't see that as standing for user freedoms.

People constantly call on them to compromise

It's about being more nuanced, not about making compromises.

jeroenhd• 4 years ago

I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here.

Nobody produces truly free consumer hardware and nobody has produced any for years now. Everything is hidden away because of fears of patent lawsuits and other people copying this One Neat Trick when initializing the devices.

Intel would lose very little if it published the source code for the blobs loaded into their processors, because the signature requirements prevent anyone else from developing their own microcode, yet it still encrypts and obfuscates the compiled code. The same is true for most chip and UEFI suppliers.

I hope riscv will soon take off in a way that foregoes all of these blobs, though I highly doubt it since modern hardware is encumbered by patents and secrets. It's a sad reality that free, libre computers do not exist and blaming the FSF for having high standards is the wrong approach.

kryptiskt• 4 years ago

I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here.

Their ideology has led them into preferring proprietary firmware that is inaccessible to the user like in the Purism example. I hate that, there is hope that a device that requires binary blobs from the main OS can be reverse engineered and free software developed for it. Making it inaccessible to tinkering is strictly worse for the user in all respects.

marcodiego16• 4 years ago

People are parroting "the purism example...". Just stop it! Librem-5 is NOT certified!

r2834929• 4 years ago

Making it inaccessible to tinkering is strictly worse for the user in all respects.

"all respects" is wrong. It also makes it so the proprietary developer can't say "here is a new version, but you must agree to some very nasty license terms, or accept some malicious feature along with it." NOT having a capability does have advantages, a physical book is impossible to be remotely deleted out of existence by DRM, but sure, you can't tinker with the software.

edit: yes, I understand in that the case of sticking the exact same software in a rom vs a read-write memory hurts the ability of a user reverse engineering it, which could ironically decrease user freedom over time. Calling this out for FSF to address is a good thing.

seba_dos17• 4 years ago

proprietary firmware that is inaccessible to the user like in the Purism example. I hate that

Personally I'd hate that too - thankfully, that's not what happens on the Librem 5 (see my other comments in this thread for details).

blihp2• 4 years ago

At this point, I think that's become a cop-out on their part. If they really want to make their vision of truly open hardware a reality, they need to roll up their sleeves and make it happen.

Mostly open (due to reverse-engineering) FPGAs are a thing, SkyWater is a thing, RISC-V is a thing. Take one of the open source RISC-V designs, design and build a test system using an FPGA[1] (or more than one... depending on what is needed) so you've got something to put on a board, once the design is validated use SkyWater to produce a small run of actual chips to replace the (proprietary) FPGA(s) and produce a 100% open CPU etc. as needed.[2] Sure, performance will be dismal compared to the latest silicon from Apple/Intel/AMD but it will be infinitely better than the Unobtainium processor / system they continue to fantasize about.[3] Yes, they'll probably have to jettison things like cellular and probably WiFi support due to IP issues. (note: that's not to say a wireless solution would be impossible, just that it wouldn't be one of the widely deployed or mainstream ones[4]) I understand that this isn't a simple task but how would it be more work than whining for decades with virtually nothing to show for it (given their requirements) on the hardware front?

Build a bad open source device that you can iterate on rather than complaining about for-profit companies behaving like for-profit companies. Right now open source hardware is decades behind and sitting around waiting doesn't seem to be accomplishing much.

[1] Better yet, design a fully open source FPGA of their own. Sure, it will be a couple/few decades behind the state of the art. But it would provide a starting point to build on.

[2] Of course this would take multiple iterations. One approach would be to see if Google would sponsor this as part of their partnership with SkyWater. Worst case, the FSF might have to do some light fundraising for the iterations.

[3] Again, it would likely be a couple of decades or more behind the state of the art. This too would provide a starting point. Then they could use the finished product as a fund raising aid (i.e. sell it) to fund future iterations.

[4] Open source SDR is a thing, for example.

marcodiego16• 4 years ago

IMHO, we need a free hardware foundation today just like we needed FSF in the 80-90's.

shmerl• 4 years ago

DRM garbage also adds to the incentives of using blob firmware.

For example for GPUs it goes a bit like this:

You need to support HDCP? Use a blob. You want to have a separate FOSS firmware without HDCP? An extra expense that bean counters won't like.

marcodiego16• 4 years ago

I've got the feeling the author has read my comment: https://news.ycombinator.com/item?id=30036588

What is said about librem5 is irrelevant: it is not certified.

What is said about gaming the certification is irrelevant: no currently certified devices does it.

There are modern certified devices: Talos motherboards.

There are no modern laptops certified? Blame the vendors. OK, this may not make them change their mind, but while we are not fully independent, I see no other way.

basilgohar• 4 years ago

Very few people or organizations willingly give up control. The whole reason of using copyright law to "enforce" freedom by preventing free software from becoming unfree was because of how much the current legal framework around imaginary property is stacked against a libre approach. So, it's a tough game to play, but FSF didn't achieve what it has thus far by being soft or compromising. Substantial change with hostile parties doesn't happen by constantly yielding.

anjbe• 4 years ago

Since hardware vendors by and large ignore RYF certification and the FSF’s opinions in general, it’s hardly “yielding” for the FSF to change its policies if the existing policies are harmful to the free software community.

The people who are most vocal about FSF’s incorrect views on firmware are those who themselves are bringing free operating systems to new hardware, writing drivers, and reverse engineering hardware and firmware. They are not hostile parties—their contributions are among the most important to free software today, and their opinions should hold more weight.

someoneelse9• 4 years ago

A 2009 thinkpad is rather capable of being a daily driver for most people. Saying otherwise, you're only contributing to the growing problem of ewaste.

Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks.

The FSF might be wrong in some aspects but there's no real alternative to Libreboot. The Framework laptop is not free software friendly. Even if it was corebooted, it would require many proprietary blobs and it's highly unlikely, if not impossible, that they will be ever able to remove the Intel ME.

There are other options that are nearer to be completely free (as in freedom) hardware, eg the Pinebook Pro. I'm unsure if there are any proprietary blobs required to boot it tho, but the lack of Intel ME makes it a much better candidate for a new generation of 'libre' hardware.

marcan_4219• 4 years ago

That 2009 ThinkPad that the FSF certified is running proprietary blobs in updatable microcontrollers connected to the LPC bus which have full access to RAM and to take over the OS. Blobs which you can't audit, modify, sandbox, nor verify are the correct intended version.

I'd rather buy an M1; sure, it runs a pile of blobs, but at least I know those blobs are there and they're all sandboxed behind IOMMUs and cannot take over or compromise my OS.

na85• 4 years ago

Even the T60 offers a decent performance if your usecase is browsing the web,

I actually own a T60 and this is not true, for any reasonable definition of "decent".

The web is a horrid wasteland of poor performance JavaScript.

Forget running any Electron apps (a necessity it seems in this day of Zoom and MS Teams).

YEwSdObPQT2• 4 years ago

That hardware is 13 years old now and laptops tend to start falling apart and spares become difficult to source.

I have a Dell E6410 laptop. Which is really easy to repair and built like a tank. Keyboard has started dying and there are no replacement keyboards on ebay that are UK. You are asking people to use things that are quite out of date and may not be easily repairable.

I've got desktop machines from 2007 that I've had to replace the motherboard (wasn't worth it really) because capacitors had started bulging (and it was a board from a well known manufacturer). It probably more capable than the machines you mention but it was unstable as the parts were literally disintegrating.

Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks.

I really get annoyed by this. "If your tasks are restricted to a very small subset of what I think a basic user actually might want to use your computer for this will be okay". What happens when someone needs to use more modern software (even for one off thing like a job interview over a video conference), or use a particular site for taxes or whatever that needs a more modern hardware. They are screwed.

I have an Amiga 1200 with an accelerator card and technically I can use the web, check mail, chat (IRC basically) and do 85% of what I do online. But for the other 15% it is a total non-option and that other 15% might be what pays my bills.

Avamander2• 4 years ago

This discussion all seems to boil down to the semantics of what's "firmware", what's "software" and what's "hardware". Considering how blurred the line really is between the three, the feud seems pedantic at best.

FSF should stick to software only, learn to see shades of grey and label hardware accordingly or reject anything that isn't open until silicon (silicon excluded). Current choice is half-baked.

irfwashere• 4 years ago

If you'll forgive my naivete here I've been thinking a lot about the FSF philosophy and wanted to ask HN: how big of a project would it be to create a fully libre (whatever you want to call you it) laptop? Like how feasible is it to use "free" components put together into a package and what kind of budget would be required?

I think China has a few companies working on domestic processors. Let's say they are convinced by Stallman's charisma to make chips that are not cutting edge but decent, and libre.

Whatever your thoughts are on China but I would suggest to the FSF to slowly move in that direction. Where all the component schematics are open and viewable. At least to go for auditability since no one trusts the Chinese.

Like I said, forgive the naivete, but it feels like a noble yet lofty goal.

And then proceed to go into every industry with right to repair issues. Deere tractor competitors, home appliances, and so on. In the name of component longevity and repairability. All of this to repudiate forced obsolescence and to promote end user freedoms.

It's a stretch but I enjoy dreaming about it. Hoping a better world is possible.

marcan_4219• 4 years ago

That "libre" gives you auditability is a common myth believed by those pushing for libre hardware. The reality is you can't audit silicon, because it's a destructive process requiring extremely expensive analysis equipment.

You always have to trust the chip manufacturer; doesn't matter how documented the chip design is, even if the masks are outright public. You can never know that your CPU is not backdoored. That's just a physical reality.

There is one exception: FPGAs, under the premise that "generically" backdooring an FPGA is computationally infeasible. That's how Precursor gets to seriously claim trustability.

https://www.crowdsupply.com/sutajio-kosagi/precursor

But if you want more than a 100MHz RISC-V softcore you're going to have to trust the silicon vendor.

DarylZero2• 4 years ago

You can still backdoor a FPGA in the style of Reflections on Trusting Trust... wait for known code to be installed into the FPGA and then patch it.

mlyle4• 4 years ago

There is one exception: FPGAs, under the premise that "generically" backdooring an FPGA is computationally infeasible.

IMO, this isn't a reasonable premise.

- The entire boundary scan chain is a backdoor. You could have an embedded processor poking around looking for things that look like RISC-V code and adding implants or observe state.

- You could make SERDESes do various kinds of naughty things when certain patterns go by-- dump some scan chain info, so you can kick some special packets and read out state remotely. Same thing for other dedicated peripherals that are connected to the outside world. This could be a pretty small number of gates compared to the processor implant idea.

- You could make naughty patterns of bits crossing places do bad stuff. Think of dynamic effects like rowhammer being deliberately included, so if you know the design you can figure out what outside data will trigger bits to flip and state to leak. (Yes, I know that block rams are SRAMs, but that doesn't mean you can't deliberately add capacitive coupling or screw up synchronizers in various ways. And it looks like we may have block NVRAMs soon, so that opens the possibility for various evil even more).

- You could deliberately break some kinds of operations-- e.g. make elliptic curve cryptography unreliable in some cases so you leak key data.

Note the various defense and national security applications of FPGAs. They're a wonderful target for state actors to try to backdoor.

Teknoman1172• 4 years ago

For something considered modern, pretty much next to impossible.

All of the modern CPUs require blobs to function, whether it's microcode, embedded firmware, binary driver blobs, or otherwise.

I don't believe there is a wireless card (wifi, Bluetooth, etc.) on the market that doesn't use binary, closed source firmware. In fact, it's almost mandated by law that there can't be. FCC regulations require that devices be made resistant to attempts to change their function in an effort to limit people's ability to transmit stuff unintentionally (or intentionally). Modern radio protocols are heavily dependent on SDR (software defined radio), so fixed function is probably infeasible. You could make the firmware unchangeable, but now any bugs discovered in your public source code are now entirely uncorrectable.

Heck, even the SDR community is having to be really careful about not drawing the ire of the FCC. That's why so few of them tend to advertise transmit capabilities.

The main ARM cores have been generally blob-less, but that's only the cores. Various SOCs require blobs to initialize. Their GPUs are all proprietary blobs up and down the stack.

So you basically would have to make your own GPU, your own radios, etc. and integrate them into your own SOC - and get the regulatory bodies to certify them for sale in their various countries. You then have to fight the entrenched companies in court over IP for years. The GPU portion will be especially tricky. The moment you try, lawyers from Nvidia, AMD, Imagination Technologies, Apple, etc. will be all over you. The radios will have Qualcomm, Broadcom, and Intel all over you.

So technical, legal, and regulatory hurdles - which is why I say next to impossible, especially on the FSF's budget.

- a jaded hobbyist

pabs34• 4 years ago

There are some old WiFi devices with libre firmware, but they only support old WiFi standards.

https://github.com/qca/open-ath9k-htc-firmware https://github.com/chunkeey/carl9170fw http://netweb.ing.unibs.it/~openfwwf/

Some also call into the initial version of their code that is in the ROM, and don't have enough RAM to update all of the ROM to the current code. Things like the Osmocom Baseband code also do this.

https://www.osmocom.org/projects/baseband/

oshiar53-04• 4 years ago

it's almost mandated by law that there can't be. FCC regulations require that devices be made resistant to attempts to change their function in an effort to limit people's ability to transmit stuff unintentionally (or intentionally). Modern radio protocols are heavily dependent on SDR (software defined radio), so fixed function is probably infeasible. You could make the firmware unchangeable, but now any bugs discovered in your public source code are now entirely uncorrectable.

1. You can use signed firmwares to make it both compliant and upgradable.

2. You can separate the controller/receiver and the transmitter, and only lock up/restrict the transmitter part. Alternatively, you can implement the restriction at the hardware level if feasible (effectively making it fixed function).

3. Finally, you can sell the parts individually to serve a separate market segment.

serendipitous2• 4 years ago

That's why so few of them tend to advertise transmit capabilities.

Any SDR that has transmit capability freely advertises it and there are many of them. The makers of one of them (bladeRF) also develops an open source 802.11 PHY that can run on their SDR's FPGA if you want to run an open source WiFi radio. (and you don't mind using $700 hardware to run older generation WiFi) Legality of the transmission may be a concern for users of the SDRs but is not for those selling them.

marcodiego16• 4 years ago

I questioned myself about it many times. AFAIK, the rockpi4 without WiFi is ryf-certifiable. DisplayPort may need blobs, but USB-C is used only for power.It has blob free FLOSS drivers for the GPU and VPU. Its arm trusted firmware is fully open source.

So, yes it is possible to have a modern and affordable ryf-certified system.

pabs34• 4 years ago

I expect the USB-C chip has proprietary software running on it, since USB-C chargers have more computing power than the Apollo 11 Guidance Computer:

https://forrestheller.com/Apollo-11-Computer-vs-USB-C-charge...

segfaultbuserr2• 4 years ago

how big of a project would it be to create a fully libre (whatever you want to call you it) laptop?

But what does it mean by "Libre"? You see, the entire disagreement is about a problem of our definition: How does one define "a hardware system without non-proprietary software"?

Ideally, if every single chip in a computer has free hardware design down to the logic gate or HDL level, that would certainly qualify as 100% libre in both hardware and software (if a free operation system is also used). But obviously it's not practical, and it's also out of scope of what the FSF does, it's the Free Software Foundation, and it only cares about software, not hardware. Thus, the FSF defines "Respect Your Freedom" as a hardware system that doesn't require you to execute any nonfree software to use.

This sounds like a straightforward definition, right? But for many different types of hardware - essentially 90% of all digital electronics - if you open it up, decap the chips, you'll find a general-purpose microprocessor core executing code in a hard-wired Mask ROM. The chip can be a CPU with embedded microcode, a serial port transceiver, a USB controller, or even a Voltage Regulator Module (just search "DigiVRM"). Sometimes you don't even know it's implemented in this way. Thus, a practical boundary between hardware and software must be drawn.

The FSF's argument is basically the following: Consider a blackbox hardware system, such as a chip. Inside the chip, you may find a bunch of logic gates, hardwired to be a finite state machine, or you may find a read-only Mask ROM driving the microprocessor. But it's irrelevant: from the perspective of the software user outside the chip, it doesn't make any difference, it's just an implementation detail in the hardware realm that matters to a hardware engineer, not a software developer. Externally they can even be indistinguishable, if not at the electrical level, at least at the software level. Thus, as long as the logic is not controllable by software, it's not considered as a form of "non-free software" and it gets "Respect Your Freedom" approval. I think there's little to no disagreement at this point, but it gets controversial next.

Now, consider two chips, one is a controller and another is its ROM. The FSF argues that, if the ROM is not reprogramable via software even by its vendor after it leaves the factory (if the ROM is 100% read-only, or if the Write function is permanently disabled at hardware level), the controller and its own ROM are collectively considered equivalent to some hard-wired electronic circuitry in the pure hardware realm, using the same argument. Thus it also gets "Respect Your Freedom" approval.

However, if the ROM can be reprogrammed (e.g. has an enabled "Write" function) or controlled by software (e.g. uploading a blob by the device driver to the chip), it's considered as a form of non-free software, thus the FSF say it "Does Not Respect Your Freedom".

And this is where the disagreement starts.

The FSF may insist that a software-controlled firmware is strictly a type of computer program, thus it must be non-free software, meanwhile firmware not controlled by software may as well be a collection of hard-wired logic gates, so it's a "don't care" item for a software user - or at least a form of compromise. The counterargument is that, regardless of whether the firmware control is enabled or disabled, you're ultimately running the same non-free software in both cases (even though, the first case is invisible to software and the second case is visible to software), and it's just a matter of location, either ROM or disk. Since running fixed non-free software is better than running vulnerable non-free software, the "Respect Your Freedom" hardware's "quasi hard-wired" firmware is a waste of time and provides less user freedom.

I only described the disagreements, it's up to you to decide. Now, I'm curious to know what would be your definition of "Libre", after learning what I've told you?

iostream23• 4 years ago

You would make an EXCELLENT moderator or facilitator. You gave fair shrift and explanation to the various perspectives anc concerns this thread is full of. I will happily vote for you if you ever run for public office.

mindslight2• 4 years ago

I'm not arguing with your overall comment, because I think it's a decent summary of the FSF's position. But a few nitpicks with their position:

The FSF's argument is basically the following: Consider a blackbox hardware system, such as a chip. Inside the chip, you may find a bunch of logic gates, hardwired to be a finite state machine, or you may find a read-only Mask ROM driving the microprocessor. But it's irrelevant: from the perspective of the software user outside the chip, it doesn't make any difference, it's just an implementation detail in the hardware realm that matters to a hardware engineer, not a software developer.

This contains an assumption about the behavior complexity of the black box chip. A digital SMPS controller could also be replaced by an appropriate discrete analog signal conditioning and an appropriate beefing up of the power electronics. Instead it uses some advanced digital processing (assorted operating modes based on current draw, etc), which is why the manufacturer chose to use a general purpose CPU programmed with software. As soon as something rises to the level of using software, I would say the FSF has "jurisdiction" - the complexity of software is being deployed without a way for the end-user to grok that complexity. It's only historic pragmatism for why the FSF gave it a pass.

if the ROM is 100% read-only, or if the Write function is permanently disabled at hardware level

Except that for the most part true mask "ROM" isn't a thing except for tiny bootloaders, and we're mostly talking FLASH which remains writable. Tying !write_enable high and calling that a "ROM" is more rules lawyering than an appropriate description of the actual situation. Especially when the developer of the proprietary blob expects to release updates (ie has released unfinished software), and this one device's implementation is unusual to prohibit such updates.

I'm curious to know what would be your definition of "Libre"

Due to "software eating the world", close to nothing these days is actually "Libre". I think it needs to be a scale, for things that afford you more or less freedom. Furthermore it needs to take into account anti-Freedom developments such as signature lockdowns and the upgrade treadmill. Furthermore a complex device needs multiple numbers to take into account where the code is running - on the main CPU domain versus an isolated subprocessor.

For example my desktop is a librebooted KGPE with an AMD video card. The AMD video card is locked down hard and itself is very poor for software freedom, but the overall device is excellent for software freedom because the main CPU domain is completely Libre. So ideally it would have a combined score saying "this is one of the best Libre options you have right now", combined with another metric on the same scale describing the peripherals. If you wanted an actual Libre video card, then you'd need some newly designed thing which also endeavored to be open, not just a video card from one of the big three full of proprietary software, in assorted stages of being reverse engineered.

FWIW on such a scale I would make higher numbers more Free, as we obviously have a lot of headroom with regards to embedded/hardware freedom, and manufacturer community engagement.

jabl• 4 years ago

how big of a project would it be to create a fully libre (whatever you want to call you it) laptop? Like how feasible is it to use "free" components put together into a package and what kind of budget would be required?

Very big, and unfeasible?

I think, to start with, the goal can't be "a laptop". It'll be obsolete in an instant, likely even long before hitting the market. IMHO the goal should be building up a ecosystem of companies producing libre components (from which one hopefully eventually would be able to source everything needed for a laptop). There is some movement in this direction (e.g. OSHWA, FOSSi, Skywater PDK), but you know, starting from the bottom so currently mostly microcontroller level stuff. Long way from a laptop still.

China

A regime hellbent on surveilling everything their citizens do suddenly caring about the personal freedoms Stallman worries about?

I'm quite sure that whatever China is doing to rein in the surveillance capitalists it's not because of their threat to personal freedom but rather because they have become powerful enough to pose a threat to the party.

And then proceed to go into every industry with right to repair issues. Deere tractor competitors, home appliances, and so on. In the name of component longevity and repairability. All of this to repudiate forced obsolescence and to promote end user freedoms.

I have great hopes for the right to repair movement. They might eventually achieve something big. As opposed to RYF, which is problematic as the article and this discussion points out, and is destined to be nothing but an extremely niche thing only a few fanatics will ever care about.

jancsika• 4 years ago

Anyone know if the mnt reform laptop is blob-less?

https://mntre.com/media/reform_md/2020-05-08-the-much-more-p...

marcodiego16• 4 years ago

Not blob-free. Imx8 needs blobs to train RAM. There probably other blobs too.

r2834929• 4 years ago

It has one tiny blob for ram initialization, people are looking into removing it. It may become RYF certified. Freedom wise, it is the best modern laptop.

marcodiego16• 4 years ago

Better than the pinebook pro?

pabs34• 4 years ago

Some open firmware resources:

https://wiki.debian.org/Firmware/Open

r2834929• 4 years ago

About the microcode: the argument is basically "It is good nonfree software, just give up and accept it." Sorry? This is FSF. And no, it is not always good: https://www.theregister.com/2018/08/21/intel_cpu_patch_licen..., and when people don't accept it, https://www.theregister.com/2018/08/23/intel_microcode_licen.... If a majority of intel's customers said: sorry, we'll find other solutions rather than accepting your nonfree license, intel would freely license it.

In other words, you can’t microcode update a CPU to add or substantially change capabilities.

There is CCC security presentation floating around where someone reversed engineered microcode before it was signed, and designed a backdoor into it, a remote code execution triggered by going to a specific webpage. That is a substantial capability that exists in todays microcode.

marcan_4219• 4 years ago

It is good nonfree software, just give up and accept it.

You already accepted it when you bought the CPU and it came with the base version. Your choices are to install a bugfix, or not. The FSF advocates for not installing the bugfix, or even informing users of the possibility of doing so. That is utterly illogical. There is no reason whatsoever to run broken proprietary software over fixed proprietary software.

r2834929• 4 years ago

You already accepted it when you bought the CPU and it came with the base version.

No, that is a version you can't physically modify. The other version is one you can't modify because of it's license and signature verification. You are simply ignoring important differences, like saying an elevator is no different than a flight of stairs, they both get you up, and anyone who avoids elevators must be an idiot.

ineedasername• 4 years ago

Is RYF certification a significant market force among users who want more open devices? I don't really follow it closely enough to know, but I checked in on the Librem 5 project periodically and this is the first I heard about RYF certification for the project, or the implication that it would be a significant driver of customer behavior. Is my outsiders impression of this niche incorrect?

marcodiego16• 4 years ago

Personally, I'd love to have a certified device. I'd like to support the cause because I fear my devices can became as locked down as smartphones and video game consoles.

People may mock now, but the trend with regard to DRM, IME and others make me consider "the right to read" as not mere fiction

boomboomsubban• 4 years ago

I think if a reasonable product actually got RYF certification it would attract a lot of people who have so far just accepted that an open device isn't happening and compromises need to be made.

Basically I don't check RYF certification before buying a product, but if I heard of one getting it I'd be interested in it.

jeppesen-io3• 4 years ago

FSF's hardline attitude has always rubbed me the wrong way. I respect and support their goals but at the end of the day software should respect the needs and desires of their users

I saw this on the nonguix repo for all non free software for guix

Please do NOT promote this repository on any official Guix communication channels, such as their mailing lists or IRC channel, even in response to support requests! This is to show respect for the Guix project’s strict policy against recommending nonfree software, and to avoid any unnecessary hostility.

To do my job and boot my laptop nonguix is required but not even allowed to talk about it with the OS it intends to support, is not something I can agree with

I think the above is the type of side-effects seen with a hardline policy of the FSF. Obviously I'm not the target of this type of policy, but I still feel more good can be done in the long run with a little compromise to the realities of using a computer today

marcodiego16• 4 years ago

I understand your position, but it would be better if the compromise was made by "the other side".

jeppesen-io3• 4 years ago

Oh, sure, that would be preferred but I can't see that happening anytime soon. I guess it all depends on whether you feel like the FSFs polices will bring improvement for open blobs etc

seanhunter• 4 years ago

Everyone always thinks it would be better if the compromise was made by the other side, don't they?

What you're describing is just a concession. A compromise is where neither side quite gets everything they want and both have to give a little.

r2834929• 4 years ago

To do my job and boot my laptop nonguix is required but not even allowed to talk about it with the OS it intends to support, is not something I can agree with

The OS isn't a person. The OS has online discussion forums and the people who develop the OS CAN talk about it in the appropriate forum. Identifying and separating nonfree issues is a useful tool in their goals.

The FSF last year started a new campaign that is specifically meant to not be hardline and to respect the needs and desires of users: https://www.fsf.org/blogs/community/support-the-freedom-ladd....

jeppesen-io3• 4 years ago

Identifying and separating nonfree issues is a useful tool in their goals.

Issues are not always easily separated but I understand it's a tool for their goals. It's just not for me

The FSF last year started a new campaign that is specifically meant to not be hardline and to respect the needs and desires of users: https://www.fsf.org/blogs/community/support-the-freedom-ladd....

I was not aware of this - I will read up on it. Thank you

BrS96bVxXBLzf5B3• 4 years ago

Attending an RMS talk at a university ~8 years ago, some (increasingly irritated) lecturers questioned him on the use of proprietary graphics drivers in image processing for use in medical equipment and research. While RMS argued his absolute stance that proprietary drivers are never permissible, the lecturers argued that the drivers were literally saving lives and people would die without them.

"They should die for the cause."

Harm isn't very present on the FSF priority list.

r2834929• 4 years ago

If you try to pin down someone on the fly who is publicly advocating for something on what exceptions are ok, expect them to be stubborn. But there is a lot of pragmatism at work. It's why we have the LGPL, GPL, and AGPL. https://www.gnu.org/philosophy/pragmatic.en.html

marcan_4219• 4 years ago

Ah yes, the AGPL. The license that wants to be an EULA (because that's the only way you can actually close the SaaS loophole), but can't, because being an EULA would be against the FSF's core values (Freeedom Zero), so instead it's a cute hack that is trivial to work around if you want to, while simultaneously being almost impossible to comply with for regular developers. And then the FSF plays it like it has EULA powers and makes everyone believe it is useful and harmless to the free software ecosystem.

Let's break down this amazing license:

9. Acceptance Not Required for Having Copies. You are not required to accept this License in order to receive or run a copy of the Program.

So it's not an EULA. Cool. You can freely run the program as long as you don't modify it. Freedom Zero.

Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.

But if you touch the code, you'd better comply with the License. Great. (These clauses are identical to the GPLv3).

Now the magic AGPL clause. Brace for it, and read it very carefully:

13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

Let's break it down:

If you modify the Program

That is if you are a developer making changes to the source code (or binary, but let's ignore that option)

your modified version

The modified source code you have created

must prominently offer all users interacting with it remotely through a computer network

Must include the mandatory feature of offering all users interacting with it through a computer network (computer network is left undefined and subject to wide interpretation)

an opportunity to receive the Corresponding Source of your version

A direct copy of the source code you have just modified

from a network server

Directly from a server, without any human involved

(the rest of the statement is irrelevant).

Let's say I am Amazon, and I want to SaaS some AGPL software. How about this:

Step 1: Put it in an internal Git repo (No license implication yet, no changes made)

Step 2: Make that Git repo accessible externally with a specific URL or access key (so it is not guessable) (Clause 9 plus plain redistribution, no modifications, no problem)

Step 3: Modify the software to include a link to that Git repo including the secret key (invokes and is fully compliant with Clause 13) with every response

Step 4: Deploy that software on their internal network (Freedom Zero, invokes Clause 9 during deployment, no extra requirements)

Step 5: Stick a reverse proxy in front that deletes the source code offer (No license implication, does not modify the AGPL software in any way, see Clause 9)

Step 6: Profit

Turns out you have to pick one: either control what people do with your software (which makes your license into a non-free EULA), or don't (which means there is no way for you to control any interaction people have with the software). You can't have it both ways.

I know what you're saying: "But a judge would see right through this trick! Amazon is both modifying the code and setting up the reverse proxy!" Great, then just have different entities do each part. Each part, on its own, is unambiguously not in violation of the license; the developing party is only responsible for including the source code offer, and the running party has no responsibility that it actually reach users if they don't touch the code. Now your license defense relies on proving collusion. Good luck with that if the people involved were careful enough not to write down their evil plans anywhere. Heck, this situation could easily happen semi-organically - a reverse proxy doesn't have to be designed to explicitly remove the source code offer, it could merely be a protocol translator/wrapper that has no support for that specific message/tag, which is something that happens all the time.

Now let's say I am a regular developer of AGPL software and I want to work on it like any other open source project.

Step 1: Clone the GitHub repo

Step 2: Make a change to the code - oops, license violation! Clause 13! I need to change the source code offer first!

Step 1.5: Change the source code offer to point to your repo

Step 2: Make a change to the code and push it

Step 3: Open a pull request with your change

Your change includes the source code offer commit in the history, and cannot be auto-merged. Any AGPL project accepting pull requests from third parties (or even their own developers, if there is no copyright assignment and each developer retains their own copyright) is accepting that everyone is repeatedly violating the AGPL as part of the normal development process, if they're using the GitHub flow and the source code links were not updated in the branches to be merged.

Note that the license doesn't even say anything about Clause 13 being restricted to redistribution or execution or deployment to external users. Merely downloading some AGPL software and changing some code locally is an instant license violation, if you haven't previously made that version accessible and changed the source code offer. Somehow. I don't know. The whole thing is crazy. It's setting rules for mandatory features that must be implemented in the code. It's not a Freedom Zero violation, but it's a Freedom 1 violation instead: The freedom to study how the program works, and change it to make it do what you wish. AGPL Clause 13 restricts how you are allowed to change programs.

As far as I can tell, there is precisely one kind of open source project that could conceivably benefit from the AGPL without being an undue burden on developers and a danger to users: Web apps with nontrivial amounts of JS source code (which would be covered under the license), with the source code offer in that code (so it cannot be removed without invoking the license, even by an automated process, maybe, hopefully a judge would see it that way), and a source code offer mechanism that has the app read its own source code from the live copy, so that no updates to the URL need to happen for different forks.

Anything else, and it's just a terrible license. But the FSF will tell you it's amazing and fixes the SaaS loophole, because they've long since given up on actually being honest and just want to have their cake and eat it too, even when it just isn't possible.

oshiar53-04• 4 years ago

"They should die for the cause."

In his stance, more like "proprietary driver vendors are holding hostage of patients."

random3142• 4 years ago

Which talk was this and what kind of medical equipment?

d0mine• 4 years ago

Imagine you are fighting for peasants rights; feudal doesn’t like it and orders to kill one peasant per day until you surrender. Question are you the bad guy for not surrendering?

chii2• 4 years ago

are you the bad guy for not surrendering?

those peasants who died are killed by the feudal lord, so no - 100% not the bad guy for fighting.

The only way you could be considered a bad guy is if you used peasants as suicide bombers - and only if those people didn't volunteer.

jimmyvalmer6• 4 years ago

Yes, if the right you're defending is as arcane and hard to explain as libre software.

smoldesu• 4 years ago

In the case of medical training, you're taught that you should assume an incapacitated person would like to receive care unless otherwise instructed. I think that pretty easily carries over to software licensing too; unless your patient refuses to receive treatment aided by proprietary software, you should assume that they're comfortable having their body fed to the proprietary meat-grinder.

idontcareabout• 4 years ago

why would life saving equipment be permitted to be proprietary in the first place.

how many people have died because they could not access it.

you speak as if proprietary causes no harm.

jimmyvalmer6• 4 years ago

how many people have died because they could not access it.

It's only in the last hundred years that one's health couldn't be discussed in a transactional quid pro quo. Both humankind (300,000 years) and evolving life (3.5B years) never held that stipulation.

neilv2• 4 years ago

I don't know how much to read into this anecdote, given a related one from around the same time...

In a discussion with RMS, after a little argument, he agreed that the immediate safety of certain underdogs who needed secure communications trumped libre software goals. (The question was something about the libre software solution at the moment being inferior for some threat model.)

BrS96bVxXBLzf5B3• 4 years ago

That's interesting! He was definitely playing an antagonistic character ("I have a bad ear", "I can't hear you" whenever someone said something disagreeable; one person didn't get it and kept repeating their sentence more loudly to no change). I could imagine him having that more liberal private stance whilst keeping the public one consistently firm.

voidhorse• 4 years ago

I get what you’re saying, but this form of argument sort of talks past the stance of the RMS’s of the world. The fact that the software being used is proprietary is a historical accident and not an attribute of the software that makes it function a certain way—it’s entirely possible to write non-proprietary life saving software.

RMS is arguing for principles and ideals. Sure when it comes down to it, it’s absurd to say we should save someone’s life because of the proprietary nature of the software, but that’s not really the point — the point is to strive for a world in which life-saving software isn’t proprietary in the first place. When one is arguing for absolute ideals, one tends to speak in absolutes and ignore historical circumstance since that’s sort of the point (though of course it’s also very silly in its own way). There’s a difference between advocating for a principle/ideal and solving concrete problems in a world that doesn’t yet meet that ideal.

If we were to constantly let proprietary software stick around because it served some crucial function and never put in the work to replace such software with non-proprietary alternatives, we’d never realize a world without proprietary software—so you can see how someone purportedly striving for that ideal really can’t capitulate.

KennyBlanken• 4 years ago

You don't get what they're saying at all. There are about a thousand better ways he could have responded while still trying to convey his ideas. Instead, he said probably the single most offensive thing he could. He either did it on purpose to piss them off, or he didn't understand how offensive it would be, or he didn't care.

He has no idea how to be persuasive, no idea how to adjust his arguments or present his ideas effectively, no idea how he comes off to others, no idea how to read a room, no idea how to see other people's perspectives on issues, and doesn't care to try. He hasn't demonstrated the slightest intellectual or emotional self-improvement in thirty years.

arminiusreturns• 4 years ago

At this point I'm seriously considering the idea of pushing for using whatever security umbrella fad of the day is to argue for imminent domaining and then forcible open sourcing infrastructure critical technology. Roll it in with a fresh healthcare for all deployment to test. Open source the resulting data, find some solutions.

edgyquant• 4 years ago

Appeals to emotion are a fallacy

Bancakes2• 4 years ago

The moral burden is on the firmware makers to release the sources. When do we stop pretending graphics stacks are some magical steampunk machinery? There is nothing unique to a few thousand lines of code, they should release it.

tmalsburg22• 4 years ago

Counterpoint: How many are dying because the software isn’t free? It’s possible that more could be saved if it was. Perhaps harm doesn’t rank highly for those seeking to make profits from medical equipment?

kaba04• 4 years ago

You think software companies get rich from the proprietary software in medical equipment sold in low quantities that cost a million dollar and is made from super strong magnets creating insane magnetic forces?

Answering your question: probably zero. Medical equipment is expensive due to the very high-tech technology it requires (the aforementioned magnets, but for ultrasound imaging one has to simultaneously output and receive sound waves in multiple dimensions) as well as the safety level being so high (you don’t want the given radiation amount overflow due to a bug).

Find blame in for-profit insurances instead.

rambojazz• 4 years ago

If that quote from RMS were to be taken seriously, then he should not even take a plane, or a car. Hopefully he'll never be in the position of choosing death vs free software.

koprulusector• 4 years ago

I’m confused. Who’s the target audience of this post? Anyone strictly adhering to FSF recommendations is most likely not a for profit business, and therefore probably doesn’t give a care about spectre or meltdown, for example. I for one add mitigations=off to all my personal systems boot flags.

marcodiego16• 4 years ago

Although small, FLOSS supporters are severely underserved. I think it is possible to use the certification as a means to profit. Even if only for a few products or to get a good image among a faithful group. The sites listed selling ryf-certified devices are certainly benefitting commercially from that.

jimmyvalmer6• 4 years ago

FLOSS supporters are severely underserved

I'd say the invisible hand is getting it right here. FLOSS advocates are the worst kind of customer -- both frugal and sententious.

yellowapple2• 4 years ago

Not only does the FSF object to the inclusion of nonfree firmware, but it also objects to even so much as making it available. Case study here would be OpenBSD, which is about as free of an operating system as it gets, and which does not ship with nonfree firmware by default. However, because of the existence of the `fw_update` command (which - by the explicit consent of the user/owner of the machine - fetches any nonfree firmware necessary for the hardware on one's system), OpenBSD doesn't qualify for the FSF's endorsement.

The FSF's stance here also impacts the "ports" trees of various BSDs and (GNU/)Linuxen; if they so much as include instructions for compiling and installing nonfree software (regardless of whether they actually include nonfree software), the FSF considers the whole OS nonfree. Same deal with any (GNU/)Linux distro that maintains a nonfree repo - even if that repo is disabled by default.

The rationale for these sorts of stances is that even so much as making nonfree software available for installation is an "endorsement" of that software. In spite of that rationale, the FSF maintains officially-sanctioned precompiled ports of software like GIMP for nonfree operating systems like Windows and macOS - because apparently it's okay to endorse those nonfree operating systems, because reasons.

ziml77• 4 years ago

They explicitly rationalize the Windows builds of Emacs, so I can only assume that's the same rationale as for any other GNU software

To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves.

Taken from https://www.gnu.org/software/emacs/download.html

jimmyvalmer6• 4 years ago

We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom

The weakness of this sauce is staggering. I understand GNU Emacs wanting to preserve forty years of hard work supporting Windows and MacOS, but justifying it via the "taste of freedom" sets off my hypocrisy alarm. It's also just patently false because emacs users stick with Windows precisely because emacs still works there.

seba_dos17• 4 years ago

I think it's important to understand that "being free" and "endorsed by FSF" are two completely distinct states. It's not enough to be fully free to get endorsed - FSF has their right to decide fully arbitrarily what's acceptable enough to endorse it and what isn't, and being technically free is just one of the aspects they are considering. Endorsement isn't technical, it's political.

the FSF considers the whole OS nonfree

As an example, the FSF does not consider Debian nonfree - they even acknowledge that "Debian is the only common non-endorsed distribution to keep nonfree blobs out of its main distribution"; they just don't want to endorse it because it points people to nonfree software. As a user, I don't mind that it does so I use Debian, but FSF is free to not want to endorse it because of that.

jimmyvalmer6• 4 years ago

the FSF maintains officially-sanctioned precompiled ports of software like GIMP for nonfree operating systems like Windows and macOS - because apparently it's okay to endorse those nonfree operating systems, because reasons.

I've been for the last year shouting myself hoarse on emacs forums regarding this hypocrisy.

guilhas2• 4 years ago

Not only does the FSF object to the inclusion of nonfree firmware, but it also objects to even so much as making it available

Guix is FSF approved and also gives the ability to enable nonfree-firmware?

I know Debian is excluded for hosting nonfree software, even if disabled by default

aragilar• 4 years ago

The author seems to limit their analysis to laptops. As far as I know, desktop/server class hardware does have reasonable options like those from Raptor Engineering (such as Talos: https://www.raptorengineering.com/TALOS/talos_comparison.php), though I could be wrong. Could this more of an issue relating to how laptops/phones are built/marketed/sold compared with desktops/servers (and given those effects, building a free-software-based laptop/phone is practically impossible given the lack of possible components)?

marcan_4219• 4 years ago

Indeed, the Raptor systems are about as free as you can get for a desktop system, as far as I can tell. I was particularly impressed when they pointed me at the source code for their RAM training routine; that one has been a sticking point in many other systems.

They still aren't 100% free because that is impossible; there is no clear line to be drawn between hardware and software, and the hardware isn't free. But at least we can truthfully say they have no nonfree mutable blobs or large ROMs, and even some critical small ROM blobs are documented and open source, like the CPU boot ROM.

(We can't say there are no nonfree ROM blobs - I guarantee there's a small CPU running nonfree ROM code somewhere in an IC on the board and they just don't know about it, because manufacturers do that all the time - and besides, even if their systems somehow avoid that, your monitor, keyboard, and mouse will all have that problem).

throwaway815233• 4 years ago

I had a discussion similar to this with RMS a while back and he seemed to think that the x86 and ARM architectures were completely hopeless for this because of the management engines etc. At that time there were credible attempts to build completely blob-free POWER9 systems, so Ifigured that was the thing to get once they got a bit more affordable. I don't think the Talos stuff ended up blob free, but it is way less blobby than x86 stuff. Maybe there is hope of blobless RISC-V systems some day.

floatboth• 4 years ago

Most processors with Arm cores do not have "management engines", in fact lots are almost blob-free. Some like Marvell Armada 7k/8k can run without any blobs.

fitzsim• 4 years ago

The Talos II is blob-free. At launch, proprietary binary-only firmware was required for the network interface, but Raptor Computing Systems offered a bounty to reverse engineer and do a Free Software re-implementation of the firmware, and that effort succeeded and the bounty was paid. See:

https://wiki.raptorcs.com/wiki/Project_Ortega

https://github.com/meklort/bcm5719-fw

deknos• 4 years ago

people have opinions. more news at 11.

sorry, but i think the FSF is totally justified. the ME engine and stuff like that showed that the industry does not have the best interest of customers (business and endusers alike) at heart and will fuck them over for more money.

and then the whining here is great again and it's like "Stallman was right" and at the next turn "but ma feetures" complaints come around, because it costs more money or time which also would be the ethical thing to do often enough

guilhas2• 4 years ago

In terms of security and stability I think FSF view is correct

Although I think they could have a second tier, more relaxed for Debian, NixOS and others, that exclude nonfree software/firmware but allows you to enable it. But in general I think it is commendable that they have been able preserve their values and not dilute and disappear

When I buy my hardware I make sure it is compatible, stable and won't have many issues with Libre Linux, even thing like swapping the wireless card to a compatible one

And this has been the rule also for all Linux users. You want to make sure you have a smooth experience, you will have to check for hardware recommendations. Want fingerprint working? Better be sure before you buy

Regarding security most Libre people are not serving cloud services in their computers, and install only open source. So the microcode security mitigations like, spectre and meltdown, are mostly unnecessary. Also browsers and kernels have been patched for it anyway

When I configure a server I will probably majorally never upgrade it, because it will always cause problems, sometimes small, other times big headaches. I would sooner configure a new one and migrate things slowly

If one microcode update is enough to fix your system is also enough to break it: Intel to disable TSX by default on more CPUs with new microcode https://news.ycombinator.com/item?id=27664856

This recent security paranoia that you should be updating everything every day or else the hackers will get you! seems unnecessary and potentially harmful

spacexsucks• 4 years ago

No. The hardware industry's relationship with the user owning their own devices is harmful.

jimmyvalmer6• 4 years ago

There's a ton of expertise being bandied about here.

It's sad any of it is being directed towards sophistic, quasi-religious debate.

toolcombinator2• 4 years ago

The central problem here, is that RYF, just like the FSF itself, is outdated and hasn’t been relevant for a decade or more.

It’s a dinosaur from another era with its hypocritical RAM vs ROM policies, or “secondary processor” loopholes.

It assumes that there’s one Central processor in charge, something that hasn’t been true for a very long time.

Which parts of an SOC is central? The CPU? Great. Modern CPUs are multicore chips, so which one are central and which one are secondary?

The FSF’s relationship with firmware is harmful to free software users

Related Stories