Although it was obvious the FSF would take this position, as it should, isn't it strategically wise to have multiple solutions for users to load a (mostly) free software OS on hardware with UEFI? For similar reasons, I think it's good to have Android devices running ClockworkMod so that they may boot CyanogenMod/Replicant. I understand that we (free software advocates) should always be encouraging consumers to make smart choices and purchase devices that will run free software (and a complete free software stack, when that's possible).
However, free software would become an "oasis in a desert", rather than a large and thriving ecosystem, if binary blobs, non-free drivers, non-free BIOS's, firmware hacks, etc. weren't around. It would become increasingly difficult to bring in more users. Those who have developed free software implementations to replace proprietary ones originate from all over the free software spectrum, so the pool of developers would also shrink.
I think you always want both: the hardcores who will run free software and free software only, and those who will make compromises on devices until (if/when) stable free software is developed for those devices. The FSFE's advice on installing CyanogenMod seems like a sensible approach that takes this into consideration. Likewise, why not help someone install as much free software as possible on a device with a non-free BIOS/bootloader?
It seems to me that UEFI will die a quick death if we A) fight very vocally against it, B) convince powerful corporations and governments that it's bad for them, C) ignore it where/when we can, and D) help others to circumvent it when necessary. It doesn't seem much different than the DRM problem in that way.
I would be very happy with Canonical's UEFI strategy if the following from this past /. comment can be done:
- Canonical will get efilinux signed with microsoft keys. So GRUB2 has to be made bootable from efillinux (efilinux is rather primitive, it just loads a kernel from a set collection of blocks from the device and run it. It shouldn't be too much difficult to have efilinux load and execute a GRUB2's "stage 1.5" or "stage 2").
Thus efilinux is the part that needs to be signed with microsoft's key (and efilinux's license makes it possible. Although that also means that you won't be able to hack it).
...
- GRUB2 can load coreboot (an opensource firmware) payloads, so it could also load SeaBIOS (a legacy BIOS implementation as a coreboot payload).
- GRUB2 can also load windows XP's boot loader.
So if any of the above is possible (either chainloading efilinux to grub2, or signing grub2 in a gplv3 compatible way). That means that grub2 could be used to boot windows XP on secure-boot hardware. (with seabios providing the legacy bios compatibility, and windows XP's ntldfr being loaded from grub2).
That unfortunately-complex method of chaining together multiple bootloaders seems to allow for any OS, even legacy ones, to boot (or at least attempt to boot) on UEFI hardware. Such a door might be closed if Canonical decides it won't play ball with Microsoft, and that seems like a door worth having open. However, I welcome any rebuttals...I don't know nearly enough about the issue.