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.

2 Answers 2


The anti-tivoization change made to the GPLv3 is to explicitly call 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 ever 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.

  • Well, that's pretty much what we do right now. When generating the source tree for distribution to the customer, we first remove our own closed-source application (which is responsible for >90% of the functionality) and replace the keys. The resulting source can still be compiled just fine, but the web-interface used for installation will reject those updates (because the key is different). If we are required to allow installation, we would tell the customer to send the device back to us, so we can "unlock" it. But of course it would be easier if we wouldn't have to do that.
    – Felix G
    Commented Jul 27, 2020 at 6:46
  • So i guess if we want to be 100% safe from a license compliance perspective, we can just allow the installation (but with additional hoops to jump through). But in theory, even if we don't allow it, we should still be fine (i.e. that's probably something a lawyer should check before we sell the first device).
    – Felix G
    Commented Jul 27, 2020 at 6:52
  • @FelixG, you should be fine, but as usual you should consult a professional lawyer if you are going to bet a company on it. In my experience, businesses don't ask for the source code to tinker with the device. If they want source code at all, it is to ensure they can keep maintaining the device in the event that your company goes out of business and then they are willing to sign an escrow agreement to get everything including the closed-source bits after your company has stopped. So the GPL requirements on providing source code are probably not going to be invoked anyway in a B2B context. Commented Jul 27, 2020 at 9:19
  • Yeah, that's what we figured as well, we just want to make this as easy as possible for ourselves while still making sure that we don't violate any OSS license. That's also why we'll just ship the source with each device, because then we'll have fulfilled all our obligations on delivery (as opposed to the written-offer option). To be honest, for some of our customers, i expect they'll destroy the source DVD anyway, just to make sure nobody can mess with the device. Thank you very much for your insight.
    – Felix G
    Commented Jul 27, 2020 at 9:55
  • As an author of software covered by GPLv2, I absolutely do consider signing keys part of the "preferred form for modification" if the combined program someone is shipping cannot be used without being signed by those keys. I don't see the "2 keys" argument as valid either. If you make a single change to the program, rebuild it with the nerfed key, and suddenly a bunch of functionality is gone, then you did not have the "source" (in sence of "preferred form...") for the program that was shipped but for a lesser-functionality program. Commented Mar 9, 2022 at 13:32

The GPLv2 requires that you provide the scripts that are used to compile and install the executable. It doesn't talk about authorization keys and it doesn't require the the end user to be provided the ability to install and execute the modified software in a specific product or device. As long as the scripts allow it to be installed "somewhere", the terms of the license is fulfilled.

The source code for a work means the preferred form of the work for making modifications to it. 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.

On the other hand, the GPLv3 does require the the end user to be provided the ability to install and execute the modified software in a specific product or device (i.e. the "User Product") where the original version of the software is installed in and executes in. It also explicitly includes "authorization keys".

“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. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

Many companies developing embedded products are completely opposed to inclusion of any software licensed under GPLv3 or LGPLv3 or AGPLv3, due to the Tivoization clause.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.