GPLv2 and installation requirements

By Jonathan Corbet
January 8, 2026

On December 24 2025, Linus Torvalds posted a strongly worded message celebrating a ruling in the ongoing GPL-compliance lawsuit filed against VIZIO by the Software Freedom Conservancy (SFC). This case and Torvalds's response have put a spotlight on an old debate over the extent to which the source-code requirements of the GNU General Public License (version 2) extend to keys and other data needed to successfully install modified software on a device. It is worth looking at whether this requirement exists, the subtleties in interpretation that cloud the issue, and the extent to which, if any, the SFC is demanding that information.

Tivoization

It is increasingly common for computing systems to refuse to boot and run software that is lacking an authorized signature. There are many legitimate reasons to want this feature; a company may want to ensure that its internal systems have not been tampered with, or a laptop owner may want defense against evil maid attacks. There are also numerous cases of companies using this feature to protect their own business models. The practice of locking down devices running otherwise free software so that their owners cannot change that software has become known as "tivoization", after Tivo used it to control access to its digital video recorders.

Tivoization sits poorly with many free-software developers, who see it as a way of using copyleft software without providing all of the freedoms that should come with it. The practice enables devices built around antifeatures that, in a more free world, users would simply remove. But, while there is no universal agreement on whether this practice violates version 2 of the GPL, the larger contingent would appear to be on the side of "no". It is noteworthy that the GNU project, while criticizing tivoization, does not claim that it is a GPLv2 violation. When version 3 of the GPL was drafted, a special effort was made to add language disallowing tivoization, but many projects, including the kernel, have never adopted that version of the license.

Keys in the VIZIO case

At the end of 2025, the judge in the VIZIO case ruled that provision of signing keys is not required by the GPL. Specifically, the ruling said that the GPL's source-code requirements do not extend to materials required to install a modified version of the software on the original device and have it "continue to function properly". The SFC was quick to put out a press release saying that the ruling addressed an issue that was not actually before the court — that the SFC had not been asking for that ability. The truth of the matter would appear to be a bit more nuanced, though.

The SFC's complaint driving this lawsuit goes into a fair amount of detail about why access to the source code is important. Examples include claim 111:

With the source code for the SmartCast Works at Issue as used on the Subject TVs, developers could continue to develop and improve an operating system for smart televisions, which would benefit the public and further the goals of software freedom.

And claim 118:

Access to the Source Code of the Linux kernel, the other SmartCast Works at Issue, and for the Library Linking Programs, as used on VIZIO smart TVs, would enable software developers to preserve useful but obsolete features. It would also allow software developers to maintain and update the operating system should VIZIO or its successor ever decide to abandon it or go out of business. It would also allow for the maintenance of older models that are no longer supported by VIZIO. In these ways, purchasers of VIZIO smart TVs can be confident that their devices would not suffer from software-induced obsolescence, planned or otherwise.

The complaint also goes into some detail about how VIZIO makes far more money from sales of advertising and data about its customers than it does from selling televisions. Supporting the company's real business model requires monitoring what owners of the devices are doing and selling that information to others. With access to the source, developers could remove the surveillance features built into VIZIO devices, improving their privacy and security. The complaint notes that VIZIO seems unlikely to make it possible to disable those features on its own.

All of these assertions are fairly obviously true, and there is no doubt that the owners of VIZIO devices would benefit from the ability to make the described changes. That is what the freedom of free software is all about. But there is a catch: access to the source will provide none of those freedoms without the ability to install modified software on the device — and have the device actually run that software. The SFC's complaint does not mention signing keys specifically, but it describes freedoms that cannot be exercised without those keys.

Reinstallation requirements

So why does the SFC claim that the court's ruling is irrelevant? There are, as it turns out, multiple ways to look at what it means to install software on a device. Specifically, should a modified software load still be able to provide all of the functionality that the original did? VIZIO's software, for example, surely contains proprietary components that allow the device to play DRM-protected content. Allowing a user-modified kernel to access those components would enable the creation of a channel to export unprotected content from the device, thus accelerating the escape of that content onto the Internet by several milliseconds. For some reason, VIZIO feels that this outcome should be avoided.

The SFC states that it never asked for this capability, that, specifically, nobody is claiming that the device must continue to provide all of its functionality if modified software is installed. At the other extreme, though, while a device that refuses to boot because the kernel lacks the requisite signature surely fits within the description of "not continuing to function properly", the SFC appears to find that result insufficient. The level of functionality that must be available to user-modified software has not been clearly defined, but it seems to involve functionality beyond that needed for a doorstop.

