LWN: Comments on "Conill: the FSF’s relationship with firmware is harmful to free software users"

Conill: the FSF’s relationship with firmware is harmful to free software users

ecm — Tue, 01 Mar 2022 15:32:39 +0000

Indeed, this wrong view completely ignores the benefits of an assembly language that you _cannot_ get from just disassembly. Symbol names and comments as for the big ones. In my program logic work I also make extensive use of macros to aid my sources' advanced learning and style.

Hardware certification & open source

excors — Wed, 23 Feb 2022 01:38:29 +0000

You can never be sure if you've licensed all relevant patents, though. Maybe a patent troll will turn up years later with one that you had missed.

As I understand it, they are required to do some analysis of publicly-available materials to have reasonable confidence that you're infringing their patent before suing you; they can't sue purely speculatively. (Once they have sued with reasonable grounds, then you can be legally compelled to share your private code with them to help them prove infringement, but not before.)

It's much more economically viable for the patent troll if they can download a hundred companies' public firmware source trees and grep for their patented algorithm, than if they have to spend weeks manually reverse-engineering each firmware blob to find the ones that might infringe. So hiding your source code will increase the chances that they won't bother looking for your accidental infringements.

Hardware certification & open source

JanC_ — Wed, 23 Feb 2022 00:24:12 +0000

But there is no reason for you to obfuscate your code when you licensed all relevant patents (it might be useful for the patent holder, but not for you as the licensee).

Hardware certification & open source

excors — Tue, 22 Feb 2022 14:03:19 +0000

> Patents are written in a very obscure legalese, designed to make the inner workings of the patented thing as obfuscated as possible.

Hmm, that doesn't seem to describe most of the patents I've looked at.

To pick an arbitrary example that would be relevant for a GPU, the S3TC texture compression patent (now expired, so there should be no risk of liability from reading it) at https://patents.google.com/patent/US5956431A/en has a perfectly readable "Background" and "Summary", explaining broadly what the new technology is for and how it works. Then there's the "Detailed description" which is still not too bad and gives most of the information you'd need to implement it. It's certainly not good technical writing, I guess because it was probably written first by an engineer (who understands the technology but may not be a great writer) and then adapted by a lawyer (who only half understands the technology and really likes saying "preferred embodiment" and referring to stupid flowcharts), but it's not actively obfuscated - if you have a reasonable level of background knowledge then you can skim over the nonsense parts and extract the important information without too much trouble.

I don't think that's an outlier; most patents that I can remember reading have a similar kind of description, some better and some worse, usually written clumsily but making a good-faith attempt to describe the technology. (Perhaps it's different in other fields though, I can't claim to have very wide experience.)

The "Claims" is the largely unreadable legalese, but that section doesn't matter when you're trying to implement the technology described in the readable sections. It only matters when you're trying to _not_ implement what was patented, so you can solve the same problem in a non-infringing way, in which case you need legal advice.

> Otherwise you could just tweak a key part of the patented idea and replace it with something else.

That's why the claims are structured as they are ("claim 6: the system in claim 5, further comprising ...", where each claim is separately enforceable) - it's a tree of variations of the idea, where the root node is the most generic and the leaves are the most specific. You can avoid one of the leaf claims by tweaking a part of the idea, but then you might be infringing a different leaf claim (if the patent writer had already thought of that tweak), and/or you'll still be infringing one of the broader claims. As you get closer to the root, the claims are more likely to get thrown out for being too obvious or for there being prior art - the more specific claims are there in case the broader ones turn out to be invalid. But none of that depends on deliberately obfuscating the idea.

Hardware certification & open source

geert — Tue, 22 Feb 2022 09:54:37 +0000

Exactly. All Intellectual Property laws were envisioned for the greater good of society, and tried to find a good balance between the benefit for the owner and the benefit for society. But the modern approach of the owners is to try altering the deal, so we (society) constantly have to pray the deal isn't altered any further.

E.g. disclosure in patents is hampered by obfuscation.
E.g. copying for fair use and after copyright expiry is hampered by DRM, anti-circumvention laws, and repeated extention.

Hardware certification & open source

smurf — Tue, 22 Feb 2022 07:45:26 +0000

It's perfectly useful. Patents are written in a very obscure legalese, designed to make the inner workings of the patented thing as obfuscated as possible. Otherwise you could just tweak a key part of the patented idea and replace it with something else.

If it's significantly more work to figure out how the thing is supposed to work than to reverse-engineer the code implementing it, well, there's your answer.

