On tivoization and communities

Alexandre Oliva

Tivoization violates the spirit of the GNU GPL in various ways. One of the major changes in the third version the GNU GPL is the addition of terms that make it clear that this practice is not permitted for software licensed under it, so as to encourage computer vendors to respect the users' freedoms that the GPL is designed to defend.

A computer is tivoized when its manufacturer includes copyleft Free Software in it, in such a way that it could be modified it, but does not pass this ability on to the user who purchases the computer. Tivoization is named after TiVo, the most widely known company that applies this technique on GNU libc, the kernel Linux, bash, gzip, and several other copyleft (GPLed) Free Software packages.

The spirit of the GPL, summarized in the preamble of the GPL and complemented by the Free Software definition alluded in it, can be further summarized as "ensuring that Free Software remains Free for all its users", i.e., that whoever modifies and/or distributes the software respects the freedoms of other users of the software, passing them on along with the software when it is distributed.

The principal author of the kernel Linux doesn't oppose Tivoization, and claims the anti-Tivoization terms are the sole reason for his dislike for the GPLv3 last-call draft. However, he praises the GPLv2 (even in the same message) for its spirit of encouraging retribution in kind.

This is contradictory, because the anti-Tivoization provisions can only improve the spirit of retribution in kind. This article will analyze this contradiction.


TiVo installs various Free Software packages in the computer it sells, configured to perform the functions of a Digital Video Recorder. Its boot loader verifies that the boot partition is digitally signed with a signature that only TiVo itself can generate. Since the kernel Linux is installed in this partition, users are prevented from booting other kernels in their computer, whereas TiVo retains this ability, which it could even exercise remotely.

The spirit of the GPL

The Free Software definition states that software is Free when the users have 4 freedoms: (0) the freedom to run the software for any purpose, (1) the freedom to study the software and adapt it to their needs, (2) the freedom to distribute the software, and (3) the freedom to modify the software and distribute the modifications.

The GNU GPLs are designed not only to respect these freedoms, but also to defend them, such that software licensed under these licenses remains Free. They do so by demanding respect for other users' freedoms in return for permission to modify and distribute the software, such that no additional restrictions on the exercise of the permissions granted by the license can be imposed. Intuitively, the notion is that whoever distributes the software passes on to the recipient every right he had with regard to the software.

Tivoization conflicts with the spirit of the GPL

TiVo does not really prevent anyone from modifying the software, or running modified versions of the software. It even publishes in its web site the source code of the GPLed programs it installs in the device it sells, such that anyone can get it. Users can indeed modify the source code, build it, install it on computers where the binaries will run, and run them.

However, these modified binaries won't run on the TiVo device. TiVo omits essential information from the source package, such that the user cannot create a functional boot partition: the signing keys and the installation scripts that create and install the signature. Taking the signature out of the boot disk will render the system non-functional, therefore the signature is a functional portion of the system, and therefore the signing key and the installation scripts ought to be included in the source package for compliance with the spirit, if not with the letter, of the license.

Furthermore, even though TiVo does not prevent modification of the software in a general sense, it does impose artificial restrictions on the user's ability to adapt the software to their own needs, in that the user cannot replace the kernel that it installs on the device, and it does so in order to prevent the user from making such modifications. This is clearly an additional restriction on the freedom to adapt the software, and a failure to pass on to the user the right to change the kernel that will boot on the machine, which it retains to itself. This fails to comply with the spirit of the GPL.

Technically, one can actually install a modified kernel on the machine, and configure the boot loader to load it. It just won't run, because the hardware was designed to impose an artificial restriction on the user's ability to run modified versions of the GPLed software included in it. This additional restriction also violates the spirit of the GPL, designed to defend the four freedoms and ensure the software remains free.

Tivoization conflicts with "giving back in kind"

Linus Torvalds claims he chose the GPLv2 for Linux because this license encourages giving back in kind, a spirit he describes as tit-for-tat. Even though the GPL does not require distribution of modifications, and it does not require distributed modifications to reach the original author (any such requirements would render it a non-Free Software license), in many cases useful modifications do get back, because there are various moral and economic incentives for this practice.

The reasoning goes that, the more users there are, the more contributors there are, and thus the more useful changes will be fed back into the software, which in turn brings in more users, in a virtuous cycle that enables the Free Software to flourish.

