Conversation

Notices

1. Embed this notice
   Matthew Garrett (mjg59@nondeterministic.computer)'s status on Friday, 13-Dec-2024 02:32:38 JST Matthew Garrett

   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: https://mjg59.dreamwidth.org/70895.html

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Friday, 13-Dec-2024 02:32:34 JST Wolf480pl

     in reply to

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

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Friday, 13-Dec-2024 02:32:35 JST Wolf480pl

     in reply to

     @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

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Friday, 13-Dec-2024 02:32:35 JST Wolf480pl

     in reply to

     @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/

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Friday, 13-Dec-2024 02:32:37 JST Wolf480pl

     in reply to

     @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'

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Friday, 13-Dec-2024 02:32:37 JST Wolf480pl

     in reply to

     @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/

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Dec-2024 18:43:00 JST 翠星石

     in reply to

     • Ignas Kiela
     • Wolf480pl
     @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.
   • Embed this notice
     Ignas Kiela (ignaloidas@not.acu.lt)'s status on Friday, 13-Dec-2024 18:43:02 JST Ignas Kiela

     in reply to

     • Wolf480pl

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

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Dec-2024 19:04:03 JST 翠星石

     in reply to
     @mjg59 >Freedom isn't necessary.
     Well there it is.
     
     
     Unlike a PCIe Wi-Fi card, remote network servers don't have DMA access to the main memory space (IOMMU is a pretty shoddy workaround).
     
     
     Microcode in ROM in an intel CPU is hardware circuits that don't have a proprietary software license attached to it that restricts you and you do have the right to do whatever you want to your own hardware - even to sell it.
     
     As far as I can tell, the microcode in ROM doesn't contain malicious circuits, as intel knows that a decapping enjoyer is going to take a look eventually and report on any found malicious circuits.
     
     
     Meanwhile, microcode updates are software, with nasty proprietary license terms that require acceptance and this line from the software license confirms that the updates are partially proprietary malware;
     >3. No reverse engineering, decompilation, or disassembly of this software is permitted.
     
     That's right "reverse engineering our updates and finding the malware is not allowed, even though we've made every effort at doing so extremely difficult with encryption and an undocumented instruction set and only around a dozen people knowing how microcode updates work".
     
     
     All software running on a computer should be free and I am working towards achieving that.
     
     Encouraging the user to accept a proprietary license for proprietary peripheral software only leads the user away from freedom, as such software almost never gets replaced (there are arguments that RAM loaded proprietary software is easier to replace than EEPROM installed proprietary software, but for some reasons EEPROM installed proprietary software gets replaced much more often? (maybe it's something to do with how the RAM loaded software often has license terms and digital handcuffs that try to prevent replacement, while EEPROM included software on peripheral devices usually has no such restrictions)).
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Dec-2024 19:47:27 JST 翠星石

     in reply to

     • Ignas Kiela
     • Wolf480pl
     @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.
   • Embed this notice
     Ignas Kiela (ignaloidas@not.acu.lt)'s status on Friday, 13-Dec-2024 19:47:28 JST Ignas Kiela

     in reply to

     • 翠星石
     • Wolf480pl

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

   • Embed this notice
     Ignas Kiela (ignaloidas@not.acu.lt)'s status on Friday, 13-Dec-2024 20:55:00 JST Ignas Kiela

     in reply to

     • 翠星石
     • Wolf480pl

     @Suiseiseki@freesoftwareextremist.com @wolf480pl@mstdn.io Stop your word vomitFirmware is microprocessor instructions stored on socketed ROM chips - you can't electronically reprogram it, but you can just swap the chip - hence the firmnessThis hasn't been the common accepted meaning for agesIf 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

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Dec-2024 22:19:37 JST 翠星石

     in reply to

     • Ignas Kiela
     • Wolf480pl
     @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.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Friday, 13-Dec-2024 22:20:43 JST Rich Felker

     in reply to

     @mjg59 I don't have the link handy but I've written about this before, and IMO whether the software being nonfree matters depends on its role, privilege, and what information it processes..

     Nonfree firmware in a position to thoroughly backdoor everything is unacceptable. Nonfree firmware that transports encrypted network traffic is nbd.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Dec-2024 22:24:13 JST 翠星石

     in reply to
     @mjg59 >it's software
     The circuits are circuits that are hardware, even though they happen to encode microprocessor instructions.
     
     >(including performing cryptographic validation of other blobs)
     If you don't include any proprietary software on core 2 duo's, such cryptographic validation is not done.
     
     >would you argue that a copy of Linux in ROM creates no GPL obligations?
     There would be no obligation under the GPLv2 to provide installation information, but the source code would need to be provided.
   • Embed this notice
     Matthew Garrett (mjg59@nondeterministic.computer)'s status on Friday, 13-Dec-2024 22:24:15 JST Matthew Garrett

     in reply to

     • 翠星石

     @Suiseiseki Microcode in an Intel CPU is not hardware circuits - it's software. Pretending otherwise is dishonest. When you power on an Intel CPU it runs code out of ROM that performs a series of operations (including performing cryptographic validation of other blobs) before jumping to the reset vector. And, well, good luck making the argument that there's no license associated with that - would you argue that a copy of Linux in ROM creates no GPL obligations?

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Dec-2024 23:03:29 JST 翠星石

     in reply to
     @mjg59 You do not need a license to operate hardware.
     
     The user does deserve the source code to the hardware microcode, alas Intel does not provide it.
   • Embed this notice
     Matthew Garrett (mjg59@nondeterministic.computer)'s status on Friday, 13-Dec-2024 23:03:30 JST Matthew Garrett

     in reply to

     • 翠星石

     @Suiseiseki The only way that source code distribution could be required is if software licenses can apply, so why do you think that would apply to Linux in mask ROM but not Intel microcode?

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Dec-2024 23:19:07 JST 翠星石

     in reply to
     @mjg59 I don't really care about what bizarre conclusion a court arrived at decades ago, as the conclusion is not applicable to operating hardware.
   • Embed this notice
     Matthew Garrett (mjg59@nondeterministic.computer)'s status on Friday, 13-Dec-2024 23:19:09 JST Matthew Garrett

     in reply to

     • 翠星石

     @Suiseiseki But microcode is copyrightable software, as established in decades-old case law.

   • Embed this notice
     Matthew Garrett (mjg59@nondeterministic.computer)'s status on Sunday, 15-Dec-2024 03:38:28 JST Matthew Garrett

     in reply to

     • Wolf480pl

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

     valhalla likes this.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 16-Dec-2024 19:55:58 JST 翠星石

     in reply to

     • LisPi
     @lispi314 That would be a bonus, but commented source code would often be enough.
   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Monday, 16-Dec-2024 19:55:59 JST LisPi

     in reply to

     • 翠星石
     @Suiseiseki @mjg59 > The user does deserve the source code to the hardware microcode
     
     And accompanying documentation to make it understandable.