By Arjun Mehta, gpl-devices.org Most engineers I talk to assume the GPL is a checkbox. Release the kernel source, slap a tarball on a website, and you’re done. But when you actually sit down and audit a device — especially a router or IoT gateway running a Linux-based firmware — you quickly realize that compliance is more about traceability, build integrity, and complete corresponding source than it is about intention. I’ve performed dozens of these audits, and I can tell you: the gap between what a company thinks it ships and what the GPL actually requires is often alarmingly wide. This guide is not a legal opinion. It’s a principled, engineering-level process for verifying whether a device respects the freedoms guaranteed by the GNU General Public License. If you’re a…

Buying a Linux-powered gadget isn't just a transaction—it's a handshake with the developers whose code makes the thing work. The GNU General Public License says that if you ship a product with GPL-covered code inside, you have to hand over the corresponding source when someone asks. Plenty of manufacturers still don't bother. I've spent years tearing down firmware and chasing vendors, and along the way I've put together a method that works. This isn't about blame. It's about keeping the open-source world honest, one device at a time. Understanding the GPL's Core Requirement The GPL isn't anti-business—it's pro-freedom. Under GPLv2, the variant you'll find in most embedded Linux boxes, distributing binaries means you also have to offer the complete, corresponding source that produced them. That includes scripts, patches, and any…

"Open source" carries real ethical weight among engineers and tinkerers. It signals a commitment to transparency, collaborative improvement, and user sovereignty. But the movement has matured, and a distinct fork has appeared in its philosophy: open source software on one side, open source hardware on the other. We habitually lump them together under a single banner of shared digital ideals. That's a mistake. The differences aren't superficial. They're rooted in the physics of atoms versus bits, in the economics of fabrication versus distribution, and in the legal frameworks that govern each. My aim here is to dissect these two paradigms with the precision they deserve. The physical reality of hardware: copper traces and silicon packages demand a different open source logic than lines of code. The Core of the Fork:…

Anyone who's spent serious time with open source software knows that particular buzz of liberation. You pull down a library, skim the source, tweak a config, recompile, and you're rolling. The only real barriers are a text editor and a compiler. The community ticks along on GitHub, GitLab, or some self-hosted Gitea box, and collaboration feels almost weightless. But the moment you swap a .c file for a .kicad_pcb file, the ground shifts under your feet. The chatter pivots from merge requests to procurement spreadsheets. This isn't just a tooling hiccup—it's a fundamental fork in what "open" even means once atoms elbow their way into a world built for bits. Defining the Terms with Precision Open source software (OSS) stands on a legal and cultural foundation that's been poured and…

I first bumped into the term “open source” through software. The idea that anyone could pick apart a codebase, poke around, and rebuild it struck me as a genuine shift—not just in how we make digital tools, but in who gets to have a say. Naturally, when I started tinkering with open source hardware, I assumed the same principles would carry over. They don’t. Not really. The gulf between open source software and open source hardware isn’t just about trading ones and zeros for copper and fiberglass. It’s embedded in the licensing, the money, the factory floor, and the stubborn physics of real-world stuff. I want to walk through that gap properly. Not as an abstract debate, but as something that bites every time you try to take a beautiful…

I still remember cracking open a broken handheld radio when I was twelve. My toolkit: a borrowed multimeter and a photocopied service manual my uncle had saved from his engineering college days. The schematic inside wasn't just a drawing—it was a map. It showed me where the signal entered, how it got filtered and amplified, and where it finally left for the speaker. Without it, I would have been jabbing blindly at a green board covered in cryptic labels. That afternoon planted a conviction that has only hardened over twenty-plus years of working with hardware: manufacturers should publish their schematics. Not as an afterthought, not locked behind a restrictive NDA, but openly and by default. The Schematic as a First-Class Citizen When I talk about schematics, I mean the symbolic…

Richard Stallman wrote the first GPL in 1989, and the thing still shapes how we build connected hardware. I’ve been designing embedded Linux devices for ten years, and if there’s one thing I’ve absorbed, it’s this: GPL compliance is not something you bolt on before shipping. It’s a design constraint. It belongs in the bill of materials, the build system, and the conversations you have with your supply chain before you’ve even settled on a processor. This piece walks through the whole process of putting together a GPL-compliant IoT appliance—bootloader choice, kernel configuration, userspace components, how to actually hand over source code, and the hardware gotchas that catch otherwise careful teams off guard. Understanding Which Licenses Actually Apply An IoT device is a stack of software layers, each with its…

Most IoT devices arrive as locked boxes. The firmware might lean on Linux, BusyBox, and a hundred other GPL-licensed bits, but the manufacturer hands you no source, no toolchain, and no way to change what you bought. This isn't just sloppy engineering—it's a licence violation. Putting together a GPL-compliant IoT device, whether from scratch or by reworking an existing design, is a quiet act of technical self-respect. Here I'll walk through the architecture calls, the bill of materials, and the compliance plumbing you need to do it right. Why GPL Compliance in Embedded Systems Is Harder Than It Looks Desktop and server software have tidy ways to ship source code. Embedded devices bring constraints that fight the GPL's demands every step of the way: tiny flash storage, locked bootloaders, proprietary…

An open development board ready for embedded Linux and GPL compliance work. Building an IoT device that respects the GNU General Public License isn't just about ticking a legal box. It's a quiet stand on how we choose to share technology. I've been designing connected hardware for years, and the moment a Linux kernel or GPL-licensed userspace lands inside your firmware, you've made a promise to the people who use your device. This piece walks through the hardware and software architecture calls, how to shape your build system, and the physical side of delivering source code—all from an engineer who treats compliance as a feature, not a headache. Defining the GPL Boundary in an Embedded System Most IoT devices juggle a bootloader, a kernel, and a root filesystem. The GPL…

The community tends to pop a cork when a hardware vendor tosses open-source license stickers on their board schematics and leaves it at that. I’ve been there myself—raising a glass to what sure looked like another win for openness. Then I actually boot the device and smack straight into a proprietary bootloader, standing guard like some mute bouncer. The good mood evaporates. If the board is open, why is the very first code that runs on it locked inside a binary blob? This isn’t a minor paperwork slip. It’s a foundational crack that empties the whole open-hardware promise of meaning. I’m Arjun Mehta. My work sits at the ugly crossroads of firmware security and hardware design. I’ve spent years peeling apart boot sequences, auditing silicon init code, and watching one…