Every time you pick up a router, a smart camera, or an Android phone, you’re holding a box full of Linux code. The GPL—the license that covers the kernel and a heap of other core components—says you have a right to the source code that makes that box tick. Not a stripped-down tarball. Not a dead link. The exact, buildable source that produced the firmware running on your device. But plenty of manufacturers ship products and quietly ignore those obligations. A compliance audit is how you check whether they’ve actually given you what the license demands. This guide lays out the technical steps, from grabbing the vendor’s source drop to tearing apart binaries and testing whether the code really builds the firmware you’re holding.
What the GPL Actually Requires
Before you start pulling apart firmware images, you need to know what you’re looking for. The GPL covers every GPL-licensed component baked into the device’s firmware—usually the Linux kernel, but also BusyBox, U-Boot, the GNU C Library, and dozens of other packages. Under GPLv2, the vendor must hand over the complete corresponding source: the exact code used to build the binaries, plus any modifications, build scripts, and configuration files. GPLv3 goes further and demands installation information so you can actually deploy your modified version on the same hardware.
One of the most common tricks is incomplete source. A vendor might toss you a vanilla kernel tarball from kernel.org and pretend that’s enough, while quietly shipping proprietary drivers, a modified bootloader, or a build system they cooked up in-house. Another classic move is locking the hardware so it refuses to run anything that isn’t signed with the vendor’s private key. Your job during an audit is to catch both: missing source and practical roadblocks that stop you from exercising the freedoms the license promises.
Step 1: Collect Everything the Vendor Offers
Start by grabbing whatever the manufacturer makes publicly available. Hit the support section of their website, dig through the open-source portal if they have one, and download every source archive, SDK, and license notice you can find. Save copies of any written offers for source code—GPLv2 allows a written offer valid for three years instead of shipping physical source, so note the date you request it and the exact URL or email address you use. If the only way to get source is by email, send that request right away and keep a record of every reply (or lack of one).
Don’t stop at the website. Check the device itself and its packaging. Look for a printed license notice, a URL, or a QR code. Many embedded gadgets bury GPL notices in a settings menu under “About” or “Legal Information.” Take photos or screenshots of everything you find. This initial paper trail is your baseline—you’ll compare it against what’s actually running on the hardware.
Step 2: Pull the Firmware and Map What’s Inside
To audit properly, you need access to the live binaries. If the device gives you SSH or a serial console, log in and start poking around. Run uname -a to grab the kernel version and build string. cat /proc/version will often spill compiler details. If there’s a package manager, list installed packages; if not, manually walk through /bin, /sbin, /lib, and /usr. A quick way to spot GPL binaries is to run strings /bin/busybox | grep GPL—license headers embedded in the binary will pop right up.
When the device is locked down tight, you’ll need to extract the firmware from a vendor update file. These are usually ZIP archives that contain a raw binary or something wrapped in a proprietary header. Feed the image to binwalk and let it sniff out embedded filesystems, kernels, and compressed chunks. Then use dd and unsquashfs or cpio to pull out the root filesystem. Once you’ve got the filesystem on your workstation, run a proper license scan with FOSSology or scancode-toolkit. These tools match file hashes and license texts against known open-source packages, which saves you hours of manual grepping.
Building a Bill of Materials
Make a spreadsheet. List every binary and library you find on the device: file path, apparent package name, version string if you can spot one, and the detected license. Then cross-reference that list against the source code the vendor provided. If the vendor’s source archive contains a different version of a package than what’s actually running on the device, that’s a red flag. The source has to correspond exactly to the shipped binaries—not a similar version, not a newer release, but the precise code that produced what you’re holding.
Step 3: Check That the Source Is Complete and Actually Builds
Having source code isn’t the same as having the right source code. You need to confirm that the provided tarball can be compiled into the exact binaries on the device. This is the hardest part of the audit, hands down. Try to recreate the vendor’s build environment. Clues often hide in the /proc/version string or in a toolchain bundled with the source. Follow any build instructions that came with the archive. If there are no instructions at all, that’s already a compliance gap—the GPL requires the scripts and build steps used to produce the binaries.
Run the build and compare the output. For the kernel, check the .config file against the running kernel’s configuration. You can often pull that from the device with zcat /proc/config.gz if the kernel was built with CONFIG_IKCONFIG. For userspace binaries, compare checksums or use diffoscope to dig into differences at the binary level. If the vendor’s source produces a binary that differs in functionality, size, or symbol table, the source is incomplete. Pay extra attention to loadable kernel modules. Vendors love to ship proprietary .ko files without source and claim they’re “separate works.” Under GPLv2, any module that links to the kernel must be licensed compatibly, and its source must be provided. No exceptions.
Derivative Works and Scripts
Embedded devices lean heavily on shell scripts, init scripts, and config files that tie GPL components together. These scripts are often derivative works of the GPL programs they invoke, especially when they’re tightly integrated and call GPL binaries in a specific, non-trivial sequence to implement core device behavior. Audit the /etc/init.d directory and any custom startup sequences. If the vendor didn’t release these scripts, they may be holding back required source. Don’t let them hand-wave it away as “just glue code.”
Step 4: Inspect the Bootloader and Installation Path
The bootloader is a compliance choke point. U-Boot, GRUB, and RedBoot are all GPL-licensed and show up in countless embedded devices. Extract the bootloader binary from a firmware update or, if you have the tools, read it straight from flash memory with a hardware programmer. Check whether the vendor provided the corresponding source, including any board-specific modifications. For devices that use GPLv3 components, the vendor also owes you “Installation Information”—the data and procedures needed to install a modified version of the software on that exact hardware. That includes cryptographic signing keys if the bootloader refuses to boot unsigned images.
Test the installation procedure yourself. Build a modified firmware image using the vendor’s source and try to flash it onto the device. If the device rejects the image because of signature verification, and the vendor hasn’t given you a way to disable that check or sign your own image, the device is violating GPLv3. Document every step: error messages, hardware identifiers, the exact flashing method you used. This evidence is what turns a suspicion into a solid finding.
Step 5: Write Up Your Findings and Contact the Vendor
An audit that sits in your notebook doesn’t help anyone. Compile a detailed report that lists every mismatch between the provided source and the device binaries. Include file names, version mismatches, missing build scripts, and any locked bootloader behavior. Stick to technical facts. Instead of “this violates the GPL,” say “the source archive for BusyBox v1.24.2 is missing the .config file and two custom applets found in the device binary.” Precision makes it harder for a vendor to brush you off.
Send the report to the vendor’s designated GPL compliance contact if one exists. If not, escalate to general counsel or the CEO. Give them a reasonable deadline—30 days is standard. Expect pushback. Many vendors will claim the missing code is proprietary or that you’re mistaken. Be ready to explain that proprietary code linked with GPL code creates a combined work that must be released under GPL. If the vendor stays silent or refuses to fix the gaps, you can report the violation to the copyright holders of the infringed code. Groups like the Software Freedom Conservancy and the Free Software Foundation have enforcement programs that can apply real pressure.
Common Pitfalls and How to Sidestep Them
One trap auditors fall into is assuming a source dump is complete just because it compiles. A vendor might hand you a tarball that builds a generic kernel but quietly omits the out-of-tree drivers for the Wi-Fi chipset. Always compare the modules list from the running device (lsmod) with the modules produced by the vendor’s build. Another pitfall is ignoring user-space GPL components. Even if the kernel source is spotless, the device might run a modified iptables or gdbserver without source. Scan the entire root filesystem—don’t stop at the kernel.
Time can work against you, too. Vendors sometimes release source months after a product launch, hoping interest fades. If you request source under GPLv2’s written offer provision, the vendor has to respond promptly. Note the date of your request and follow up relentlessly. And don’t overlook the toolchain. The GPL requires the complete source needed to build the binaries, which means the exact compiler, linker, and libraries. If the vendor used a custom GCC with proprietary patches, those patches have to be released.
FAQ
What if the vendor claims the missing code is a trade secret?
The GPL doesn’t carve out a trade-secret exception for derivative works. If the code is linked with GPL code or based on GPL code, it has to be released under the same license. Vendors can keep genuinely separate proprietary applications closed, but they can’t be tightly coupled with GPL components. A kernel module that’s required for basic device operation is almost certainly a derivative work and must be open.
How do I audit a device that uses signed firmware and refuses unsigned images?
First, check the GPL version. GPLv2 doesn’t explicitly require installation information, but GPLv3 does. If the device uses GPLv3 components, the vendor must provide signing keys or a way to bypass signature checks. For GPLv2-only devices, the legal requirement is murkier, but the spirit of the license demands that users can actually exercise their freedom to modify. Document the restriction and include it in your report. Some enforcement groups have successfully pushed vendors to unlock bootloaders even under GPLv2.
What tools are essential for a firmware audit?
Start with binwalk for firmware extraction, dd and unsquashfs for filesystem unpacking, and strings for quick license header checks. For deeper analysis, FOSSology and scancode-toolkit automate license and component detection. Use diffoscope to compare built binaries with shipped binaries. A JTAG debugger or serial console can be a lifesaver for locked-down devices. A hex editor helps you inspect raw firmware images for hidden strings or copyright notices.
What if the device uses a mix of GPLv2 and GPLv3 code?
Each component is governed by its own license. The vendor has to comply with GPLv2 for v2-licensed code and GPLv3 for v3-licensed code. That often means providing installation information for the v3 parts while the v2 parts only require source. In practice, the whole firmware image is usually treated under the stricter v3 terms to simplify compliance. Check the license notices for each package individually.
Auditing a device for GPL compliance is a technical pursuit grounded in principle. It takes patience, a methodical approach, and a willingness to push back against corporate obfuscation. By following these steps, you protect your own rights and help build a culture of accountability in the embedded Linux industry.