Neuf scénarios de distribution

Chaque page suit la même trame : ce qui se passe réellement (y a-t-il distribution ? interaction réseau ? liaison ?), le verdict par famille, les pièges propres au scénario, et ce que le CRA y ajoute.

Les trois questions qui classent un scénario

Avant de chercher votre cas dans la liste, répondez à ces trois questions : elles suffisent à prédire l’essentiel.

Question	Si oui	Si non
Un tiers reçoit-il le logiciel sous une forme exécutable ?	Le copyleft se déclenche	La GPL est sans effet
Un tiers interagit-il avec lui par un réseau ?	Le copyleft réseau se déclenche	L’AGPL est sans effet
L’utilisateur peut-il remplacer le composant par une version modifiée ?	La LGPL est satisfaite	La LGPL impose de le rendre possible

Le détail de ces mécanismes est dans Ce qui déclenche une obligation.

Le classement des neuf scénarios

Du plus permissif au plus contraint :

Cas général vient en premier parce que ce n’est pas un produit : c’est la posture par défaut, celle qu’on applique tant qu’on ne sait pas encore où le composant finira — et celle qui doit gouverner une bibliothèque de base réutilisée partout.

Les huit autres sont classés du moins au plus contraint :

Rang	Scénario	Ce qui le caractérise
1	Outil interne	Aucune distribution — presque tout est permis
2	Backend SaaS	Pas de distribution, mais exposition réseau
3	Bibliothèque / SDK	Vous êtes l’amont : votre licence contraint vos utilisateurs
4	Application bureau / CLI	Distribution binaire classique
5	On-premise	Distribution complète, système d’exploitation compris
6	Frontend web	Distribution de code source, presque toujours ignorée
7	Application mobile	Distribution + conditions de magasin restrictives
8	Embarqué / IoT	Distribution + verrouillage matériel

Un produit relève souvent de plusieurs scénarios

C’est le piège d’application le plus fréquent. Un même produit combine :

• un backend SaaS, qui ne distribue rien ;
• un frontend web, qui distribue du code à chaque visiteur ;
• une application mobile, soumise aux conditions des magasins ;
• un agent installé chez le client, qui est une distribution binaire ;
• une image de conteneur publiée sur un registre, qui est aussi une distribution ;
• une éventuelle édition on-premise.

Chaque brique doit être évaluée dans son propre scénario, avec sa propre liste de licences autorisées. Un composant acceptable dans le backend peut être interdit dans l’agent, et la politique de licences doit le refléter — voir Propriété intellectuelle, qui décline vos listes par contexte d’usage.

La règle de la brique la plus contrainte. Si le même dépôt sert à construire le backend et l’agent installé chez le client, c’est le régime de l’agent qui s’applique à tout le dépôt. Séparer les dépôts est parfois la seule façon de conserver une liberté de choix sur les composants du backend.