What the SFC may be asking for is something akin to the Chromebook developer mode. A Chromebook can either be locked down, in which case all supported functionality is available, or it can be in developer mode, which allows user-installed software but loses access to some features. Similarly, some Android devices allow their software to be replaced, but they lose the ability to attest to the purity of their software and some apps may refuse to run. If VIZIO televisions had a developer mode that allowed users to install software with reduced functionality, that would seemingly satisfy the SFC's requests. VIZIO, though, did not see fit to design that feature into its products.

That said, the SFC did argue that the GPL at least might have a "reinstallation requirement" that preserves the functionality of the device; it is worth understanding why. As noted above, the SFC's complaint assumes that it would be possible to install modified software on the system. As a way of heading off the threat to its business model, VIZIO asked for a summary judgment that no such requirement exists in the GPL:

VIZIO moves on the grounds that the plain language of GPLv2 and LGPLv2.1 or, in the alternative, the undisputed extrinsic evidence, compels the conclusion that neither license imposes a duty on licensees to provide all information necessary to permit reinstallation of modified software back on the same device such that the device continues to function properly.

Note that this motion was brought forward as a way of requesting that a significant portion of the SFC's case be thrown out of court. A failure to respond to the motion in the strongest possible way would have been an act of malpractice on the part of the SFC's lawyers; they had to challenge it. So, even though the SFC claims to have never brought in the "the device continues to function properly" language, it found itself having to defend that language anyway. That defense came in this filing, which included quotes from some important developers that the installation requirement does indeed exist:

As one member of the FOSS community [Bdale Garbee] explains, under the GPLv2, the distributor of a device that includes a computer program licensed under the GPLv2 "must provide scripts that allow a recompiled binary of the source code to be installed back onto the device in question."

The purpose here was not to establish the existence of a reinstallation requirement; it was to show the existence of doubt on the question so that a summary judgment would be inappropriate. The judge, however, sided with VIZIO and granted the motion. While the judge did not address the issue of whether installation without the need for proper functioning might be required by the license, it seems unlikely that the outcome would be different.

The approach taken by Torvalds and other (but certainly not all) kernel developers toward tivoization reflects an important tradeoff. Had the kernel moved to GPLv3 and required the ability to install modified versions, much of the industry built around Linux may well have moved on to something else. That, in turn, would lead to a significant reduction in corporate support for Linux development.

There are certainly developers who would happily make that trade in exchange for a license that guarantees more freedom. But a kernel that is not used provides no freedom at all, and Linux without companies behind it would not be in anything close to the condition it is now. Torvalds chose, many years ago, a policy that freedom extends to the software, but not beyond; the result is a kernel that is now nearly ubiquitous. So we find ourselves in a situation where the software is capable and free, but that is not always the case for the hardware it runs on. That problem is well worth solving, but GPLv2 does not appear to be the right tool for the job.

Index entries for this article
Kernel	Copyright issues

to post comments

Thanks

