5 ms·

why is it a religious dogma? i dont see the point of hostility. they have every right to hold to those principles as long as they are not deciving anyone and st

why is it a religious dogma? i dont see the point of hostility. they have every right to hold to those principles as long as they are not deciving anyone and state their values clearly. who are they harming?

marcan_42 5y ago
They are deceiving people into believing they are not running proprietary software, while they are, and that software is just not evident because it doesn't live on their filesystem. Then they actively withhold information from users so they will neither find out nor be tempted to find out for some other reason. If they were being honest, they would tell people that this dongle has a good half a megabyte or so of proprietary Bluetooth stack built-in (with runtime patching/update ability; they all do), and they wouldn't deceptively have a "TET-BT4 source code" link that makes it sound like the firmware is open, while it's actually just a tarball of the Linux kernel (which contains a generic Bluetooth controller driver, nothing specific to this device). https://ryf.fsf.org/products/TET-BT4 https://ryf.fsf.org/products/TET-BT4
- medo-bear 5y ago
  i just looked through this website and found a link to their certification process at https://ryf.fsf.org/about/criteria https://ryf.fsf.org/about/criteria it states: > 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. >We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification. END QUOTE According to you, what is deceptive about this?
  - marcan_42 5y ago
    The existence of that exception, the way it is implemented, the way they work with vendors to help them fit into it, and the way they do not require informing users of such secondary processors are all deceptive. Just look at the Librem 5. That CPU needs a blob to even boot (to train the RAM). Normally that would just be embedded into the bootloader. But that would make it evident in the build process for their boot stack that there is a blob involved, and they can't certify that as "Respects your Freedom". So instead they worked with the manufacturer, and came up with this contrived interpretation of the "secondary processor" rule where, as long as the firmware in the "secondary processor" is at least two steps removed from the main CPU and never handled "directly" by it, it's okay. Then they had the manufacturer put the blob in a Flash ROM (Flash, so updatable, remember? just not that easily), and then they had them write a little loader code that runs on another secondary CPU. So the main CPU (running free software) boots a secondary CPU (running free software) that loads a blob from Flash and then boots a third CPU, which now runs proprietary software. According to the FSF, all this pointless obfuscation and extra levels of indirection makes the device magically compliant with their criteria. And so it got certified. It is completely evident that absolutely none of this helps end-users' freedom in any way, shape, or form vs. just having the blob in the normal bootloader where it can be more easily inspected and analyzed (and also lets users ensure that it hasn't been tampered with). It's just adding obfuscation so users won't find the blob, and therefore will feel better believing they aren't running any blobs. By this interpretation of the rule, I could ship an x86 PC with an Nvidia GPU that runs its proprietary driver on one of the CPU cores (isolated from the main OS), loaded by the UEFI firmware through ME or something, which communicates with the rest of the cores via VirtualGL or some other RPC, and that would make this PC eligible for RYF certification. Tell me that's not a farce.
    - medo-bear 5y ago
      not knowing about https://ryf.fsf.org/ https://ryf.fsf.org/ previously, i managed to find and understand their certification process within a matter of ten minutes. if i was a user of these products i don't think i would feel decieved
      - 5y ago
- r283492 5y ago
  Look, its all very simple, "firmware that is not normally changed is ethically equivalent to circuits" https://www.gnu.org/philosophy/applying-free-sw-criteria.html https://www.gnu.org/philosophy/applying-free-sw-criteria.htm... Ya, monitors and hard drives all have very complicated firmware too. It is very simple, it is not denying you a freedom which is unethical to deny. FSF is not saying: it's totally great and fine, I'm sure the FSF will be happy to promote any of those devices if they have free firmware in them, celebrating them as more free. It's the same reason they focus on software and not on hardware designs.

marcan_42 5y ago

They are deceiving people into believing they are not running proprietary software, while they are, and that software is just not evident because it doesn't live on their filesystem. Then they actively withhold information from users so they will neither find out nor be tempted to find out for some other reason. If they were being honest, they would tell people that this dongle has a good half a megabyte or so of proprietary Bluetooth stack built-in (with runtime patching/update ability; they all do), and they wouldn't deceptively have a "TET-BT4 source code" link that makes it sound like the firmware is open, while it's actually just a tarball of the Linux kernel (which contains a generic Bluetooth controller driver, nothing specific to this device). https://ryf.fsf.org/products/TET-BT4 https://ryf.fsf.org/products/TET-BT4

medo-bear 5y ago
i just looked through this website and found a link to their certification process at https://ryf.fsf.org/about/criteria https://ryf.fsf.org/about/criteria it states: > 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. >We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification. END QUOTE According to you, what is deceptive about this?
- marcan_42 5y ago
  The existence of that exception, the way it is implemented, the way they work with vendors to help them fit into it, and the way they do not require informing users of such secondary processors are all deceptive. Just look at the Librem 5. That CPU needs a blob to even boot (to train the RAM). Normally that would just be embedded into the bootloader. But that would make it evident in the build process for their boot stack that there is a blob involved, and they can't certify that as "Respects your Freedom". So instead they worked with the manufacturer, and came up with this contrived interpretation of the "secondary processor" rule where, as long as the firmware in the "secondary processor" is at least two steps removed from the main CPU and never handled "directly" by it, it's okay. Then they had the manufacturer put the blob in a Flash ROM (Flash, so updatable, remember? just not that easily), and then they had them write a little loader code that runs on another secondary CPU. So the main CPU (running free software) boots a secondary CPU (running free software) that loads a blob from Flash and then boots a third CPU, which now runs proprietary software. According to the FSF, all this pointless obfuscation and extra levels of indirection makes the device magically compliant with their criteria. And so it got certified. It is completely evident that absolutely none of this helps end-users' freedom in any way, shape, or form vs. just having the blob in the normal bootloader where it can be more easily inspected and analyzed (and also lets users ensure that it hasn't been tampered with). It's just adding obfuscation so users won't find the blob, and therefore will feel better believing they aren't running any blobs. By this interpretation of the rule, I could ship an x86 PC with an Nvidia GPU that runs its proprietary driver on one of the CPU cores (isolated from the main OS), loaded by the UEFI firmware through ME or something, which communicates with the rest of the cores via VirtualGL or some other RPC, and that would make this PC eligible for RYF certification. Tell me that's not a farce.
  - medo-bear 5y ago
    not knowing about https://ryf.fsf.org/ https://ryf.fsf.org/ previously, i managed to find and understand their certification process within a matter of ten minutes. if i was a user of these products i don't think i would feel decieved
    - 5y ago
r283492 5y ago
Look, its all very simple, "firmware that is not normally changed is ethically equivalent to circuits" https://www.gnu.org/philosophy/applying-free-sw-criteria.html https://www.gnu.org/philosophy/applying-free-sw-criteria.htm... Ya, monitors and hard drives all have very complicated firmware too. It is very simple, it is not denying you a freedom which is unethical to deny. FSF is not saying: it's totally great and fine, I'm sure the FSF will be happy to promote any of those devices if they have free firmware in them, celebrating them as more free. It's the same reason they focus on software and not on hardware designs.