On-premise et auto-hébergé
Le logiciel est installé et exécuté sur l’infrastructure du client : appliance virtuelle, image machine, paquet d’installation, ensemble de conteneurs, cluster livré clés en main.
Ce qui se passe réellement
| Question | Réponse |
|---|---|
| Un tiers reçoit-il le logiciel sous forme exécutable ? | Oui, intégralement |
| Un tiers interagit-il avec lui par un réseau ? | Oui, mais c’est le client qui devient l’opérateur |
| Le produit est-il un bien de consommation ? | Non — client professionnel |
| Que reçoit exactement le client ? | Souvent tout un système, système d’exploitation compris |
C’est, avec l’embarqué, le scénario où le volume de composants distribués est le plus important — et de très loin.
Le verdict par famille
| Famille | Verdict | Raison |
|---|---|---|
| Permissive | ● | Attribution due pour l’ensemble de ce qui est livré |
| Copyleft faible fichier (MPL, EPL) | ● | Publier les fichiers modifiés |
| Copyleft faible bibliothèque (LGPL) | ◐ | Praticable si liaison dynamique ; en conteneur, souvent le cas |
| Copyleft fort (GPL) | ◐ | Obligation pleine, y compris envers le client, qui peut ensuite redistribuer |
| Copyleft réseau (AGPL) | ○ | Vous distribuez : les articles 4 et 5 s’appliquent. L’article 13 s’appliquera au client, ce qu’il faut lui dire |
| Source-available | ✕ | Presque toutes interdisent la redistribution |
Le point qui change tout : le client hérite de droits
En recevant un binaire sous GPL, le client devient titulaire des droits de la licence. Il peut :
- exiger le code source correspondant, y compris de vos modifications ;
- le redistribuer à qui il veut, sous la même licence ;
- modifier le composant et déployer sa version.
Ce n’est pas théorique : c’est la voie par laquelle une violation devient publique. Un client mécontent, ou simplement curieux, demande le source. S’il ne l’obtient pas, il dispose d’un levier considérable — et, s’il est lui-même contributeur du projet amont, d’un intérêt à agir.
La conséquence commerciale. Sur du copyleft fort livré en on-premise, il n’y a pas de secret de composition possible. Si le code combiné a une valeur concurrentielle, le composant doit être isolé dans un processus séparé, ou remplacé.
L’appliance : le piège de volume
Livrer une image machine ou une image de conteneur complète, c’est distribuer tout le système : noyau, bibliothèque C, utilitaires, interpréteurs, gestionnaire de paquets. Des milliers de composants, très majoritairement sous GPL et LGPL.
| Ce qu’on croit livrer | Ce qu’on livre réellement |
|---|---|
| Votre application | Votre application plus une distribution complète |
| Une dizaine de dépendances | Plusieurs milliers de paquets |
Bonne nouvelle : il s’agit très largement de simple agrégation — votre application n’est pas une œuvre dérivée du noyau. Mauvaise nouvelle : chaque paquet agrégé conserve ses obligations, dont l’attribution et, pour les composants GPL, la fourniture du source correspondant.
La parade standard : partir d’une image de base minimale, et s’appuyer sur les archives de source que l’éditeur de la distribution met déjà à disposition, en les référençant explicitement — à condition de vérifier que cette mise à disposition couvre bien la version exacte livrée.
Les pièges de ce scénario
L’offre écrite qui survit au contrat. En GPL-2.0, l’offre de fourniture du source doit rester valable trois ans après la dernière distribution — indépendamment de la fin du contrat commercial, de la fin de vie du produit ou du départ de l’équipe.
Les correctifs livrés au coup par coup. Chaque correctif transmis au client est une nouvelle distribution, avec ses obligations propres et son source correspondant.
La version modifiée pour un client. Un développement spécifique livré à un seul client reste une distribution. Le fait qu’il n’y ait qu’un destinataire ne change rien.
Le client qui redistribue. Rien ne l’en empêche pour les composants sous copyleft. Vos conditions contractuelles peuvent l’interdire pour votre code, pas pour le code tiers sous licence libre.
La double casquette AGPL. Vous distribuez, donc vous devez fournir le source. Le client exploite un service réseau, donc l’article 13 s’appliquera à lui s’il modifie. Cela mérite d’être écrit dans la documentation, sous peine de créer chez lui une non-conformité qu’il n’avait pas vue.
Ce que le CRA ajoute
Le scénario le plus lourd du point de vue réglementaire aussi. Le produit est mis sur le marché, avec toutes les obligations qui s’ensuivent, et deux difficultés propres :
- le SBOM doit couvrir tout ce qui est livré, image de base comprise. Un SBOM applicatif qui ignore les milliers de paquets du système sous-jacent est incomplet — voir Qualité et complétude ;
- la période de support porte sur l’ensemble : corriger une vulnérabilité de la bibliothèque C livrée dans votre appliance vous incombe, pendant cinq à dix ans.
C’est la raison technique pour laquelle les images minimales ne sont pas seulement une bonne pratique de sécurité : elles réduisent directement le périmètre de vos obligations, sur les deux terrains à la fois.