The flip point of this is that the patent system was envisioned to foster sharing new ideas, not to inhibit it. Unfortunately you can't point at a piece of code the same way you'd point at a piece of machinery and say "see, that's the fooselwort from my invention, it's obvious that they stole it!".

It's a real problem, but the current obfuscation in both patents and code is its worst-possible solution IMHO.

Hardware certification & open source

JanC_ — Sat, 05 Feb 2022 23:24:00 +0000

Hiding source code is only useful when you violate patents, not when you license them…

Hardware certification & open source

marcH — Sat, 29 Jan 2022 22:17:51 +0000

> They tried to draw the line somewhere to make it possible to create a device with their stamp on it,

In other words they tried to find a _binary_ answer for an "analog" problem that is too complex for that.

Some people complained the FSF has become "out of touch" but that's not true: this shows it is 100% ready for social media, partisanship, etc. Very well in tune with the times.

> even if it ended up creating some comical implementations.

It is indeed a "show" for the most part.

Conill: the FSF’s relationship with firmware is harmful to free software users

marcH — Sat, 29 Jan 2022 21:55:30 +0000

DisplayPort link training is very similar BTW. Others probably too.

Hardware certification & open source

khim — Sat, 29 Jan 2022 16:38:05 +0000

> The claim is that firmware in ROM is OK, firmware that can be changed by the vendor is not, but the reality appears to be that the rules allow for firmware in changeable memory as long as the Free software can't directly change the firmware.

Thus, basically, precisely and exactly backward from where others are trying to push?

> So SSDs and ODDs get away with it, because the Free software can't rewrite the firmware flash, only the firmware itself can do that (and can implement arbitrary anti-Freedom checks in the process).

Worse, they can attack the host system easily.

There are ways to mitigate that problem, but, again, it's not clear if anyone on list of FSF-endorsed distributions works on that or even if they think about these issues at all.

> It's a mess that comes from taking a rule without thinking through the rationale

Yes, and no. Mostly it comes down to an attempt to push the World back to the state of 1980th or maybe even 1960th. When everything was either free software or, if not, you can easily view bits with naked eye and reverse-engineer everything.

The world have changed, these principles have become pointless, but instead of stopping and thinking about what new rules may you invent which make at least some sense in the middle of XXI century they try to push history back.

It's not even comical. It's sad.

Hardware certification & open source

farnz — Sat, 29 Jan 2022 10:30:19 +0000

For all the noise the FSF makes about RYF, it's not actually internally consistent with its own rules. The claim is that firmware in ROM is OK, firmware that can be changed by the vendor is not, but the reality appears to be that the rules allow for firmware in changeable memory as long as the Free software can't directly change the firmware.

So SSDs and ODDs get away with it, because the Free software can't rewrite the firmware flash, only the firmware itself can do that (and can implement arbitrary anti-Freedom checks in the process). GPUs, however, don't, even if you soft-disable them so that the proprietary driver can't work without additional Free code to enable the GPU, because reasons (that from the Free software side of the system, the SSD/ODD has firmware in ROM).

It's a mess that comes from taking a rule without thinking through the rationale; the "ROM content does not have to be Free software" rule makes sense if you're thinking about a boot ROM that's literally carved in silicon inside the SoC and just brings up enough of the hardware to replace the running code with external code. It does not make sense when thinking about hardware that loads its firmware from external sources, because it closes off the option of reverse engineering the hardware and producing your own firmware.

Hardware certification & open source

farnz — Sat, 29 Jan 2022 09:58:26 +0000

Admittedly, the US version has to meet both 47 CFR Part 15 and 47 CFR Part 97 rules, because it's designed as an amateur radio transceiver, but my Icom IC-7300 has a grid of surface-mount diodes for configuring its SDR software, acting as a ROM you program with a soldering iron. Take off the wrong diode, and there's no guarantee that the device will meet Part 15 rules.

So, current feeling seems to be that if you have to disassemble the case and apply a soldering iron to breach the rules, then you're compliant with Part 15 rules - it's not readily accessible to the user, and it's clearly not intended to be accessible to the user (it's a tiny grid of 1.2 mm by 0.8 mm diodes as close together as Icom's factory can handle).

You could easily do similar on a device - a 3x3 grid of diodes where the outer 8 have to be in the correct positions to enable TX, and the inner diode disables signature checks on firmware. Voilà, a device that meets Part 15 rules if unmodified, but where a user of sufficient skill can take it apart, remove the middle diode, and run their own software; if you do that modification, you can't legally sell the device any more, but that's a different matter.

