Buy a router, a smart TV, or an industrial controller that runs Linux, and you’re getting more than a box of electronics. You’re also getting software covered by the GNU General Public License — the GPL. That license says you can ask for the source code, study it, change it, and share your changes. Plenty of manufacturers, though, either ignore that obligation or make it needlessly hard to fulfill. Auditing a device for GPL compliance is part forensics, part stubbornness, and part standing up for the idea that software freedom actually matters. Here’s a practical way to do it.
Understanding the GPL’s Core Requirements
Before you crack open a case or dump firmware, get straight on what the GPL actually asks for. GPLv2 — still the most common version in embedded gear — says anyone distributing GPL binaries has to provide the complete corresponding source code. That means the kernel, sure, but also the libraries, the scripts that drive compilation, and the install helpers. The source has to be the “preferred form for modification.” No obfuscated dumps, no tarballs with the build glue stripped out. If the device pulls in GPLv3 components, you’ve got extra requirements around installation info and anti-lockdown clauses to think about.
The core idea is straightforward: you get the binary, you get the source. A written offer to send source on request is legally fine, as long as it’s good for three years and doesn’t slap you with unreasonable costs. In practice, most vendors just put source archives on a website — or say they do. Your audit checks whether those archives are complete and actually buildable.
Step 1: Identify the Device and Its Software Stack
Start by pinning down exactly what you’re looking at. Grab the model number, hardware revision, and firmware version. You’ll usually find these on a sticker or inside the admin interface. If the device gives you a serial console or SSH, log in and run uname -a to catch the kernel version, then cat /proc/version to see compiler details. Look for /proc/config.gz or a /boot/config-* file — that kernel configuration is part of the corresponding source and has to be handed over.
Next, take stock of the GPL-licensed pieces. If the device has opkg or dpkg, use them. Otherwise, poke around /lib, /usr/lib, and /bin manually. Watch for shared libraries (.so files) and executables. readelf and strings can pull out copyright lines and license hints. BusyBox, uClibc, glibc, and the usual networking tools deserve extra attention — they’re almost always GPL’d and frequently mishandled.
Step 2: Locate the Source Code Offer
Check the box, the manual, and the vendor’s website for a source offer. The GPL lets a written offer travel with the binary, but most companies just put up a download link. If you find a link, pull the archive right away. If all you get is a written offer, request the source in writing — email works — and note the date. The vendor has a legal duty to respond.
Look at the downloaded archive with a skeptical eye. Is it one giant tarball or a set of packages? Does it include a top-level README that explains the build? The archive should hold the exact source for the firmware version running on your device, not something close or a newer release. Cross-check the kernel version and library versions you inventoried against what’s in the source.
Common Red Flags in Source Archives
- Missing build scripts: Raw source with no Makefiles, config files, or instructions to produce the binary.
- Stripped or obfuscated code: Comments gone, variable names mangled, or preprocessor output instead of original source.
- Incomplete components: Kernel source is there, but user-space GPL bits like iptables or ntpd are absent.
- Mismatched versions: Source for a different kernel version or library release than what’s actually on the device.
Step 3: Extract and Analyze the Firmware
When the vendor’s source offer is missing or looks dodgy, you’ll need to pull the firmware straight from the device. This part demands care — you can void warranties or turn the thing into a brick. Start by researching the hardware platform. FCC IDs on the label often lead to internal photos and chipset details in the FCC database. Figure out the flash memory type (NOR, NAND, eMMC) and any accessible interfaces like JTAG, UART, or USB.
For devices where you can reach the storage, dump the firmware with dd over a serial link, or desolder the flash chip and read it with an external programmer. Once you have a binary image, feed it to binwalk to spot file systems, compressed blobs, and known magic bytes. Extract the root file system with unsquashfs, jefferson (for JFFS2), or whatever fits. Now you can inspect the binaries directly and compare them against the vendor’s source archive.
Verifying Binary-Source Correspondence
This is the real test. For each GPL binary, you need to see if the provided source can build an identical copy. That means setting up a build environment that mirrors the original — same toolchain, same config, same flags. Pull toolchain info from the binary with readelf -p .comment or by checking the ELF notes section. Replicate the build, then compare the result against the original using sha256sum or a byte-by-byte diff.
Mismatches often come from missing config files, proprietary modules linked into GPL code, or post-compilation stripping. If the vendor’s source builds a different binary, document exactly what’s off. A common violation: proprietary kernel modules that taint the kernel. Check for that with modinfo or by hunting for “Tainted” flags in kernel logs.
Step 4: Check for License Notices and Attribution
GPL compliance isn’t only about source code — it’s also about giving credit where it’s due. The license says each copy of the program should carry copyright notices and a reference to the GPL text. On embedded devices, you’ll often find this in an “About” or “Legal” menu, or buried in a printed manual. If the device has a screen, click through the UI. If it’s headless, look for a COPYING or LICENSE file in the root file system.
Check for the actual GPL text — GPLv2 or GPLv3, depending on what components are inside. Some vendors slip in only the LGPL or a vague open-source blurb. Make sure the copyright notices point to the real authors. For the Linux kernel, you should see a notice that mentions the Free Software Foundation and the kernel developers, not just the device maker.
Step 5: Document and Report Findings
Your audit should end with a clear, fact-based report. Organize it with sections for device identification, source offer evaluation, firmware extraction method, binary-source comparison results, and license notice review. Include command outputs, file hashes, and screenshots where they help. Stay away from legal conclusions — stick to technical observations. Say “The provided source archive lacks the build script for the kernel module example.ko” instead of “The vendor violates GPLv2 Section 3.”
If you spot compliance gaps, think about telling the vendor first. A lot of problems come from oversight, not bad intent, and a solid technical report can push them to release a fix. If the vendor ignores you or pushes back, you can escalate to the copyright holders of the affected GPL components. Groups like the Software Freedom Conservancy and gpl-violations.org have enforcement experience and may pick up cases backed by strong evidence.
Special Considerations for Different Device Classes
Consumer Routers and IoT Devices
These are the most common targets. They usually run a busybox-based Linux with a custom web interface. Manufacturers often ship ancient kernel versions alongside binary-only wireless drivers, which taints the kernel. Check for the wireless driver source — if it’s a proprietary module, the vendor has to provide source for any GPL code it links against, but not the driver itself. The line between GPL and proprietary code needs to be clear and documented.
Android-Based Devices
Android devices use the Linux kernel under GPLv2, but the userspace is mostly Apache-licensed. Keep your audit focused on the kernel and any GPL libraries tucked into the system image. Many vendors ship modified kernels with locked bootloaders, which can raise GPLv2 Section 6 concerns if the device blocks execution of modified versions. Extract the boot image and compare the kernel binary against the vendor’s published source.
Industrial and Medical Equipment
These often run real-time Linux or specialized distros. The audit process is similar, but access may be limited by safety interlocks or proprietary interfaces. Try non-invasive methods first — network scanning, SNMP queries, or analyzing update files pulled from the vendor’s support portal. If you can get physical access, look for debug headers on the board. Document any encryption or signing mechanisms that prevent firmware modification; they can complicate compliance checks.
Tools of the Trade
A well-equipped auditor leans on a set of open-source utilities. Here are the essentials:
- binwalk: Firmware analysis and extraction tool that spots file signatures and pulls out embedded file systems.
- readelf/objdump: Binutils programs for examining ELF binaries, pulling symbol tables, and disassembling code.
- strings: Grabs printable strings from binaries — handy for finding copyright notices and build paths.
- dd/rescue: For raw device imaging and memory dumping.
- hexdump/xxd: Hex viewers for manual inspection of binary structures.
- diffoscope: Deep comparison tool that can recursively unpack archives and highlight differences.
- tcpdump/Wireshark: Network analysis to capture firmware downloads or device chatter.
Build a reference environment in a VM or container with common cross-compilation toolchains. Keep detailed logs of every command you run — reproducibility is what makes an audit credible.
FAQ: GPL Compliance Audits
What if the vendor provides source code but it’s for a different firmware version?
This happens a lot. The GPL requires source that matches the binaries shipped, exactly. If the vendor only offers source for a newer or older version, they’re not in compliance. You can ask for the correct version, and if they don’t deliver, document the mismatch with version strings and build dates. That evidence is often enough for enforcement actions.
Do I need to be a copyright holder to enforce the GPL?
No, but it helps. Anyone who receives GPL-licensed software can demand source from the distributor. But only copyright holders can sue for infringement. As an auditor, your job is to gather evidence and report it to people who can act — either the vendor directly or the copyright holders of the violated components.
How can I tell if a binary is statically linked to a GPL library?
Use readelf -d to check dynamic linking. If the binary has no dynamic section or lists only non-GPL libraries, but strings shows GPL-licensed function names or copyright strings, it may be statically linked. You can also disassemble the binary and look for library code embedded directly. Static linking to a GPL library requires the whole program to be GPL-licensed, so this is a serious violation if the source isn’t provided.
What about devices that download GPL components after purchase?
If the device fetches GPL-licensed software from a network source after you buy it, the distributor still has to provide source for those components. The obligation kicks in at the moment of distribution, which includes making the software available for download. Check the device’s update mechanism and any cloud-dependent features — the vendor should offer source for all GPL code the device runs, no matter how it arrives.
Conclusion
Auditing a device for GPL compliance is a technical task with real consequences. It’s about making manufacturers answer to the communities whose work they build on. By following a structured path — identifying the software stack, evaluating source offers, extracting firmware, verifying binary correspondence, and documenting what you find — you push for transparency and respect for user freedoms. The tools are free, the methods are proven, and the principles are worth defending. Every compliant device strengthens the ecosystem; every audit moves us closer to that goal.