Tivoization cuts this cycle short. Even if the hardware manufacturer contributes its own changes back, some users may avoid the hardware because of its restrictions, and others who would spend time improving the software may end up not doing so when they realize they won't be able to use the result of their efforts in their tivoized computers. Tivoized hardware won't bring retributions in kind from as many potential developers as non-tivoized hardware would.

Whom is tivoization good for?

Unfortunately, some hardware manufacturers, in order to comply with law, with agreements they have entered, or with their business models, may decide they need to cut the virtuous cycle short, and they end up prohibiting every user from adapting the software to his/her own needs.

One way to accomplish this is to use a license that permits tivoization (there are conflicting opinions as to whether the legal terms of the GPLv2 permit it). Users get a product they can't modify, the community around the software (if there is one) gets contributions (if any) from the manufacturer alone, and the manufacturer gets software it can use to comply with regulations, agreements and to serve its business model. For purposes of comparison with other cases, let's call this the break-even point for user, community and manufacturer.

Another way to stop users from modifying the behavior of the software in the computer is to completely prevent modifications to it, such that nobody, not even the manufacturer itself, can make changes to the software. Users still get a product they can't modify, and they know the manufacturer can neither fix nor break it. The community gets just as many contributions from the manufacturer. The manufacturer still gets compliance with regulations and agreements that require prohibiting users from making changes. So this is essentially break-even for user, community and manufacturer, unless the business model depends on the ability to modify the software.

Now, compare this with being able to modify the software in the hardware. It is better for the user, who can adapt, improve and fix the product according to her own needs and preferences, without any dependency on the manufacturer. It is better for the community, because it can get the contributions from the manufacturer and the users. And it is better for the manufacturer, because it gets contributions from a larger community that devotes more attention to its own product. They all reap the benefits of the virtuous cycle that the spirit of the GPL enables, unless the business model is based on using the software against the user.

Of course, if modifications by the user are not an option by force of law or other regulations, the best everyone can get is the break-even point offered by one or two of the first options above. But if the wish to stop users from making changes is a business model choice, the manufacturer has to evaluate whether it would get a greater benefit from prohibiting the user from changing the behavior of the software than by helping the community flourish. The benefits from the flourishing of the community would be an economic incentive to respect users' freedoms, even if it doesn't end up being a decisive factor.

Whom is anti-tivoization good for?

If a project used by a manufacturer who chose tivoization were to switch to a license with anti-tivoization provisions, the manufacturer would have to decide among sticking with an old version of the software, or options similar to the 3 options above.

If it sticks with an old version of the software means, it won't be able to integrate improvements to the software made by the community, and the community probably won't get improvements back from the manufacturer. Users get stuck with an old version of the software. This is slightly worse than break-even for the community, something between break-even and slightly worse for the user, and much worse for the manufacturer.

If the manufacturer switches to another similar project without anti-tivoization provisions, it loses ground and expertise in the short term, and, depending on the chosen platform, it may face growing per-unit costs in the long term. The community of the original project loses the contributions the manufacturer might make. For the user, the change is likely irrelevant, so it's break-even.

Accepting a license change and prohibiting adaptation of the software in the hardware may be incompatible with the manufacturer's business model, but it's clearly break-even for the community, and the same likely break-even for the user.

Accepting a license change and permitting adaptation, if this option is compatible with law and other agreements, may require the manufacturer to evaluate whether the benefits of respecting users' freedoms outweigh any losses it might face in its business model, but it's clearly good for the community and the user.

So the results of the manufacturer decision on the user range from slight loss to being part of a flourishing community; for the community, it ranges from losing one commercial contributor to flourishing; for the manufacturer itself, all options (except perhaps for permitting adaptation) represent losses, so there is likely to be an economic incentive for respecting users' freedoms and helping the community flourish.


Tivoization works against the flourishing of the community, and while switching to an anti-tivoization license might lose the manufacturer as a contributor to the community, it also provides a higher economic incentive for the manufacturer and its customers to become active contributors to the community, which can then advance more than with tivoization in place.

While the community risks facing a small loss out of adopting anti-tivoization provisions, the manufacturer may very well find it more profitable to permit modifications than the other available courses of action, and then the community reaps the benefits of the mechanics of copyleft Free Software.

Copyright 2007 Alexandre Oliva

All rights reserved for now, because this is still an early draft. Please don't publish the URL or quote this article before its final publication.

Permission is NOT YET granted to make and distribute verbatim copies of this entire document without royalty provided the copyright notice, the document's official URL, and this permission notice are preserved.