Embarqué et objets connectés
Micrologiciel livré dans un appareil : routeur, caméra, automate, capteur, passerelle, équipement médical hors périmètre CRA, véhicule hors périmètre CRA.
Ce qui se passe réellement
| Question | Réponse |
|---|---|
| Un tiers reçoit-il le logiciel sous forme exécutable ? | Oui, intégré au matériel |
| Le produit est-il un bien de consommation ? | Souvent oui — et c’est le point critique |
| L’utilisateur peut-il installer une version modifiée ? | Non, par construction : démarrage vérifié, signature |
| Le composant est-il lié à votre code ? | Oui, statiquement, presque toujours |
| Quel volume de composants ? | Un système complet : noyau, libc, utilitaires, pile réseau |
Tous les mécanismes de déclenchement sont actifs simultanément. C’est le scénario le plus contraint, et c’est aussi celui où le contentieux réel est le plus concentré : l’essentiel des affaires publiques de violation de la GPL, en Europe comme ailleurs, concerne des routeurs, des téléviseurs et des équipements réseau.
Le verdict par famille
| Famille | Verdict | Raison |
|---|---|---|
| Permissive | ● | Attribution due, à rendre accessible malgré l’absence d’écran |
| Copyleft faible fichier (MPL, EPL) | ● | Réciprocité limitée, sans contrainte de liaison |
| Copyleft faible bibliothèque (LGPL-2.1) | ○ | Liaison statique quasi systématique : fichiers objets à fournir |
| Copyleft faible bibliothèque (LGPL-3.0) | ✕ | Ajoute l’anti-verrouillage de la v3 |
| Copyleft fort GPL-2.0 | ○ | Obligation pleine de source, mais pas d’anti-verrouillage. Praticable, et c’est le régime de Linux, BusyBox, U-Boot |
| Copyleft fort GPL-3.0 | ✕ | Anti-verrouillage incompatible avec un appareil verrouillé |
| Copyleft réseau (AGPL) | ✕ | Cumul |
| Source-available | ✕ | Restrictions incompatibles avec la vente d’un produit |
Le conflit central : anti-verrouillage contre intégrité
C’est le point le plus important de toute cette section.
La GPL-3.0, article 6, impose, pour un produit de consommation, de fournir les informations d’installation : ce qu’il faut pour installer et exécuter une version modifiée du logiciel sur l’appareil. Si l’appareil refuse de démarrer un logiciel modifié par l’utilisateur, la licence n’est pas respectée.
Le CRA, annexe I, partie I, impose de protéger l’intégrité des programmes et configurations contre toute modification non autorisée. La réponse d’ingénierie standard à cette exigence est le démarrage vérifié : l’appareil ne démarre que du code signé.
Les deux exigences pointent en sens contraire.
| GPL-3.0, article 6 | CRA, annexe I | |
|---|---|---|
| Objectif | L’utilisateur garde le contrôle de son appareil | L’appareil résiste à la modification non autorisée |
| Moyen | Fournir les clés ou la procédure d’installation | Refuser tout code non signé |
Comment le secteur résout la tension
Il n’existe pas de solution universelle. Quatre approches, par ordre de fréquence :
- Rester en GPL-2.0 pour les composants système. C’est la raison — rarement dite mais bien réelle — pour laquelle le noyau Linux, BusyBox et U-Boot demeurent en GPL-2.0-only. Cela suppose de refuser les composants qui ont migré en v3.
- Distinguer les niveaux de confiance : un démarrage vérifié verrouillé pour la partie sécurité, et une partition applicative où l’utilisateur peut installer sa propre version. Techniquement propre, mais coûteux.
- Fournir les informations d’installation, y compris une procédure de déverrouillage documentée, tout en conservant l’intégrité par défaut. C’est la lecture littérale de la licence, et elle est défendable au regard du CRA, qui exige la protection contre les modifications non autorisées — une modification faite par le propriétaire de l’appareil, selon une procédure documentée, est autorisée.
- Écarter la GPL-3.0 du produit, ce qui suppose une politique appliquée dès le choix du board support package.
La lecture qui réconcilie les deux textes. Le CRA protège contre les modifications non autorisées ; il n’impose nulle part que le propriétaire légitime d’un appareil ne puisse pas y installer son propre logiciel. Une procédure de déverrouillage explicite, volontaire, et qui remet l’appareil dans un état signalé comme non conforme au support, satisfait les deux exigences. C’est la position à instruire avec le conseil juridique avant de figer l’architecture de démarrage, pas après.
La liaison statique, systématique en embarqué
Il n’y a généralement pas de chargeur dynamique. Toute bibliothèque LGPL est donc liée statiquement, ce qui impose de fournir les fichiers objets de l’application permettant à l’utilisateur de relier avec sa propre version de la bibliothèque.
Peu de fabricants le font. C’est l’une des non-conformités les plus répandues du secteur, et l’une des plus faciles à établir pour un tiers qui analyse un micrologiciel.
Le volume : un micrologiciel, c’est des milliers de composants
| Composant type | Licence |
|---|---|
| Noyau Linux | 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 (les versions antérieures : double licence historique, incompatible GPL) |
| Buildroot, Yocto | Recettes sous licences diverses, produisant des artefacts sous licences diverses |
Une image de micrologiciel typique contient plusieurs milliers de paquets. Sans SBOM produit par la chaîne de construction, l’inventaire est impossible à établir a posteriori — et c’est exactement ce que le CRA rend obligatoire.
Les pièges de ce scénario
Le BSP du fournisseur de puce. Le board support package arrive sous forme d’archive, sans inventaire, avec des pilotes propriétaires, des blobs binaires et parfois du code GPL modifié sans que le source correspondant soit fourni. C’est le point le plus faible de la chaîne, et la diligence exigée par le CRA impose désormais de le traiter — donc de l’exiger contractuellement du fournisseur.
Les blobs binaires. Micrologiciels de puce Wi-Fi, de modem, de GPU : redistribuables sous conditions, souvent avec une licence propriétaire restrictive. À inventorier et à documenter.
L’attribution sans écran. L’obligation d’attribution demeure sur un appareil sans interface. Les solutions usuelles : une page web servie par l’appareil, un fichier accessible par l’interface d’administration, la notice papier, ou une adresse internet imprimée sur le produit — cette dernière devant rester valide pendant toute la durée de vie de l’appareil.
L’offre écrite de dix ans. L’obligation de fournir le source correspondant survit très longtemps : trois ans après la dernière distribution en GPL-2.0, davantage en GPL-3.0. Elle se superpose à la période de support du CRA. Les deux imposent la même chose : conserver le source, la chaîne de compilation et la capacité de reconstruire, pendant une décennie.
La reprise de projet abandonné. Un composant embarqué non maintenu dans un produit couvert par une période de support de dix ans est une dette double : sécurité et licence.
Ce que le CRA ajoute
Beaucoup, et pas seulement le conflit décrit plus haut :
- classification : microprocesseurs et microcontrôleurs dotés de fonctionnalités de sécurité relèvent de la classe I ; s’ils sont résistants à l’altération, de la classe II, où l’auto-évaluation est exclue. Voir Les classes de criticité ;
- période de support : les cycles de vie matériels dépassent souvent dix ans, et les fournisseurs de composants ne suivent pas. Voir Période de support ;
- SBOM du micrologiciel : à produire par la chaîne de construction, pas par analyse a posteriori ;
- mises à jour sécurisées : mécanisme de mise à jour signé, résistant à la coupure, avec protection contre le retour arrière — voir Mises à jour sécurisées, qui est le lieu où le conflit avec l’article 6 de la GPL-3.0 se matérialise techniquement.