Why don’t unprivileged user accounts violate the GPLv3?

Question

The GPLv3 says:

Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.

[…]

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source.

[…]

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information.

The Free Software Foundation added these clauses because they did not like that companies like TiVo were able to use GPL'ed software on their devices.

The Open Source Definition has the following requirement:

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

The SSPL is not considered an open source license because it is deliberately almost impossible to comply with for hosting providers. Why, then, is the GPLv3 considered an open source license even though it is deliberately almost impossible to comply with for TiVo, Nintendo, Sony, etc.?

On top of that, it doesn't seem like most Linux distro's comply with it either. You can buy a laptop, install Linux on it, create a user account without access to sudo or equivalent, lock the UEFI/BIOS with a password, and give the laptop away to someone else while only telling them the password for the unprivileged account. It seems to me that the GPLv3 is being violated here, because the user cannot install other software on their laptop. Yet, almost every Linux distro supports unprivileged accounts (GNOME even has parental control settings)! Does this mean almost every Linux distro violates the GPLv3?

Answer 1

Firstly, the source you link to says that the principal problem with the SSPL is that it "is intentionally crafted to be aggressively discriminatory towards a specific class of users", not that it's almost impossible to comply with. It may well be that, too, but that's not the reason that Fedora says they have taken against it.

Secondly, the GPL is not almost impossible for a hardware vendor to comply with. It's easy to comply with it: the vendor needs to stop locking their devices down so their users can't modify the software running on them. If the vendor doesn't want to do that, fine, but they can't ship GPLv3 software on them.

You can buy a laptop, install Linux on it, create a user account without access to sudo or equivalent, lock the UEFI/BIOS with a password, and give the laptop away to someone else while only telling them the password for the unprivileged account. It seems to me that the GPLv3 is being violated here

I haven't thought too deeply about it, but you may be right (though note that although some of the software included in most Linux distros is GPLv3, the Linux kernel itself is not). If you are right, it means the person who did all those things to the laptop before conveying it was indeed violating GPLv3.

Yet, almost every Linux distro supports unprivileged accounts (GNOME even has parental control settings)! Does this mean almost every Linux distro violates the GPLv3?

No, because a distro is not a device. It's just software. Sitting at rest, on its DVD, with source packages, it denies no rights to its users. Only if someone installs it on a user-hostile device which they distribute is the GPLv3 then violated, and the person violating it is the device distributor, not the distro author.

Edit: you ask in a comment below "Why is the button there to begin with?". The answer is: because that button has legitimate uses, too. As a parallel example, TPMs can be misused to lock down my hardware so it can't boot the OS I want; but they can also be used to increase the security of my crypto keys (full disclosure: I wrote that article). A good licence (like a good law; take note, Parliament and others) doesn't proscribe a technology merely because it can be used badly, but instead proscribes the bad uses of that technology.

Answer 2

even though it is deliberately almost impossible to comply with for TiVo, Nintendo, Sony

Why do you think it's impossible? They just have to give users more access to the device they bought. That is quite possible - in fact, the developers have such access by default and go out of their way to prevent users from having the same access.

The fact that Nintendo doesn't want its users to have access to their own purchased devices is nothing to do with whether the GPL is valid. It just means they can't use GPL software.

The SSPL is not considered an open source license because it is deliberately almost impossible to comply with for hosting providers. Why, then, is the GPLv3 considered an open source license

In my opinion, the discrimination argument is a bad one. The intent behind the SSPL appears to be to create an even stronger version of the AGPL, which is reasonable on the face of it. However, there are other arguments against the SSPL, namely that its main effect is to create uncertainty around legal requirements. It's not obvious whether using SSPL software requires a company to open-source every piece of software used by the company. That seems like a pretty good reason not to consider it a "proper" licence.

Answer 3

Setting aside the question of when exactly a transfer of ownership of a laptop occurs and setting aside the fact that the Linux kernel is licensed under the GPLv2, not GPLv3:

Performing a transfer of ownership of a laptop whose GPLv3-licensed OS can only boot a unprivileged account will not violate the GPLv3's Tivoization requirements, unless you also separately lock down the hardware to prevent the installation of new operating systems (i.e., perform the act of making the hardware "Tivoized"). The GPLv3 requires only that the device's owner be able to install and execute a modified version of the GPLv3 software on the hardware:

"Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source

This seems primarily like a matter of what the laptop's BIOS allows, not how the OS is configured. The OS does not get a say in what OS replaces it or is a coresident OS. In general, I'd expect selling a laptop with a locked BIOS is sufficient to violate this condition even with admin access to the OS.

Admittedly most desktop Linux distros allow the OS to install modified versions of itself, so if you don't grant a recipient the ability to use that OS-upgrade functionality and you lock the hardware (e.g. BIOS) such that you can't install any new OS, then indeed that union of lockdowns together are sufficient to violate the GPLv3's Tivoization requirements. If the laptop contains a well-docunented approach to resetting a BIOS password via hardware switch, you may still yet avoid avoid a violation if a court views this information as a well-understood normal use of that laptop hardware. If the laptop doesn't include a well-documented reset mechanism, then you have indeed created a Tivoized device that doesn't let its owner install a new OS, so I'm unsurprised the Tivoization requirements would be violated in this case.

Another pressing concern is that transferring ownership of any GPL software on a laptop requires providing or offering the source code for each GPL-licensed binary whose ownership is transferred. However, this consideration doesn't pertain much to unprivileged accounts or to the GPLv3 in particular; that issue may arise equivalently for GPLv2 or v3 systems sold to a new owner with full admin access.

---

As for Fedora 's rejection of the SSPL on the grounds of discrimination, I can see the logic (it names a specific industry whereas other licenses do not), but I agree I don't find it particularly persuasive. I agree their reasoning seems much more steeped in the cultural difficulties that would arise from admitting the SSPL under the definitional umbrella of FOSS licenses. However, just as the Debian Free Software Guidelines build specific interpretation on top of the Free Software Definition (e.g., the desert island test, the dissident test), so too is Fedora free to provide their own interpretation of the OSD.

I'll also agree with another answer here and say that I object to the SSPL on the basis that its requirements are so far-reaching that they might be legally unenforceable.

Honestly, I find the OSD's point #9 more relevant to rejection of the SSPL as open source:

9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

The SSPL imposes requirements on "management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software," which seems likely to be out of compliance with point #9. For example, if SSPL-covered software runs a service that produces some data, and a separate piece of software asynchronously backs that data up to a remote drive, the SSPL places requirements on the unrelated backup software.