TransWikia.com

Tivoization and the GPLv2

Open Source Asked by Felix G on December 14, 2021

I have seen several questions on this site regarding tivoization, and how the GPLv3 can prevent it. However, for my particular use case, the GPLv3 actually seems to be more permissive than the GPLv2.

That’s because the GPLv3 anti-tivoization clause only applies to consumer products, but the company i’m working at doesn’t make consumer products. We are currently developing several linux-based embedded devices, which will be incorporated into the machines we are selling to our customers (other companies). Preventing the installation of "unofficial" updates (i.e. updates not signed with our private key) is pretty important to us (and our customers), to make it harder for any random operator to accidentally (or intentionally) brick the machine.

So, the GPLv3 definitely isn’t a problem for our use case, but i’m not so sure about the GPLv2, and here’s why (emphasis mine):

For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

The wording is of course not nearly as clear as in the GPLv3, but the intent sure seems to be that we need to allow installation of modified software.

So, when people say the GPLv2 doesn’t prevent tivoization, is the situation actually that clear-cut?
Or is it more like "well, technically, if you follow the license text to the letter, and the installation isn’t done by a script…"

PS: i have seen this question, but the answer unfortunately doesn’t actually explain why the GPLv2 isn’t violated.

One Answer

The anti-tivoization change made to the GPLv3 is to explicitly cal out that signing keys are part of the installation information that you must provide as part of the Corresponding Source, and that using a modified version by itself must not be a cause for a degraded (or non-)functioning of the device.

It is debatable if the signing keys are also required to be distributed under the GPLv2, but imagine the following scenario

I build a device that contains a signed Linux image (under the GPLv2) and a firmware blob (under a closed source license). I design things such that the Linux image and the firmware blob are not derived works of each other, so I don't have licensing issues with the GPL <-> closed source combination.
I have two signing keys for the Linux image. If the image is signed with key1, the firmware provides the full functionality, but if it is signed with key2 the firmware provides limited functionality.
When people ask for the source code, I only even provide them with key2. When people now rebuild the Linux image and load it onto the device, they get a device with degraded functionality, even if they built the sources without making any changes to them.

With this scheme, I have fulfilled my obligations under the GPLv2 to the letter (and I might have gone slightly further by providing the signing key). People can install their own executables. They just don't get as much functionality from the closed-source firmware blob.

Answered by Bart van Ingen Schenau on December 14, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP