> Their stated concern is that someone might ship an Ubuntu Certified machine with Restricted Boot (where the user cannot disable it). In order to comply with GPLv3, Ubuntu thinks it would then have to divulge its private key so that users could sign and install modified software on the restricted system.
> This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine.
That's because like pretty much everyone who is not the FSF, Ubuntu has not actually carefully read the part of GPLv3 that deals with software that requires signing in order to install. Almost everyone just seems to skim through that section, sees something about having to provide keys, and then moves on. They don't read the definitions that define the terminology used in that section, and so have no clue whatsoever about what they have just read means.
I can kind of excuse it when it is just random end users or individual software developers who don't understand the license they are using...but one of the leading Linux companies!?
Another place you see this problem is in discussion of the incompatibility between Apple's App Store and GPLv3. There are people who still think the signing requirements have something to do with it. They do not. The problem is Apple's terms and conditions, which Apple requires end users to agree to before being allowed to use the store, count as additional terms under GPL (both v2 and v3) that are incompatible with GPL. The GPLv3 restrictions on distributing signed code without the signing keys would only apply to GPLv3 code that Apple ships bundled with iOS devices.
> That's because like pretty much everyone who is not the FSF, Ubuntu has not actually carefully read the part of GPLv3 that deals with software that requires signing in order to install [...] I can kind of excuse it when it is just random end users or individual software developers who don't understand the license they are using...but one of the leading Linux companies!?
In response to:
"Have you talked to the FSF about their position on this? They're the
sole copyright holder of grub 2, so any position they'd publicly take
would be pretty relevant in terms of potential legal action."
The reply:
"I haven't been privy to all the mails on this, but in the ones I saw,
the responses were distinctly equivocal at best. They certainly didn't
say that we were safe, rather the reverse."
I think the problem is it doesn't matter how carefully you read the GPL v3, you still can't understand it. The license is complex and inconsistent in important ways and applied mechanically and literally leads to bizarre conclusions (such as that it is incompatible with the BSD-style licenses but not the MIT license).
I have discussed this matter both with folks like Richard Fontana (involved in SFLC, general counsel for Red Hat, and one of the drafters of the GPL v3) and Eben Moglen (SFLC, FSF, and one of the drafters of the GPL v3) and their understandings of key provisions was not only different but incompatibly so.
Here's the problem: the SFLC's official view, which is also the view of many developers who use the BSD-license, is that the BSD license does not allow a license change on the original code, but only allows restrictions to be placed on new code. Therefore if you write a program and release it under the BSD license, I can change the license to the GPL (any version) when, and only when, I actually make copyright-worthy changes to the code. Anything short of that and I am impermissively sublicensing your code, as prohibited in US copyright law. Now, slowly read the GPL v3, section 7, on additional terms.
Section 7 outlines a few areas where additional restrictions are permitted, and also addresses additional permissions. Since the work as a whole must be licensed according to the GPL v3, this would apply to any modules the work is dependent on, by the terms and definitions of the GPL v3, and additional permissions must be removable without changing the code. Earlier drafts allowed these permissions to be removed only when changing code but this was removed in a later draft. The BSD license does not allow this, and therefore it is incompatible. OTOH, the MIT license does allow it and so is compatible. Oops.
Except that everyone agrees the licenses are compatible. Moglen says that basically you can claim anything you want but nobody can sue you for it (sorry, I am not betting my house on that). Fontana says that the license was intended to be compatible and therefore must be read to be compatible, that one cannot safely convert BSD files to the GPL without modifying them, and that the GPL v3 should be read to accommodate this restriction. What a mess that opens up. Now we have to read the GPL as explicitly authorizing things it says it does not authorize.
So given my time trying to figure the GPL v3 out (and I have slowly read it more than a few times) I will give Ubuntu the benefit of the doubt here. The GPL v2 has problems too, but I would pick the problems of a license which is, perhaps, too simple over one which is undeniably too complex.
Now, my reading of the GPL v3 here is that Ubuntu would only possibly be off the hook but every distributor of Ubuntu-certified computers would have to release their keys. Moreover I am not convinced entirely that if a distributor failed to that Ubuntu could not be held accountable. If it's copyright infringement, Ubuntu is a vicarious infringer unless they did everything reasonably within their power to stop it. They have the power to require the vendor to distribute the keys, and they have a financial incentive. That makes them responsible. Worse if they told any distributor "you don't have to distribute your keys" that might make them guilty of Grokster-style contributory infringement.
I am not convinced Ubuntu would be safe at all. More likely depending on what was in the agreements, they might be held accountable along with the distributor.
> This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine.
That's because like pretty much everyone who is not the FSF, Ubuntu has not actually carefully read the part of GPLv3 that deals with software that requires signing in order to install. Almost everyone just seems to skim through that section, sees something about having to provide keys, and then moves on. They don't read the definitions that define the terminology used in that section, and so have no clue whatsoever about what they have just read means.
I can kind of excuse it when it is just random end users or individual software developers who don't understand the license they are using...but one of the leading Linux companies!?
Another place you see this problem is in discussion of the incompatibility between Apple's App Store and GPLv3. There are people who still think the signing requirements have something to do with it. They do not. The problem is Apple's terms and conditions, which Apple requires end users to agree to before being allowed to use the store, count as additional terms under GPL (both v2 and v3) that are incompatible with GPL. The GPLv3 restrictions on distributing signed code without the signing keys would only apply to GPLv3 code that Apple ships bundled with iOS devices.