What GPL Compliance Actually Means in the Embedded World
The GNU General Public License isn’t a polite request. When a vendor ships a Linux-based device—a router, a smart camera, an industrial controller—they’re legally on the hook to provide the source code for the GPL-licensed components they distribute. Yet in the embedded space, compliance is often an afterthought, buried under marketing deadlines and a deep-seated fear of opening up proprietary bits. This guide is for the engineers, tinkerers, and legally curious hackers who want to move past a company’s word and verify what’s really running inside a sealed box. We’ll walk through a concrete, repeatable audit process that starts with a shrink-wrapped product and ends with a documented compliance report.
The GPL’s core demand is straightforward: distribute a binary, and you must offer the complete corresponding source. For embedded Linux, that means the kernel, any GPL-licensed user-space tools, and the scripts or toolchain details needed to rebuild the exact firmware image. Groups like the Software Freedom Conservancy and the Free Software Foundation have championed these principles for years, but the gap between what’s written and what’s practiced is still a chasm. This article is about the hands-on steps to expose that gap.
Phase 1: Physical Recon and Chip Spotting
Before you plug anything in, the hardware itself has a lot to say. Crack open the enclosure—carefully. Note the screw types, any tamper-evident seals, and physical barriers to entry. Once you’re inside, your main targets are the System-on-Chip (SoC), the flash memory type, and any obvious serial console headers. A vendor that hides UART pads under a sticker or drowns a flash chip in epoxy is already telling you exactly how they feel about user modification.
Grab a high-res camera and photograph both sides of the PCB. Document every chip marking. For the SoC, a part number like “BCM5358” or “MT7621AT” instantly reveals the architecture and likely kernel version. For flash, you’re usually looking at SPI NOR (common in cheap routers) or eMMC/NAND (in higher-end Android-based gear). The flash type dictates your extraction strategy. Spot a standard 8-pin SPI flash? You’re in luck—a cheap SOIC-8 clip and a Raspberry Pi can dump the entire firmware. For eMMC or managed NAND, you might need to hunt down test points or fall back on software extraction methods.
Phase 2: Firmware Extraction—Getting the Bits Out
Your extraction method lives and dies by the hardware. If you’ve got physical access to a raw NAND or SPI flash chip, a programmer like a Dediprog or the open-source flashrom tool with a suitable FTDI-based adapter is the most direct path. For devices with accessible serial consoles (UART), interrupt the bootloader—usually U-Boot—and lean on its built-in memory dump commands. This is often the cleanest way to grab the kernel and root filesystem without touching a soldering iron. If the device is running a full OS and you can snag a root shell via an exposed debug interface or a known exploit, tools like dd can copy the mtdblock partitions directly.
Once you have a binary blob, the real work starts. Use binwalk to scan for magic bytes and map out the partition layout. A typical output will show a bootloader, a device tree blob (DTB), a compressed kernel image, and a root filesystem—often SquashFS or JFFS2. Extract each piece. The root filesystem is your main target for license analysis, but don’t sleep on the kernel. Many vendors ship a stock kernel but tack on proprietary loadable kernel modules (LKMs). The GPL’s stance on modules is a decades-old debate, but the kernel community’s view is blunt: if a module uses EXPORT_SYMBOL_GPL or weaves itself deep into kernel internals, it’s a derivative work and must be GPL-compatible. A tainted kernel flag (proprietary module loaded) is a glaring red flag.
Phase 3: Source Code Analysis and the Missing Pieces
With the root filesystem mounted locally, start by checking for a /usr/src directory or a source archive. A lot of vendors mistakenly think that tossing a partial kernel source tree onto the device checks the box. It doesn’t. The GPL demands the complete corresponding source—the exact version used to build the binary, including any vendor tweaks, build scripts, and configuration files. If the device uses BusyBox, check the busybox --help output for the version string, then verify that the vendor’s offered source matches that version exactly. A classic violation is handing over a pristine upstream tarball while the actual binary includes custom patches.
Next, inventory every GPL-licensed binary. Use readelf and strings to pull out copyright notices and license references. Cross-reference these against the provided source. Find a binary for iptables but no corresponding source? That’s a violation. Pay close attention to dynamically linked libraries. A proprietary application linked against libc.so.6 (LGPL) is generally fine, but if it links against a GPL library like libreadline, the whole application must be GPL-compatible. This is where vendors trip over themselves—they treat the GPL like a virus to be quarantined, and in doing so, they often create a legal mess.
Phase 4: The Build Verification Test
The ultimate proof of compliance is the ability to rebuild the firmware from the provided source and get a bit-for-bit identical binary. This is the standard the Software Freedom Conservancy uses in its enforcement actions. Set up a build environment that matches the vendor’s specified toolchain—often a specific version of GCC and binutils. If the vendor doesn’t provide the toolchain or build scripts, they’re already in violation. Run the build and compare the resulting kernel image and root filesystem against the extracted binaries. Differences in build timestamps are normal, but functional differences—missing features, different binary sizes—point to incomplete source.
For the kernel, zero in on the .config file. The vendor must provide the exact configuration they used. A common dodge is to hand over a defconfig that builds a generic kernel, while the actual device kernel includes proprietary drivers as modules. Check the extracted kernel’s /proc/config.gz (if available) or the IKCONFIG data embedded in the kernel image. Compare it line-by-line with the provided config. Missing options, especially those that enable custom hardware support, are a dead giveaway of a violation.
Phase 5: Documenting and Reporting Violations
Once you’ve gathered evidence, compile a clear, factual report. Steer clear of legal conclusions—stick to technical observations. For each violation, state the GPL-licensed binary, the missing source component, and the specific GPL clause (e.g., GPLv2 Section 3). Include the steps you took to attempt a rebuild and the discrepancies you hit. If you’re reporting to the vendor, give them a reasonable timeline to respond—30 days is standard. If they ignore you or come back with a non-compliant offer (like a source CD for a fee that exceeds the cost of distribution), escalate to the copyright holders of the violated code. Organizations like the Software Freedom Conservancy and the Free Software Foundation can offer guidance, but they act on behalf of copyright holders, not third-party auditors.
A word of caution: in some jurisdictions, the act of extracting firmware may run afoul of anti-circumvention laws, even if your intent is compliance verification. The GPL itself doesn’t override these laws, but the license’s implicit permission to modify the software often provides a defense. If you’re auditing a device you own, you’re on solid ground. If you’re auditing on behalf of a client, make sure you have written authorization to reverse-engineer the device.
Common Compliance Traps and How to Spot Them
The “Source Available on Request” Runaround
A written offer in the manual is valid under GPLv2 Section 3(b), but it has to be valid for three years and the source must be available to any third party, not just the original buyer. When you request the source, the vendor must provide it on a medium customarily used for software interchange—a download link is fine, a physical CD is fine, but a link that expires after 48 hours is not. Test the offer. If the vendor demands a fee, it can’t be more than the cost of physically performing the distribution. A $50 “handling fee” for a download link is a violation, plain and simple.
The “Userspace Only” Dodge
Some vendors release the source for BusyBox and other userspace components but hold back the kernel source, claiming it’s “unmodified.” The GPL makes no such distinction. If they distribute a kernel binary, they must provide the complete corresponding source for that exact kernel, including any patches, configuration, and build scripts. A link to kernel.org doesn’t cut it.
The Tivoization Trap
Devices that use signed bootloaders to block modified firmware from running are engaging in “Tivoization.” While this isn’t a direct GPL violation under GPLv2, it completely guts the spirit of the license. GPLv3 explicitly prohibits Tivoization, but plenty of embedded devices still use GPLv2 components. If a vendor uses a GPLv3-licensed program (like Samba 3 or later) and locks down the hardware, that is a direct violation. Check the license versions of all components.
FAQ: GPL Compliance Audits in Practice
What’s the first thing I should check when I get a device?
Look for a written offer for source code in the documentation or on the packaging. If it’s missing, the vendor is already in violation of GPLv2 Section 3. If an offer is there, note the contact method and the date—it has to be valid for three years from the date of distribution. Then, request the source code immediately to start the clock on the vendor’s response time.
How do I know if a binary blob in the firmware is a GPL violation?
Not every binary blob is a violation. Proprietary applications that run in user-space and link only against LGPL libraries (like glibc) are generally permitted. The violation happens when a proprietary program links to a GPL-licensed library or when a GPL-licensed program (like the kernel) includes proprietary code. Use readelf -d to check dynamic linking, and examine kernel module licenses with modinfo. A kernel module that reports “license=Proprietary” while using GPL-only symbols is a clear violation.
What if the vendor provides source code, but it won’t compile?
Incomplete or non-compilable source is a GPL violation. The GPL requires the “complete corresponding source code,” defined as “all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work.” If the provided source lacks build scripts, depends on proprietary toolchains, or produces a binary that’s functionally different from the shipped version, the vendor isn’t compliant. Document the exact build errors and missing dependencies.
What’s the best tool for scanning a firmware image for GPL components?
binwalk is the standard for initial analysis and extraction. For deeper license auditing, the Binary Analysis Tool (BAT) and FOSSology can scan extracted filesystems for license texts and copyright notices. But no tool replaces manual verification. Automated scanners miss dynamically linked libraries, kernel modules, and components where the license is embedded in the binary rather than a separate file. Always pair automated scanning with manual inspection of key binaries.
Building a Compliance Database
Each audit you complete generates valuable data. Start a structured log of devices, their SoCs, wireless chipsets, bootloaders, kernel versions, and compliance status. Over time, patterns emerge. You’ll notice that certain vendors consistently violate the GPL by withholding kernel source, while others are meticulous about compliance. This database becomes a powerful resource for the community—a factual, evidence-based record that cuts through marketing fluff. It also helps you identify which chipsets have open-source drivers and which are locked behind proprietary blobs, guiding future hardware purchases and recommendations.
The goal isn’t to punish vendors. It’s to nudge the industry toward genuine open-source collaboration. When a vendor realizes their device will be publicly audited and the results shared, compliance stops being a legal headache and starts being a competitive edge. The next step after an audit is often a deeper dive into the device’s security posture—a topic we’ll tackle in a follow-up article on firmware vulnerability assessment.