10 ms·

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 liv

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
    - atdrummond 5y ago
      Is the poster you’re replying to saying anything about the ease of parsing their policy? He doesn’t seem to be calling it confusing. Rather, he seems to be attacking the supposed (il)logic of its contentions and the resulting consequences. At the moment this back and forth feels like you’re talking past his actual point(s).
      - medo-bear 5y ago
        no. he is calling it deceptive, which is even stronger than confusing. his statement was: > They are deceiving people into believing they are not running proprietary software edit: as regards FSF's logic i am not informed enough to comment so i didnt. but the conversation (this thread) was definitely about deceptiveness
        User23 5y ago
        The FSF’s principles have always permitted the use of non-free software when it advances the goal of software freedom. GNU was initially built using non-free software. Given the pejorative yet inaccurate references to “religion.” I can’t help but think some people are deeply disturbed by the very concept of moral principles and and cognitive dissonance is forcing them to hallucinate that the FSF doesn’t actually have principles but is instead a cult. Very odd.
        mindslight 5y ago
        No, the argument is about the pragmatic criteria used to implement agreed upon principles. Bringing this back to concrete discussion, here is a quote from the Libreboot KGPE page: > AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization) > AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates. "Avoid like the plague", yet there is little philosophical difference between compromising to trust AMD's 6200 masked microcode, and compromising to trust AMD's microcode update that fixed Spectre on 6300. The main possible distinction is if you want to argue that AMD became less trustworthy in the time between those two releases. Obviously if AMD releases new microcode for the 6300 going forward, it's a software freedom/security question of whether that microcode should be installed (automatically or even after review). But as it stands, slow changing microcode updates are in the same security/freedom realm as new CPU releases.
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.

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
  - atdrummond 5y ago
    Is the poster you’re replying to saying anything about the ease of parsing their policy? He doesn’t seem to be calling it confusing. Rather, he seems to be attacking the supposed (il)logic of its contentions and the resulting consequences. At the moment this back and forth feels like you’re talking past his actual point(s).
    - medo-bear 5y ago
      no. he is calling it deceptive, which is even stronger than confusing. his statement was: > They are deceiving people into believing they are not running proprietary software edit: as regards FSF's logic i am not informed enough to comment so i didnt. but the conversation (this thread) was definitely about deceptiveness
      - User23 5y ago
        The FSF’s principles have always permitted the use of non-free software when it advances the goal of software freedom. GNU was initially built using non-free software. Given the pejorative yet inaccurate references to “religion.” I can’t help but think some people are deeply disturbed by the very concept of moral principles and and cognitive dissonance is forcing them to hallucinate that the FSF doesn’t actually have principles but is instead a cult. Very odd.
        mindslight 5y ago
        No, the argument is about the pragmatic criteria used to implement agreed upon principles. Bringing this back to concrete discussion, here is a quote from the Libreboot KGPE page: > AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization) > AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates. "Avoid like the plague", yet there is little philosophical difference between compromising to trust AMD's 6200 masked microcode, and compromising to trust AMD's microcode update that fixed Spectre on 6300. The main possible distinction is if you want to argue that AMD became less trustworthy in the time between those two releases. Obviously if AMD releases new microcode for the 6300 going forward, it's a software freedom/security question of whether that microcode should be installed (automatically or even after review). But as it stands, slow changing microcode updates are in the same security/freedom realm as new CPU releases.

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.