Introduction: Why GPL Compliance Audits Matter for Embedded Devices

Introduction: Why GPL Compliance Audits Matter for Embedded Devices

If you ship a product with Linux or any GPL-licensed code inside, providing the corresponding source isn’t a nice-to-have. It’s a hard legal requirement. For engineers, compliance managers, and open-source program officers, auditing a device for GPL compliance means walking through a structured technical and legal process. This guide lays out a methodical way to inspect firmware, spot GPL components, verify source code offers, and document what you find. The point isn’t just to dodge lawsuits. It’s about respecting the collaborative rules that keep open source alive.

1. Pre-Audit Preparation: Gathering Materials and Documentation

Before you even power on the device, round up everything you can get your hands on. Ask the manufacturer for these—or dig them up through public channels:

• Complete source code offer: The written offer for source code, as required by GPLv2 Section 3 or GPLv3 Section 6. This might be a URL, a physical medium offer, or a written commitment.
• Firmware images: Official binary firmware files, including updates, from the vendor’s website or support portal.
• Corresponding source code: The actual source packages, ideally organized by component and version.
• Build scripts and toolchain information: Scripts, configuration files, and compiler details used to generate the binaries. GPLv3 explicitly requires “scripts used to control compilation and installation.”
• License notices: Copies of any physical or digital license texts included with the product.

Jot down the device model, firmware version, and date you got it. That metadata anchors your audit trail. If the vendor has an “open source” or “legal” page on their site, archive it right away with wget or the Wayback Machine. I’ve seen too many compliance failures that boil down to broken links or missing archives.

2. Extracting and Analyzing the Firmware

Firmware extraction is where you get your hands dirty. The method depends on how the firmware is packaged:

• Standalone binary file: Use binwalk to scan for embedded filesystems, compressed archives, and kernels. Follow up with dd or jefferson (for JFFS2) to carve out components.
• OTA update captures: Intercept over-the-air updates with a proxy like mitmproxy, then analyze the payload.
• Direct device access: If the device has a serial console (UART) or JTAG, dump flash memory directly. This is often the only way to get a complete image, including bootloaders and hidden partitions.

Once you’ve got the root filesystem mounted, catalog every binary and library. Use find and file to identify ELF executables, kernel modules, and shared objects. Pay special attention to statically linked binaries—they can hide GPL code without any accompanying source.

3. Identifying GPL-Licensed Components

Not all open-source software in a device is GPL-licensed. Permissive licenses (MIT, BSD, Apache) don’t require source distribution. Focus on strong copyleft licenses: GPLv2, GPLv3, LGPL, and AGPL. Here’s how to spot them:

3.1 String Scanning

Run strings on binaries and search for copyright notices, license references, and version strings. Common patterns include “GNU General Public License,” “GPL,” “Free Software Foundation,” and specific program names like “BusyBox” or “Linux.” A simple command:

strings firmware.bin | grep -iE 'gpl|general public license|free software foundation'

3.2 Package Metadata

If the firmware includes a package manager (opkg, dpkg, rpm), query the installed package list. For example, on an extracted rootfs:

cat /var/lib/dpkg/status | grep -E 'Package:|Version:|License:'

Cross-reference package names with known open-source projects. Many embedded Linux systems use BusyBox, uClibc, or the Linux kernel—all GPLv2.

3.3 Binary Analysis

For stripped binaries, use tools like binwalk -A to identify function signatures or radare2 to disassemble and look for GPL-licensed library fingerprints. Kernel modules can be checked with modinfo if the module is accessible. Verify the kernel version with strings vmlinuz | grep 'Linux version'.

4. Verifying Source Code Correspondence

Having the source code isn’t enough. It has to be the exact source that built the binaries on the device. This is the most technically demanding phase.

4.1 Build Environment Reconstruction

Set up a build environment matching the vendor’s claimed toolchain. Compile the provided source and compare the resulting binaries with those on the device. Use diff, cmp, or hashing (SHA256) for a byte-by-byte comparison. Even minor differences—compiler flags, library versions, or kernel configurations—can point to incomplete source.

4.2 Kernel Verification

The Linux kernel is almost always present. Extract the kernel image and compare its symbol table, modules, and configuration. The /proc/config.gz file, if available on a running device, gives you the exact kernel configuration. Demand the corresponding .config file and any patches applied to the vanilla kernel source.

4.3 Derivative Works and Modifications