Hardware certification & open source

Wol — Fri, 28 Jan 2022 23:11:51 +0000

> My freedom to receive bugfixes was removed, sorry. Intentionally. My ability to run free firmware replacement was removed, sorry. Intentionally. These are not theoretical how many angels can dance on the head of a pin? style freedoms, these are very practical and important freedoms. And FSF demands their removal, there are no other reason to remove them.

Have you read Terry Pratchett's "Science of Diskworld"? The argument about how many angels can dance on the head of a pin is an extremely serious philosophical question! Just because our arrogant "we know better in the 21st century" minds don't believe in angels ...

The FSF's obsession with RYF is EXACTLY THE SAME ARGUMENT, just viewed through 1980s blinkers!

And unfortunately for us, in the 1920s Godel proved that your argument is subject to exactly the same philosophical blinkers, just looking through a different set of eyes! :-)

By the way, I am agreeing with you that I think the FSF stance is stupid, it's just that by being dogmatic you are yourself making exactly the same mistake that they are, just disappearing down a different one of those twisty little passages, all ....

(And I'd actually thought about angels on a pin, even before I saw your response! :-)

Cheers,
Wol

Hardware certification & open source

khim — Fri, 28 Jan 2022 19:52:32 +0000

> Nope, for RYF certification, it's OK to have your proprietary blob in a ROM that cannot be replaced, but not OK to load unsigned code from the user.

Is it actually true? They have laptops in the list. With SSD and DVD drives.

Do they actually cripple these, too, and make firmware unupdateable on these?

I just couldn't find any info on Technoethical web site.

Conill: the FSF’s relationship with firmware is harmful to free software users

khim — Fri, 28 Jan 2022 19:02:20 +0000

Please don't feign ignorance.

Situation with Debian is more-or-less-the-same as with RYF certifications: Debian wanted to be endorsed by FSF, crippled their official installers to do so, failed to achieve that goal. This article is similar to papering over a binary blob in more ways than one: yes, the problem with FSF is more than a decade old, yet everything is the same even today: Debian is needlessly crippled yet FSF doesn't recommend it because it's not crippled enough.

> Debian policy is determined by Debian Developers, not the FSF, and is sometimes at odds with FSF policy; e.g., manuals for GNU software are usually considered non-free packages by Debian, or not packaged at all.

True. And I, for one, would have been happier if Debian stopped these useless attempts to get endorsement from FSF, made an official installation DVDs actually usable (and thus reduced workload: they already provide usable DVD images, you just have to dig a little on the website to find them) but, apparently, not everyone agrees.

RYF does similar harm: people are crippling their devices for no good reason and this doesn't, really, help anyone. That's what the article which we are discussing says.

Thankfully both FSF's OS distribution enforcement and RYF-list are freak sideshows which affect very few people, but they still do some harm, thus couldn't be completely ignored.

Conill: the FSF’s relationship with firmware is harmful to free software users

anton — Fri, 28 Jan 2022 18:44:58 +0000

Before Linux even arrived FSF was making GNU tools available for proprietary OSes.

And many of them still are (although sometimes with fewer capabilities than on free OSs). But the FSF never claimed that the proprietary OSs respect your freedom.

I have no idea what your Debian installation problem is about and what it has to do with the FSF. Debian policy is determined by Debian Developers, not the FSF, and is sometimes at odds with FSF policy; e.g., manuals for GNU software are usually considered non-free packages by Debian, or not packaged at all.

Conill: the FSF’s relationship with firmware is harmful to free software users

khim — Fri, 28 Jan 2022 18:10:31 +0000

> The purpose of the FSF is not compatible with adjusting their positions to achieve maximal mindshare

Before Linux even arrived FSF was making GNU tools available for proprietary OSes. Specifically to make sure people would be able to use them for their own needs. And maybe later would become a GNU developers.

So it was capable of doing that long time ago.

> i.e., becoming proponents of proprietary software

You don't have to become proponents of proprietary software. But have to admit that it exists.

FSF tries to play very strange game and pretend that if you just stop talking about proprietary software it would, somehow, disappear.

This is naive. Specifically because of that:

> As for positions of the FSF, they have always been minority positions.

Instead of promoting anything at all you are just becoming a laughing stock.

> In that case, why worry about what the requirements for that label are?

Because their propaganda makes life harder for people. If I want to install Debian then I have to seek some “kinda-sorta-unofficial-except-produced-by-the-same-people-who-make-official” image.

Which, frankly, just makes life harder for newbies and achieves nothing else.

RYF label? Frankly, I'm surprised it still exists. If Ariadne Conill wouldn't have written it's article I wouldn't have even known it's still there and even includes some strange things, like four-figure motherboards.

Conill: the FSF’s relationship with firmware is harmful to free software users

anton — Fri, 28 Jan 2022 17:36:34 +0000

They don't want it.

In that case, why worry about what the requirements for that label are?

As for positions of the FSF, they have always been minority positions. The purpose of the FSF is not compatible with adjusting their positions to achieve maximal mindshare (i.e., becoming proponents of proprietary software).

Conill: the FSF’s relationship with firmware is harmful to free software users

jschrod — Fri, 28 Jan 2022 17:23:40 +0000

Ah yes, open standards -- like Unix(tm).

That's all that we needed to get the Unix vendor wars. I was there and still have my scars -- and I prefer FOSS to these open standard times very much, thank you.

Hardware certification & open source

farnz — Fri, 28 Jan 2022 17:09:03 +0000

Nope, for RYF certification, it's OK to have your proprietary blob in a ROM that cannot be replaced, but not OK to load unsigned code from the user. It appears from the way that people are doing things that with a little bit of sleight of hand (flash only rewriteable by the proprietary code, not from free code), you could get RYF certification for a device where the vendor can replace the firmware, but the user cannot, since the certifier cannot check that the flash really is read-only.

This is part of why the RYF scheme is such a mess; I can take a system that's almost entirely built on proprietary software, shove the lot into ROM, leaving just the Free Software on modifiable storage, and I have a system that meets RYF guarantees. I can also have a system where the user controls all the running software, but because I don't currently have Free Software for part of it, I can't get RYF certification, even though I might supply no software at all for the hardware that has no Free Software driver.

In the extreme, an RPi with the Broadcom VideoCore software in ROM is RYF-certifiable, as long as the proprietary software is in ROM, the VideoCore is locked down to stop you running user-supplied code on it, and the Free software can be freely changed by the user. An RPi where you don't use the VideoCore at all is not RYF-certifiable, because you could later upgrade the software stack to mix Free software on the ARM cores and proprietary software on the VideoCore.

And yet, in the latter case, I could reverse-engineer the VideoCore hardware and make Free software for it, whereas in the former case, I cannot ever replace the proprietary software with Free software.

I understand where the line comes from - it's attempting to say that only field-replaceable software needs to be Free, and if it's not field-replaceable then it's basically the same as hardware - but it leads to a situation where I can have a multicore ARM running gigabytes of proprietary code and RYF certification, but the same SoC with fully user replaceable code, and no proprietary software can't get RYF.

Hardware certification & open source

khim — Fri, 28 Jan 2022 16:53:51 +0000

> Or am I seriously out-of-date? :-)

