mstdn.io is one of the many independent Mastodon servers you can use to participate in the fediverse.

Administered by:

Server stats:

368
active users

When it comes to non-free firmware I think there's two reasonable positions - treat it like non-free code running on a remote system (suboptimal, outside the scope of current free software priorities) or treat it like software running on the primary CPU (all code on the local system should be free software, no matter where it's running). I think the FSF's position is unreasonable: mjg59.dreamwidth.org/70895.htm

mjg59.dreamwidth.orgCaptcha Check

@mjg59
> users would benefit from most (if not all) firmware being free software

yes

> So I think this is less of a philosophical discussion

no, that does not follow

The stance of FSF is that developing proprietary software is immoral. Therefore, all software is *required* to be free

Just because something is beneficial to users does not mean it's morally required

Therefore, I think there's still a philosophical discussion here: where is the line between the vendors' rights and the users'

Wolf480pl

@mjg59
Now, as to why FSF may've thought ROMs are ok:

The purpose of Free Software is to remove a power imbalance between vendor and user.

If the vendor can change the software, but the user can't, that gives the vendor coercive power over the user.

So one might conclude that if firmware is in ROM, then vendor is as powerless to change it as the user, so there is no power imbalance.

1/

@mjg59
One could even argue that if the OS blocks the ability to load proprietary firmware, that means the vendor can no longer coerce the user to do so.

"You won't be able to watch this Netflix movie unless you update your ME firmware"

"Well my kernel won't let me do that, so I guess I won't be able to watch this Netflix movie either way"

IMO this is too contrived.

It's logically consistent, but I don't think it's useful in practice.

2/2

@mjg59
Oh, also, this ignores the fact that there still is power asymmetry: the vendor knows what code runs on the user's system.

So FSF should also argue that the source code for any ROM firmware must be shared with the user in a way that allows the user to read and understand it, but not necessarily make modifications or run modified versions - since the vendor can't do the latter either.

3/

@mjg59

There is one more argument one might make why ROM shouldn't be considered firmware:

It's possible to have two functionally equivalent chips, one hard-wired to do its job, and the other with an embedded MCU and firmware ROM.

And they would be externally indistinguishable.

Therefore, if one demands that ROM firmware be free, one should also demand that hardware be free.

Which I think is also a valid maximalist stance, and I'd be happy if FSF was to take it.

4/4

@wolf480pl@mstdn.io @mjg59@nondeterministic.computer But FSF is now taking a stance that when taken to it's maximum encourages hardware that locks users in into proprietary firmware rather than hardware that has firmwaare that may be made free. E.g. see Librem phone, it essentially has a bunch of proprietary stuff that is impossible to change vs Pinephone, which started with a proprietary modem firmware, but over time most of it was reverse engineered and made free.

@ignaloidas @mjg59
Yeah, but like

Let's say you draw up a scale of certifications, from
"RIF Bronze: can run upstream Linux kernel"
to
"RIF Platinum: all software and hardware is open-source"

and one of the intermediate levels is
"All software running on main CPU is open-source, all software on other chips is runtime loadable"

And someone sends you a laptop.

How do you check there isn't a hidden ROM in one of the chips?

@wolf480pl@mstdn.io @mjg59@nondeterministic.computer there is quite a difference between "hidden ROMs" and "not runtime loadable". IIRC Librem phome had a separate chip that loaded all of the firmware, and then started up the main processor. It was incredibly dumb, and clearly chasing a RYF certification, even if there was zero tangible benefits to the user. That's why the intermediate position sucks.

@ignaloidas @mjg59
Yes, there is a difference between "hidden ROM" and "not runtime loadable".

What I'm saying is, if you require firmware to be runtime-loadable, but can only check for obvious ROMs, not for hidden ROMs...

then the applicants just won't tell you about ROMs

