Re: Changing how we handle non-free firmware
On August 23, 2022 5:38:52 PM GMT+02:00, Simon Josefsson <simon@josefsson.org> wrote:
> I have no problem
>with builtin non-upgradeable firmware -- see
>https://ryf.fsf.org/about/criteria for rationale.
Hi!
I've always had a really hard time understanding that rationale, despite not doubting the FSF's good intentions. Would you indulge in an exaggerated thought experiment to help me understand?
Machine A is a pretty normal laptop. It runs whatever you want, but in order for it to be usable, it needs non-free firmware. Say CPU microcode and some GPU firmware blob. Said firmware is upgradable (the user has to initiate the upgrade, but may not be able to load any code they want).
Machine B has two independent CPUs. CPU 1 is wonderfully free, and in itself requires no non-free firmware to run. However, CPU 2 is completely outside of the user's control. It runs 10 GB worth of proprietary OS. On top of that is a proprietary emulator for CPU 1. CPU 1 is hard-wired to pass any instruction it executes on to the proprietary OS running on CPU 2, which executes it in its proprietary emulator. But hey, all that stuff running on CPU 2 is completely non-upgradable, burned in at the factory only and physically unchangeable.
A debate about whether A or B is more free can perhaps be nuanced. But does the FSF rationale really imply that machine A is non-free while machine B is free?
Thanks for indulging me with this silly thought experiment.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply to: