Open-Source Licensing Pitfalls That Can Sink Your Embedded Systems Product

The open-source software ecosystem is an extraordinary engineering resource. For embedded systems developers, it provides proven Real-Time Operating System (RTOS) kernels, network stacks, cryptographic libraries, bootloaders, communication protocol implementations, and thousands of other components that would take years to develop from scratch. The ability to compose a working firmware stack from well-tested open-source building blocks has accelerated embedded product development by an order of magnitude.

The legal obligations that come with open-source components are less celebrated. They are also less understood — particularly in embedded systems teams where the software engineers who make dependency choices are often not the people responsible for product distribution, and the legal team (if one exists) is not involved in architecture reviews.

The result is a recurring pattern: a technology company builds a product, ships it at scale, attracts a strategic investor or acquirer, and then discovers during due diligence that the firmware stack contains GPL-licensed components whose distribution conditions have not been met. The options at that point range from expensive to catastrophic.

The License Taxonomy That Matters for Embedded Firmware

Not all open-source licenses impose the same obligations. For embedded systems companies, the critical distinction is between permissive licenses and copyleft licenses.

Permissive licenses — Massachusetts Institute of Technology License (MIT), Berkeley Software Distribution (BSD, 2-clause and 3-clause), Apache License 2.0, Internet Systems Consortium License (ISC) — allow you to incorporate the licensed code into a proprietary product without triggering any obligation to release your own source code. You must include the copyright notice and license text in your distribution (typically satisfied by including a NOTICES or LICENSES file in the product documentation or firmware image), but your proprietary firmware remains proprietary. These are the licenses to prefer for embedded commercial products.

Copyleft licenses — GPL version 2 (GPL v2), GPL version 3 (GPL v3), GNU Lesser General Public License version 2.1 (LGPL v2.1), LGPL version 3 (LGPL v3), AGPL, MPL — impose conditions on distribution that range from significant to existential for a commercial embedded product. The GPL family is the most important to understand in detail.

The GPL in Embedded Firmware: The Core Problem

The GNU General Public License (GPL) operates on a concept called copyleft: if you distribute a binary that incorporates GPL-licensed code, you must make the complete corresponding source code of the entire combined work available under the GNU General Public License (GPL). This is the "viral" characteristic that makes GPL problematic for proprietary embedded products.

In a desktop software context, dynamic linking has been used as a technical and legal mechanism to isolate GPL components from proprietary code. The GPL's "system library exception" and the concept of "separate works" that merely communicate with GPL-licensed programs have been argued, with varying success, to limit the copyleft effect to the GPL component itself. These arguments are legally contested and depend heavily on the specific factual and technical context.

In embedded firmware, these isolation mechanisms are far harder to achieve. Embedded systems typically use static linking, where all object files — GPL and proprietary — are linked into a single binary image that runs directly on the target hardware. There is no dynamic linking, no clear separation between processes, and no operating system abstraction that cleanly isolates components. The technical reality of embedded firmware makes the "separate work" argument much weaker, and the copyleft effect much more likely to extend to the entire firmware image.

The practical implication: if your RTOS kernel, your Transmission Control Protocol/Internet Protocol (TCP/IP) stack, or your bootloader is licensed under GPL v2 or GPL v3, and you distribute a firmware binary that incorporates that component, you have a legally significant obligation to make the source code of the entire combined firmware image available under the GPL — including your proprietary application code, your control algorithms, and your trade secrets.

LGPL: The Lesser Copyleft and Its Embedded Limits

The GNU Lesser General Public License (LGPL) was designed specifically to allow proprietary applications to link against LGPL-licensed libraries without triggering the full copyleft effect. Under the LGPL, you may distribute a proprietary binary that uses an LGPL library, provided that the user can replace the LGPL library component with a modified version. In desktop software, this is typically achieved through dynamic linking.

The LGPL v2.1 includes a specific provision addressing this: LGPL v2.1 Section 6 requires that you either use dynamic linking (so the library can be replaced) or provide the object files for your application so that the user can relink against a modified library. In embedded firmware with static linking, option two — providing your object files — is often the only available mechanism. Providing your object files is not the same as providing source code, but it does expose your compiled proprietary code to analysis by anyone who receives the product.

Whether this satisfies the LGPL's requirements, and whether it adequately protects your proprietary implementation, depends on what information can be extracted from the object files. For algorithms implemented in C, quite a lot can be reconstructed. LGPL is not a safe harbor for embedded proprietary products — it is a slightly smaller legal problem than GPL, but it is still a problem.

Common Embedded Open-Source Components and Their License Exposure

Several widely used open-source components present license compliance issues in commercial embedded products. The Linux kernel is licensed under GPL v2. FreeRTOS was relicensed from GPL to the MIT License in 2018 — a significant change that made it safe for commercial embedded use. lwIP (lightweight IP, a small-footprint TCP/IP stack) (the lightweight TCP/IP stack) is BSD-licensed. OpenSSL is Apache 2.0 licensed. U-Boot (a common bootloader) is GPL v2. Newlib (a C library often used in embedded systems) is BSD/MIT licensed.

The challenge is not usually the headline component — most embedded engineers know the FreeRTOS license changed. The challenge is the transitive dependencies: the GPL-licensed utility that the LGPL library pulls in, the GPL build tool that generates code incorporated into the binary, the GPL test framework that somehow ended up in the production build. Dependency graphs in embedded firmware are complex, and license compliance requires auditing the entire graph, not just the direct dependencies.

What Compliance Actually Requires

GPL compliance for a distributed embedded product requires: identifying all GPL and LGPL components in the firmware image; providing the complete corresponding source code (CCS) — meaning all source code needed to generate the distributed binary — in a form that can be used to rebuild the binary; making the CCS available for at least three years after the last distribution of the binary; and including the GPL license text and appropriate notices in the product documentation or the binary image itself.

Many embedded companies comply with the source code provision by creating a written offer to provide source code on request, including it in the product manual, and then actually honoring requests. This is legally compliant but requires maintaining the build environment and source code archive throughout the product lifecycle — which can span 10–15 years in automotive and industrial applications.

---

Attorney advertising. The information in this post is provided for general informational purposes and does not constitute legal advice. Prior results do not guarantee a similar outcome. © 2026 guibert.law