Why GPL Audits Matter for Embedded Hardware
When a manufacturer ships a router, camera, or IoT gadget running Linux or BusyBox, the GPL says they have to hand over the source code. But in practice, that obligation gets ignored more often than not. I’ve spent years cracking open consumer electronics, and the pattern is always the same: a sticker with a URL that leads nowhere, or a tarball that’s missing half the build scripts. A proper audit isn’t just about checking a box—it’s about holding companies accountable when they treat open-source like a free lunch. This guide lays out the technical steps to inspect firmware, spot GPL-covered binaries, and push back with a request that actually sticks.
Pre-Audit Preparation: Tools and Legal Context
Before you even power on the device, get your toolkit sorted. A Linux workstation with binwalk, strings, and a hex editor is the bare minimum. I’d also keep a UART-to-USB adapter handy for serial console access, plus a multimeter and maybe a logic analyzer if the bootloader is locked down. On the legal side, remember that the GPLv2 and GPLv3 give you the right to source code for any binary you’ve legally obtained—whether you bought the device or just downloaded a firmware update. The audit itself is a technical exercise, but every step you take should be timestamped and documented. That paper trail turns a polite email into a compliance request that’s hard to ignore.
Step 1: Firmware Acquisition and Static Analysis
First, get your hands on the firmware. If the manufacturer offers a downloadable update, grab it and start there. Otherwise, you’ll need to dump the flash chip directly using a programmer like Flashrom and a clip. Once you have the binary, run binwalk -Me firmware.bin to unpack filesystems, compressed archives, and kernel images. Look for SquashFS, JFFS2, or YAFFS—these are the usual suspects for root filesystems. Mount the extracted filesystem and start hunting for ELF binaries: find . -type f -exec file {} \; | grep ELF. Then, for each binary, run strings and grep for GPL references, copyright notices, or kernel symbol strings. Pay close attention to /bin, /sbin, /usr/bin, and /lib—that’s where the GPL-covered code usually lives.
Step 2: Identifying GPL Components in Kernel and User Space
The Linux kernel itself is GPLv2, so its presence alone triggers obligations. Check the firmware for a kernel image—zImage, uImage, or vmlinuz—and extract the config if it’s embedded (/proc/config.gz on a running device, or use extract-ikconfig). That config tells you which GPL-licensed drivers and modules are compiled in. In user space, common GPL binaries include BusyBox, GNU Coreutils, Samba, and various networking tools. But don’t stop at the obvious—proprietary applications often link against GPL libraries like libgcc_s.so or libstdc++.so, which can create a license conflict. Use readelf -d to check dynamic linking, and modinfo on kernel modules to see their license tags. A module that claims “proprietary” but uses GPL-only symbols is a red flag.
Step 3: Dynamic Analysis and Runtime Verification
Static analysis gives you a list of suspects, but dynamic analysis confirms the crime. Boot the device and get shell access—UART is the most reliable, but SSH or a debug interface might work too. Run ps to see running processes and lsmod for loaded kernel modules. Check /proc/kallsyms for exported GPL-only symbols and cross-reference with the modules you found. Use lsof to map which libraries are linked to each process. If a proprietary app is dynamically linked to libgcc_s.so or libstdc++.so, that’s a strong indicator of a license conflict. Also, watch for obfuscation tricks: stripped symbol tables, encrypted firmware, or signed bootloaders that block modified kernels—a practice called Tivoization. Compare the running kernel’s checksum with the one in the firmware update; a mismatch often means a locked bootloader. Check for CONFIG_MODULE_SIG_FORCE in the kernel config. If it’s enabled, only signed modules load, which can restrict your right to modify GPL code. Document these restrictions carefully—they matter for GPLv3 compliance but aren’t prohibited under GPLv2.
Step 4: Verifying Source Code Availability
Once you’ve mapped the GPL-covered components, check if the manufacturer actually provides the corresponding source. Look for a written offer in the device manual, on the packaging, or in the firmware’s /usr/share/doc directory. The GPL requires that the offer be valid for at least three years and accessible to any third party, not just the original buyer. If a URL is listed, download the source and try to build it. Use diff and md5sum to compare the resulting binary with what’s on the device. Incomplete source is a common violation—missing build scripts, modified files without patches, or omitted toolchain information. If the source doesn’t compile to the exact binary, the manufacturer hasn’t met their obligations.
Step 5: Documenting Findings and Requesting Source
Now, turn your notes into a formal audit report. For each binary, record the file path, the GPL component it matches, the license version, and whether source is available. Include console logs, firmware hashes, and photographs of the device and its PCB. When you request source from the manufacturer, be specific: list the exact binaries and the GPL text that obligates them. Cite the copyright holders who have standing to enforce the license—this isn’t just a consumer complaint, it’s a copyright matter. If the manufacturer ignores the request, the report can be shared with organizations like the Software Freedom Conservancy, which enforces GPL compliance on behalf of Linux kernel developers.
Common Pitfalls and How to Avoid Them
One mistake I see a lot is assuming all open-source components are GPL. A device might use MIT, BSD, or Apache-licensed code, which have different requirements. Always verify the license text inside the source files. Another pitfall is relying solely on the manufacturer’s source offer. Some companies provide source that compiles to a different binary, omitting the proprietary modifications that actually run on the device. Always build the source yourself and compare. Finally, be aware of the legal distinction between GPLv2 and GPLv3. GPLv3 includes anti-Tivoization clauses and explicit patent grants, while GPLv2 does not. Misidentifying the version can weaken your compliance argument.
FAQ: GPL Compliance Audits
What if the device uses a signed bootloader that prevents me from running modified code?
Under GPLv2, this is not a violation, though it frustrates the spirit of the license. Under GPLv3, the manufacturer must provide installation information so you can deploy modified versions. Check which GPL version applies to each component. If the kernel is GPLv2 only, Tivoization is technically allowed, but you can still request the signing keys as part of the corresponding source for GPLv3 user-space tools.
How do I handle a device that uses proprietary kernel modules linked to GPL symbols?
This is a gray area. The Linux kernel community generally considers proprietary modules that use GPL-only exported symbols to be derivative works, thus requiring full source release. However, legal interpretations vary. Document the exact symbols used (from /proc/kallsyms) and the module’s license tag (often visible in modinfo). If the module declares a non-GPL license but uses GPL-only symbols, that’s a strong indicator of a violation.
Can I audit a device without opening it or voiding the warranty?
Sometimes. If the device provides a firmware update file on the manufacturer’s website, you can perform a static analysis without physical access. Network-based dynamic analysis is also possible if you can gain shell access via SSH or a debug interface. However, for a thorough audit, physical access is often necessary to dump the flash chip and access the serial console. Check local laws regarding reverse engineering and warranty voiding; in many jurisdictions, opening a device for interoperability analysis is protected.
What should I do if the manufacturer’s source code is incomplete?
First, attempt to build the source exactly as provided. Document any missing files, broken build scripts, or absent toolchain components. Then, send a detailed request to the manufacturer’s designated GPL compliance contact, specifying what is missing and why it violates the license. If they fail to respond, escalate to the copyright holders of the GPL components. Organizations like gpl-violations.org have successfully enforced compliance through legal action in Europe.