GPL ou AGPL : quelles différences pour distribuer son logiciel et choisir la bonne licence

GPL ou AGPL : la différence centrale concerne l’accès au code source lorsque le logiciel est exploité via un réseau. La GPL déclenche principalement ses obligations lors de la distribution du logiciel, tandis que l’AGPLv3 ajoute une obligation spécifique pour une version modifiée accessible à des utilisateurs à distance.

Le choix entre GPL et AGPL ne dépend donc pas d’un slogan sur l’open source, mais du mode réel de déploiement : application installée, logiciel embarqué, bibliothèque, service web ou API. Une licence mal interprétée peut imposer des obligations de code source incompatibles avec l’architecture ou le modèle commercial prévu.

GPL et AGPL : quels principes ont-elles en commun ?

La GPL et l’AGPL sont des licences de logiciel libre publiées par la Free Software Foundation. Une licence libre est une autorisation accordée par les titulaires des droits d’auteur pour exécuter, étudier, modifier et redistribuer un programme selon des conditions écrites. La gratuité n’est pas une condition : un logiciel sous GPL ou AGPL peut être vendu.

Le copyleft impose que les libertés accordées au destinataire soient préservées lors de la redistribution d’une œuvre dérivée. En pratique, un distributeur ne peut pas reprendre du code couvert, le modifier puis distribuer la version modifiée sous une licence propriétaire qui retirerait ces libertés.

Le code source, pas les données produites

Le code source logiciel désigne la forme du programme privilégiée pour y apporter des modifications. Le code source ne recouvre pas automatiquement les données saisies par les utilisateurs, les contenus publiés sur une plateforme, une base de données métier ou les résultats générés par le service. Le périmètre exact dépend toutefois des composants concernés et de leur intégration.

Ce que permettent les deux licences

• Exécuter le programme pour tout usage, y compris commercial.
• Étudier le code source et l’adapter aux besoins du projet.
• Redistribuer des copies du programme selon les conditions applicables.
• Distribuer des versions modifiées en conservant les avis et obligations de licence.

Une licence libre ne supprime pas le droit d’auteur : elle organise les autorisations et les conditions d’exercice de ce droit.

Les textes de référence restent les versions officielles des licences. La GNU GPL version 3 et la GNU AGPL version 3 ne doivent pas être confondues avec leurs versions antérieures, car les compatibilités et les clauses applicables varient selon la version retenue.

Quelle est la différence entre GPL et AGPL pour un logiciel en ligne ?

La différence GPL AGPL tient au déclencheur principal des obligations de partage du code. La GPLv3 vise la « transmission » du programme à un tiers, alors que l’AGPLv3 prévoit aussi un mécanisme pour une version modifiée avec laquelle des utilisateurs interagissent à distance via un réseau.

Un logiciel SaaS modifié sous AGPLv3 doit être analysé différemment d’une application GPL installée chez chaque client. L’AGPL cherche précisément à éviter qu’une modification reste inaccessible au public concerné lorsque le programme est exploité uniquement comme service en ligne.

La GPL : le cas typique de la distribution

La GPLv3 encadre notamment la fourniture d’exemplaires à des tiers. Une entreprise qui remet un logiciel GPL modifié à ses clients, sur support ou par téléchargement, doit respecter les obligations de licence applicables, dont la fourniture du code source correspondant dans les modalités prévues par le texte.

L’AGPLv3 : la clause d’interaction à distance

L’AGPLv3 reprend l’essentiel du mécanisme GPLv3 et ajoute, dans sa section 13, une exigence pour les versions modifiées utilisées pour interagir à distance via un réseau informatique. La version modifiée doit offrir de façon visible aux utilisateurs concernés une possibilité d’obtenir son code source correspondant.

Une connexion réseau isolée ne suffit pas à produire une réponse juridique universelle. L’analyse doit vérifier la version de la licence, l’existence d’une modification, le programme réellement accessible, l’interface offerte et la frontière entre composants indépendants.

