Firmware freedom, the way I use the term on this blog, is the practical ability to read the software off a device you own, rebuild it from source, fix it, update it, and share the result without asking a vendor for permission. It sits where right-to-repair advocacy, GPL compliance enforcement, and low-level hardware work — SPI, UART, SWD, JTAG — meet. Most of what I audit is Linux-based: consumer routers, Android TV boxes, single-board computers, industrial IoT gateways, and, increasingly, medical devices. For that class of hardware, firmware freedom is the precondition for durable repair. You can stock every capacitor and MOSFET on the planet, but when the failure is a bricked bootloader or a kernel that stopped getting CVE fixes years ago, spare parts alone won’t bring the device back. My argument in this piece is narrow: the right-to-repair movement, as legislated so far, has a firmware blind spot — and the GPL is the repair law we already have.
What firmware freedom means on my bench
Four capabilities. A device needs all of them to stay repairable for more than a few years.
- You can read the firmware off the silicon. flashrom over SPI on the NOR flash, a UART console into the bootloader, or SWD/JTAG on the microcontroller.
- You can rebuild what you just read. GPLv2 section 3 calls this “complete corresponding source”: the source itself, the exact configuration, the device tree source for your board, the toolchain, and the scripts that bind it together.
- You can write a replacement back. That takes an open boot path — an unlocked U-Boot, no enforced verified boot, no Android Verified Boot lock.
- You can share the result. The GPL-covered parts can be redistributed, and that is the only reason community repair images exist at all.
Most devices I audit fail at step 2 or step 3. The failure is legal before it is technical: an incomplete source release, a locked boot chain, or both.
The repair movement has a firmware blind spot
The repair statutes passed so far give you parts, tools, and documentation. Almost none of them give you firmware, and several go out of their way to say so.
The FTC’s 2021 report Nixing the Fix documented how manufacturers restrict independent repair through parts pairing, diagnostic lockouts, and withheld documentation (FTC report on repair restrictions). Since then the state laws have landed: New York’s Digital Fair Repair Act (signed December 2022), Colorado’s agricultural-equipment law (2022) with its consumer-electronics follow-up (2024), and Minnesota’s and California’s statutes, both effective July 1, 2024. These are real wins for board-level repair. Independent shops can finally get schematics, parts, and tools for categories that used to be closed.
Then read the carve-outs. California’s SB 24 says nothing in the act obliges a manufacturer to reveal passwords, security keys, or anything that disables a security lock. Comparable language shows up in the other statutes. As written, these laws repair the hardware half of a device and leave the software half untouched — and the software half is where devices actually die now.
A repair right that stops at the firmware wall is a repair right for 2010. Firmware is the component most likely to fail, and it’s the only one the vendor keeps custody of after you’ve paid.
GPL compliance is the repair law we already have
If a device ships Linux, its vendor is already under a source-disclosure obligation — and courts have started treating that obligation as a consumer right, which is exactly the framing repair advocacy needs.
GPLv2, section 3, requires “the source code … plus the scripts used to control compilation and installation of the executable.” The FSF’s GPL FAQ spells out what that means for embedded products: not a tarball of some kernel that doesn’t match the shipped image, but the materials needed to rebuild the shipped thing (GNU GPL FAQ). Read it as a repair specification. That’s what it is.
The enforcement record backs this reading. In 2003, community members found a GPL-covered kernel inside the Linksys WRT54G; the source release that followed seeded OpenWrt, today the de facto repair ecosystem for hundreds of router models. Harald Welte’s gpl-violations.org project, founded the next year, turned that discovery into a repeatable enforcement method. The FSF’s suit against Cisco over Linksys devices settled in 2009 with a compliance officer and re-published source. The Software Freedom Conservancy’s BusyBox cases — Monsoon Multimedia in 2007, Verizon in 2008, and the Westinghouse case filed in 2009 that ended in a default judgment — established that the source obligation is enforceable in US courts.
The case I follow closest is Software Freedom Conservancy v. Vizio (case background from the Conservancy). Filed in 2021 in California state court, it argues that Vizio’s failure to provide BusyBox and Linux source is a breach of contract that consumers — not only copyright holders — can sue over. In July 2024 the California Court of Appeal held that the claim could proceed on that third-party-beneficiary theory, and the state supreme court declined review later that year. If the claim succeeds at trial, GPL source stops being a courtesy extended to foundations and becomes something a device owner can demand. That is a right-to-repair statute nobody had to pass.
A case from my bench: the router that outlived its vendor portal
Concreteness beats argument, so here is firmware freedom as it looked during one actual repair. I’m withholding the vendor’s name because my compliance query to them is still open.
The device: an AC1900-class Wi-Fi router built on a MediaTek MT7621A, bought new in 2019, end-of-life since 2021. The failure: the 16 MiB Winbond W25Q128JV SPI NOR stopped reading cleanly — repeated dumps of the upper region failed checksum on re-read. The vendor portal offered nothing for the model. No firmware file. No recovery tool. No documentation.
The dump: a SOIC-16 test clip on the chip, in circuit, flashrom 1.3.0 driving a CH341A programmer. Mine is modified for 3.3 V logic, because stock CH341A boards drive 5 V on the data lines and will happily cook a NOR flash. The JEDEC ID came back 0xEF 0x40 0x18 — exactly what a W25Q128JV should answer. The lower half of the chip was intact.
Triage from the dump took twenty minutes:
- A U-Boot banner in the old Ralink/MediaTek SDK lineage. The fork resembles U-Boot 1.1.3 with vendor patches; I can’t date the fork precisely from strings alone, and I won’t pretend otherwise.
- The kernel banner: Linux version 4.14.221, built with GCC 5.4.0.
- A SquashFS root filesystem carrying BusyBox 1.29.2, plus the compiled device tree blob for this exact board.
Then the GPL offer. The vendor’s GPL download page held a linux-4.14 tarball, and the version matched the banner — but there was no device tree source for this board, no defconfig, no build script, and no toolchain named. So I reconstructed the DTS from the on-flash DTB with dtc, advanced the tree from 4.14.221 to 4.14.336 (the final 4.14 stable release, January 2024), rebuilt, carved the Wi-Fi calibration and firmware regions out of my own dump, recombined, and flashed the result onto a replacement W25Q128JV. The router now runs again at my parents’ house.
Two honest caveats. First, I can prove the published tarball doesn’t build the shipped image as-is; I can’t prove why. Maybe the vendor’s internal build system had the missing pieces and the web team published the wrong archive. The GPL doesn’t grade intent, so I’ll flag the uncertainty rather than assume bad faith. Second, this took me one afternoon because I do it weekly. For an owner without a usable source release, the device is a paperweight the day its flash degrades — and flash does degrade.
Where GPL source stops short of repairable firmware
A source tarball is not the whole of firmware freedom, and pretending otherwise would make this blog useless. Three gaps come up constantly.
Signing keys are not in the GPL
The kernel is GPLv2, which has no key-disclosure requirement. GPLv3’s “Installation Information” clause for User Products comes closer to what repair needs, but essentially no router or TV-box kernel is GPLv3. On a device with enforced verified boot — an Android TV box with AVB 2.0 locked and keys burned into eFuses, or a Rockchip board checking signed fitImages — you can hold perfect source and still be unable to flash your rebuild. GPL compliance is necessary for firmware freedom. It is not sufficient. The missing piece is an open boot path, and only the vendor or a hardware bypass can provide it.
Proprietary blobs stay proprietary
Wi-Fi firmware blobs, DSP code, and secure-world binaries are not GPL, are not source, and cannot be redistributed. The legal repair pattern is the one OpenWrt normalized: rebuild the GPL-covered parts, extract the blobs from your own device, recombine locally, and share patches and scripts rather than whole images. It works. It also means community firmware for a given model dies with the last person holding a donor dump.
Regulated sectors move slower than the silicon
Since March 2023 the FDA has required a software bill of materials and postmarket update plans for “cyber devices” under section 524B of the FD&C Act, and it began refusing submissions that lacked them. That gives hospitals visibility into what’s running, not the ability to rebuild it. In a 2023 review I saw a bedside gateway still on Linux 3.10, carrying a vendor end-of-support notice; I’m keeping the site anonymous because the finding was shared with me under NDA. In the EU, the Radio Equipment Directive’s cybersecurity conditions apply from August 1, 2025, which should push vendors to keep firmware buildable longer. Neither regime hands anyone a build recipe, and the distance between “an SBOM exists” and “I can rebuild this” is exactly where this blog lives.
What I check on every device I audit
The checklist I run, in order, on any Linux-based device that crosses my bench:
- Dump first, ask questions later. Identify the flash via its JEDEC ID, dump twice, compare SHA-256 hashes. In-circuit clip first; desolder only if the board fights back.
- Strings triage. Search for “Linux version”, “U-Boot”, and “BusyBox v”. Kernel, bootloader, and userspace versions in under a minute.
- Carve the image. binwalk for the uImage kernel blob, the SquashFS or cpio rootfs, and the DTB; unsquashfs to browse the early userspace.
- Decompile the device tree. dtc -I dtb -O dts. The compat strings tell you which board family you’re actually holding — that’s what you match against the GPL offer.
- Audit the GPL offer. Does the kernel version match the banner? Is there DTS for your exact board? A defconfig? A build script? A named toolchain?
- Try to build it. The only test that matters: does the documented recipe produce something bootable? Compare the resulting kernel banner against the dump.
- Check the boot path. Is the U-Boot console reachable over UART? Is AVB locked? Is there an unsigned fallback — SD boot, USB recovery mode?
- Write everything down. Offsets, hashes, version strings. Both enforcement and repair depend on the notes later.
Step six is where most “compliance” fails. I’ve started calling the failure mode source dump theater: a tarball that satisfies a checkbox but not section 3.
What would actually move the needle
If I could add one sentence to every repair statute, it would be this: when a manufacturer ends support for a device, it must publish, at a stable public URL, everything needed to rebuild the firmware it last shipped — or state exactly which parts cannot be rebuilt and why. That single clause would turn GPL enforcement from an occasional courtroom event into routine end-of-life procedure.
Short of legislation, three things I’ve seen work. Procurement clauses — an industrial client of mine now requires a demonstrated firmware rebuild before accepting delivery of Linux-based gateways. Reporting violations to the Software Freedom Conservancy or the FSF compliance lab. And simply asking, because vendors do fix their GPL offers when a customer with a purchase order asks politely, in writing.
Frequently asked questions
Does the GPL require a vendor to give me signing keys so I can flash modified firmware?
No. GPLv2 — which covers virtually every router and TV-box kernel — has no key-disclosure requirement. GPLv3’s Installation Information clause for User Products comes closest, but it’s rarely in play on this hardware. On devices with enforced verified boot, perfect GPL compliance and a permanently locked boot chain can coexist. That’s the biggest gap between GPL compliance and firmware freedom, and I flag it on every audit.
Can I legally share a full modified firmware image for my router?
Not the whole image. The GPL-covered parts — kernel, BusyBox, U-Boot where it applies — can be redistributed; the vendor’s proprietary blobs cannot. The accepted pattern is to share patches plus a script that extracts the blobs from the user’s own dump and rebuilds locally. That’s been the community method since the WRT54G era.
How do I tell whether my device’s GPL source offer is real?
Try to build it. Check five things against your own dump: the kernel version matches the banner, DTS for your exact board exists, a defconfig exists, the toolchain is named, and a build script is included. If any are missing, the offer is likely incomplete under GPLv2 section 3 — a tarball that can’t rebuild the shipped image is not complete corresponding source.
Do right-to-repair laws give me firmware access?
Not meaningfully. The statutes cover parts, tools, and documentation, and they carve out security keys and lock-bypass material — California SB 24 does so explicitly. Firmware access currently rides on GPL enforcement, which is why I treat every audit as a repair-rights document as much as a compliance one.
What is the minimum kit for dumping firmware at home?
A CH341A programmer (verified or modified for 3.3 V logic), a SOIC-8 or SOIC-16 test clip, flashrom on any Linux machine, a USB-UART adapter for the bootloader console, and optionally a Raspberry Pi as a spare SPI host. About $30 of hardware covers the majority of routers, TV boxes, and SBCs on the market.
Where this column goes next
This piece opens a series I’m calling Bench Logs: one device per installment, one flash dump, one GPL offer checked against section 3, with hashes and version strings included so you can reproduce the findings. Next up is an Amlogic-based Android TV box — the hardware class where my compliance checks fail most often. I’m also drafting a glossary page for the terms that repeat here, because corresponding source, AVB, and verified boot deserve their own reference entries. If you own a device you suspect ships GPL-covered code without a usable source offer, send me the kernel banner string from your dump and the vendor’s GPL link. The backlog is whatever readers hand me.