@ignaloidas @mjg59
though it can still work if the applicants are relatively powerless compared to the manufacturers of the chips, who make the datasheets for those chips, casually mentioning ROMs because they don't give a fuck about your certifications.

Then hiding a ROM is not a viable option, so it's not tempting.

@wolf480pl@mstdn.io @mjg59@nondeterministic.computer Yes. And I see zero problem with hidden ROMs. But wast majority of more complex chips have firmware that is loaded on every boot rather than ROMs for a multitude of reasons, and it's incredibly hard to build a useful computer if you're limiting yourself to chips that either have open source firmware or only have on-chip ROMs. It's essentially impossible, and chasing that "higher" level will only produce shit workarounds for the forseeable future.

@ignaloidas @mjg59
Ok, so let's say we have a certification level of "only free software on the main CPU, other chips do whatever" - we accept hidden ROMs, and obvious ROMs, and loadable proprietary firmware.

Let's say then a vendor with that certification, with some community help, goes to an extra effort over many years to produce free firmware replacements for all loadable fw blobs except the HDMI controller.

Can we reward such a vendor?

@wolf480pl@mstdn.io @mjg59@nondeterministic.computer I mean that's quite literally whats happening with Pine64 - maybe not quite enough help from the vendor itself, but they generally do try to organize freeing-up of their hardware. And in general the response has been mostly positive, with maybe some grumblings for them relying a bit too much on community volunteers on making their hardware useful.

@ignaloidas @mjg59
yeah.

Imagine you're FSF and you want to give them an award for doing that.
How do you...

oh

An award...

Can have a vague criteria.
Like "free firmware champion of the year" - "awarded to the vendor for the greatest effort in providing Free Softwtware firmware for their devices"

and then a committee gives that award to whoever they want.

Yeah, that'd work.

@ignaloidas @wolf480pl @mjg59 >taken to it's maximum encourages hardware that locks users in into proprietary firmware
I don't see how it's a problem if users select hardware that contains proprietary circuits if the circuits aren't malicious and the hardware actually works.

>that has firmwaare that may be made free.
Unfortunately, I'm not aware of a single case of proprietary Wi-Fi card peripheral software being replaced with something usable.

I've only seen one case of some 802.11g Broadcom Wi-Fi chipset getting free peripheral software, but unfortunately that's not usable as it lacks support for Wi-Fi encryption and can only be used on "open" networks.

In many cases, free Wi-Fi card peripheral software is cryptographically impossible to write, as the manufacturer has implemented digital handcuffs in the hardware to stop the user from doing so (intel does this for their wireless cards).

>Pinephone, which started with a proprietary modem firmware, but over time most of it was reverse engineered and made free.
The modem software is still mostly proprietary - only the userspace was replaced.

In this case there was no proprietary software loaded onto the modem at runtime - the software is preloaded onto the modem and as it turns out that someone skilled enough to replace proprietary software has no problem working out how to reprogram an EEPROM.

As always, absolutely nothing has been done about the proprietary Wi-Fi, Bluetooth and auto-focus software.

@Suiseiseki@freesoftwareextremist.com @wolf480pl@mstdn.io @mjg59@nondeterministic.computer I see zero reasons why locking people with proprietary firmware in is better than at least leaving a possibility of loading free firmware. But that's what RYF does.

It's impossible to make a computer these days that complies with RYF without also making it fully open hardware. Because RYF doesn't just restrict loading of the firmware on each boot, it restricts modification of firmware
at all. Pinephone is not RYF compliant not because it needs to load modem firmware each boot, but because it can change the modem firmware. When going with these requirements, you can't even use any remotely modern SSDs or hard drives, because their firmware can be updated.

Building hardware that FSF sees as good is building hardware that restricts your ability to modify it.

@ignaloidas @wolf480pl >locking people with proprietary firmware in is better than at least leaving a possibility of loading free firmware. But that's what RYF does.
Firmware is microprocessor instructions stored on socketed ROM chips - you can't electronically reprogram it, but you can just swap the chip - hence the firmness,

