Publication du code dérivé : ce qu’impose une licence open source
Une licence open source autorise l’utilisation, l’étude ou la modification d’un logiciel selon des conditions précises. Certaines sont permissives ; d’autres, fondées sur le copyleft, exigent des obligations particulières lorsque le programme est modifié puis distribué.
Le mot « publier » peut prêter à confusion : il ne signifie pas toujours rendre un logiciel accessible à toute personne. Selon la licence et le mode d’utilisation, il peut s’agir de fournir le code source aux destinataires d’une copie ou aux utilisateurs d’un service en réseau.
Le copyleft repose sur la réciprocité
Avec une licence réciproque comme la GNU GPL, la redistribution d’un programme dérivé entraîne des conditions de partage définies par la licence. L’objectif est de préserver les libertés accordées au code d’origine, y compris dans les versions modifiées distribuées.
Une entreprise peut donc utiliser un composant GPL en interne sans déclencher automatiquement les mêmes obligations qu’une livraison à un client. En revanche, avant la distribution du logiciel, elle doit examiner si son produit constitue une œuvre dérivée et respecter les conditions applicables.
À retenir pour l’analyse juridique :
- Licence exacte et version applicable
- Modification ou intégration du composant
- Destinataires et mode de mise à disposition
- Accès au code source correspondant
GNU GPL et distribution du logiciel : quand fournir le code source
La distinction entre usage interne et distribution permet de mieux comprendre les obligations de la GNU GPL. Lorsqu’un programme couvert est transmis à des tiers, la licence impose notamment de respecter les conditions de redistribution et de donner accès au code source correspondant selon ses modalités.
Identifier le périmètre du code dérivé
Le point délicat consiste à déterminer si le composant est simplement utilisé à côté du logiciel ou intégré dans un ensemble qui relève des obligations de la licence. Une bibliothèque incorporée dans un exécutable peut soulever des questions différentes d’un outil indépendant appelé séparément.
Le lien dynamique ne constitue pas une garantie automatique d’absence d’obligations. L’interprétation dépend du contexte, de la licence précise et des faits techniques ; la Free Software Foundation défend une lecture étendue pour certains modes de liaison, tandis que l’analyse juridique doit rester contextualisée.
Avant une livraison commerciale, une équipe peut vérifier les points suivants :
- Composants incorporés dans le binaire final
- Modifications apportées au code sous GPL
- Texte de licence et avis de droit d’auteur conservés
- Mécanisme prévu pour fournir le code source requis
Cette vérification évite de confondre la publication générale sur Internet avec la mise à disposition conforme aux destinataires concernés. Elle aide aussi à repérer les composants à isoler ou à remplacer avant la sortie du produit.
| Licence | Déclencheur principal | Portée générale |
|---|---|---|
| GPL | Redistribution d’un programme couvert ou dérivé | Réciprocité sur l’œuvre concernée |
| AGPL | Redistribution et certains usages accessibles par réseau | Obligations supplémentaires pour les utilisateurs distants |
| LGPL | Redistribution et modifications de la bibliothèque | Copyleft principalement centré sur la bibliothèque |
| MIT ou BSD | Redistribution du composant | Conservation des avis et conditions applicables |
AGPL et SaaS : les règles de publication liées au réseau
La GPL classique se concentre sur la redistribution, ce qui laisse une situation particulière lorsque le public utilise un logiciel à distance sans recevoir de copie. L’AGPL répond à cet enjeu en prévoyant des obligations spécifiques pour certains programmes modifiés accessibles par réseau.
Examiner le service réellement proposé
Si une entreprise exploite un logiciel modifié sous AGPL et permet à des utilisateurs d’interagir avec lui à distance, la licence peut exiger que ces utilisateurs puissent obtenir le code source correspondant. Cela ne signifie pas que tout service utilisant n’importe quel composant AGPL doit automatiquement publier l’ensemble de son infrastructure.
Le périmètre dépend notamment de la version de la licence, des modifications et de la relation entre le composant et le service. Une équipe qui prépare une offre SaaS doit donc examiner l’architecture et les conditions de la licence avant le déploiement, plutôt que supposer que l’absence de téléchargement écarte tout risque.
Pour cadrer l’évaluation d’un composant AGPL, documentez :
- Fonctions du logiciel accessibles aux utilisateurs
- Modifications réalisées sur le composant
- Interaction entre le service et les autres modules
- Modalités d’accès au code prévues par la licence
Cette démarche est particulièrement utile avant un audit d’investissement ou une cession, où les acquéreurs examinent la provenance des composants et la conformité des pratiques de développement.
LGPL, licences permissives et maintien d’un logiciel propriétaire
Les effets du copyleft varient selon la licence ; la LGPL illustre une approche intermédiaire. Elle vise principalement la bibliothèque elle-même : ses modifications restent soumises à la licence, tandis que le logiciel qui l’utilise peut, sous conditions, conserver une licence propriétaire.
Le mode d’intégration compte
Le lien dynamique facilite généralement le remplacement de la bibliothèque par une version modifiée, mais ne dispense pas de respecter les conditions de la LGPL. Une intégration statique peut nécessiter des informations ou des moyens permettant à l’utilisateur de modifier la bibliothèque et de relier le programme selon les termes applicables.
Les licences MIT, BSD et Apache 2.0 sont habituellement plus permissives sur la redistribution du code intégrateur. Elles imposent toutefois de conserver les avis requis et, pour Apache 2.0, de prendre en compte des dispositions spécifiques, notamment relatives aux brevets.
Pour choisir une stratégie d’intégration :
- Bibliothèque LGPL : vérifier liaison et possibilités de remplacement
- Licence MIT ou BSD : conserver les mentions et textes applicables
- Apache 2.0 : examiner les clauses de licence et de brevets
- Licence inconnue : suspendre l’intégration jusqu’à clarification
Qualifier les obligations de licence avant l’intégration
Une décision fiable croise la licence exacte et l’architecture prévue. Un composant permissif peut lui-même dépendre d’une bibliothèque copyleft : sans inventaire des dépendances transitives, l’entreprise risque de découvrir tardivement une obligation qu’elle n’avait pas anticipée.
Documenter les choix techniques et juridiques
Commencez par relever le nom du composant, la version et le fichier de licence, puis examinez les dépendances directes et indirectes avec un outil d’analyse de composition logicielle. Un inventaire automatisé aide à repérer les licences, mais les résultats doivent être vérifiés lorsque les métadonnées sont incomplètes ou ambiguës.
Ensuite, décrivez le mode d’intégration, les modifications et le contexte de distribution. Si une licence propose une option commerciale parallèle, comparez son coût avec celui d’une isolation, d’un remplacement ou d’une adaptation de l’architecture.
Une fiche de conformité peut consigner les éléments suivants :
- Nom, version et origine de chaque composant
- Licence déclarée et texte conservé
- Mode d’intégration et modifications réalisées
- Décision retenue et personne responsable de sa validation
Cette traçabilité renforce la transparence logicielle sans faire de l’open source un risque à éviter. Elle permet aux développeurs de profiter du logiciel libre tout en anticipant les conditions de redistribution et la publication du code source lorsque la licence l’exige.
