I have spent the better part of a decade working with embedded Linux systems. From routers to medical devices, from smart home hubs to industrial controllers, the GNU General Public License is everywhere in the hardware world. And yet, compliance with it remains staggeringly poor. This is not a marginal concern. The GPL is one of the foundational legal instruments that makes open source sustainable, and when companies treat it as a suggestion rather than a license, the entire ecosystem suffers.
The Scope of the Problem
Let us start with some blunt facts. The Software Freedom Conservancy has documented hundreds of violations across dozens of companies. Many of these are repeat offenders. A router manufacturer ships a device with a modified Linux kernel and provides no source. A smart TV vendor includes BusyBox but omits the written offer for source code that the GPLv3 mandates. An IoT gateway runs a heavily patched version of an open source real-time operating system, and the only way to discover this is through reverse engineering the firmware binary.
This is not accidental. Most hardware companies have legal teams. Most legal teams understand license obligations. The violations persist because the consequences of non-compliance are vanishingly small compared to the cost of compliance. That calculus needs to change.
Why Hardware Is Different
Software-only GPL violations are serious, but they have a certain transparency. A distributed binary can be inspected. Build systems can be reproduced. The community can identify mismatches between the distributed binary and the provided source with relative ease, thanks to tools like binwalk and strings.
Hardware blurs these lines considerably.
Installation Information Gaps
The GPLv2 requires that distributed source code include “the scripts used to control compilation and installation of the executable.” The GPLv3 goes further, explicitly requiring “Installation Information”—the information needed to install and run modified versions of the covered work on the device.
Hardware companies routinely ignore this. They might publish a tarball of kernel source on a forgotten FTP server, but they omit the toolchain configuration, the bootloader signing keys, the device tree blob sources, and the flash partition layout. Without these, the source code they provide is functionally incomplete. You cannot build a replacement firmware image and install it on the device you own. The letter of the license is arguably satisfied; the spirit and the explicit terms of GPLv3 are not.
Obfuscation Through Complexity
Modern system-on-chip designs are labyrinthine. A typical embedded Linux device might use a proprietary bootloader (U-Boot with vendor patches), a trusted execution environment running on a separate core, a mainline kernel with out-of-tree drivers, and a userland assembled from dozens of projects under various licenses. The GPL-licensed components are interwoven with proprietary pieces in ways that make it difficult to even identify which parts are covered.
Companies exploit this complexity. They release partial source and claim the rest is proprietary. They argue that certain drivers are separate works not derived from the kernel, even when those drivers are statically linked, use internal kernel symbols, and depend on kernel headers that are marked GPL-only. The legal ambiguity becomes a shield for non-compliance.
The Enforcement Gap
GPL enforcement in the hardware space is underfunded, underlitigated, and underpublicized. The Free Software Foundation and the Software Freedom Conservancy do commendable work with limited resources, but they cannot pursue every violation. Individual copyright holders often lack the legal standing or financial means to bring enforcement actions. Class action mechanisms for GPL enforcement are largely untested in most jurisdictions.
The result is predictable: companies calculate that the expected cost of non-compliance—a sternly worded email, perhaps a delayed source release after months of prodding—is far lower than the cost of establishing proper compliance processes, training engineers, and maintaining source releases for the required duration.
The DMCA Shield
Hardware companies have also learned to use copyright law defensively. Device firmware is often encrypted or signed, and circumventing these measures to inspect the software can trigger DMCA anti-circumvention liability. This means that even discovering a GPL violation in a hardware product can require legal risk on the part of the investigator. It is a perverse outcome: a license designed to guarantee user freedom is undermined by a law designed to restrict it.
What Better Enforcement Looks Like
Better enforcement does not mean being punitive for its own sake. It means creating conditions where compliance is the default, not the exception.
Specific, Actionable Source Release Requirements
Enforcement should demand complete, buildable source releases that include all materials necessary to produce a functional firmware image. This means toolchain specifications, board configuration files, signing keys where they are required to install modified software, and build instructions that actually work. A source dump that cannot be compiled into the binary running on the device is not compliance.
Proactive Auditing
The community cannot rely solely on volunteer reverse engineers to find violations. We need funded organizations that systematically audit hardware products for GPL compliance. This should include automated firmware analysis tools that can identify known GPL-licensed code in binary images, flag common violation patterns, and generate reports that can be acted upon.
Contractual Enforcement
Large purchasers—governments, enterprises, educational institutions—should include GPL compliance requirements in their procurement contracts. A company that wants to sell networking equipment to a government agency should have to demonstrate that it complies with the licenses of the software it distributes. Procurement standards like those under the EU’s open source strategy could serve as models.
Judicial Clarity
We need more case law. The few GPL enforcement cases that have gone to court have generally resulted in favorable outcomes for the enforcing party, but they often settle before establishing precedent. Strategic litigation aimed at clarifying the scope of “Installation Information” under GPLv3, the definition of a “derived work” in the context of kernel modules, and the obligations of distributors who modify and redistribute GPL-licensed code would provide the legal clarity that currently allows bad actors to operate in the gray areas.
The Stakes
I am not making an abstract argument. When a hardware vendor violates the GPL, it denies users the freedom to understand, modify, and improve the software running on their devices. This has real consequences. Security vulnerabilities in GPL-licensed components go unpatched because users cannot rebuild and update the firmware. Features are locked behind artificial restrictions. Devices that could be repurposed at end of life instead become electronic waste.
The GPL was written to prevent exactly these outcomes. Its enforcement provisions are not optional addenda; they are integral to the license’s purpose. Treating them as optional undermines the contract between licensors and licensees that makes free software possible.
Hardware companies benefit enormously from the free software ecosystem. Linux powers billions of devices. BusyBox, U-Boot, and countless libraries form the infrastructure of modern embedded computing. The least these companies can do is honor the terms under which that software was shared with them.
Better enforcement is not a radical proposition. It is a demand that existing legal obligations be taken seriously, and that the structures supporting those obligations be given the resources and clarity they need to function. The GPL deserves nothing less.
FAQ
Does the GPL actually require hardware vendors to release source code?
Yes. When a vendor distributes a device containing GPL-licensed software—whether that software is in firmware, a bootloader, or an operating system kernel—the vendor must make the corresponding source code available to recipients. Under GPLv2, this can be done by including the source with the device or by providing a written offer valid for three years. Under GPLv3, the requirements are more specific and include Installation Information necessary for installing modified versions.
What can an individual do if they discover a GPL violation in a hardware product?
Document the violation thoroughly. Record the device model, firmware version, and any GPL-licensed components you can identify. Contact the copyright holders of the infringed software—this may include individual developers, the Free Software Foundation, or the Software Freedom Conservancy. These organizations have experience with enforcement and may take action on your report. You can also publicize the violation, which sometimes generates enough reputational pressure to prompt compliance.
Is releasing source code really practical for small hardware companies?
It can be, especially if the company builds compliance into its development process from the start. Using unmodified upstream versions of GPL-licensed components reduces the burden significantly, since the upstream source is already publicly available. For companies that do modify GPL-licensed code, the cost of maintaining source releases is a legitimate business expense—not unlike the cost of complying with safety regulations or tax law. The difficulty of compliance does not excuse its neglect.