If you (or the manufacturer) can electronically change it, it's software, if you (and the manufacturer) cannot change it, it's hardware.


Please actually read the criteria before commenting; https://ryf.fsf.org/about/criteria (clearly the most important part is "Cooperation with FSF and GNU public relations").

The RYF doesn't require implementing digital handcuffs - it requires you not attack the user with proprietary software.

The exception allows putting proprietary software in the EEPROM of a peripheral device for secondary processors and a skilled enough user certainly can change that (and such does get replaced far more often than hotloaded proprietary software).

>It's impossible to make a computer these days that complies with RYF without also making it fully open hardware.
It is very possible to make a modern computer that complies with RYF that has proprietary hardware, you just need to avoid garbage chipsets.

A lot of so called "open hardware" doesn't work without lots of proprietary software.

>RYF doesn't just restrict loading of the firmware on each boot, it restricts modification of firmware at all
In demonstrated practice a developer skilled enough to replace proprietary software is skilled enough to reprogram an EEPROM, thus such "modification restriction" doesn't occur in practice.

>Pinephone is not RYF compliant not because it needs to load modem firmware each boot, but because it can change the modem firmware.
The pinephone is not RYF compliant because of how the Wifi+Bluetooth chipset doesn't work without hotloaded proprietary software, that is recommended to the user, same as nonfree autofocus software and I believe there are further issues.

The pinephone SoC doesn't load any modem software on boot - that comes installed on EEPROM in the usb modem, which would pass RYF if it wasn't for how that modem software is malicious.

>Building hardware that FSF sees as good is building hardware that restricts your ability to modify it.
The GNUbootable thinkpads actually have schematics available, which actually allows you to modify such hardware.

RYF doesn't do anything to restrict anyone from building hardware that runs 100% free software - it rather encourages doing so.
ryf.fsf.orgRespects Your Freedom (RYF) certification requirements | RYF

@Suiseiseki@freesoftwareextremist.com @wolf480pl@mstdn.io Stop your word vomit

Firmware is microprocessor instructions stored on socketed ROM chips - you can't electronically reprogram it, but you can just swap the chip - hence the firmness
This hasn't been the common accepted meaning for ages
If you (or the manufacturer) can electronically change it, it's software, if you (and the manufacturer) cannot change it, it's hardware.
What do we define as "electronically change it"? If you connect an extra cable to the device and use an external device to change it, is it "electronically change it" or no?

There is a spectrum between hardware and software, and this completely ignores it. RYF says FPGA bytecode is "hardware", so then is Analogue Pocket (almost completely built on FPGAs) RYF? Everything on there is "hardware", so RYF doesn't care about it, even if really, the main purpose of the device is the damn ability to change what's on the FPGA.
The RYF doesn't require implementing digital handcuffs - it requires you not attack the user with proprietary software.
It quite literally gives an exception to "software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product". The simplest way to fulfill the "software installation is not intended after the user obtains the product" is to add blockers.

When the easiest way to satisfy all of the
objective qualifications for a certification is making shit worse, the certification isn't good.

And the "Cooperation with FSF and GNU public relations" section is full of shitty FSF ideological bullshit that as usual does absolutely nothing to actually help free software. You absolutely can have free software Linux without GNU or shit, but nooooooooo, you must mention GNU or the FSF will say that your hardware is shit. This is bullshit, and you know it's bullshit.
It is very possible to make a modern computer that complies with RYF that has proprietary hardware, you just need to avoid garbage chipsets.
Find a single SDD or HDD that has no ability to update it's firmware. I'm absolutely certain that there is none that are still manufactured.

