24 ms·

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 "fre

by argsnd 2y ago

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.

exe34 2y ago
> 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.
- viraptor 2y ago
  Yes they do. https://news.ycombinator.com/item?id=29286715 https://news.ycombinator.com/item?id=29286715
  - exe34 2y ago
    I've read the link from the comment that you refer to: https://lists.gnu.org/archive/html/info-gnu/2018-04/msg00002.html 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.
    - RealStickman_ 2y ago
      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 https://ryf.fsf.org/about/criteria
      - anthk 2y ago
        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.
        viraptor 2y ago
        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 https://github.com/trabucayre/openFPGALoader
        spookie 2y ago
        Depends. There are FPGA that can only be programmed once, others a limited amount, and others that have no limit.
        viraptor 2y ago
        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.
        spookie 2y ago
        I am noting a limitation. Previous claims might've led some thinking this was not the case for all.
        exe34 2y ago
        where "minimal effort" might mean soldering wires to a surface mounted chip. for you maybe - my own hands aren't that stable.
        viraptor 2y ago
amiga386 2y ago
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?
tourmalinetaco 2y ago
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.
mindslight 2y ago
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.
prmoustache 2y ago
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.

by argsnd 2y ago

exe34 2y ago

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

viraptor 2y ago
Yes they do. https://news.ycombinator.com/item?id=29286715 https://news.ycombinator.com/item?id=29286715
- exe34 2y ago
  I've read the link from the comment that you refer to: https://lists.gnu.org/archive/html/info-gnu/2018-04/msg00002.html 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.
  - RealStickman_ 2y ago
    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 https://ryf.fsf.org/about/criteria
    - anthk 2y ago
      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.
      - viraptor 2y ago
        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 https://github.com/trabucayre/openFPGALoader
        spookie 2y ago
        Depends. There are FPGA that can only be programmed once, others a limited amount, and others that have no limit.
        viraptor 2y ago
        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.
        spookie 2y ago
        I am noting a limitation. Previous claims might've led some thinking this was not the case for all.
        exe34 2y ago
        where "minimal effort" might mean soldering wires to a surface mounted chip. for you maybe - my own hands aren't that stable.
        viraptor 2y ago

amiga386 2y ago

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?

tourmalinetaco 2y ago

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.

mindslight 2y ago

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.

prmoustache 2y ago

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.