2

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.

3

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.

4
  • 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
    Jul 27 '20 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
    Jul 27 '20 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. Jul 27 '20 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
    Jul 27 '20 at 9:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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