Point de comparaison	GPLv3	AGPLv3	Conséquence pratique
Copyleft	Oui	Oui	Les redistributions d’œuvres dérivées restent encadrées.
Distribution à un client	Obligations de source applicables	Obligations de source applicables	Prévoir avis, licence et code source correspondant.
Service accessible en ligne	Pas de clause réseau équivalente	Clause de la section 13 pour les versions modifiées	Le SaaS sous AGPLv3 exige une vérification dédiée.
Version de licence	GPLv3	AGPLv3	Les règles de compatibilité doivent être vérifiées version par version.

Le point décisif n’est pas seulement « open source ou propriétaire », mais la manière dont le logiciel est assemblé, modifié et mis à disposition.

Comment choisir entre GPL ou AGPL selon son projet ?

Le choix GPL ou AGPL commence par une question opérationnelle : le logiciel sera-t-il remis à un utilisateur ou restera-t-il hébergé comme service accessible à distance ? La GPL convient souvent à un logiciel distribué, tandis que l’AGPLv3 répond plus directement à la volonté d’appliquer le copyleft à un service réseau modifié.

Une licence logiciel commercial peut rester GPL ou AGPL, mais le modèle de revenus doit supporter les obligations de redistribution. La vente de support, d’hébergement, d’intégration, de formation ou de garanties contractuelles reste possible ; le verrouillage exclusif du code distribué ne l’est pas dans le périmètre couvert.

Application à installer chez le client

Une application de bureau, un outil en ligne de commande ou un logiciel embarqué remis à un client entre dans un scénario de distribution. La GPLv3 constitue une option cohérente si le projet veut garantir la disponibilité du code source des versions distribuées et accepte le copyleft associé.

Service web, plateforme SaaS ou application métier hébergée

Un logiciel accessible par navigateur n’est pas distribué de la même manière qu’un installateur remis au client. L’AGPLv3 devient pertinente lorsqu’un éditeur souhaite que les modifications apportées à une version utilisée en réseau soient proposées aux utilisateurs distants selon les conditions de la licence.

Bibliothèque ou composant réutilisable

Une bibliothèque destinée à être liée à des logiciels variés mérite une analyse plus fine. La LGPL est une alternative réelle à considérer lorsqu’un projet veut autoriser plus largement l’utilisation d’une bibliothèque par des applications sous d’autres licences, sous réserve du respect de ses propres conditions.

Comparatif rapide avec la LGPL

• GPLv3 : copyleft fort pour les œuvres dérivées distribuées.
• AGPLv3 : GPLv3 complétée par une obligation relative aux versions modifiées accessibles par réseau.
• LGPLv3 : mécanisme pensé pour certaines bibliothèques, avec des conditions différentes sur la liaison et les modifications.

La GPLv3 autorise la combinaison avec du code AGPLv3 selon sa section 13, mais l’ensemble combiné doit être fourni sous les conditions de l’AGPLv3. La compatibilité ne doit jamais être supposée entre des composants GPLv2, GPLv3, AGPLv3 ou des licences « GPL uniquement » : le fichier de licence et les avis de chaque dépendance comptent.

Comment distribuer un logiciel libre : les étapes de conformité

La conformité GPL ou AGPL ne se résume pas à ajouter un fichier LICENSE dans un dépôt. Une distribution propre exige de relier chaque binaire, conteneur ou service publié à son code source correspondant, à ses avis de droit d’auteur et aux conditions des composants intégrés.

La meilleure protection contre une erreur de licence est un inventaire maintenu avant la sortie produit, pas une régularisation improvisée après livraison. Les étapes suivantes donnent un cadre technique et documentaire ; elles ne remplacent pas un conseil juridique adapté au projet.

1. Inventorier les dépendances : relever les bibliothèques, images de conteneur, modules, outils de build et leurs versions exactes.
2. Identifier les licences effectives : contrôler les fichiers de licence, les avis présents dans le dépôt et la documentation officielle des composants.
3. Délimiter les modifications : conserver la liste des correctifs internes, des forks et des modules ajoutés au programme couvert.
4. Préparer le code source correspondant : prévoir scripts de construction, fichiers de configuration nécessaires et instructions reproductibles lorsque la licence l’exige.
5. Publier les avis utiles : joindre les textes de licence, les notices de copyright et, pour l’AGPLv3 modifiée en réseau, un moyen visible d’accéder au source correspondant.
6. Faire valider les cas sensibles : soumettre les architectures hybrides, intégrations profondes et produits commerciaux à un juriste compétent en licences logicielles.