Ugh. I don't know. Have you read that decade old article? Situation haven't changed since then.

> What matters to the FSF is tivo-isation, where the VENDOR can rewrite it, but not the user.

Not even close. From that POV situation where binary blob have to come from the host system and it may determine what kind of blob should be uploaded would be perfectly acceptable. After all without the ability to actually deliver binary blob vendor couldn't do anything.

But no, that's not enough for FSF. It says that if you cripple your device and ensure that nobody can ever fix bugs or upgrade the firmware on the “secondary embedded processor” — then it's fine, it's Ok, your device respects your freedom. But if you add the ability to, you know, look on what's driving that secondary processor, maybe even make it possible to control it, then… bam: device no longer “respects your freedom” because, you know, you can actually study how it works now. That's apparently so awful that couldn't be allowed.

Conill: the FSF’s relationship with firmware is harmful to free software users

khim — Fri, 28 Jan 2022 16:35:15 +0000

> Too many people take the simplistic line "possessor == owner". Would it were that simple ...

That's perfectly sensible approach for the $5 “smart lightbulb”. If your margins don't make it possible to employ more sensible route then just go with “possessor == owner”.

If that's something more sophisticated then make it possible to lock it down, but leave the ability to disable that protection, too.

> How is a vendor to know that?

Why would the vendor need to know? It may give the ability to the end user to put it's own keys into the device — and noone except said user would be able to go back to factory state.

IOW: there are many schemes which may be used to combine reasonable security with the ability to reset the device to the factory-shipped state, but, indeed, there are no single “perfect” answer.

Hardware certification & open source

Wol — Fri, 28 Jan 2022 16:28:51 +0000