GPL compliance requires disclosure of modifications. If a binary is based on a GPL component but has been altered, the vendor must provide the modified source, not just a link to the upstream project. Use binary diffing tools like radiff2 to compare the device’s binary with a freshly compiled upstream version. Any differences must be explained and source provided.

5. License Compliance and Notice Requirements

GPLv2 Section 1 and GPLv3 Section 4 require appropriate copyright notices and disclaimer of warranty. Inspect the device’s user interface, printed manuals, and packaging. Check for:

• Copyright notices in “About” screens or settings menus.
• Physical copies of the GPL text included in the box.
• Clear indication that the device contains GPL software.

GPLv3 adds requirements for “Installation Information” if the device locks down modified software. If the device uses secure boot or signed firmware, the vendor must provide information to allow installation of modified versions. Test this by attempting to build and flash a custom kernel or application.

6. Documenting Findings and Engaging the Vendor

Compile a detailed report. For each GPL component found, record:

• Component name and version.
• Location in the firmware (file path).
• License type and exact text reference.
• Source code status: provided, missing, incomplete, or non-matching.

If gaps exist, contact the vendor with a clear, specific request. Reference the GPL sections that apply. Many vendors have a designated compliance officer or email address (e.g., gpl-compliance@company.com). Set a reasonable deadline—30 days is common—and keep a record of all correspondence.

If the vendor doesn’t respond or refuses to comply, consider escalation. Copyright holders have standing to enforce the GPL. Organizations like the Software Freedom Conservancy (SFC) and gpl-violations.org have a history of successful enforcement actions. As an auditor, your role is to provide the technical evidence that underpins a legal case.

7. Special Considerations for Embedded Systems

7.1 Bootloaders and Trusted Execution Environments

U-Boot, Barebox, and other bootloaders are often GPLv2. They may reside in write-protected flash or execute before the main OS. Dump these regions via JTAG or chip-off methods. Verify that source for the exact version is available, including any board-specific modifications.

7.2 Copyleft in User Space

Applications like ffmpeg, Qt (under GPL), or GStreamer bring strong copyleft into user space. Check dynamic linking: if a proprietary application links against a GPL library, the entire application must be GPL-compatible. Use ldd on the target’s binaries to map library dependencies.

7.3 Aggregation vs. Combination

GPL allows mere aggregation—placing GPL and proprietary programs on the same medium without interaction. But if they communicate through shared data structures, pipes, or IPC, they may form a single work. This is a legal gray area; document the interaction patterns for legal analysis.

8. Tools and Resources for the Auditor

Build a toolkit for repeatable audits. Essential open-source tools include:

• binwalk: Firmware analysis and extraction.
• radare2 / rizin: Reverse engineering and binary diffing.
• FOSSology: License scanning and component identification.
• scancode-toolkit: Detects licenses, copyrights, and packages.
• Buildroot / Yocto: For reconstructing build environments.

For legal reference, consult the GNU GPL FAQ and the Software Freedom Conservancy’s compliance resources. The Linux Foundation also offers guidance on open-source license compliance for embedded systems.

FAQ: Common Questions on GPL Device Audits

What is the difference between GPLv2 and GPLv3 compliance for devices?

GPLv3 introduces specific requirements for “User Products,” including the obligation to provide Installation Information that allows users to install modified versions. It also addresses DRM and patent retaliation. GPLv2 lacks these explicit terms, but the core source code disclosure obligation is similar. Always identify the exact license version for each component.

Can a vendor just point me to a public upstream repository?

No. If the vendor modified the software, they must provide the modified source. Even for unmodified GPL code, a mere link to a third-party site is insufficient if the vendor distributes the binary. The vendor is responsible for ensuring source availability for as long as they distribute the binary. A written offer valid for three years is a common method.

What if the device uses a signed bootloader and I cannot run modified code?

Under GPLv3, the vendor must provide “Installation Information” including keys and methods to install modified software. Under GPLv2, this is a gray area, but the spirit of the license suggests users should be able to exercise their freedom to modify. Document the restriction and consult with legal experts or enforcement bodies.

How do I handle proprietary kernel modules?

Proprietary kernel modules that link to GPL-licensed kernel symbols are generally considered derivative works and must be GPL-licensed. However, the legality of non-GPL kernel modules is debated. Check for modules marked with “proprietary” or “non-GPL” modinfo tags. If found, flag them for legal review and verify that they do not use GPL-only symbols.