Embedded and IoT
Firmware shipped inside a device: router, camera, controller, sensor, gateway, medical equipment outside CRA scope, vehicle outside CRA scope.
What actually happens
| Question | Answer |
|---|---|
| Does a third party receive the software in executable form? | Yes, embedded in hardware |
| Is the product a consumer good? | Often yes — and that is the critical point |
| Can the user install a modified version? | No, by construction: verified boot, signing |
| Is the component linked to your code? | Yes, statically, almost always |
| What volume of components? | A whole system: kernel, libc, utilities, network stack |
Every trigger is active at once. This is the most constrained scenario, and it is also where real litigation is concentrated: most public GPL enforcement cases, in Europe and elsewhere, concern routers, televisions and network equipment.
The verdict per family
| Family | Verdict | Reason |
|---|---|---|
| Permissive | ● | Attribution owed, to be made reachable despite the absence of a screen |
| Weak copyleft, file (MPL, EPL) | ● | Limited reciprocity, no linking constraint |
| Weak copyleft, library (LGPL-2.1) | ○ | Static linking is near-universal: object files owed |
| Weak copyleft, library (LGPL-3.0) | ✕ | Adds the v3 anti-lock-down clause |
| Strong copyleft GPL-2.0 | ○ | Full source obligation, but no anti-lock-down. Workable, and it is the regime of Linux, BusyBox and U-Boot |
| Strong copyleft GPL-3.0 | ✕ | Anti-lock-down incompatible with a locked device |
| Network copyleft (AGPL) | ✕ | Cumulative |
| Source-available | ✕ | Restrictions incompatible with selling a product |
The central conflict: anti-lock-down versus integrity
This is the most important point in the whole section.
GPL-3.0, section 6 requires, for a consumer product, supplying the Installation Information: what is needed to install and run a modified version of the software on the device. If the device refuses to boot software the user modified, the licence is not respected.
The CRA, Annex I, Part I, requires protecting the integrity of programs and configurations against unauthorised modification. The standard engineering answer to that requirement is verified boot: the device only boots signed code.
The two requirements point in opposite directions.
| GPL-3.0, section 6 | CRA, Annex I | |
|---|---|---|
| Objective | The user keeps control of their device | The device resists unauthorised modification |
| Means | Supply the keys or the installation procedure | Refuse any unsigned code |
How the sector resolves the tension
There is no universal answer. Four approaches, in order of frequency:
- Stay on GPL-2.0 for system components. That is the rarely stated but very real reason the Linux kernel, BusyBox and U-Boot remain on GPL-2.0-only. It means refusing components that have moved to v3.
- Separate the trust levels: locked verified boot for the security partition, and an application partition where the user can install their own build. Technically clean, but costly.
- Supply the Installation Information, including a documented unlocking procedure, while keeping integrity on by default. That is the licence’s literal reading, and it is defensible under the CRA, which requires protection against unauthorised modification — a change made by the device’s owner, following a documented procedure, is authorised.
- Exclude GPL-3.0 from the product, which means a policy applied from the choice of board support package onwards.
The reading that reconciles the two texts. The CRA protects against unauthorised modification; nowhere does it require that a device’s legitimate owner be unable to install their own software. An explicit, deliberate unlocking procedure that leaves the device in a state flagged as unsupported satisfies both. This is the position to work through with legal counsel before freezing the boot architecture, not after.
Static linking, systematic in embedded
There is usually no dynamic loader. Every LGPL library is therefore statically linked, which means owing the object files of the application so the user can relink against their own build of the library.
Few manufacturers do it. It is among the sector’s most widespread non-compliances, and among the easiest for a third party to establish by analysing a firmware image.
Volume: firmware means thousands of components
| Typical component | Licence |
|---|---|
| Linux kernel | GPL-2.0-only |
| BusyBox | GPL-2.0-only |
| U-Boot | GPL-2.0-or-later |
| glibc | LGPL-2.1-or-later |
| musl | MIT |
| OpenSSL 3.x | Apache-2.0 (earlier versions: a historical dual licence, GPL-incompatible) |
| Buildroot, Yocto | Recipes under various licences, producing artefacts under various licences |
A typical firmware image contains several thousand packages. Without an SBOM produced by the build chain, the inventory cannot be reconstructed afterwards — and that is exactly what the CRA makes mandatory.
Pitfalls in this scenario
The chip vendor’s BSP. The board support package arrives as an archive, with no inventory, proprietary drivers, binary blobs and sometimes modified GPL code whose corresponding source is not supplied. It is the weakest link in the chain, and the due diligence the CRA requires now forces you to address it — which means requiring it contractually from the supplier.
Binary blobs. Wi-Fi, modem and GPU firmware: redistributable under conditions, often under a restrictive proprietary licence. To inventory and document.
Attribution with no screen. The attribution duty survives on a device with no interface. The usual solutions: a web page served by the device, a file reachable through the administration interface, the printed manual, or a URL printed on the product — the last of which must remain valid for the device’s whole service life.
The ten-year written offer. The duty to supply the corresponding source lasts a long time: three years after the last distribution under GPL-2.0, longer under GPL-3.0. It overlays the CRA’s support period. Both require the same thing: keeping the source, the toolchain and the ability to rebuild, for a decade.
Taking over an abandoned project. An unmaintained embedded component inside a product covered by a ten-year support period is a double liability: security and licensing.
What the CRA adds
A great deal, and not only the conflict described above:
- classification: microprocessors and microcontrollers with security-related functionalities fall under class I; if they are tamper-resistant, under class II, where self-assessment is excluded. See Criticality classes;
- support period: hardware life cycles often exceed ten years, and component suppliers do not follow. See Support period;
- firmware SBOM: to be produced by the build chain, not reconstructed by later analysis;
- secure updates: a signed update mechanism, resilient to power loss, with rollback protection — see Secure updates, which is where the conflict with GPL-3.0 section 6 becomes technically concrete.