> But what the FSF is actually saying is that the Four Freedoms don't matter as long as I'm willing to put the software in a ROM instead of in user-rewritable memory.

User-rewriteable, or vendor-rewriteable? I thought that USER-rewriteable was perfectly okay with RYF. What matters to the FSF is tivo-isation, where the VENDOR can rewrite it, but not the user.

Or am I seriously out-of-date? :-)

Cheers,
Wol

Hardware certification & open source

nybble41 — Fri, 28 Jan 2022 16:24:13 +0000

> It really comes down to what you consider "accessible to the user." Which user? All of them, or just the ones who are clever enough to actually do it?

If we assume the latter interpretation, a sufficiently clever user could equally well reverse-engineer and replace a ROM, or even rewire the device's circuitry.

Hypothetically, if replacing the software required the same tools and skills as, say, replacing a resistor, would that satisfy the requirements and still allow for the software itself to be open-source? Perhaps something along the lines of the internal write-protect screw that needs to be removed to update the bootloader on certain Chromebooks? Anyone doing that has various other equally accessible ways to modify the device besides changing the software.

Conill: the FSF’s relationship with firmware is harmful to free software users

Wol — Fri, 28 Jan 2022 16:19:09 +0000

> Keeping a scorecard of a private individual's comments is generally considered creepy beyond the pale.

Is he? Or does he just remember you and has decided he doesn't like you? Reputation matters, and online personae have reputations just as much as meat-space. I'm quite happy to have a (hopefully good) reputation, but I'm sure (in fact certain) some people here consider me an idiot. Your nick is one I always recognise, in a nice way I would add ...

But nicks and names carry reputations, and some people have longer memories than others. You'll probably remember him, next time round ...

Cheers,
Wol

Conill: the FSF’s relationship with firmware is harmful to free software users

khim — Fri, 28 Jan 2022 16:12:26 +0000

> The other is the tactical question of how to get manufacturers to make the software free.

It's not the “tactical question”. That ship have already sailed.

And you either accept that fact and deal with it or you invent useless and pointless certificates.

> If they want the label, this approach increases the probability that they won't slack off until they succeeded.

They don't want it. I have only know about it's existence because I have read about it in the article which made it absolutely clear to me why I don't want it.

I know a lot of devices which were made with an idea to empower their users and give them the ability to tinker with different things: Arduino and Raspberry Pi, Flipper Zero and HiFive Unmatched, there are lots of them. What they have in common is the fact that they don't have that silly “respects your freedom” moniker as long as it can only be given to crippled and obsolete hardware which nobody needs and very few want.

Once upon time FSF was at the very center of FOSS and tinkerers world. Today it pushes itself further and further into irrelevancy.

