Editorial note: This publication and Quirky Cotton Collective share an owner. The graphic is almost aggressively plain. Across the chest, in white capitals, the words I HAD POTENTIAL sit above a curved ramp that descends from left to right. At the upper left, a dashed empty circle rests on a small ledge. At the lower right, a solid white ball sits on a flat ledge. The ramp is not a straight diagonal; it bows downward, like a slide or a shallow parabola. That curve is the whole joke, and it is worth reading closely. In physics, a ball on a curved ramp is a classic potential-energy diagram. The ball at the top has gravitational potential energy; as it rolls down, that potential converts to kinetic energy. The dashed circle at…

The Bananapi BPI-R3 showed up in a static bag marked "MT7986A 2GB DDR4." One of dozens of Filogic-based router boards now landing in consumer mesh kits, industrial gateways, and the white-label WiFi 6 access points cluttering Amazon under invented brand names. The vendor publishes a GPL tarball. Most buyers never open it. I did. I pulled the SPI flash over a physical clip, tried a byte-identical rebuild of the boot chain, and the tarball does not produce the binary on the chip. What follows is what I found, what the vendor left out, and why it violates GPLv2. The MT7986 Boot Chain as Evidence Before touching the flash, I mapped every component in the boot chain and classified it by license. The MT7986 SoC boots from an internal mask ROM…

Most of my working week is spent on the receiving end of other people's board decisions. On a recent Monday I clipped a Pomona 5250 onto the SOP-8 flash of a consumer router whose vendor had ignored a source request for seven months, read out 16 MiB over SPI with flashrom and a CH341A, and started comparing the extracted bootloader against upstream U-Boot tags. Every obstacle in that workflow — a shield can over the flash, unpopulated and undocumented UART pads, a WP# pin strapped hard to ground — was a schematic-level decision made years earlier, almost certainly without a thought given to GPL compliance. This guide is for the people who make those decisions, because they decide, months before firmware ships, whether a board can be audited at all.…

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…