Buying a Linux-powered gadget isn’t just a transaction—it’s a handshake with the developers whose code makes the thing work. The GNU General Public License says that if you ship a product with GPL-covered code inside, you have to hand over the corresponding source when someone asks. Plenty of manufacturers still don’t bother. I’ve spent years tearing down firmware and chasing vendors, and along the way I’ve put together a method that works. This isn’t about blame. It’s about keeping the open-source world honest, one device at a time.
Understanding the GPL’s Core Requirement
The GPL isn’t anti-business—it’s pro-freedom. Under GPLv2, the variant you’ll find in most embedded Linux boxes, distributing binaries means you also have to offer the complete, corresponding source that produced them. That includes scripts, patches, and any toolchain pieces needed to reproduce the executable. The rule kicks in whether you sell the gadget, give it away, or fold it into a bigger product. “We didn’t know” won’t fly—courts keep reminding distributors they’re on the hook for their whole supply chain.
Before you get into technical checks, pin down which GPL version applies. A lot of devices mix GPLv2-only and GPLv2-or-later components. The Linux kernel itself is GPLv2-only, full stop, so later terms can’t override it. That matters because GPLv3 tacks on patent grants and anti-tivoization language, but for anything kernel-based, v2 sets the baseline. Your audit has to confirm that the source you’re offered matches the exact binary on the device—not a cousin release, not a pristine upstream tarball with no local changes.
Phase 1: Gathering Evidence
Begin with the physical box. Write down the model, hardware revision, and firmware version—usually on a sticker or buried in a settings screen. Every variant can ship different binaries, so sloppy labelling will trip you up later. If the device exposes a serial console, hook up a USB-to-TTL adapter (3.3 V logic is the safe bet). Boot logs often spill the kernel version, build date, and sometimes the compiler flags. Grab that output raw—it’s the first real breadcrumb in your paper trail.
Extracting Firmware Images
When a vendor offers firmware downloads on their site, snag the newest version plus any older releases. Checksum everything and stash it. For gear that updates over the air, you may need to intercept the traffic with a proxy or a packet sniffer. mitmproxy or Wireshark are your friends here. Once you’ve got the firmware file, start unpacking. Common wraps are SquashFS, JFFS2, or UBIFS. Feed the file to binwalk and let it hunt for embedded filesystems—it’ll carve them out automatically.
Inside the filesystem, look for the kernel image (often zImage or uImage) and the root filesystem. Hunt down a /proc/version signature or the kernel’s banner string—that gives you the exact version and the compiler that was used. Cross-check this against the source the vendor claims to provide. A mismatch here waves a red flag: they may have dumped source for an entirely different kernel tree.
Phase 2: Analyzing the Vendor’s Source Offer
Find the compliance offer. It might be a note packed in the box, a link on the product page, or a reply to a plain email request. The GPL wants a written offer that’s good for at least three years—not a fleeting web link that might vanish next quarter. If the vendor points you to a generic open-source page, squint hard. Does it name the exact product and firmware version? Or is it one fat tarball covering “all our products”? That second option almost never satisfies the corresponding source requirement.
Verifying Completeness
Take the offered source and stack it against the binary. A fast smoke test: pull the kernel configuration from the running device or firmware image. Many kernels keep /proc/config.gz handy; you can also yank it from the image with scripts/extract-ikconfig out of the kernel source. Diff that config against the one in the vendor’s source drop. Missing drivers, tweaked options, extra debug flags—all signs the source isn’t whole. Also hunt for out-of-tree kernel modules; the vendor has to supply the build machinery and source for every module that ships on the device.
User-space bits aren’t optional. If the device runs BusyBox, the source must line up with the exact version and config. Run strings on the BusyBox binary to fish out version strings, then diff the vendor’s config against the default for that release. Same drill for other GPL libraries—glibc, libstdc++, you name it. A tired shortcut is vendors handing over upstream tarballs with none of their own patches. That’s non-compliant if they’ve touched the code at all.
Testing Build Reproducibility
The real litmus test: can you rebuild the binaries from the source they gave you? Spin up a build environment that mirrors the vendor’s toolchain. If they didn’t disclose the toolchain, ask for it outright—under GPLv2, the “scripts used to control compilation and installation” are part of the source. Try a build. Even if the output isn’t bit-for-bit identical (timestamps and linker quirks can shift things), it should behave the same. Compilation failures out of the gate usually mean missing pieces or incomplete source.
Phase 3: Documenting Findings and Taking Action
Your audit isn’t done until you’ve written up every gap. Build a report that ties each finding to a concrete GPL requirement. Something like: “Kernel version 4.9.84 on device shows CONFIG_FOO=y, but supplied source has CONFIG_FOO not set, violating GPLv2 §3(a).” Attach console dumps, file listings, and any email threads with the vendor. That paper trail is what gives weight to an escalation, whether to a copyright holder or a legal group.
Engaging with the Vendor
Before you post findings publicly, send the vendor a clear, level-headed request for the complete source. Name the exact product and firmware version, and cite the GPL section you think they’ve bumped into. Many companies list a compliance contact or legal address—if not, start with the support alias. Give them a fair window, two weeks in my usual rhythm, before you push harder. The point is compliance, not a public flogging. Smaller shops sometimes genuinely don’t grasp their obligations, especially when they lean on third-party integrators.
If the vendor goes silent or pushes back, you still have levers. Copyright holders can enforce the GPL through legal channels, but as an auditor you can shine a light. Share your findings on forums like the Software Freedom Conservancy’s compliance list or in relevant community spaces. The Conservancy has a long track record of successful enforcement and may pick up cases where the copyright holder is a member. Don’t make legal threats yourself unless you hold the copyright—stick to the technical facts.
Common Pitfalls in GPL Audits
Patterns emerge after enough audits. One classic slip is assuming a headless device doesn’t need to offer source. The GPL applies to all distribution, no exceptions. Another is the “we bought it from a vendor” defence—the company that puts the device in customers’ hands is still responsible. A trickier snag is binary blobs inside the kernel; the kernel is GPLv2, but proprietary firmware loaded onto peripherals can be separate, though the licence for that firmware still needs to be disclosed. If the vendor ships a patched kernel that folds proprietary blobs into the source tree, they’ve created a derivative work—and the whole thing has to come out under GPL.
Dealing with Obfuscation
A few companies work to hide non-compliance. Encrypted firmware, serial consoles that are lasered off, or source trees stripped of build scripts—those are warnings. When you hit encrypted firmware, see if the vendor offers a decryption tool or key as part of the source. If not, the source isn’t complete because you can’t install modifications. Likewise, if the source tarball ships precompiled objects with no corresponding source, that’s a violation unless those objects sit under a different licence and aren’t linked to GPL code in a way that creates a single work.
Your best counter to obfuscation is methodical notes. Fingerprint binaries with hashes and compare across releases. Trace each binary component back to its origin using package databases or build artefacts. When something doesn’t add up, ask the vendor directly for clarification—their reply, or the silence that follows, becomes part of the compliance record.
Building a Compliance Culture
Auditing isn’t just about catching slip-ups—it’s about nudging the industry toward a norm where compliance is the default. When manufacturers see that people are paying attention and that cutting corners costs more than doing it right, their processes shift. As engineers we’ve got the tools and, honestly, the responsibility to keep them honest. The GPL relies on that watchfulness. Without it, the code we contribute risks getting locked behind proprietary walls, sitting idle instead of improving.
Pick a device on your desk. Boot it, pull its firmware, and hold it up against the source the vendor provides. You’ll likely spot holes. Write them down, report them, and follow up. It’s slow, unglamorous work, but every audit that ends with corrected source code tightens the open-source foundation the whole industry stands on.
Frequently Asked Questions
What if the device manufacturer is based in a country with weak intellectual property enforcement?
The GPL is a licence, not a contract, so enforceability rides on local copyright law. Still, many global distributors sell into markets with strong protections—the United States and the European Union come to mind—where copyright holders can act. Public pressure and community reporting often nudge compliance along even without a courtroom. Focus on documenting the violation and sharing your findings with international advocacy groups like the Software Freedom Conservancy, who can coordinate across borders.
How do I audit a device that uses a real-time operating system instead of Linux?
The GPL covers any software licensed under it, not just Linux. If the RTOS includes GPL components—some FreeRTOS releases have GPL-licensed files, for example—the same obligations kick in. Start by scanning the firmware for licence notices and copyright statements. Tools like scancode-toolkit can automate that. Then verify that corresponding source is offered for each GPL component, applying the same completeness and build-reproducibility checks I’ve walked through above.
Can I perform an audit without violating the device’s terms of service or anti-circumvention laws?
This depends on where you live. In many countries, pulling firmware from a device you own for licence compliance checks is protected under exceptions to anti-circumvention rules—think of the security research exemption in the US DMCA. If you’re uneasy, limit your work to firmware images the manufacturer posts publicly, or ask for the source directly before you start extracting anything. Talking to a lawyer who knows your local landscape is smart if you plan to publish detailed technical findings.