What Is a GPL Compliance Audit and Why Does It Matter?
A GPL compliance audit is a methodical dissection of a device’s software distribution to see if it actually honors the GNU General Public License. The GPL is a copyleft license—it gives users the freedom to run, study, share, and modify the software. In return, anyone shipping GPL-licensed code inside a product must hand over the corresponding source, build scripts, and installation info. This isn’t a polite request. It’s a legal condition baked into the license itself. For embedded Linux engineers and open-hardware people, auditing a device is a direct challenge to proprietary lock-in. It reveals whether a manufacturer respects user freedom or hides behind binary blobs and half-baked source drops.
This article lays out a practical, evidence-driven audit process. You’ll learn how to spot GPL components, demand source code, verify it’s complete, and document what you find. The tone is confrontational toward non-compliance because the GPL’s teeth come from enforcement. Without audits, the license becomes a suggestion—and suggestions don’t keep vendors honest.
Step 1: Identify the GPL-Licensed Components
Before you can audit, you need to know what software the device is actually running. Start with the obvious: the Linux kernel. Nearly every embedded Linux device ships a kernel, and it’s licensed under GPLv2. But the kernel is just the start. Look for user-space pieces like BusyBox (GPLv2), uClibc (LGPL), or GNU Coreutils (GPLv3). Many devices also pull in GPL-licensed libraries—libgcc, libstdc++, and the like.
Extracting the Bill of Materials
If the device has a UI, poke around for an “open source licenses” screen. It often lists components and their licenses. But these lists are frequently incomplete or deliberately vague. A more reliable route: get into the device’s file system. If you’ve got root access through a serial console, SSH, or ADB, run commands like ls /usr/bin or ls /lib to see installed binaries and libraries. Then use strings on those binaries to hunt for GPL copyright notices. For example, strings /bin/busybox | grep GPL usually spills the license right out.
If the device is locked down, you’ll need to extract the firmware. Grab the firmware update from the manufacturer’s site and feed it to binwalk. A command like binwalk -e firmware.bin will pull out squashfs, jffs2, or other file systems. Once extracted, browse the rootfs and identify GPL components by checking package metadata or binary strings. It’s grunt work, but it’s the foundation of everything that follows.
Step 2: Request the Source Code
The GPL says distributors must provide the “complete corresponding source code” for every GPL-licensed binary. That means the exact version used in the device, plus build scripts and any modifications. The source has to be delivered on a medium customarily used for software interchange—a downloadable archive, or a physical medium like a USB stick. A written offer is valid only if it’s clear and persistent.
How to Make a Formal Request
Send a written request to the manufacturer. Be specific: list the device model, firmware version, and the GPL components you’ve already identified. Cite the exact GPL version (e.g., GPLv2 Section 3) and demand the corresponding source code. Keep the tone professional but firm. If the manufacturer has a public source repository, check it first. A lot of companies dump a tarball on their website and call it a day. Your job is to verify that the tarball is complete and actually matches the binary running on the hardware.
If the manufacturer ignores you or hands over incomplete source, escalate. The Software Freedom Conservancy and gpl-violations.org have a long history of enforcing the GPL. You can report non-compliance to them, but be ready to back it up with evidence. This is where your audit stops being a checklist and starts being a weapon.
Step 3: Verify the Source Code
Getting a source tarball isn’t the finish line. You have to verify that the source code matches the binaries on the device. This is where a lot of manufacturers stumble—or cheat. They’ll toss you a generic kernel source but leave out their proprietary drivers or the exact .config file used to build the kernel. They might include BusyBox source but not the configuration that enables the applets on the device. That’s a violation, plain and simple.
Kernel Verification
For the Linux kernel, check the version string on the device: uname -a or cat /proc/version. Compare it to the provided source. Then, if you can, extract the kernel config from the device: zcat /proc/config.gz or look for /proc/config.gz. If the manufacturer gave you a .config file, diff it against the extracted one. Any mismatch is a red flag. Next, check for proprietary kernel modules. Run lsmod and look for modules with tainted flags. A tainted module means non-GPL code is loaded, which may violate the kernel’s license if it uses GPL-only symbols.
User-Space Verification
For user-space GPL components, you need to confirm that the source builds the exact binary. This is harder. You might need to set up a cross-compilation toolchain that matches the device’s architecture. Build the component and compare the resulting binary with the one on the device using md5sum or sha256sum. If they differ, the source is incomplete or modified. Pay close attention to build scripts. The GPL requires “scripts used to control compilation and installation,” so a missing Makefile or a vague reference to a proprietary build system is a violation.
Common Evasion Tactics
Manufacturers have a bag of tricks to dodge their obligations. Watch for these:
- Binary-only kernel modules: They provide kernel source but load a proprietary
.kofile that taints the kernel. - Obfuscated source: They provide source that’s been deliberately stripped of comments and meaningful variable names, making it useless for modification.
- Incomplete build environment: They omit the toolchain, linker scripts, or other pieces needed to produce a working binary.
- Time-bombed source: They provide source that only works with a specific, outdated toolchain that isn’t provided.
If you run into any of these, document it. The GPL requires the source to be the “preferred form of the work for making modifications.” Obfuscated or incomplete source fails that test, period.
Step 4: Check for License Notices and Attribution
The GPL also demands that the software carry appropriate copyright notices and a copy of the license. On an embedded device, this often means including the license text in the documentation or displaying it on-screen. If the device has a user manual, check for GPL notices. If it has a display, dig through the settings or about menu. Missing notices are a violation—though a minor one compared to withholding source code.
For GPLv3 components, there are extra requirements: the device must allow user-modified software to be installed (the “anti-tivoization” clause) and must provide any necessary installation information, like signing keys. If the device uses GPLv3 code and locks down the bootloader, that’s a violation. Check the license version of each component carefully.
Step 5: Document and Report
Your audit is only as strong as the evidence you collect. Keep a detailed log of every step: the device model, firmware version, commands run, output received, and any correspondence with the manufacturer. Take screenshots or photos. If you find a violation, write a clear report explaining what’s missing and why it violates the GPL. Share it with the community if the manufacturer stays silent. Public pressure is often the only thing that forces compliance.
Remember, the GPL isn’t a polite request for source code; it’s a condition of distribution. If a company distributes GPL-licensed software without providing source, they lose the right to distribute that software. Your audit is the first step in holding them accountable.
FAQ
What if the device uses a proprietary kernel module?
Proprietary kernel modules sit in a gray area. The Linux kernel is licensed under GPLv2, which allows some non-GPL modules if they don’t use GPL-only symbols. But many kernel developers consider any proprietary module a violation. If the module uses GPL-only symbols (marked with EXPORT_SYMBOL_GPL), it’s a clear violation. Check the kernel log for taint messages. Even if it’s technically legal, a proprietary module undermines the spirit of the GPL and should be called out.
How long does a manufacturer have to provide source code?
The GPL doesn’t set a hard deadline, but the source must be provided “in a timely manner.” In practice, a few weeks is reasonable. If a manufacturer stalls for months, they’re likely non-compliant. The written offer for source code must be valid for at least three years from the last distribution of the binary.
Can I audit a device without physical access?
Yes, if you can get the firmware image. Many devices let you download firmware updates from the manufacturer’s website. You can extract and analyze these images using tools like binwalk, as described above. But physical access gives you more options—like accessing the device’s console or dumping the flash memory directly.
What if the manufacturer claims the GPL code is from a third party?
The GPL obligation follows the distribution chain. If a manufacturer distributes a device containing GPL code, they’re responsible for providing the source, no matter who wrote it. They can’t shift the blame to a chip vendor or an outsourced software house. The manufacturer is the distributor and must comply.
Next Steps: Building a Compliance Toolkit
This audit process is just the start. To make it repeatable, assemble a toolkit: a Linux workstation with cross-compilation toolchains for common embedded architectures (ARM, MIPS, PowerPC), forensic tools like binwalk, dd, and strings, and a collection of GPL license texts for reference. Document your findings publicly to build a knowledge base of compliant and non-compliant devices. The more engineers who audit, the harder it becomes for manufacturers to ignore their obligations. Open hardware depends on this vigilance.