If you bought a gadget that runs Linux or any GPL-licensed code, you have a right to the source that built the binaries on it. Not a polite request, not a favor—a legal requirement. Yet plenty of manufacturers ship products with half-baked source drops, locked bootloaders, or sneaky proprietary kernel modules that spit in the face of the license. Whether you’re an independent auditor or a developer who just got burned by a vendor, you can check compliance methodically. This guide walks through a real, step-by-step audit process, mixing forensic-level technical checks with the legal backbone of copyleft.
What the GPL Actually Demands
Before you even pick up a screwdriver, get clear on what the license covers. The GPL requires “Corresponding Source”—not just a link to a random tarball, but all the source code, scripts, toolchain configurations, and instructions needed to generate, install, and run the object code on that specific device. If the kernel links against proprietary modules, those modules are likely derivative works and their source must be disclosed too. GPLv2, which still dominates embedded Linux, says the source must come on a “medium customarily used for software interchange.” GPLv3 tightens this further, explicitly demanding installation scripts and keys if the device uses signed bootloaders.
Many vendors misunderstand—or pretend to misunderstand—these obligations. They’ll toss an upstream kernel tarball over the wall and call it done. Your job is to prove otherwise.
Step 1: Inventory Every GPL Component on the Device
Start by mapping what’s actually running. Boot the device and get shell access if you can—serial console, SSH, or by dumping the firmware. Run lsmod to list loaded kernel modules. Check /usr/share/doc for license files. Use strings on binaries to hunt for copyright headers and GPL references. If the filesystem is locked down, pull the firmware image directly from flash with dd or a hardware programmer. You’re building a bill of materials: kernel, busybox, uClibc, proprietary drivers, firmware blobs, everything.
Pay extra attention to kernel modules. A module tagged “Proprietary” that calls symbols exported via EXPORT_SYMBOL_GPL is almost certainly a derivative work. The legal line can get fuzzy, but from an audit perspective, that’s a bright red flag. Note every instance.
Step 2: Chase Down the Written Offer
The GPL says the source offer must accompany the object code. That means it should be in the box, on the device’s interface, or in the manual. If you can’t find it, the vendor is already in violation. If you do find it, follow it exactly. Send a formal request—email, web form, whatever they specify—and log the date, method, and every response. Broken links and silence are common. Be persistent.
When source arrives, don’t just archive it. Compare the kernel version string from uname -a against what they sent. Look for board-specific patches, custom drivers, and build scripts. A generic upstream tarball without the vendor’s modifications is a compliance fail. If pieces are missing, write back and cite the specific GPL clauses they’re violating.
Step 3: Rebuild the Binary and Compare
Having source is step one. Proving it actually produces the binary on the device is where most audits get real. Set up a build environment that matches the target architecture—same cross-compiler, same kernel config, same build scripts. Grab the kernel config from /proc/config.gz if it’s available, or extract it from the kernel image. Compile the kernel and modules, then hash the results with sha256sum and compare byte-by-byte with vbindiff.
Mismatches often point to hidden proprietary blobs linked into the kernel or drivers. The GPL permits separate firmware binaries for auxiliary processors, but if that firmware is baked into a GPL driver or the kernel image itself, it likely needs source disclosure. Scan the build scripts for precompiled .o files that get linked in. Those are trouble.
Build Scripts and Toolchains: The Hidden Gotcha
Vendors love to ship source but “forget” the toolchain or the scripts that make it build. GPLv3 calls out “scripts used to control compilation and installation” explicitly. Even under GPLv2, that’s part of Corresponding Source. Dig through the provided package for Makefiles, defconfig files, and any custom build wrappers. If they used a proprietary toolchain, they either need to hand it over or give you a detailed recipe to get and configure a free equivalent.
Test the build in a clean environment. If it fails because of missing dependencies, wrong paths, or half-baked instructions, the source is incomplete. Document every failure. A classic dodge is providing source that builds a generic kernel but lacks the patches for the actual hardware, so the resulting binary is useless.
Step 4: Test Installation and Bootloader Freedom
A compliant device must let you run your modified version. That means the bootloader can’t be locked down with cryptographic keys that reject unsigned images. Get into the bootloader console—usually via serial during startup. U-Boot, Barebox, GRUB—whatever it is, look for commands to load an alternative kernel or rootfs.
If the bootloader is locked, the vendor is undermining the whole point of the GPL. Under GPLv3, it’s a direct violation. Under GPLv2, it’s a murkier area, but most copyright holders see it as a breach of the license’s intent. Try flashing a custom image. If the device bricks or refuses to boot, document that behavior. Some vendors go as far as blowing hardware fuses to permanently lock the bootloader—a deliberate anti-user move and a clear compliance failure.
Tivoization: When Hardware Says No
Tivoization—named after the TiVo DVR—uses hardware restrictions to block modified software. GPLv3 kills it outright, but plenty of devices still ship with GPLv2 code where the ban isn’t explicit. Regardless of version, the FSF considers it unethical. As an auditor, flag any device that uses signed bootloaders or similar mechanisms to stop user-modified code, even if the vendor hides behind a GPLv2 argument.
Step 5: Check License Notices and Attribution
The GPL requires that users get a copy of the license and proper copyright notices. Look on the device’s UI, printed manuals, and any included docs. The license text should be easy to find. Many embedded devices bury GPL notices in obscure menus or leave them out entirely. That’s a violation, even if source is available online.
Then examine the source packages themselves. Every source file should carry a clear copyright notice and a GPL reference. If the vendor stripped them, they’re in breach. Also scan for third-party GPL components that were incorporated without acknowledgment. Tools like grep and licensecheck can sweep source trees for license declarations.
Step 6: Write It Up and Take Action
An audit without a solid report is just a personal grudge. Create a detailed document listing every GPL component found, the corresponding source provided, and every discrepancy. Include checksums, build logs, and screenshots. If you uncover violations, you have a few paths. You can report the vendor to the copyright holders—often the FSF or Software Freedom Conservancy—who run enforcement programs and may pursue legal action.
You can also approach the vendor directly. Some companies genuinely don’t know they’re out of compliance and will fix things once you lay out the technical gaps. Give them a clear explanation of what’s missing and a reasonable timeline. If they stonewall or get hostile, public disclosure might be the next step. But be careful: always ground your claims in verifiable evidence.
Mistakes That Trip Up Auditors
Stopping at the tarball. Getting a source archive feels like a win, but if you don’t verify it’s complete, matches the binary, and actually builds, you’ve only done half the job.
Skipping build scripts and toolchains. Without the right build environment, the source is a paperweight. Always demand and test the full build system.
Ignoring license notices. Missing copyright and license headers are a common violation. Check both the device and the source code.
Accepting locked bootloaders. Even under GPLv2, a locked bootloader guts the license’s purpose. Flag it every time.
FAQ
What if the vendor provides source code but it doesn’t compile?
Incomplete or non-compilable source is a GPL violation. The license requires the “complete corresponding source code,” which includes all scripts, toolchains, and configurations needed to build the exact binary. If the provided source fails to compile, document the errors and request the missing pieces. If the vendor refuses, they’re in breach.
How do I handle proprietary kernel modules?
Proprietary kernel modules that link to GPL-licensed kernel code are generally considered derivative works and must be licensed under the GPL. The legal line is drawn at modules that only use “public” kernel interfaces. In practice, if a module uses symbols exported via EXPORT_SYMBOL_GPL, it’s likely a derivative work. Flag any proprietary modules and request their source. If the vendor claims they’re not GPL-licensed, ask for a detailed legal justification.
What if the device uses a locked bootloader?
A locked bootloader prevents users from installing modified software, which undermines the GPL’s purpose. Under GPLv3, this is explicitly prohibited. Under GPLv2, it’s a gray area, but many copyright holders consider it a violation of the license’s spirit. Document the restriction and report it to the copyright holders of the GPL components used in the device. They may choose to enforce their rights.
Can I audit a device without physical access?
Partial audits can be performed remotely if the vendor provides firmware images and source code online. However, physical access is often necessary to extract the actual binary from the device, verify bootloader behavior, and test installation of modified software. For a thorough audit, obtaining the hardware is strongly recommended.