Engineers working with embedded systems often encounter the GNU General Public License at some point in a project’s lifecycle. Whether you are building a network switch, a medical monitor, or an industrial controller, the software running on that hardware frequently includes GPL-licensed components. Understanding what the GPL requiresâand what it does notâis a matter of both legal compliance and engineering ethics. This guide walks through the mechanics of GPL licensing as they apply specifically to embedded devices.
What the GPL Actually Says
The GNU General Public License is a copyleft license. Unlike permissive licenses such as MIT or BSD, which allow code to be reused with minimal conditions, the GPL requires that derivative works be distributed under the same license. The core principle is straightforward: if you distribute a work that incorporates GPL-licensed code, you must make the complete corresponding source code available to your recipients, under the GPL, at no charge beyond the cost of physical distribution.
Two major versions of the GPL are in wide circulation: GPLv2 and GPLv3. The Linux kernel, for instance, operates under GPLv2. Many user-space tools and libraries, including the GNU C Library, have moved to GPLv3. The differences between these versions have direct consequences for embedded device manufacturers.
How Copyleft Propagates
The GPL’s copyleft mechanism triggers when two conditions are met: distribution of the work and the creation of a derivative work. Distribution, in the GPL’s terms, means conveying a copy to someone else. If you build firmware for internal use only and never ship the device outside your organization, the distribution requirement does not activate. The moment you sell, lease, or give the device to a third party, distribution has occurred.
Whether something constitutes a derivative work is where practical disagreements arise. The Free Software Foundation (FSF) holds that linking GPL code with other codeâstatically or dynamicallyâcreates a single derivative work. Many in the embedded industry interpret this more narrowly, arguing that clearly separated processes communicating via well-defined interfaces do not create derivation. This distinction matters enormously when deciding whether your proprietary application must be released under the GPL.
The Tivoization Problem and GPLv3
One of the most significant changes from GPLv2 to GPLv3 concerns what the FSF calls “tivoization.” The term comes from TiVo’s practice of using Linux in its DVR hardware while installing cryptographic checks that prevent users from running modified versions of that Linux kernel. Under GPLv2, TiVo complied with the letter of the license: they released the kernel source code. But users could not exercise the freedom to run modified versions on the hardware they owned.
GPLv3 addresses this directly. Section 6 of GPLv3 requires that if you distribute a consumer product containing GPL-licensed code, you must also provide the installation information necessary to install and run modified versions of that code on the product. This means providing keys, passwords, and instructionsâanything needed to bypass hardware-enforced restrictions on software modification.
For embedded device manufacturers, this requirement has real teeth. If your device includes GPLv3-licensed software, and you use secure boot or signed firmware to prevent unauthorized code from running, you must give your customers the means to install their own modified GPL-covered software. This is one reason some companies actively avoid GPLv3 components in their builds.
Source Code Distribution Requirements
Under both GPLv2 and GPLv3, distributing a device with GPL-licensed software obligates you to distribute the source code. The GPL defines several acceptable methods for this, including:
- Accompanying the device with the source code on a physical medium (such as a CD-ROM or USB drive).
- Providing a written offer, valid for at least three years, to provide the source code to any third party upon request.
- Making the source code available via a publicly accessible network server.
The third option is the most common in practice, but it carries an obligation that many companies overlook: you must keep the source code available for as long as you continue to offer the product. If you take the server offline, you may no longer be in compliance. Additionally, the source you provide must correspond exactly to the version of the GPL-covered code actually running on the device. Supplying source for a later or different version does not satisfy the requirement.
What Constitutes “Complete Corresponding Source”
The GPL defines “complete corresponding source code” broadly. It includes not just the GPL-licensed code itself, but also the scripts, build systems, Makefiles, toolchain specifications, and any other information needed to reproduce the exact binary running on the device. If you cross-compile the Linux kernel for an ARM target using a specific version of GCC and a particular set of configuration options, those details form part of the corresponding source. The goal is to ensure that a recipient can actually build a working replacementânot merely read the source.
Compliance in Practice
Compliance is not just a legal exercise. It reflects a principled commitment to the social contract that open-source licenses embody. The GPL grants you the right to use and modify the software; in return, it asks that you extend those same rights to others. When a device manufacturer ships a product with GPL code inside but fails to release the corresponding source, they break that contract. The practical and reputational consequences can be severe. Organizations like the Software Freedom Conservancy have pursued legal action against companies that violate GPL terms, resulting in court-enforced compliance and monetary settlements.
A sound compliance program for embedded devices should include several elements:
- Software Bill of Materials: Maintain a detailed inventory of every open-source component in your firmware, including version numbers, license types, and any modifications you have made.
- Build Reproducibility: Ensure that anyone receiving your source code can actually build the binary. Test this periodically by performing clean builds from your released source archives.
- Written Offers: If you choose the written-offer method for source distribution, make sure the offer text is included with the deviceâand that your organization has processes to honor requests promptly.
- Upstream Contributions: Whenever possible, contribute your modifications back to the upstream projects. This reduces the gap between what you ship and what is publicly available, simplifying source distribution.
Selecting and Isolating GPL Components
Engineers building embedded systems have a legitimate interest in controlling which parts of their firmware fall under copyleft obligations. This is not about circumventing the GPLâit is about understanding your obligations so you can meet them fully. A well-architected firmware stack isolates GPL-licensed components from proprietary code through clear boundaries. The Linux kernel, for example, explicitly permits user-space applications to interact with the kernel via system calls without those applications becoming derivative works. This “user-space exception” is documented in the kernel’s COPYING file.
Similarly, you can use LGPL-licensed libraries in proprietary applications, provided you comply with the LGPL’s termsâwhich typically require dynamic linking and the ability for users to replace the library with a modified version. Understanding these boundaries allows you to design your software stack with purpose rather than discovering compliance gaps after the product ships.
Common Compliance Failures
Several patterns appear repeatedly in GPL compliance failures within the embedded industry:
- Stale source archives: A company publishes source code for an older version of the firmware but never updates the archive when new versions ship. This violates the “corresponding source” requirement.
- Missing build instructions: The source code is published, but without the toolchain configuration, kernel config files, or build scripts needed to reproduce the binary. The source is incomplete.
- Unreachable servers: A device ships with a URL pointing to a source code download page, but the page returns a 404 error. The written-offer clause in GPLv2 requires that the source remain accessible for three years from the last distribution of the product.
- Ignoring GPLv3 implications: A device uses secure boot with GPLv3-licensed components but does not provide the keys or installation information needed for users to run modified versions.
Each of these failures is preventable with proper process and attention. The GPL’s requirements are explicit and well-documented. The full text of GPLv3 and GPLv2 are publicly available and should be read directly by anyone responsible for compliance.
The Ethical Dimension
Beyond legal risk, there is a principled reason to comply with the GPL. The software you rely onâwhether it is the Linux kernel, BusyBox, U-Boot, or any of the thousands of GPL-licensed librariesâexists because developers chose to share their work under terms that guarantee continued sharing. When you use that software in a product, you benefit from that collective effort. The GPL asks that you pass those benefits along. Treating compliance as a bureaucratic burden rather than a reciprocal obligation misunderstands the relationship between you and the software community.
Arjun Mehta writes on licensing, embedded systems, and the intersection of engineering practice with software freedom at gpl-devices.org.
Frequently Asked Questions
Does the GPL require me to release the source code for my proprietary application if it runs on a Linux-based embedded device?
Generally, no. The Linux kernel’s COPYING file includes a statement that user-space applications interacting with the kernel via system calls are not considered derivative works. If your proprietary application runs as a separate process and communicates with the kernel only through standard system calls, the GPL on the kernel does not extend to your application. However, if your application is statically linked with a GPL-licensed library, that library’s GPL terms would apply to the combined work. The specific architecture of your software stack determines where the boundaries fall.
What if my device is only used internally within my company and never sold to external parties?
The GPL’s distribution requirement is triggered by conveyanceâtransferring a copy to someone outside your organization. If you build a device with GPL-licensed software and it remains entirely within your company, the source distribution obligation does not activate. This is sometimes called the “internal use” exception. Be aware, however, that distributing devices to contractors, subsidiaries with separate legal identity, or other entities outside your immediate organization may constitute distribution under the GPL.
Can I use GPL-licensed code in my embedded device if I use secure boot?
It depends on the GPL version. With GPLv2-licensed code (such as the Linux kernel), secure boot is technically permissible as long as you meet the source distribution requirements. The GPLv2 does not address hardware restrictions directly. With GPLv3-licensed code, secure boot is permissible only if you provide the installation informationâincluding any keys or signaturesâneeded for users to install and run modified versions of the GPLv3-covered software on the device. If you cannot or will not provide those keys, you should avoid GPLv3-licensed components in your firmware.