GPLv2 and installation requirements
[LWN subscriber-only content]
Welcome to LWN.net
The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!
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 |
Posted Jan 9, 2026 2:21 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (3 responses)
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.
Posted Jan 9, 2026 5:35 UTC (Fri)
by felixfix (subscriber, #242)
[Link] (2 responses)
Posted Jan 9, 2026 12:56 UTC (Fri)
by mpg (subscriber, #70797)
[Link] (1 responses)
> 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 :)
Posted Jan 9, 2026 22:01 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
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? :-)
Posted Jan 11, 2026 23:33 UTC (Sun)
by alison (subscriber, #63752)
[Link] (7 responses)
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.
Posted Jan 12, 2026 1:03 UTC (Mon)
by DemiMarie (subscriber, #164188)
[Link] (2 responses)
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.
Posted Jan 12, 2026 4:41 UTC (Mon)
by alison (subscriber, #63752)
[Link]
Posted Jan 12, 2026 10:29 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
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).
Posted Jan 12, 2026 2:43 UTC (Mon)
by SLi (subscriber, #53131)
[Link] (2 responses)
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.
Posted Jan 12, 2026 4:45 UTC (Mon)
by alison (subscriber, #63752)
[Link]
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.
Posted Jan 15, 2026 16:49 UTC (Thu)
by smoogen (subscriber, #97)
[Link]
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).
Posted Jan 12, 2026 11:30 UTC (Mon)
by mtthu (subscriber, #123091)
[Link]
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.
Thanks
Thanks
Thanks
DRM
designing for responsible reinstallability
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.
designing for responsible reinstallability
designing for responsible reinstallability
There's an inherent tradeoff there, and the whole concept of "functional safety" is about addressing this tradeoff seriously.
designing for responsible reinstallability
designing for responsible reinstallability
designing for responsible reinstallability
designing for responsible reinstallability
designing for responsible reinstallability