API, microservices et conteneurs : ne pas conclure trop vite

Une API est une interface de programmation qui permet à deux services de communiquer. Un appel API distant ne transforme pas automatiquement deux programmes séparés en une œuvre dérivée unique ; l’architecture, les dépendances, le couplage et les modalités de distribution doivent être examinés.

Les conteneurs peuvent compliquer la traçabilité, car une image livrée peut embarquer un système, des bibliothèques et un programme applicatif sous plusieurs licences. Un fichier SBOM, ou inventaire de composants logiciels, facilite la revue mais ne tranche pas à lui seul la qualification juridique.

Quelles erreurs fréquentes éviter avec la GPL et l’AGPL ?

Les difficultés viennent rarement d’une seule ligne de licence. Les incidents apparaissent quand une dépendance est ajoutée sans revue, quand le code source publié ne correspond pas au binaire diffusé ou quand une équipe assimile trop vite un simple appel réseau à une obligation générale de divulgation.

• Confondre usage interne et distribution : utiliser un programme n’a pas les mêmes effets que remettre des copies à des tiers. Documentez le flux de livraison réel.
• Oublier la version exacte : GPLv2, GPLv3 et AGPLv3 ne sont pas interchangeables. Conservez les formulations « only » ou « or later » lorsqu’elles figurent dans les avis.
• Publier un dépôt incomplet : un code source sans scripts, correctifs ou fichiers nécessaires à la construction peut être insuffisant selon le contexte.
• Traiter toutes les API comme une liaison : une communication réseau ne permet pas, à elle seule, de qualifier toute l’architecture. Analysez les composants et leurs relations.
• Ignorer les composants transitifs : une dépendance indirecte peut introduire une obligation qui n’apparaît pas dans le dépôt applicatif principal.

Sources utiles à consulter

Les documents suivants permettent de vérifier le texte applicable avant de choisir une licence libre ou de distribuer un logiciel :

• Free Software Foundation — GNU GPLv3 : texte complet de la licence et obligations liées à la transmission.
• Free Software Foundation — GNU AGPLv3 : texte complet, notamment la clause d’interaction avec les utilisateurs à distance.
• Free Software Foundation — GNU LGPLv3 : référence utile pour comparer le cas des bibliothèques.
• SPDX : standard de désignation et d’inventaire des composants logiciels, utile pour structurer une revue de dépendances.

Questions fréquentes sur GPL et AGPL

Peut-on vendre un logiciel sous GPL ou AGPL ?

Oui. La GPL et l’AGPL n’interdisent pas la vente d’un logiciel, d’un support ou d’une prestation associée. Le vendeur doit toutefois respecter les obligations de licence applicables, notamment celles portant sur le code source correspondant lors d’une distribution ou d’un cas réseau couvert par l’AGPLv3.

Peut-on utiliser du code GPL dans un logiciel propriétaire ?

La réponse dépend de la nature du code, de son intégration et de la version de licence. Distribuer une œuvre dérivée incorporant du code GPL sous une licence propriétaire pose généralement un problème de compatibilité. Une analyse juridique est recommandée avant toute intégration dans un produit fermé.

L’AGPL impose-t-elle de publier tout le code d’un site web ?

Non, cette formulation est trop large. L’AGPLv3 vise le code source correspondant d’une version modifiée du programme couvert, accessible à des utilisateurs qui interagissent avec elle via un réseau. Le périmètre ne se confond pas automatiquement avec tous les services, données ou composants d’un site.

Une API déclenche-t-elle automatiquement les obligations AGPL ?

Non. Un appel distant à une API ne suffit pas, à lui seul, à établir que tous les logiciels reliés forment une même œuvre soumise à l’AGPL. L’intégration technique, les modifications apportées et la séparation effective des programmes doivent être étudiées au cas par cas.

Peut-on changer la licence après avoir publié un logiciel ?

Le titulaire des droits peut publier ses futures versions sous une autre licence s’il détient les droits nécessaires sur le code. Les exemplaires déjà distribués sous GPL ou AGPL conservent les droits accordés par cette licence. Les contributions externes peuvent empêcher un changement unilatéral sans accord des contributeurs concernés.