Did OEM influence Canonical Secure Boot plan?
Reasons why GRUB 2 got dropped without consulting FSF
As the Linux community continues to debate the best way to deal with Microsoft Windows 8-certified machines that will have Secure Boot on UEFI, some nagging questions still remain as to why Canonical opted to take the solution it did.
Both the Fedora Project and Canonical has publicly announced their proposed solutions to how users will be able to boot Secure Boot-enabled machines to Linux. Secure Boot requires that "all firmware and software in the boot process must be signed by a trusted Certificate Authority." Microsoft is requiring that hardware makers of all Windows 8-certified machines be configured to meet these strict requirements.
On a Secure Boot machine, any user who wanted to dual-boot on a Windows 8-certified machine would be unable to accomplish the task, unless they had a signed key the UEFI secure boot system recognized.
Fedora's proposed solution to this problem is to purchase a Microsoft-signed encryption key from VeriSign for a one-time $99 fee and use a two-stage bootloading process to (1) use the key to boot straight to a modified GRUB 2 bootloader that will (2) then boot to Fedora.
Canonical's solution was a bit more radical: drop the GRUB 2 bootloader in Ubuntu as a default tool on systems with Secure Boot enabled and generating an Ubuntu-specific signing key to use with UEFI.
The rationale for abandoning GRuB 2, Canonical's Steve Langasek stated, was a perceived problem with the GPLv3 under which GRUB 2 is licensed:
"The reason we've arrived at a different plan is that Ubuntu has a rather extensive base of preinstalled systems. Microsoft's Windows 8 logo requirements do say that there must be a way for users to disable secure boot or to install their own keys, and we strongly support this in our own firmware guidelines; but in the event that a manufacturer makes a mistake and delivers a locked-down system with a GRUB 2 image signed by the Ubuntu key, we have not been able to find legal guidance that we wouldn't then be required by the terms of the GPLv3 to disclose our private key in order that users can install a modified boot loader. At that point our certificates would of course be revoked and everyone would end up worse off."
But here's the thing: late last week, the Free Software Foundation released their own position paper on Canonical's and Fedora's respective solutions. Predictably, the FSF didn't like either plan, and they specifically mentioned something that's rather odd:
"No representative from Canonical contacted the FSF about these issues prior to announcing the policy."
Now, at first, I sort of knee-jerk reacted to this statement as just one more example of some of the hubris that occasionally comes out of the FSF when they get on one of their righteous tears. They're just ticked off that Canonical's moving away from GRUB 2 to the BSD-licensed efilinux bootloader, I thought.
But the more I ruminated this statement, the more it bugged me. Why didn't Canonical seek FSF's counsel about the GPLv3? After all, not only is the FSF the legal expert on all things GPLv3, but the organization owns the copyright for GRUB 2 and therefore decides which license applies to GRUB 2.
On those two qualifications alone, I would think Canonical would have turned to the FSF for guidance on this question. So why didn't they? Some possible answers:
Canonical did reach out to the FSF, and the FSF is mistaken about or deliberately covering up this contact. This is a bit possible, but that's a pretty easy thing to contradict. Canonical has had several days to produce an e-mail or chatlog of attempted contact to disprove this statement.
Canonical didn't feel it necessary to reach out to the FSF. This would be very odd, given the two big reasons why the FSF knows quite a bit about GRUB 2 and the FSF. But it could be that Canonical's lawyers thought they had the right answer and they went with it. It is also possible that the Ubuntu developers involved in this decision didn't think to contact the company lawyers or the FSF. This would put the whole thing in the one-big-miscommunication department.
Canonical has other reasons for wanting to drop GRUB 2. Given the amount of technical work Canonical states they have put into GRUB 2 development, this reason may not seem likely, but it's the one to which I keep returning. I think it very likely that Canonical had other reasons for wanting to remove GRUB 2 as a bootloader.
And what might those reasons be? If you were to ask me to speculate, I have to wonder if it's Canonical's partnership with Dell.
Canonical is very proud and protective of its OEM and ODM partnerships, and (at least in terms of notoriety, if not sales) the partnership with Dell has to be the partnership it wants to protect most.
So what if Dell, faced with pleasing both its partners (Microsoft and Canonical), told Canonical that in order to keep the partnership going, they would have to drop GRUB 2? Perhaps it was Dell's lawyers that were really mixed up about how the GPLv3 worked, and were worried that if Canonical were somehow forced under the terms of the GPLv3 to release its private key to assist a customer who was accidentally shipped a locked computer, there would suddenly be a potential vector where a bunch of "cracked" Ubuntu instances could be used to invade Windows 8 machines.
That answer makes sense if Dell is indeed less-than-clueful about the nature of the GPLv3. According to the FSF, there should never be a situation where Canonical would have to release its private key: it's the responsibility of the hardware manufacturer to fix a customer's problem if something like this were to happen.
So, let's take this one step further and postulate Dell's response if they did know that the onus to fix a user's system would be on them. In the hypothetical stuck-user situation, Dell would presumably have to give the customer a way to turn Secure Boot off.
Dell has not definitively stated that they will give customers the option to turn Secure Boot off, though they have said that they have "plans to make SecureBoot an enable/disable option in BIOS setup," which is a positive sign.
Did Dell, then, inform Canonical that the GPLv3d GRUB 2 had to go because of the enable/disable feature? I doubt it. If this hypothetical situation happened with efilinux, Dell would still have to let users turn Secure Boot off. It's a moot argument.
No, what I think is that someone at Dell looked at the GPLv3 license on GRUB 2 and decided that it would not be compatible with Microsoft's Windows-8 logo program. Because above all else, Microsoft does not want any chance there will be private keys out in the wild for any reason.
Faced with losing its most visible OEM partner, Canonical probably had a choice: consult with the FSF and use the correct legal explanation to try to set Dell straight or simply take the safe (for Canonical) approach and just drop GRUB 2 for the permissively licensed efilinux.
Dell hasn't had a reason to be wary of the GPLv3 before, but Microsoft never tried the audacious UEFI/Secure Boot program before, either. It's this new wrinkle that has Dell worried and what may have forced Canonical to make the bootloader switch. In a way, Canonical may have dodged a bullet: Dell could have easily have dropped preloaded Ubuntu machines altogether, thought surely antitrust fire and brimstone would have rained down on Dell and Microsoft at that point. (It still might.)
That the Fedora Project is keeping GRUB 2 is also negatively reinforces this theory of mine: Fedora doesn't have marquee OEM partnerships, so there's no one to raise a stink.
Again, this is a lot of conjecture on my part, but when I look at a lot of smart people at Canonical doing what seem to be such dumb things, I can't help but wonder if there's another motive. Protecting a big-name OEM partnership certainly seems like a good motive to me.
Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.