I'm kinda tempted to get one of the only full computers that are RYF certified - those shit-ass decades old thinkpads - just to prove that the drives they're using in them are not RYF compliant because they allow firmware updates. They don't put their model numbers online, because they're just getting whatever random ones they can get cheap, and I can guarantee that their firmware can be updated.
A lot of so called "open hardware" doesn't work without lots of proprietary software.
OSHWA certification requires that all software for using the hardware is open source. https://certification.oshwa.org/
In demonstrated practice a developer skilled enough to replace proprietary software is skilled enough to reprogram an EEPROM, thus such "modification restriction" doesn't occur in practice.
Why I, as a user, should need to get new hardware if I want to start using free software with it? The cost can be zero, but only if the hardware wasn't designed for RYF to start with.
The pinephone is not RYF compliant because of how the Wifi+Bluetooth chipset doesn't work without hotloaded proprietary software, that is recommended to the user, same as nonfree autofocus software and I believe there are further issues.
So you'd rather have all of that stuff in EEPROMs? Making the product worse and burying any chances for simple updates to any free software rewrites of them.
would pass RYF if it wasn't for how that modem software is malicious.
Malicious? How?

And still, it wouldn't have passed, because even though it's stored on NAND Flash (not EEPROM) on the modem module, you can update it from the main CPU, hence failing the "within which software installation is not intended after the user obtains the product" clause.
RYF doesn't do anything to restrict anyone from building hardware that runs 100% free software - it rather encourages doing so.
It may, but the last fully certified computer is ~15 years old, and only became such after 9 years of the actual release of the hardware. Nobody seems to be encouraged to build computers because of RYF. It's a shitty ass program that displays how inept the FSF has been when talking about the software-hardware interface.h

certification.oshwa.orgOSHWA CertificationCertification provides an easy and straightforward way for producers to indicate that their products meet a well-defined standard for open-source compliance.
@ignaloidas @wolf480pl >This hasn't been the common accepted meaning for ages
People have gravitated to an incorrect meaning that misleads the user into thinking that a nasty proprietary program must be this "firmware" stuff instead.

I do not hesitate to call software, software, even if it is popular to mislead people into not realizing that something is software.

If you (or the manufacturer) can electronically change it, it's software, if you (and the manufacturer) cannot change it, it's hardware.

>If you connect an extra cable to the device and use an external device to change it, is it "electronically change it" or no?
If you change the bytes of the program, you've changed the software.

EEPROM can often be externally reprogrammed with wires.

>There is a spectrum between hardware and software, and this completely ignores it.
There is no spectrum - there is software and there is hardware.

Some hardware runs software that is functionally equivalent to a circuit, which is fine provided there is no proprietary license and the user has the freedom to go reprogram the EEPROM if they wish.

>RYF says FPGA bytecode is "hardware"
It does not say that - it lists that software running on FPGA's is software, although it is ideally temporarily excepted.

>the main purpose of the device is the damn ability to change what's on the FPGA.
Not particularly - in many cases including a FPGA chip costs less than getting the hardware designed fabbed and the ability to change what's on the FPGA is never used.

>The simplest way to fulfill the "software installation is not intended after the user obtains the product" is to add blockers.
Adding handcuffs is in no way simpler than just including an EEPROM with no R/W restrictions.

>satisfy all of the objective qualifications for a certification is making shit worse
ROMs and EEPROM's actually makes the hardware functionally better, as the only way to fix any issues is to do a product recall, such products tend to be of acceptable quality.

The first release of hotloaded software is usually hot garbage, full of bugs and typically what happens is that one or two updates are released that fix the most glaring bugs, but such software is still a buggy mess.

I've noticed that freedom-respecting 802.11n Atheros cards actually work properly, but freedom-denying 802.11ac cards are buggy garbage (i.e. I've observed that the was one update that fixed a severe bug that made the card almost useless (would time out instead of connecting to APs), but that was it) - for me it's the 802.11n cards that actually work properly.

>You absolutely can have free software Linux without GNU or shit
You cannot as Linux is proprietary software that doesn't operate on its own; https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/init/main.c#n1522

