Open Source License Risk in Embedded Software

Most discussion of the relicensing wave assumes software that runs on a server you control. Embedded software breaks that assumption. The product is conveyed to a customer, often manufactured in volume, and updated over a long service life. Each of those traits raises the stakes on a license question that a cloud service might never trigger. The discipline is the same one set out on the open source license risk pillar, but the act of distribution changes which obligations apply and how costly a mistake becomes once units have shipped.

Why open source license risk in embedded software is sharper

A server side deployment may keep software inside your own walls, where some copyleft obligations stay dormant because nothing is conveyed to a third party. Embedded software does the opposite. When you ship firmware on a device, you distribute the software, and distribution is the trigger that many licenses wait for. The GPL and the LGPL attach their strongest duties to the act of conveying a binary, which can include providing corresponding source, written offers, and license texts. A component that raised no concern on an internal server can carry real obligations the moment it travels inside a product to a buyer.

How distribution turns dormant duties into live ones

The center of embedded license risk is the distinction between using software and conveying it. Copyleft licenses are designed to keep source available to those who receive the binary, so the obligation follows the binary out the door. For an embedded product that means the customer who receives the device may have a right to the corresponding source of the copyleft components inside it. Meeting that duty is straightforward when planned and painful when discovered late, because firmware images are built, signed, and shipped in volume, and reissuing them carries real cost. Mapping where each obligation sits before release is far cheaper than answering the question after a unit is in a customer's hands. The broad framing of how a change creates exposure is covered in how a license change creates enterprise exposure.

When a relicensing event reaches a shipped device

A license change applies to the versions released after the change. A component you already shipped under its prior license generally keeps those terms for that version, which is reassuring for a device already in the field. The exposure appears when you take the next update. A security fix, a new feature, or a routine version bump may only ship under the new license, and pulling that version into your firmware brings the new terms with it. For a long lived product that is updated for years, this is the live risk: not the unit you shipped, but the patch you are about to compile in. The detail of what happens to prior versions is covered in notice and effective dates in a relicense.

Linking, layers, and the technical detail that drives the duty

Embedded license questions often turn on engineering detail. The way a copyleft library is linked into your firmware can change what you owe, and the LGPL in particular treats static and dynamic linking differently. The boundary between your proprietary code and a copyleft component is a technical fact with a legal consequence, so it cannot be settled by intuition. Map how each copyleft component is incorporated, record whether it is linked statically or dynamically, and treat anything ambiguous as a question for your counsel rather than a judgment call for the build team. The transitive depth that hides these components is the same problem covered in transitive dependencies and hidden license risk.

How to map embedded exposure before release

Build a software bill of materials for each firmware image, pinned to the exact versions you compile in, and capture direct and transitive components alike. Record the license of every component, flag copyleft and source available terms, and note which obligations distribution triggers for each. Tie the inventory to the build so it refreshes when the image does, because a one time review goes stale the next time someone bumps a dependency. The output is an image level picture that tells you, before a unit ships, exactly which source you must offer and which components carry restrictions you cannot meet. The mechanics of producing that inventory are set out in the open source license risk assessment process.

We are independent and buyer side. We take no vendor fees and resell no software, so our read of your firmware reflects your exposure and nothing else, including when the finding is that your obligations are manageable as planned. This is commercial and licensing risk advisory, not legal advice. For interpretation of copyleft obligations and distribution duties in your embedded products, engage your own counsel.