Posted Jan 9, 2026 2:21 UTC (Fri) by marcH (subscriber, #57642) [Link] (3 responses)

> The SFC's complaint does not mention signing keys specifically, but it describes freedoms that cannot be exercised without those keys.

Thanks, this (and the rest) is the sort of nuanced analysis and journalistic work that readers never get when they are either "the product" (cause it's "free"), or the target of some lobbyist or some other propaganda.

Thanks

Posted Jan 9, 2026 5:35 UTC (Fri) by felixfix (subscriber, #242) [Link] (2 responses)

I second that emotion. This is a welcome analysis.

Thanks

Posted Jan 9, 2026 12:56 UTC (Fri) by mpg (subscriber, #70797) [Link] (1 responses)

Thirded. This kind of well-researched, precise and at the same time very readable article on a complex (and contentious) topic is exactly why I like LWN so much. (Same for the other recent one about who can enforce.)

> accelerating the escape of that content onto the Internet by several milliseconds. For some reason, VIZIO feels that this outcome should be avoided.

> The level of functionality that must be available to user-modified software has not been clearly defined, but it seems to involve functionality beyond that needed for a doorstop.

And also the style is just the icing on the cake :)

DRM

Posted Jan 9, 2026 22:01 UTC (Fri) by marcH (subscriber, #57642) [Link]

> accelerating the escape of that content onto the Internet by several milliseconds. For some reason, VIZIO feels that this outcome should be avoided

I smiled too but more seriously and to be fairer with DRM: no one is naive enough and expects DRM to completely solve that problem. It's only meant to stop "casual" sharing between trusted friends and family and redirect people to scarier, malware-loaded sources. For that more realistic purpose and combined with decent legal options (at last), DRM has been quite successful.

Until... some GPL snafu breaks security through obscurity? :-)

designing for responsible reinstallability

Posted Jan 11, 2026 23:33 UTC (Sun) by alison (subscriber, #63752) [Link] (7 responses)

My conscience has wrestled with the "anti-Tivoization" question for years. Like many of you, I firmly believe that purchasers of products own them and have an implicit right to repair and modify them as they fit. Like many of you also, I have worked on products which are potentially dangerous. My various employers have spared no effort and money in testing and re-testing these products at the unit, board, component and system levels following a formal, methodical safety-case analysis. My doubts about product owners reinstalling such products comes down to whether we can trust them to be so thorough in considering possible failure modes and their mitigations. Have participated in the formal safety process, I am compelled to answer no.

Would that conclusion mean we are doomed to live in a world where device buyers must live with what manufacturers give them? Not necessarily. Going beyond the trivial "customizations" and limited "app stores" which manufacturers now provide is possible. There is no reason why even potentially hazardous products cannot be partitioned into "safe" and "open" enclaves, with reinstallation of the former requiring secret keys, and reinstallation of the latter not. Many products assuredly already have such partitioning already, but there is no pressure on manufacturers to document it. That's too bad even for them, as they're liable to get accessibility, internationalization and documentation support for free if they cooperate.

designing for responsible reinstallability

Posted Jan 12, 2026 1:03 UTC (Mon) by DemiMarie (subscriber, #164188) [Link] (2 responses)

Are TVs example of such products? My instinct says no: protections against physical dangers (such as fire or electric shock) should be typically be implemented entirely in hardware, not in software. For instance, overheating something to the point it could catch fire should be prevented by hardware mechanisms that shut down the device before this can happen. Linux isn’t safety certified and relying on it for safety applications seems like a misdesign in general.

There are devices where this isn’t possible. One example in the consumer space is 3D printers. Specifically, PEEK recommended nozzle temperature is 380°C-440°C according to Prusa, whereas one of the many safety data sheets for PLA states an autoignition temperature of 388°C. However, in this case the hazard can also be triggered by misuse by a human operator, even with OEM firmware.

It’s definitely possible for software to cause hardware damage in some cases, but as long as the damage is contained within the device and does not endanger anyone outside it, I think the owner of the device should have the right to take this risk. After all, they could destroy the device much more easily in other ways, but they usually have a vested interest in not doing so.

designing for responsible reinstallability

Posted Jan 12, 2026 4:41 UTC (Mon) by alison (subscriber, #63752) [Link]

I agree that TVs lack safety implications, while many kinds of robots have them. I also agree that sometimes letting the responsibility for some hazards fall on the user is reasonable. Nonetheless, there are places to draw the line, for example when a potentially hazardous device is routinely operated in a public place, or when the failure of the device (e.g. x-ray machine) has the potential to harm not only the operator but also the patient.

designing for responsible reinstallability

Posted Jan 12, 2026 10:29 UTC (Mon) by farnz (subscriber, #17727) [Link]

There's an inherent tradeoff there, and the whole concept of "functional safety" is about addressing this tradeoff seriously.

In general, software is more capable of complex decisions than hardware; as an example from my field, you have "arc fault detection", which has to distinguish arcing that's caused by things like relays opening, or contained in a vacuum tube and triggered deliberately to start a process ("benign arcs") from arcing caused by damaged cabling ("hazardous arcs"). As a safety matter, you want to cut power on a hazardous arc, because hazardous arcs lead to fire, but not on benign arcs, because then people bypass the safety device that trips every few minutes in normal operation.

Hardware can detect an arc very easily (there's a "signature" waveform that's a sign of arcing), but cannot classify into hazardous and benign particularly easily. Instead, you run hard real-time software (certified to an appropriate standard) which does the classification, looking at not just whether there's an arc or not, but also the history of voltages and currents when arcs happen; some patterns are signs of hazardous arcs (since they indicate that the arc is uncontrolled), while others are signs of benign arcs (since they indicate that the arc is controlled and therefore not going to result in a hot-spot without tripping either the circuit breaker or an RCD/GFCI).

designing for responsible reinstallability

Posted Jan 12, 2026 2:43 UTC (Mon) by SLi (subscriber, #53131) [Link] (2 responses)

While I'm not going to say your stance is wrong (it's a policy question, and there are arguments on both sides), I think there's another way of looking at it: Are there technical and legal means used to accomplish this the most reasonable ones?

As for technical, I think quite possibly yes. It just sounds like if such a restriction is to exist yet not pointlessly require firmware that even the vendor cannot update, then certainly that starts to sound a lot like DRM, even though that word is more associated with copyrights.

Legally? I generally don't like it when copyright law is used to advance random good agendas unrelated to the purposes of copyright. I would hope that hacking your airliner or writing a distasteful book using your text editor code would be prevented by some non-copyright mechanism.

designing for responsible reinstallability

Posted Jan 12, 2026 4:45 UTC (Mon) by alison (subscriber, #63752) [Link]

> It just sounds like if such a restriction is to exist yet not pointlessly require firmware that even the vendor cannot update, then certainly that starts to sound a lot like DRM, even though that word is more associated with copyrights.

I'm not proposing new mechanisms for a safe enclave. There already ways to update such software which are outside the scope of the current discussion. What is more pertinent is that running only signed binaries is a good idea, but there's no reason that signing keys and installation scripts couldn't be available for an open enclave.

> I generally don't like it when copyright law is used to advance random good agendas unrelated to the purposes of copyright.

Agreed. What we want is thoughtful regulation proposed by panels of experts. Unfortunately, there's not much sign that's imminent, although some European entities seems to want to try.

designing for responsible reinstallability

Posted Jan 15, 2026 16:49 UTC (Thu) by smoogen (subscriber, #97) [Link]

| Legally? I generally don't like it when copyright law is used to advance random good agendas unrelated to the purposes of copyright. I would hope that hacking your airliner or writing a distasteful book using your text editor code would be prevented by some non-copyright mechanism.

I used to think that this would come about, but I have come to realize that brains are too damn lazy and risk adverse. You could go and craft a new device to hammer a shell open... OR you could use the rock your ancestors have used for 40 million years before to do so.

The previous version I have run into is where someone used a hammer on a screw because it drove the damn thing in just as well. Over and over again. The modern day version is after being trained from N million commits, the various LLMs "fix" many tests by turning them off or removing the code which was not passing.

So copyright is the hammer which is immediately available and something 'tested' to work on nearly any problem. And then if copyright isn't there.. there is contract law which also gets pulled in here. Nice old hammers ranging from the 1700 AD (copyright) to at least 1700 BC (contract law).

designing for responsible reinstallability

Posted Jan 12, 2026 11:30 UTC (Mon) by mtthu (subscriber, #123091) [Link]

I too think the matter of "right to repair" should be looked at completely separate from the software licensing question. The Linux kernel runs on many applications which are not consumer oriented and fall under different jurisdiction. This is mainly related to safety, as you also point out. On the other hand it also is related to trade compliance questions in the context of military applications. As the GPLv2 doesn't restrict the usage of the kernel in this kind of applications, it's widely used there. If the GPLv2 would have the implication that hardware must be open to the user, it would undermine various applications where this is strictly prohibited for other reasons.

I strongly support the idea that the buyer of a certain good is actually the owner of it and should be capable of doing with it whatever he likes. Where the supplier of a good is mandated to keep safety measures in place and take responsibility for the usage of said good, the supplier should be allowed to impose access restrictions.

Sophos are a great example of doing the right thing

Posted Jan 22, 2026 0:27 UTC (Thu) by neggles (subscriber, #153254) [Link]

I like the way Sophos handles this for their WiFi access points. Their internal build system has two folders in its root source directory, one for proprietary code and one for OSS code, and goes to some lengths to ensure that proprietary code is never statically linked to OSS code.

They publish an ISO containing this entire build system (minus the contents of the proprietary source tree), along with instructions for how to build a working image, a list of what features are missing due to the absence of proprietary code, and most importantly, a signing key (public+private components)

That key's public key is baked into the devices' bootloader (u-boot, naturally) but out of the box, the device won't accept it as trusted. If you connect directly to the serial console, you can set a u-boot environment variable to enable "developer mode", and the device will accept images signed by the developer key, or you can set the "verify" env var to "no" and it will bypass validation entirely.

If you do this on a unit running release firmware, the firmware will either revert it on boot, or trigger an alert in the controller UI to flag that the device is in an insecure state.

Yes, it does stop you from being able to load your own u-boot image, but their u-boot builds are competent and this seems like a reasonable compromise to me. Their firewall appliances work similarly, and have a similar GPL source ISO supplied