There is no nontrivial free OS's other than GNU/Linux-libre and GNU/Hurd - every other OS I've inspected has been nonfree.

If the OS lacks GNU and sucks, it clearly would be important to note that by writing that it's BusyBox/Linux.

>Find a single SDD or HDD that has no ability to update it's firmware.
I haven't ever been offered a proprietary HDD update and intend to never install one.

I don't get where you get the concept that RYF requires disabling the ability to update things - all that is required is that the user isn't induced to install proprietary software, which won't happen in the case of a HDD unless you were to.

On non-handcuffed HDD's, the user still has the freedom to write free software for such HDDs.


>OSHWA certification requires that all software for using the hardware is open source. https://certification.oshwa.org/
That site is full of corporate propaganda.

In fact, what the certification requires is; "In order to qualify for OSHWA certification, you must have chosen an open source license for your hardware, your software (if any), and your documentation"

All this means is that the developer's software must qualify, if there is proprietary software from elsewhere for RAMinit or whatever, that's accepted.

>Why I, as a user, should need to get new hardware if I want to start using free software with it?
Effective hardware reverse engineering unfortunately requires external hardware like scopes.

Most EEPROMs can be reprogrammed just fine without requiring external hardware if you really want.

Software on EEPROMs also tends not to be obfuscated, signed or encrypted unlike hotloaded software.

>The cost can be zero
Freedom is never gratis.

>So you'd rather have all of that stuff in EEPROMs? Making the product worse and burying any chances for simple updates to any free software rewrites of them.
If all that stuff was in EEPROMs, the hardware wouldn't be as buggy - the Wi-Fi chip wouldn't be hot garbage for example.

Running an update script that does a sanity check and flashes an EEPROM is quite simple.

Hotloaded proprietary software appears to be the thing that buries the chances, as I don't really recall many cases of replacement of such.

>Malicious? How?
All mobile chipsets are malicious as disobeying the user and disallowing the change of the IMEI and reporting the users location is the requirement of the mobile signalling specifications.

>even though it's stored on NAND Flash (not EEPROM)
NAND flash is a type of EEPROM.

>on the modem module, you can update it from the main CPU, hence failing the "within which software installation is not intended after the user obtains the product" clause.
That's an exception clause, rather a restriction clause.

Offering a free software update to be installed onto that chipset would in no way fail RYF.

As occurs in practice, as it used EEPROM NAND flash, there was actually a partial free software replacement of the modem userspace written - but the much more complicated kernelspace that actually handles the protocols is still proprietary.

>It may, but the last fully certified computer is ~15 years old
False.
https://ryf.fsf.org/index.php/products/Talos-II-Mainboard
https://ryf.fsf.org/index.php/products/Talos-II-lite-Mainboard
https://ryf.fsf.org/index.php/products/KCMA-D8-Workstation
https://ryf.fsf.org/products/TET-D16

That hardware is newer than 15 years old, is very good and is quite fast.
git.kernel.orgmain.c « init - kernel/git/torvalds/linux.git - Linux kernel source tree

@wolf480pl@mstdn.io @mjg59@nondeterministic.computer vendor is not powerless to change it - they now have the power to charge for replacement ROMs. I'm fairly certain that BIOS update ROMs actually existed at some point.

@ignaloidas @mjg59
yeah but these days it'd be a mask ROM inside another chip that is BGA-soldered to the mainboard, so they'd just tell you to buy the next gen laptop instead

@wolf480pl@mstdn.io @mjg59@nondeterministic.computer And thats shit from right to repair perspective (and with EU laws on software/hardware warranties that seeem to be incoming, really not wise from the vendor). I don't see a reason to support something that would lead to unfixable trash being made on the regular.

@wolf480pl The vendor no longer has the power to change it, but they still have the power to control how the hardware behaves in the first place and this may not be to the user's benefit. Proprietary software that the vendor never updates is just as harmful as proprietary software that the vendor ships optional updates for.