Pouvez-vous utiliser cette application auto-hébergée pour votre entreprise ? Checklist de diligence raisonnable sur les licences open source
L’auto-hébergement peut modifier la manière dont une application est exploitée, mais ne répond pas à lui seul aux questions de licence, de redistribution, de marque ou de divulgation du code source. Utilisez cette checklist pratique pour réunir des éléments probants, définir l’usage envisagé et savoir quand demander un avis juridique qualifié.
L’auto-hébergement ne répond pas à toutes les questions de licence
« Open source » ne correspond pas à un niveau d’autorisation unique, et l’accès à un dépôt de code source public ne suffit pas à déterminer si une entreprise peut utiliser, modifier, héberger, personnaliser avec sa marque ou redistribuer une application comme elle l’envisage. L’Open Source Initiative (OSI) établit directement cette distinction : l’open source concerne les conditions de distribution autant que l’accès au code source.
Si une application est réellement placée sous une licence open source conforme aux critères de l’OSI, cette licence ne peut pas restreindre l’utilisation dans un domaine d’activité particulier, y compris l’usage professionnel. C’est utile, mais cela ne clôt pas l’examen. Votre déploiement peut inclure des composants, ressources ou plugins sous des licences distinctes ; l’activité prévue peut impliquer une distribution ; et les noms, logos et domaines peuvent être régis par des règles de marque plutôt que par la licence logicielle.
Considérez cet article comme un cadre opérationnel de diligence raisonnable, et non comme un avis juridique. L’objectif est de remplacer les suppositions par un dossier vérifiable et d’identifier les situations qui justifient un avis juridique qualifié avant le déploiement.
- N’assimilez pas « code source disponible » à « open source ».
- N’assimilez pas l’hébergement interne à une autorisation de redistribuer des copies à des clients ou à des utilisateurs.
- Ne supposez pas qu’une licence à la racine du dépôt couvre tous les éléments du déploiement.
- Examinez les règles relatives aux marques et à la dénomination séparément des conditions de la licence logicielle.
Commencez par l’usage envisagé, et non par la liste des fonctionnalités de l’application
Avant de lire le texte de la licence, décrivez ce que votre organisation fera réellement. Les questions de licence deviennent plus claires lorsqu’elles sont liées à un modèle concret de déploiement et de distribution plutôt qu’à une volonté générale d’« utiliser le logiciel à des fins commerciales ».
Un outil utilisé uniquement par votre propre personnel présente une situation factuelle différente d’un service destiné aux clients, d’un déploiement personnalisé chez un client ou d’un produit qui intègre l’application en vue de sa redistribution. La même distinction s’applique si vous prévoyez de fournir à quelqu’un d’autre une image Docker, un programme d’installation, une arborescence de code source modifiée ou une instance gérée.
Formulez cette déclaration de manière suffisamment précise pour qu’un collègue puisse la confronter à la licence. Si l’usage envisagé évolue ultérieurement, rouvrez l’examen au lieu de vous fier à l’ancienne conclusion.
- Outil interne : qui peut y accéder et l’équipe le modifiera-t-elle ?
- Service destiné aux clients : des utilisateurs externes interagiront-ils avec l’application à distance ?
- Déploiement chez un client : remettez-vous une copie, une image, le code source ou une version modifiée ?
- Produit redistribué : intégrez-vous l’application ou des composants substantiels dans votre propre offre ?
- Image de marque : utiliserez-vous le nom du projet, son logo ou un nom similaire dans un produit, un service ou un domaine ?
- Intégration : quels plugins, bibliothèques, modèles, polices, thèmes, connecteurs et ressources seront inclus ?
Trouvez des éléments probants de licence faisant autorité et consignez la version examinée
Commencez par des éléments probants de première main pour la version exacte de l’application que vous prévoyez de déployer. Le fichier LICENSE d’un dépôt constitue un point de départ important, mais il doit être vérifié avec la distribution source, la documentation de l’éditeur ou du projet, les mentions de copyright et tout fichier LICENSE ou NOTICE inclus.
Consignez la version publiée, le tag d’image le cas échéant, ou le commit source que vous avez examiné. Une conclusion sur une licence sans référence de version est difficile à revoir lorsqu’une mise à niveau modifie les dépendances, les avis ou les éléments de distribution.
Lorsqu’une application est distribuée sans code source, la définition de l’OSI est également pertinente : pour une licence open source, le code source est la forme privilégiée pour effectuer des modifications, et les conditions de distribution doivent prévoir un moyen largement publicisé de l’obtenir lorsque le code source n’est pas distribué avec le produit. Ne déduisez pas qu’un projet est conforme aux critères de l’OSI du seul fait qu’un dépôt existe.
- Capturez l’URL source et la date d’accès.
- Enregistrez ou liez le texte exact de la licence et son identifiant, s’il est indiqué.
- Consignez la version de l’application, la référence de publication ou le commit.
- Recherchez les fichiers LICENSE, COPYING, NOTICE, les en-têtes de copyright et les avis de tiers.
- Comparez les éléments du dépôt avec la documentation officielle et les artefacts distribués.
- Consignez les contradictions, fichiers manquants et provenances incertaines comme questions non résolues.
Lisez le périmètre de la licence avant de comparer les applications
Ne choisissez pas une application uniquement selon ses fonctionnalités en traitant la licence indiquée comme une note de bas de page. Lisez le texte applicable à l’œuvre que vous utiliserez, en particulier les dispositions relatives à la modification, à la reproduction, à la distribution, aux avis, aux brevets et aux marques.
Par exemple, la licence Apache 2.0 comprend des conditions explicites lorsque des copies ou des œuvres dérivées sont reproduites et distribuées. Elles incluent la fourniture d’une copie de la licence, le marquage des fichiers modifiés, la conservation des avis pertinents et la préservation des attributions applicables du fichier NOTICE. Ces exigences sont liées à la reproduction et à la distribution ; une évaluation exacte dépend donc de la question de savoir si votre modèle de fourniture envisagé relève de ces activités.
Les intitulés de licence ne remplacent pas l’analyse d’une combinaison prévue. La FAQ GNU GPL décrit la compatibilité des licences selon que les licences concernées autorisent la combinaison envisagée, et indique que la forme de la combinaison peut avoir son importance. Lorsque votre offre combine des composants d’une manière qui n’est pas clairement documentée, c’est une raison de s’arrêter plutôt que de deviner.
- Identifiez l’œuvre couverte : l’application, un plugin, une bibliothèque, une image de conteneur ou un autre artefact.
- Identifiez vos actions : exécuter, modifier, copier, distribuer, empaqueter, fournir à un client ou exposer à distance.
- Lisez les conditions et exceptions dans le texte complet de la licence, et pas uniquement dans un résumé.
- Listez les avis requis, offres de code source ou marquages de modifications qui pourraient s’appliquer à votre modèle.
- Signalez les combinaisons de composants incertaines pour un examen spécialisé.
Vérifiez séparément les dépendances, plugins, modèles, polices et ressources intégrées
Un fichier de licence situé à la racine de l’application peut ne pas résoudre les droits relatifs à tout ce qui atteint vos utilisateurs ou est inclus dans votre build. Les recommandations de licence d’Apache, par exemple, reconnaissent que des œuvres tierces peuvent être incluses dans le produit d’un projet et que leur texte de licence peut figurer dans les fichiers LICENSE ou NOTICE, ou être disponible séparément.
Établissez un inventaire de ce qui est réellement déployé, et non seulement de ce qui apparaît à la racine du dépôt. Incluez les dépendances d’exécution, les dépendances de build expédiées dans un artefact, les plugins facultatifs que vous activez, les thèmes, polices, jeux de données, fichiers de modèles et autres ressources intégrées. Ne supposez pas que tous ces éléments relèvent des mêmes conditions que l’application principale.
SPDX est utile comme vocabulaire de documentation et comme format de nomenclature logicielle (SBOM). Ses concepts de relation incluent les dépendances, les manifestes de dépendances, les dépendances de build, les dépendances de développement et les dépendances d’exécution. Vous n’avez pas besoin d’un inventaire automatisé parfait avant de prendre une décision, mais vous avez besoin de suffisamment d’éléments probants pour identifier les composants qui influencent matériellement l’usage envisagé.
- Créez une ligne de composant pour chaque dépendance importante ou élément intégré.
- Consignez le nom du composant, sa version, sa source, les éléments probants de licence et son mode d’entrée dans la pile.
- Distinguez les éléments d’exécution des éléments réservés au build et au développement.
- Vérifiez les plugins et extensions activés séparément des options non utilisées.
- Recherchez les avis intégrés, textes de licence et exigences d’attribution.
- Considérez les composants inconnus ou personnalisés comme des bloqueurs s’ils seront distribués, modifiés ou exposés à des clients.
Dissociez les décisions relatives aux marques, à l’image de marque et aux domaines
Une licence logicielle ne constitue pas une autorisation générale d’utiliser les noms, logos ou éléments de marque d’un projet de quelque manière que ce soit. L’analyse des marques a un objectif différent : éviter toute confusion quant à l’origine, l’affiliation ou le soutien apporté.
La politique d’Apache illustre cette séparation. Elle identifie les noms de projets, noms de produits et logos comme des marques, tandis que le logiciel lui-même est distribué selon les conditions de sa licence logicielle. Pour les projets Apache en particulier, les œuvres dérivées ne doivent pas utiliser des noms de projets ou des logos de projets prêtant à confusion, et l’utilisation susceptible de créer une confusion des marques Apache dans des noms de domaine requiert une approbation écrite.
Utilisez la politique de marque propre au projet lorsqu’elle est disponible. Si vous comptez faire figurer le nom de l’application dans une offre client, modifier un logo, publier un fork avec une image de marque ou enregistrer un domaine associé, ajoutez ce projet au registre des éléments probants et demandez conseil lorsque la politique ne le couvre pas clairement.
- Le service accessible au public utilisera-t-il le nom ou le logo du projet ?
- Décrirez-vous le service comme officiel, affilié ou soutenu ?
- Un fork modifié conservera-t-il, remplacera-t-il ou complétera-t-il l’image de marque existante ?
- Le domaine prévu contient-il le nom du projet ou de l’organisation ?
- Le projet publie-t-il une politique de marque ou des consignes d’utilisation de la marque ?
- La présentation envisagée risque-t-elle de prêter à confusion pour les utilisateurs ?
Comprenez précisément les questions de service réseau et de divulgation du code source
Ne supposez pas que mettre un logiciel à disposition sur un réseau produit toujours le même effet que distribuer une copie. La GPLv3 précise qu’une simple interaction avec un utilisateur via un réseau informatique, sans transfert de copie, ne constitue pas en elle-même une « transmission » (« conveying ») au sens de ce texte de licence.
L’AGPLv3 contient une disposition conditionnelle différente pour une version modifiée qui permet une interaction réseau à distance. La section 13 impose à la personne qui modifie le programme d’offrir aux utilisateurs distants la possibilité de recevoir le code source correspondant de cette version modifiée. Ce n’est pas une raison de faire des affirmations générales sur tout déploiement hébergé ; c’est une raison d’identifier la licence exacte, de déterminer si vous avez modifié le programme couvert et s’il permet une interaction à distance.
Si votre service comprend plusieurs composants, analysez la licence du composant concerné et la nature de l’intégration. La FAQ GNU GPL indique que la frontière entre des programmes distincts et un programme combiné est en définitive une question juridique. Une architecture non évidente n’est pas un contexte propice à une conclusion de conformité prise à la légère.
- Identifiez si un composant accessible à distance relève de conditions comportant des dispositions sur l’interaction réseau.
- Consignez si votre équipe a modifié ce composant et où se situent les modifications.
- Déterminez si les utilisateurs reçoivent une copie, interagissent uniquement avec un service, ou les deux.
- Documentez la manière dont l’accès au code source, les avis et les enregistrements de modifications seraient fournis si nécessaire.
- Faites remonter les combinaisons incertaines, forks et obligations de divulgation du code source avant le lancement.
Établissez un registre des éléments probants avant le déploiement
Un registre concis des éléments probants transforme la diligence raisonnable en matière de licences en un contrôle opérationnel. Il doit permettre à une autre personne de comprendre ce qui a été examiné, d’où viennent les éléments probants, ce que l’organisation prévoit de faire et ce qui reste non résolu.
Conservez le registre avec le dossier de déploiement et mettez-le à jour lorsque vous changez la version de l’application, activez un nouveau plugin, modifiez du code, changez d’image, ajoutez un modèle de fourniture au client ou modifiez l’image de marque publique. C’est plus utile qu’une affirmation ponctuelle par oui ou par non, car les piles auto-hébergées évoluent.
Utilisez des identifiants standard et les informations de SBOM lorsqu’ils sont disponibles, mais ne laissez pas un identifiant familier remplacer l’examen du texte applicable, des avis et du modèle de fourniture.
- Nom de l’application ou du composant.
- Version, publication, référence d’image ou commit examiné.
- URL source et emplacement des éléments probants de licence.
- Identifiant de licence déclaré et lien vers le texte complet.
- Observations concernant le copyright, NOTICE et les attributions.
- Notes sur les dépendances et relations, y compris les éléments d’exécution et de build.
- Modifications effectuées, prévues ou héritées.
- Plan de distribution, de remise au client et de service à distance.<br>Plan concernant les marques, logos et domaines.<br>Questions ouvertes, responsable, décision d’escalade et date d’examen.
Questions fréquentes
L’auto-hébergement d’une application signifie-t-il que nous pouvons l’utiliser à des fins commerciales ?
Pas à lui seul. Une licence open source conforme aux critères de l’OSI ne peut pas restreindre l’utilisation dans un domaine d’activité particulier, y compris l’usage professionnel. Vous devez toutefois vérifier que l’application exacte et ses composants relèvent bien des conditions indiquées, puis évaluer séparément la distribution, les modifications, les avis, les marques et votre plan de déploiement spécifique.
Un dépôt Git public constitue-t-il une preuve suffisante qu’une application est open source ?
Non. L’OSI explique que l’open source ne se limite pas à l’accès au code source ; les conditions de distribution doivent satisfaire à la Définition de l’Open Source. Examinez les éléments probants de licence faisant autorité pour la version que vous prévoyez d’utiliser.
Devons-nous examiner les dépendances si l’application possède un fichier LICENSE ?
Oui. Des œuvres tierces peuvent avoir des textes de licence ou des avis distincts. Inventoriez les dépendances d’exécution importantes, les sorties de build distribuées, les plugins, modèles, polices, thèmes et ressources intégrées, puis consignez les éléments probants de leur licence et leur rôle dans la pile déployée.
Héberger un logiciel sous GPL pour des utilisateurs compte-t-il automatiquement comme une distribution ?
La GPLv3 indique qu’une simple interaction réseau sans transfert de copie ne constitue pas une transmission. Le résultat précis dépend de la licence applicable, du composant et de ce que vous fournissez réellement. Ne généralisez pas cette affirmation à toutes les licences ou architectures.
Qu’est-ce qui est différent avec l’AGPLv3 pour un service hébergé ?
La section 13 de l’AGPLv3 comprend une obligation conditionnelle pour une version modifiée qui permet une interaction réseau à distance : les utilisateurs distants doivent se voir proposer de manière visible l’accès au code source correspondant de la version modifiée. Déterminez si vous avez modifié le programme couvert et obtenez un avis qualifié si l’application de l’obligation n’est pas claire.
Pouvons-nous utiliser le nom et le logo du projet dans notre service hébergé ?
Il s’agit d’une question de marque et d’image de marque, distincte de la licence logicielle. Examinez la politique de marque du projet, en particulier avant d’utiliser un logo, de promouvoir un fork modifié, de revendiquer une affiliation ou d’enregistrer un domaine associé.
Sources et lectures complémentaires
- The Open Source Definition — Open Source Initiative
- Apache License, Version 2.0 — Apache Software Foundation
- Apache Licensing and Distribution FAQ — Apache Software Foundation
- SPDX Overview — SPDX
- SPDX Specification: Relationships Between SPDX Elements — SPDX
- GNU Affero General Public License v3 — GNU Project / Free Software Foundation
- GNU General Public License v3 — GNU Project / Free Software Foundation
- GNU GPL FAQ — GNU Project / Free Software Foundation
- Apache Software Foundation Trademark Policy — Apache Software Foundation
- Docker Compose documentation — Docker