> But recently we found a more problematic issue that also affects many
> more distributions and all the previous GNU Boot release candidates.
> The vboot source code used in Coreboot and in the vboot-utils package
> available in many GNU/Linux distributions contains nonfree code in
> their test data in tests/futility/data (nonfree microcode, nonfree
BIOS, nonfree Management Engine firmwares, etc).
After dealing with the xz backdoor I've become a lot more suspicious of binary blob test data which can't be explained or reproduced. Of course in some cases it's unavoidable.
Read the comments about Guix, it's all about avoiding blobs in every process.
Even engines from Scummvm had to be cut out because the supported games didn't had a way to recompile those from source (Broken Sword, Drascula)...
And I think it's fair. If Broken Sword or Drascula were implemented with libre bytecode, I would be totally ok on redistributing the game data as freeware. But it's not the case. You are not redistributing game data with the bass, queen1, and the rest of packages under Trisquel, Debian or Ubuntu, but executables for a virtual a machine plus the game data.
It's the same as running a freeware Minecraft libre and free Java VM (OpenJDK).
GNU is strict about this. Strict to a dogmatic level which causes patching out firmware updates from Guix, leaving people with buggy/insecure systems. But they're free.
I always found the point of view silly that it's somehow better to ship proprietary firmware with the hardware, rather than shipping the same proprietary firmware bundled with an otherwise free operating system and uploading it to the hardware when booting.
ROM in hardware can be phisically mitigated up to a discrete time. The potential damage would be something, but never more. With nonfree firmware, you are a slave from the vendor, because he could release a new backdoored firmware anytime making even more damage to the users' freedom.
OFC libre firmware is the best, such as the ath9k supported wireless devices.
> With nonfree firmware, you are a slave from the vendor, because he could release a new backdoored firmware anytime making even more damage to the users' freedom.
You don't have to take the updated firmware, though?
We are talking about binary blobs that are bundled with drivers usually and sent to the device at initialization time which means you'd have to individually fix the version of n drivers in the package manager of your distro to avoid thay. This is doable but some people think it is easier to not have your distro shipping them in the first place.
Yes. And the commenter is pointing out that if Guix has a bug, and the available fix is via non-free firmware, they will not pull in the fix. Users thus continue to be affected by the bug.
Yes, they're dogmatic in the literal meaning of that word.
Other systems may have bugs too, but they don't take extra time to make sure you can't patch those bugs without additional work and going against the system.
> Yes, they're dogmatic in the literal meaning of that word.
Debatable. Guix has adequate grounds to build their beliefs on and they accept other stances besides their own. Guix may think the others are wrong, but that's their privilege, just like you are privileged to think they are wrong. So they seem to be more principled than dogmatic.
A belief being dogmatic isn’t about adequacy of evidence or lack thereof. It’s about that belief being one that must be held to be in fully good standing with the organization for which it is a dogma. I think we can reasonably say the FSF’s teaching on software freedom is at least something very much like dogmatic.
I happen to believe they’re essentially right, but we live in an imperfect world and I still want my microcode bugs patched so I do that.
I would much rather have a “buggy” system made for the user that was written with free software than a highly functional blob of proprietary code sending all of my data to an advertiser. Dogmatism in software is important, particularly regarding user freedoms. The very moment you relax on user freedoms you get horrible devices like the iPhone which doesn’t respect the user at all and uses them as resources to be mined for capital.
The proprietary code is still there, you're just refusing to update it. Dogmatic FSF people think that hardware that has proprietary blobs stored in ROM is "free" but having to load it yourself makes it non-free.
Microcode in ROM is fixed. Nobody - neither you nor the vendor - can alter it. You are both equal.
Microcode as a binary blob loaded at runtime means the vendor has the source and tools and can create and alter and build and distribute the modifications and FUCK YOU you can't do any of those things legally. Just copy some opaque blob unmodified - that's non-free software in a nutshell.
Solution 1: vendor gives out the source and tools for creating the blob under a free license.
Solution 2: don't buy or use that hardware. Support vendors that support solution 1.
Solution 3: the vendor, having refused to offer their firmware under free software terms (which they totally could do and the whole idea of the free software movement is to get them to do it), agrees the compromise that they cannot alter the firmware either so puts it in ROM. They'd prefer not to, of course, but if they want another option, solution 1 is right there. Free the firmware and this problem goes away.
If you think other solutions are "pragmatic", just pragmatically use non-free Windows which is full of opaque binary blobs you don't have the source for and can't recreate, let alone alter or redistribute the changes. That counts as free software, right?
I may be wrong but in some case those binary blobs coming with the drivers are needed exactly because the device themselves don't come with them stored in rom and just have a simpler initialization logic that wait for the blob before running it.
In an ideal world there would be no binary blobs. We do not live in an ideal world. Instead the “dogmatic” FSF have compromised and said that if NO ONE can change the binary blob then everyone is equal. Which is true. However, if you can upgrade it so too can the manufacturer, and this is as a whole disrespectful to user freedom as you have no access to the source. Especially in this day and age when firmwares can be updated OTA and some even include backdoors like Intel ME.
They needed to draw a line somewhere, and it made sense to draw it there in the 1980's or whenever. The unfortunate part is that rather than just pragmatically saying baked in firmware wasn't their current concern, they created a rationalization about how it's more free to not be able to change your firmware. And once you put that kind of contradiction in your axioms, you're off to the races of poor conclusions.
I'm pretty adamant about software freedom, but my own model involves computational domains and resulting security properties. CPU microcode is a pretty shitty thing, but it's in a similar camp to proprietary CPU designs so that's just where we are in 2024. Proprietary firmware in non-networked peripherals does not bother me at all. Updating firmware only bothers me to the extent that proprietary update processes require more work (including sandboxing to thwart any telemetry). Meanwhile proprietary BIOS, regardless of whether it gets updated, is a huge red flag based on how much access it has to the whole system plus the network.
Having said that, this topic is where the FSF's definition actually has more relevancy. It is neat to be able to say everything in this tarball/cdimage/etc is 100% libre licensed, orthogonal to the implications for how it affects users' freedom. So doing the work here is seemingly worthwhile even if it's not fully necessary to serve the FSF's main goal.
I just wish they'd stop focusing on this outmoded definition for things like the firmware blobs in Trisquel/Guix, which actually ends up harming user freedom/actualization by making for a poor experience that makes libre software look like some kind of religion based on purity rather than programmer self empowerment.
> Dogmatic FSF people think that hardware that has proprietary blobs stored in ROM is "free"
Do they? Or do you think you might have exaggerated their position to make your point? I seem to remember they consider it as undesirable but inevitable, whereas passing around non-free code helps to normalize it.
I don't see where they claim that "proprietary blobs stored in ROM is "free", would you care to point it out please? Or were you referring to the opinion piece in the comment that you link? That does not appear to be the official position of the people doing the actual work.
Here's a part from the "Respects your Freedom" page. The second paragraph explicitly excludes factory loaded and unupgradeable software from consideration.
>All the product software must be free software. The product software includes all software that the seller includes in the product, provides with the product, recommends for use in conjunction with the product, and steers users towards installation in the product.
>However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software.
FPGA's are pratically dealt as if the were burned ROMs.
There's no easy way to soft-update an FPGA except for expensive tools to do so. Your bare OS can't do that. A vendor can't update an FPGA based hardware at will.
What's incorrect. FP in FPGA stands for field-programmable. That's the big thing about them - you can easily reprogram them after deployment with minimal effort. Also https://github.com/trabucayre/openFPGALoader
You mean with blown fuses? Sure, but that's specific implementation's choice, not an FPGA property. You could also make an SSD read-only with enough effort, but that doesn't describe SSDs in general.
That's only if you want to do it externally. The claim was:
> There's no easy way to soft-update an FPGA except for expensive tools to do so.
If the implementation wants to support updating the FPGA then the programming can be wired in the device itself and accessible fully in software. Or even the attached SoC can reprogram it with IAP. (https://ww1.microchip.com/downloads/aemDocuments/documents/F...)
Basically it's not a technology limitation. It's the choice of the people implementing it - they can make it anywhere from trivial to almost impossible to reprogram.
crucially, it's not a choice for the user, who can treat it as hardware. so free software developers can write code on top of it and pretend it's part of the hardware - not that it's "free" as the poster above was trying to say.
I'd like that too, but there is no commonly usable platform where it's possible right now. AMD and Intel will not open their firmware. Apple stuff will always be proprietary. Arm from Qualcomm the same. This has nothing to do with advertising.
Wanting a free firmware for all components is just not realistic in any way today or in the foreseeable future.
Sure, I'm just thinking there is a chance we might actually get some platforms that are fully open.
Unlike the the existing platforms where we know almost for sure the few companies running them will keep the code and implementation details to themselves and its unlikely this will change in the future.
No information which code was nonfree, no information how it was spotted. Rereleasing tarballs with the same verison number, which means there are now two official versions of the same tarball with the same version but with another md5 hash.
In my opinion not the best information politics.
p.s.: Do they have a so small overview about the own code that they need 3 versions to detect that there is non free code in the release?
> But recently we found a more problematic issue that also affects many > more distributions and all the previous GNU Boot release candidates. > The vboot source code used in Coreboot and in the vboot-utils package > available in many GNU/Linux distributions contains nonfree code in > their test data in tests/futility/data (nonfree microcode, nonfree BIOS, nonfree Management Engine firmwares, etc).
Test data doesn't seem like a huge deal
After dealing with the xz backdoor I've become a lot more suspicious of binary blob test data which can't be explained or reproduced. Of course in some cases it's unavoidable.
The issue is not that one of a binary blob, it's one of licensing.
Read the comments about Guix, it's all about avoiding blobs in every process.
Even engines from Scummvm had to be cut out because the supported games didn't had a way to recompile those from source (Broken Sword, Drascula)...
And I think it's fair. If Broken Sword or Drascula were implemented with libre bytecode, I would be totally ok on redistributing the game data as freeware. But it's not the case. You are not redistributing game data with the bass, queen1, and the rest of packages under Trisquel, Debian or Ubuntu, but executables for a virtual a machine plus the game data.
It's the same as running a freeware Minecraft libre and free Java VM (OpenJDK).
ScummVM runs FLOSS games too.
Yes, I said 'cut down', not ditched completely, as there are FLOSS graphical and Gluxle/Z-Machine games.
GNU is strict about this. Strict to a dogmatic level which causes patching out firmware updates from Guix, leaving people with buggy/insecure systems. But they're free.
I always found the point of view silly that it's somehow better to ship proprietary firmware with the hardware, rather than shipping the same proprietary firmware bundled with an otherwise free operating system and uploading it to the hardware when booting.
ROM in hardware can be phisically mitigated up to a discrete time. The potential damage would be something, but never more. With nonfree firmware, you are a slave from the vendor, because he could release a new backdoored firmware anytime making even more damage to the users' freedom.
OFC libre firmware is the best, such as the ath9k supported wireless devices.
> With nonfree firmware, you are a slave from the vendor, because he could release a new backdoored firmware anytime making even more damage to the users' freedom.
You don't have to take the updated firmware, though?
We are talking about binary blobs that are bundled with drivers usually and sent to the device at initialization time which means you'd have to individually fix the version of n drivers in the package manager of your distro to avoid thay. This is doable but some people think it is easier to not have your distro shipping them in the first place.
is it the same?
There's no reason a bug fix for a free software needs to be non-free.
It's about a bugfix and firmware for your hardware, not for free software.
GNU Boot is not free software?
Sorry for the misunderstanding, I referred to the mentioned guix there, not boot.
Ah, okay. Thanks for clarifying, I was getting confused. But guix is free software, too, no?!
Yes. And the commenter is pointing out that if Guix has a bug, and the available fix is via non-free firmware, they will not pull in the fix. Users thus continue to be affected by the bug.
There's no reason a bug fix for a free software needs to be non-free.
They make it sound like they’ve discovered a secret
They make it sound like they're dogmatic about their views, which of exactly what they claim.
I, for contrast, use free software almost exclusively, but I have no moral problems with using proprietary drivers.
Drivers are software too.
Hence "almost".
I think you’re reading further into this than is there.
all systems are buggy and insecure and there are causes for that, not sure about dogmatic though.
Yes, they're dogmatic in the literal meaning of that word.
Other systems may have bugs too, but they don't take extra time to make sure you can't patch those bugs without additional work and going against the system.
> Yes, they're dogmatic in the literal meaning of that word.
Debatable. Guix has adequate grounds to build their beliefs on and they accept other stances besides their own. Guix may think the others are wrong, but that's their privilege, just like you are privileged to think they are wrong. So they seem to be more principled than dogmatic.
A belief being dogmatic isn’t about adequacy of evidence or lack thereof. It’s about that belief being one that must be held to be in fully good standing with the organization for which it is a dogma. I think we can reasonably say the FSF’s teaching on software freedom is at least something very much like dogmatic.
I happen to believe they’re essentially right, but we live in an imperfect world and I still want my microcode bugs patched so I do that.
I’ve only seen something called dogmatic when it lacks obvious justification.
Don’t operate heavy machinery while drunk is a lesson people and organizations learn over and over. Would you say it’s dogmatic?
Hmh, that's not what the dictionary says.
I would much rather have a “buggy” system made for the user that was written with free software than a highly functional blob of proprietary code sending all of my data to an advertiser. Dogmatism in software is important, particularly regarding user freedoms. The very moment you relax on user freedoms you get horrible devices like the iPhone which doesn’t respect the user at all and uses them as resources to be mined for capital.
The proprietary code is still there, you're just refusing to update it. Dogmatic FSF people think that hardware that has proprietary blobs stored in ROM is "free" but having to load it yourself makes it non-free.
But it makes perfect sense.
Microcode in ROM is fixed. Nobody - neither you nor the vendor - can alter it. You are both equal.
Microcode as a binary blob loaded at runtime means the vendor has the source and tools and can create and alter and build and distribute the modifications and FUCK YOU you can't do any of those things legally. Just copy some opaque blob unmodified - that's non-free software in a nutshell.
Solution 1: vendor gives out the source and tools for creating the blob under a free license.
Solution 2: don't buy or use that hardware. Support vendors that support solution 1.
Solution 3: the vendor, having refused to offer their firmware under free software terms (which they totally could do and the whole idea of the free software movement is to get them to do it), agrees the compromise that they cannot alter the firmware either so puts it in ROM. They'd prefer not to, of course, but if they want another option, solution 1 is right there. Free the firmware and this problem goes away.
If you think other solutions are "pragmatic", just pragmatically use non-free Windows which is full of opaque binary blobs you don't have the source for and can't recreate, let alone alter or redistribute the changes. That counts as free software, right?
I may be wrong but in some case those binary blobs coming with the drivers are needed exactly because the device themselves don't come with them stored in rom and just have a simpler initialization logic that wait for the blob before running it.
In an ideal world there would be no binary blobs. We do not live in an ideal world. Instead the “dogmatic” FSF have compromised and said that if NO ONE can change the binary blob then everyone is equal. Which is true. However, if you can upgrade it so too can the manufacturer, and this is as a whole disrespectful to user freedom as you have no access to the source. Especially in this day and age when firmwares can be updated OTA and some even include backdoors like Intel ME.
They needed to draw a line somewhere, and it made sense to draw it there in the 1980's or whenever. The unfortunate part is that rather than just pragmatically saying baked in firmware wasn't their current concern, they created a rationalization about how it's more free to not be able to change your firmware. And once you put that kind of contradiction in your axioms, you're off to the races of poor conclusions.
I'm pretty adamant about software freedom, but my own model involves computational domains and resulting security properties. CPU microcode is a pretty shitty thing, but it's in a similar camp to proprietary CPU designs so that's just where we are in 2024. Proprietary firmware in non-networked peripherals does not bother me at all. Updating firmware only bothers me to the extent that proprietary update processes require more work (including sandboxing to thwart any telemetry). Meanwhile proprietary BIOS, regardless of whether it gets updated, is a huge red flag based on how much access it has to the whole system plus the network.
Having said that, this topic is where the FSF's definition actually has more relevancy. It is neat to be able to say everything in this tarball/cdimage/etc is 100% libre licensed, orthogonal to the implications for how it affects users' freedom. So doing the work here is seemingly worthwhile even if it's not fully necessary to serve the FSF's main goal.
I just wish they'd stop focusing on this outmoded definition for things like the firmware blobs in Trisquel/Guix, which actually ends up harming user freedom/actualization by making for a poor experience that makes libre software look like some kind of religion based on purity rather than programmer self empowerment.
> Dogmatic FSF people think that hardware that has proprietary blobs stored in ROM is "free"
Do they? Or do you think you might have exaggerated their position to make your point? I seem to remember they consider it as undesirable but inevitable, whereas passing around non-free code helps to normalize it.
Yes they do. https://news.ycombinator.com/item?id=29286715
I've read the link from the comment that you refer to: https://lists.gnu.org/archive/html/info-gnu/2018-04/msg00002...
I don't see where they claim that "proprietary blobs stored in ROM is "free", would you care to point it out please? Or were you referring to the opinion piece in the comment that you link? That does not appear to be the official position of the people doing the actual work.
Here's a part from the "Respects your Freedom" page. The second paragraph explicitly excludes factory loaded and unupgradeable software from consideration.
>All the product software must be free software. The product software includes all software that the seller includes in the product, provides with the product, recommends for use in conjunction with the product, and steers users towards installation in the product.
>However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software.
Source: https://ryf.fsf.org/about/criteria
FPGA's are pratically dealt as if the were burned ROMs.
There's no easy way to soft-update an FPGA except for expensive tools to do so. Your bare OS can't do that. A vendor can't update an FPGA based hardware at will.
What's incorrect. FP in FPGA stands for field-programmable. That's the big thing about them - you can easily reprogram them after deployment with minimal effort. Also https://github.com/trabucayre/openFPGALoader
Depends. There are FPGA that can only be programmed once, others a limited amount, and others that have no limit.
You mean with blown fuses? Sure, but that's specific implementation's choice, not an FPGA property. You could also make an SSD read-only with enough effort, but that doesn't describe SSDs in general.
I am noting a limitation. Previous claims might've led some thinking this was not the case for all.
where "minimal effort" might mean soldering wires to a surface mounted chip. for you maybe - my own hands aren't that stable.
That's only if you want to do it externally. The claim was:
> There's no easy way to soft-update an FPGA except for expensive tools to do so.
If the implementation wants to support updating the FPGA then the programming can be wired in the device itself and accessible fully in software. Or even the attached SoC can reprogram it with IAP. (https://ww1.microchip.com/downloads/aemDocuments/documents/F...)
Basically it's not a technology limitation. It's the choice of the people implementing it - they can make it anywhere from trivial to almost impossible to reprogram.
crucially, it's not a choice for the user, who can treat it as hardware. so free software developers can write code on top of it and pretend it's part of the hardware - not that it's "free" as the poster above was trying to say.
does
> The software in such secondary processors does not count as product software.
mean free (in the GNU sense) to you? I don't think the quote you reproduced means what you think it means.
I'd like that too, but there is no commonly usable platform where it's possible right now. AMD and Intel will not open their firmware. Apple stuff will always be proprietary. Arm from Qualcomm the same. This has nothing to do with advertising.
Wanting a free firmware for all components is just not realistic in any way today or in the foreseeable future.
And reality proves over and over again that open source firmware and hardware are very much needed.
RISC-V ?
There's no requirement for keeping the code as implemented open source or not using proprietary extensions.
Sure, I'm just thinking there is a chance we might actually get some platforms that are fully open.
Unlike the the existing platforms where we know almost for sure the few companies running them will keep the code and implementation details to themselves and its unlikely this will change in the future.
> no commonly usable platform
No information which code was nonfree, no information how it was spotted. Rereleasing tarballs with the same verison number, which means there are now two official versions of the same tarball with the same version but with another md5 hash. In my opinion not the best information politics.
p.s.: Do they have a so small overview about the own code that they need 3 versions to detect that there is non free code in the release?
If only proprietary software was as concerned about shipping free software in their products.
This should be solved by law by rendering proprietary software illegal to distribute and to use.