Author: Sophia Fowler

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…

Last March, a compliance officer at an industrial IoT company in Pune shipped me a device. White-label gateway, sold under a GPL source offer printed on the inside of the enclosure — the kind of perfunctory notice that says "this product contains GPL software; written source available upon request." She had requested source twice. Both times, the vendor sent a tarball of Buildroot package metadata. No kernel tree. No U-Boot source. No device tree bindings. She asked me to determine whether the device actually contained GPL code, and if so, to pin down exactly where the violation sat in the boot chain. What follows is the methodology I used. The device — I'll call it the Pune Gateway — turned out to have a three-stage violation: a U-Boot fork with…

GPL compliance auditing for embedded Linux devices means checking whether a vendor actually met the source-code disclosure and license-notice obligations of the GNU General Public License for the software shipped on a physical product. It sits at the intersection of firmware forensics, supply-chain verification, and bootloader analysis. For engineers working with industrial IoT gateways, consumer routers, single-board computers, and medical devices, an audit answers a concrete question: can I obtain, rebuild, and modify the exact GPL-licensed components running on this hardware? This article walks through a repeatable audit method using SPI flash extraction, U-Boot environment inspection, device tree review, and package manifest cross-checking. I have used this sequence on ARM-based routers, NXP i.MX6 industrial controllers, and a Rockchip RK3399 SBC, and the steps below reflect what actually worked in those…

Last March, a compliance officer at a European industrial IoT company forwarded me a kernel source tarball from their Chinese ODM. The question was simple enough: Is this everything? The ODM had shipped 40,000 gateways running a customized Linux kernel. The source release came as a 2.3 GB compressed archive. I dumped it, attempted a build, and found it missing 187 kernel modules, the entire U-Boot SPL source, and a custom RTC driver that was clearly compiled into the shipping kernel. When challenged, the ODM's response came back: That is all the source we received from our SDK vendor. Seven years of GPL compliance audits have taught me one thing. The technical extraction is the easy part. The hard part is producing a report that a legal team can act…

GPL compliance auditing is the process of verifying that a shipping embedded product actually delivers the source code, build scripts, and license notices that the GPL requires. It sits at the intersection of firmware forensics, supply-chain archaeology, and legal risk management. For industrial IoT gateways, consumer routers, and medical monitoring hardware, a missed GPL obligation can turn a successful product launch into a cease-and-desist letter, a lost distribution right, or a forced recall. I have spent enough nights with a logic analyzer clipped to a NAND flash to know that the truth is rarely in the datasheet. It is in the firmware image, the boot log, and the vendor's willingness to answer a direct question. This article is a practical audit workflow. I will walk through the evidence you need…

I probed the SPI flash on a commercial IoT gateway last month and found a 3.18 kernel with no corresponding source on the vendor’s website. No tarball, no written offer, just a binary blob and a shrug from their support team. That’s not an edge case—it’s the default for too many embedded Linux devices I’ve torn down over the past decade. Auditing for GPL compliance isn’t about legal theory. It’s about reading chips, extracting filesystems, and matching the actual build artifacts to the source code the vendor claims to ship. This article lays out the hardware-first methodology I use when a new device lands on my bench, from physical probing to the final compliance report. GPL compliance in embedded systems lives at the intersection of firmware extraction, toolchain forensics, and…

I don’t trust spec sheets. When a new industrial IoT gateway or consumer router lands on my bench, I go straight for the hardware. I’m not looking for build quality or chip markings—I’m hunting for the software the vendor forgot to tell you about. The Linux kernel, BusyBox, U‑Boot, maybe a full Debian rootfs crammed inside. A GPL compliance audit isn’t a paperwork drill; it’s a forensic teardown. I trace the boot chain, dump the flash, and compare what I find against what the manufacturer actually released. If they’re hiding something, the silicon will tell me. Start with the Boot Log: The First Confession Before I even pick up a soldering iron, I connect a USB‑to‑UART adapter to the board’s serial header. Most embedded Linux devices have one—often unpopulated, sometimes…

When you crack open a new embedded Linux gadget—whether it’s a router, a smart camera, or an industrial IoT gateway—you’re not just holding hardware. You’re holding a bundle of open-source software, and a lot of it is covered by the GPL. That license isn’t a suggestion. It’s a binding set of requirements. Yet after years of tearing down consumer and industrial gear, I’ve seen that many manufacturers treat the GPL like an afterthought. This isn’t about legal nitpicking. It’s about supply chain integrity, security, and the right to fix what you own. A proper GPL audit is a technical process, not a philosophical one. Here’s how you do it, step by step, from the first glance at the box to the final compliance report. Why a GPL Audit Matters for…

How I Reconstructed a Buildable GPL Source Release From a Vendor's Incomplete Tarball // FIELD GUIDE The vendor's email landed on a Tuesday afternoon. One sentence, a download link, and a 247 MB tarball named linux-source-v2.3.1-release.tar.gz. Six weeks of GPL source requests, and the Chinese ODM behind a white-label industrial IoT gateway we were auditing had finally delivered. I downloaded the archive, extracted it, stared at the contents for about ninety seconds. What they sent us was not a source release. It was a funeral. The tarball had a Linux kernel source tree—correctly versioned at 5.10.110, with the right SoC patches for the Rockchip RK3568—but it was missing every artifact that makes kernel source buildable. No Makefile at the root. No scripts/ directory. No .config, no defconfig, no toolchain definitions.…

If you're holding a piece of industrial IoT hardware or a consumer router and wondering whether the vendor is actually honouring the GPL, the only way to know for sure is to open it up and look. Not at the marketing slicks. Not at the shrink-wrap license. At the firmware. At the build scripts. At the exact kernel configuration that shipped on the device. I've spent the better part of a decade doing exactly this—tearing down embedded Linux products, diffing kernel sources, and catching the shortcuts that manufacturers hope nobody will notice. This is a concrete, step-by-step audit methodology that moves from physical inspection to filesystem forensics, and it ends with a clear verdict: compliant, or not. Why a GPL Audit Matters for Industrial and Consumer Devices Embedded Linux is…