And instead of thinking about how to return the mindshare (it doesn't matter what you are writing or certifying if people are not looking for cooperation with you) it does things which make it less and less relevant.

Conill: the FSF’s relationship with firmware is harmful to free software users

Wol — Fri, 28 Jan 2022 16:11:35 +0000

> Only if vendor is an idiot and couldn't distinguish between attacker and owner of the device. But if vendor is an idiot and couldn't even design system for that… then where the idea that anything else would be designed correctly comes from?

How is a vendor to know that? You need to throw in a third hat - the hat of possessor. Are they the owner? Are they an attacker? Or are they a user?

Too many people take the simplistic line "possessor == owner". Would it were that simple ...

Cheers,
Wol

Conill: the FSF’s relationship with firmware is harmful to free software users

khim — Fri, 28 Jan 2022 15:35:37 +0000

> Any sensibly-designed secure boot architecture will have anti-rollback support, specifically to prevent those downgrade attacks.

And any freedom-respecting hardware would include a way out of that. Here's how you do that for ChromeOS devices. And here is how you rollback the Pixel phones.

It's not question of ideology or certain certificates. It's just practical need to be able to return to the “factory shipped” mode. You either owner and then should be able to do that or you are not owner and then it shouldn't be framed as sale of the device.

> If the vendor finds a vulnerability and pushes a security update to users, an attacker can read the vulnerability announcement and/or reverse-engineer the update to find the bug, then simply downgrade an updated device to an old vulnerable firmware release and exploit it.

Only if vendor is an idiot and couldn't distinguish between attacker and owner of the device. But if vendor is an idiot and couldn't even design system for that… then where the idea that anything else would be designed correctly comes from?

Yes, sometimes you need to, gasp, add $0.01 physical knob for that to work, but that is not a big deal to demand and pay for.

Conill: the FSF’s relationship with firmware is harmful to free software users

excors — Fri, 28 Jan 2022 14:49:38 +0000

> There's one important thing which FSF could have demanded: downgradeable firmware.

That defeats many of the security benefits of upgradeable firmware. If the vendor finds a vulnerability and pushes a security update to users, an attacker can read the vulnerability announcement and/or reverse-engineer the update to find the bug, then simply downgrade an updated device to an old vulnerable firmware release and exploit it.

Any sensibly-designed secure boot architecture will have anti-rollback support, specifically to prevent those downgrade attacks. (See e.g. https://www.psacertified.org/blog/anti-rollback-explained/)

Hardware certification & open source

farnz — Fri, 28 Jan 2022 14:12:32 +0000

But what the FSF is actually saying is that the Four Freedoms don't matter as long as I'm willing to put the software in a ROM instead of in user-rewritable memory.

The issue with the RYF certification is that I can take exactly the same hardware that uses user-rewritable memory, add a ROM and maybe a microcontroller, and voilà, I'm in a better place in terms of a certification that purports to push me to respect the Four Freedoms than if I allow the user to upload arbitrary code to the hardware. This feels backwards; the FSF is actively saying via RYF that if I make it hard for you to run your own software on your hardware, that's fine, but if I make it easy, then I'm punished just in case you choose to run proprietary software.

Conill: the FSF’s relationship with firmware is harmful to free software users

khim — Fri, 28 Jan 2022 13:57:55 +0000

> I tend to just ignore people who have blanket positions on firmware, because if I was designing a piece of complex hw I'd want to push some logic into something I could update…

There's one important thing which FSF could have demanded: downgradeable firmware. IOW: if any firmware on device can be upgraded then it should be able to downgrade it, too — and you should be able to return device into “factory-shipped state”, absolutely.

That is some important thing which may practically help the end-user, which doesn't affect anyone who doesn't try to restrict user and which I would have been very glad to have.

Even if factory-shipped firmware is buggy and not as robust as “latest and greatest” the ability to go back to that state is quite valuable.

Other than that… I don't see what else you may want WRT any firmware whatsoever.

Conill: the FSF’s relationship with firmware is harmful to free software users

anton — Fri, 28 Jan 2022 13:42:10 +0000

Yes, there's hardware that cannot be changed. And then there is firmware (i.e., in ROM) for programmable hardware, and software that's also called firmware because it replaces what would otherwise be firmware, but it's software because it can be updated; it resides in flash or in RAM loaded on system startup.

There's a reason why manufacturers use firmware or software instead of hardwiring everything, and why they use software rather than firmware: it enables faster time-to-market because immature software is more acceptable than immature firmware or immature hardware. The manufacturer just delivers an update for software, while immature firmware may cause a recall.

Concerning "respects your freedom", I have not looked closely at it, but it seems to me that there are two aspects at work here:

One is the practicality of distinguishing hardware from firmware. Can they do it, and if so, how? E.g., is the PLA of the 6502 instruction decoder hardware or firmware? By contrast, it is far easier to distinguish software from firmware: If somebody can update it, it is soft.

The other is the tactical question of how to get manufacturers to make the software free: It seems to me that the idea is that if they give the manufacturers the choice to forego either the dubious advantages of proprietary software or the advantages of using software rather than firmware, manufacturers will choose the former. Unfortunately, it seems that until now most manufacturers choose to forego the advantage of "respects your freedom" labeling.

But OTOH, if you stick "respects your freedom" on a piece of hardware where not all software is free, the label becomes a freewashing exercise. Some suggest that the option of turning the software into firmware also opens an avenue to freewashing, and maybe the criteria should be tightened, but that would also need an answer to the question of how to distinguish firmware from hardware.

Concerning future free software, I find it totally appropriate for a manufacturer to not get the label while that software is not there, and getting the label as soon as it is there. If they want the label, this approach increases the probability that they won't slack off until they succeeded.

Hardware certification & open source

khim — Fri, 28 Jan 2022 12:02:06 +0000

> Because it is not reasonable to replace all ROM code (e.g. SoC startup) and it is also not reasonable to demand a vendor to tell you about internal design details just because they made a certain design decision along the way (i.e. use processor + ROM).

So you accept the fact that there would be some non-free code inside of your device. Good.

> Remove the "promotes freedom" part and phrase "cripple their hardware" a little different and I agree with the FSFs position as well.

The certificate is called Respects Your Freedom certificate. Not FSF Recommends or FSF's choice. They called it RYF, not me.

And “cripples your device” is also very much on-target: firmware updates are important. These devices weren't designed with unfixable, unmodifyable ROM in mind. Examples from freeboot and other pieces (where code for “freedom-respecting” devices have to deal with artificially-unfixable bugs because these bugs couldn't just be fixed like happens with normal devices) were shown above by others. Cases where functionality was intentionally reduced to pass the certification were shown, too.

> In my opinion you are now moving the goal posts very far.

Me? Nope. FSF did that, not me. I have never wanted nor needed that certificate and after I have found out what it really provided I have never looked for it. Coz it's worse than useless: if you see it then you, then, have to look for what exact functionality was removed to obtain it.

> First we had "Free software" that was all about user-visible things: kernel, shells, utilities etc. and now the argument seems to be "no, no, we always meant internal hardware details to be open as well".

Nope. First we had BSD-style free software and FSF invented “copyleft”. The argument was: yes, it's less free (which is obvious) but it only punishes “bad guys” while “normal users” retain all the important freedoms. Some argued that it's not true, the ability to take something and build something bigger from it without publishing sources is important, too, but that idea wasn't very popular: freedom to restrict freedom of others wasn't considered “the right one” (your freedom to act ends where my nose begins, etc).

Then FSF moved into the realms of hardware and invented these crazy requirements. Which actually make device worse for the regular user which just wants to use it! That's what makes me mad. While FSF “punished the evildoers” I could side with it. Now FSF started “punishing innocents”. The actual end-users of the device who are paying for it our of their own pocket. Sorry, but that's where I draw the line.

> The world moved on, technologies changed and so did implementation strategies in chips but that does not mean that all of a sudden your freedoms are removed -- you never did have the freedom to arbitrarily change state machines inside a chip.

My freedom to receive bugfixes was removed, sorry. Intentionally. My ability to run free firmware replacement was removed, sorry. Intentionally. These are not theoretical how many angels can dance on the head of a pin? style freedoms, these are very practical and important freedoms. And FSF demands their removal, there are no other reason to remove them.

Now, if the reason why FSF demands their removal is practical (we are not sure if evil corporations wouldn't use fuses to deprive users of their important freedoms) then this is what they could have mandated: firmware must be downgradable and it should be possible to return device to factory state. That would have given me real important freedom. And I would have liked it and maybe have looked for such a certificate.

Instead they demand crippled devices which could never be fixed and which I can not study and/or modify at all. Thanks, but no, thanks.

P.S. And please don't start with the “someone may promise to make device downgradeable yet add fuses and then blow them anyway”. If someone is willing to do plain and simple fraud then nothing stops him from sending one device for the certification and then selling entirely different one in shops. That's much more practical concern then some hypothetical “hidden fuses”.

Hardware certification & open source

Vipketsh — Fri, 28 Jan 2022 09:22:12 +0000

> why do you want to draw the line?

Because it is not reasonable to replace all ROM code (e.g. SoC startup) and it is also not reasonable to demand a vendor to tell you about internal design details just because they made a certain design decision along the way (i.e. use processor + ROM).

> cripple their hardware and insist that this act, somehow, promotes freedom.

Put like that I agree with you. Remove the "promotes freedom" part and phrase "cripple their hardware" a little different and I agree with the FSFs position as well.

If the FSFs said "all software in the device must be free, ROM or otherwise" (I'm guessing that's what you are getting at here) there is not even a remote chance that a single device out there meets that requirement. They tried to draw the line somewhere to make it possible to create a device with their stamp on it, even if it ended up creating some comical implementations. Is their stamp usefull in any way ? Probably not, but the problem they are dancing around is real.

Where I think the FSF is a bit crazy is saying that if you somehow hide loading the firmware it is no different to having a ROM to begin with. I can see the logic, but implementation wise it is comical.

> Removal of my freedoms can not make something “more free”.

In my opinion you are now moving the goal posts very far. First we had "Free software" that was all about user-visible things: kernel, shells, utilities etc. and now the argument seems to be "no, no, we always meant internal hardware details to be open as well".

I think you have all the same freedoms the FSF stood for in the past today as well. The world moved on, technologies changed and so did implementation strategies in chips but that does not mean that all of a sudden your freedoms are removed -- you never did have the freedom to arbitrarily change state machines inside a chip.

Hardware certification & open source

smurf — Fri, 28 Jan 2022 08:42:59 +0000

Well, I'd argue that a firmware update is neither "readily" nor "intended to be" able to circumvent RF restrictions.

So, yeah, those arguments are basically a smokescreen. You don't want to publish your specs and/or your sources, fine, your choice, but then just plain say so instead of hiding behind an FCC reg that's not intended to do what you want us to believe.

Hardware certification & open source

smurf — Fri, 28 Jan 2022 07:46:33 +0000

Thank you. This saved me from spending time I don't really have to write what amounts to the exact same argument (and conclusion).

Conill: the FSF’s relationship with firmware is harmful to free software users

robclark — Fri, 28 Jan 2022 06:20:44 +0000

> And how many of these blobs were written in assembly or machine code?

This is almost onto the right topic.. there is a lot of hysterical discussion about firmware.. but there is also a *wide* range of what firmware is, and what (if it is malicious) it has access to. Firmware ranges from things that run RTOS's (or maybe even linux) to things that you'd be hard pressed to describe as a "cpu".. I tend to just ignore people who have blanket positions on firmware, because if I was designing a piece of complex hw I'd want to push some logic into something I could update.. because respinning a chip if I got something wrong the first time is expensive. But discussing fw is complex because you need to understand the hw and what kind of threat it can pose. AFAIK the FSF position of "fw is bad, m'kay" isn't terribly useful.

Hardware certification & open source

khim — Thu, 27 Jan 2022 21:54:29 +0000

> Where do you draw the line ?

More interesting question is: why do you want to draw the line?

> Many chips which look like something simple with an I2C interface (e.g. many power controllers) actually have some ROM + processor inside too. The pattern is everywhere.

Yes. And that, in turn, means that utopia which FSF dreams about, a world without nonfree software is no longer possible, in practice.

Instead of accepting that fact and deciding what to do about that fact — they force others to cripple their hardware and insist that this act, somehow, promotes freedom.

Classic having lost sight of our goals, we redouble our efforts, if you ask me.

> I'm not sure the FSF drew the line in the best possible place, but it is an understandable one.

No. It's not understandable. Something that is more useful and gives me more freedom shouldn't be, suddenly, declared “nonfree” when the exact same thing with certain freedoms removed is called “free” and “respecting my freedoms”.

Removal of my freedoms can not make something “more free”.

> In other words: from the outside they both look exactly the same.

And why that is important? Freedom to tinker is freedom to tinker, it doesn't matter if it's inside or outside. Some things I couldn't change (because they are embedded in ASIC) some things I could change (because they are implemented with loadable firmware). I don't see how changes to something that I may, one day, change to do my bidding into something that I may never change at all help anyone. Can you explain why this change is beneficial and who is the beneficiary?

P.S. When I discovered this craziness is also when I stopped caring for FSF and “free software” movement entirely. If people are mad enough to don't understand the simple logic then I don't see how following them may lead to anything good. Once upon time what FSF was telling made some sense. But not anymore. Sorry.

Hardware certification & open source

Cyberax — Thu, 27 Jan 2022 20:57:22 +0000

Patents don't prevent people analyzing code for security issues.

Hardware certification & open source

NYKevin — Thu, 27 Jan 2022 20:52:25 +0000

> Isn't that what the FCC warning labels on most electronics since the dawn of time are for? The "This device may not produce harmful interference" ones?

That warning references "part 15 of the FCC rules" which turns out to be 47 CFR Part 15, a rather lengthy regulation containing this sentence:

> Except as follows, an intentional or unintentional radiator must be constructed such that the adjustments of any control that is readily accessible by or intended to be accessible to the user will not cause operation of the device in violation of the regulations.

Similar sentences are repeated throughout the regulation, pertaining to more specific cases than "an intentional or unintentional radiator." (A "radiator" in this context means "something that radiates on the RF spectrum.")

So in short, the FCC doesn't want it to be easy for individual users to violate the rules by adjusting the device's controls. This is not an unreasonable goal, IMHO, because it's much easier to police a small number of manufacturers than it is to police ~300 million Americans. OTOH, the average user is not going to reprogram their cell phone or WiFi router at all, much less in a way that violates the FCC rules. It really comes down to what you consider "accessible to the user." Which user? All of them, or just the ones who are clever enough to actually do it?

> Having something like a wifi or cell modem chip with fully hackable code would in theory make it easier to cause problems, but so would not using tri-wing screws and epoxy in a lot of cases - and those are not exactly ubiquitous.

Increasingly, those things are getting used in the neverending quest for thin phones that break when you drop them.