Le non-respect de licences logicielles : contentieux et risques pour les développeurs

Cet article est publié à titre d'information générale uniquement et ne constitue en aucun cas un avis juridique. Aucune disposition du présent article ne crée de relation client avec un professionnel du droit. Les lois varient selon les juridictions. Consultez un professionnel du droit qualifié pour obtenir des conseils adaptés à votre situation particulière.

1. Introduction

Les licences logicielles constituent l'un des domaines les plus mal compris du développement moderne. Une idée fausse courante consiste à croire que le fait de rendre le code source accessible au public fait automatiquement du logiciel un logiciel libre. En réalité, un projet peut être propriétaire même lorsque son code source est accessible. On parle alors de logiciel à code source disponible, qui comporte des restrictions qu'il est facile de négliger.

1.1 Vue d'ensemble

Les logiciels open source sont devenus la pierre angulaire du développement moderne, la grande majorité des applications reposant sur des bibliothèques, des frameworks et des outils open source. Cependant, les libertés accordées par les licences open source s'accompagnent d'obligations que de nombreux développeurs et de nombreuses entreprises négligent ou comprennent mal. Leur non-respect peut avoir de lourdes conséquences : mesures judiciaires imposant le rappel de produits ou la mise à disposition du code source, mais aussi dommages-intérêts pouvant atteindre plusieurs centaines de milliers d'euros. Cet article recense des décisions de justice et des accords transactionnels documentés concernant des développeurs et des entreprises ayant utilisé des logiciels open source en violation des conditions de leur licence.

Le cadre juridique a considérablement évolué. À l'origine, les licences open source étaient parfois considérées comme dépourvues de force contraignante ou comme de simples déclarations d'intention. Aujourd'hui, des juridictions en France, en Allemagne, en Italie et aux États-Unis ont confirmé qu'elles s'inscrivent pleinement dans le régime ordinaire du droit d'auteur, sans dépendre d'une quelconque exception, et que leur violation peut constituer un acte de contrefaçon.

1.2 Définitions

Avant d'aborder les affaires, il est utile de clarifier certains termes qui apparaissent tout au long de cet article.

Pourquoi une licence est nécessaire

En vertu de la Convention de Berne, la protection par le droit d'auteur est automatique : elle naît dès la création de l'œuvre, sans formalité d'enregistrement ni mention de réserve des droits. Par défaut, le code source d'un logiciel est donc protégé selon le principe « tous droits réservés » : les tiers ne sont pas autorisés à le copier, à le modifier ou à le distribuer. Une licence open source est l'instrument par lequel l'auteur accorde expressément au public certaines de ces prérogatives exclusives, sous réserve de conditions. La simple publication du code source sans licence ne rend donc pas le logiciel open source, ni même juridiquement utilisable par des tiers : le code demeure intégralement protégé, sans autorisation d'utilisation.

Les organisations

Plusieurs organisations sont présentées dans le présent article en raison de leur rôle dans la promotion, l'interprétation ou la défense des licences logicielles :

• Software Freedom Conservancy (SFC) : organisation à but non lucratif dont la mission est de promouvoir et de défendre le droit de réparer, d'améliorer et de réinstaller les logiciels. Elle fournit une infrastructure et des services à ses projets membres dans le domaine du logiciel libre et open source, et mène également des actions visant au respect des licences copyleft.

• Free Software Foundation (FSF) : organisation à but non lucratif qui défend les droits des utilisateurs d'ordinateurs à utiliser, étudier, copier, modifier et redistribuer des programmes. La FSF veille au respect de la GNU GPL et de la LGPL au moyen d'actions de mise en conformité et, lorsque cela s'avère nécessaire, de procédures judiciaires destinées à protéger les droits accordés par ces licences.

• Open Source Initiative (OSI) : une organisation à but non lucratif dédiée à la promotion et à la protection des logiciels open source. L'OSI maintient la Définition Open Source, examine et approuve les licences en tant que licences open source, et plaide pour l'adoption et le développement de logiciels open source.

Bien que les avis de ces organisations soient largement respectés dans le secteur technologique, celles-ci ne sont pas des autorités publiques et leurs interprétations ne s'imposent pas aux tribunaux. Une juridiction interprète et applique une licence logicielle à partir de son propre examen du texte et du droit applicable, indépendamment de la qualification retenue par la FSF, la SFC ou l'OSI. Par exemple, dans l'affaire Neo4j, Inc. v. PureThink, LLC, le tribunal a refusé de se fonder sur un témoignage relatif à la position de la Free Software Foundation sur l'AGPL et s'est attaché au texte de la licence ainsi qu'aux principes établis du droit des contrats et du copyright. Cette affaire montre que les juridictions accordent généralement la primauté au libellé de la licence et aux règles de droit applicables plutôt qu'aux commentaires d'organisations ayant participé à sa rédaction ou à sa promotion.

Open source et code source disponible (source-available)

L'Open Source Initiative (OSI) établit la Open Source Definition (OSD), un ensemble de dix critères qu'une licence de logiciel doit satisfaire pour être considérée comme open source. Ces critères comprennent la libre redistribution, l'accès au code source et l'autorisation de créer et de distribuer des œuvres dérivées.

À l'inverse, les licences dites source-available donnent accès au code source, mais imposent des restrictions incompatibles avec la OSD. Parmi les restrictions courantes figurent les limitations relatives à l’utilisation commerciale, à la fourniture du logiciel en tant que service ou à la création de produits concurrents. Par conséquent, les logiciels « source-available » ne sont généralement pas considérés comme open source par l’OSI.

Licences les plus courantes

Les modèles de licence les plus courants discutés dans l'écosystème open source sont :

• Les licences permissives (par exemple MIT, BSD et Apache 2.0) imposent peu de restrictions et exigent généralement seulement le maintien des mentions d'attribution et la reproduction de la licence. Elles permettent d'intégrer le logiciel à des produits propriétaires.
• Les licences copyleft (par exemple GPL, LGPL et AGPL) exigent que les versions modifiées et, dans certains cas, les œuvres plus vastes qui incorporent le logiciel soient distribuées sous les mêmes conditions lorsqu'elles sont transmises à des tiers. Les destinataires successifs conservent ainsi les mêmes libertés. La LGPL autorise certaines formes d'édition de liens avec des logiciels propriétaires, sous les conditions qu'elle prévoit, tandis que l'AGPL étend les obligations de copyleft à certains logiciels accessibles par l'intermédiaire d'un réseau.
• Les licences propriétaires limitent l'utilisation, la modification et la distribution selon les conditions fixées par le titulaire des droits d'auteur.

1.3 Qui veille au respect des licences open source ?

Les actions engagées pour faire respecter les licences open source ne sont pas toutes motivées par les mêmes raisons. Il est essentiel de comprendre qui intente une action et pourquoi afin d’évaluer le risque et de choisir la réponse appropriée. Les plaignants se répartissent généralement en trois catégories :

• Les organisations de défense (telles que la Free Software Foundation, le Software Freedom Law Center, la Software Freedom Conservancy et gpl-violations.org) recherchent avant tout la mise en conformité. L'action en justice constitue un dernier recours. Les accords sont généralement conclus rapidement, rendus publics et centrés sur la régularisation de la situation plutôt que sur l'obtention de dommages-intérêts élevés.
• Les demandeurs stratégiques sont généralement des entreprises qui invoquent le non respect des licences open source dans le cadre d'une stratégie juridique ou concurrentielle plus large. Ils peuvent demander des mesures d'interdiction, des dommages-intérêts importants ou chercher à perturber le marché. Les accords interviennent alors généralement plus tard et demeurent confidentiels.
• Les auteurs individuels peuvent agir sans le soutien d'une organisation et réclamer parfois le paiement d'une licence commerciale plutôt qu'une mise en conformité. Avec la généralisation de l'open source, certains juristes ont averti que de tels auteurs pourraient se comporter en « chasseurs de droits d'auteur » (copyright trolls), en faisant valoir tardivement des droits contre des entreprises dont les procédures de conformité sont insuffisantes.

Les affaires présentées dans cet article impliquent ces trois catégories. Le type de plaignant explique souvent pourquoi certaines affaires se sont réglées à l’amiable par un engagement de mise en conformité, tandis que d’autres ont donné lieu à des litiges prolongés et à des dommages-intérêts importants.

2. Affaires emblématiques relatives aux licences open source

2.1 Welte c. Sitecom Deutschland GmbH (2004, Allemagne)

Cette affaire est largement considérée comme la première application judiciaire réussie de la Licence publique générale GNU (GPL). En 2004, Harald Welte, l'un des principaux développeurs du projet netfilter/iptables, a découvert que Sitecom Deutschland GmbH distribuait un routeur sans fil intégrant un logiciel du projet placé sous GPL. Sitecom ne respectait pas plusieurs obligations essentielles de la licence, notamment la fourniture du code source correspondant et des informations requises sur la licence.

Welte a demandé au tribunal régional de Munich (Landgericht München I) d'ordonner en référé à Sitecom de suspendre la distribution des routeurs jusqu'à sa mise en conformité avec la GPL. En avril 2004, le tribunal a prononcé cette mesure provisoire d'interdiction, dont Sitecom a fait appel.

Une mesure provisoire d'interdiction (prononcée par le tribunal allemand) est une décision judiciaire temporaire prononcée au début d'une procédure afin d'empêcher une partie d'accomplir un acte déterminé dans l'attente d'une décision définitive.

Dans sa décision, le tribunal de Munich a confirmé la mesure et reconnu à la GPL la valeur d'une licence de droit d'auteur juridiquement valable. Le tribunal a estimé que les droits de copier, de modifier et de distribuer le logiciel n'étaient accordés que si les conditions de la licence étaient respectées. Parce que Sitecom avait distribué le logiciel sans respecter ces conditions, elle ne pouvait se prévaloir des autorisations de la GPL.

Bien que le tribunal ne se soit pas prononcé définitivement sur chacune des dispositions de la GPL, cet arrêt a apporté un soutien judiciaire solide à l'idée selon laquelle les obligations clés de la GPL, telles que la mise à disposition du code source et le respect des mentions de licence requises, sont juridiquement opposables en vertu du droit d'auteur. Cette décision a été largement interprétée comme confirmant que la GPL est une licence contraignante et opposable en droit allemand.

L'affaire a ensuite été réglée à l'amiable. Sitecom a accepté de se conformer à la GPL en mettant le texte de la licence à disposition et en fournissant des informations sur l'accès au code source correspondant. L'affaire a marqué un tournant dans la défense des licences de logiciels libres et open source. Elle a démontré que la GPL pouvait être efficacement invoquée devant une juridiction européenne et a ouvert la voie à de nombreuses actions ultérieures en Allemagne et dans le reste de l'Europe.

2.2 Jacobsen c. Katzer (2008, Cour d'appel fédérale des États-Unis)

Cette affaire est généralement considérée comme l'un des arrêts de principe les plus importants du droit américain des licences open source. Robert Jacobsen maintenait un projet de logiciel open source pour trains miniatures appelé JMRI, sous licence Artistic License. Matthew Katzer et sa société KAM Industries ont incorporé le code de Jacobsen dans un produit commercial sans respecter les conditions de la licence, qui comprenaient l'obligation d'identifier la source du code, de rendre visible le nom de l'auteur original et d'indiquer comment les fichiers modifiés différaient de l'original. La juridiction de première instance a d'abord considéré que l'Artistic License était une licence non exclusive et que sa violation relevait uniquement d'un manquement contractuel, et non de la contrefaçon. Jacobsen ne pouvait donc pas solliciter de mesure d'interdiction, mais seulement des dommages-intérêts, d'un montant limité.

Une mesure d'interdiction ou d'exécution (injunctive relief en droit américain) est une mesure ordonnée par un juge afin d'obliger une partie à cesser un comportement ou à accomplir certains actes pour prévenir un préjudice.

En appel, la Cour d'appel fédérale a infirmé cette décision dans un arrêt de principe rendu en 2008. Elle a jugé que les clauses en cause constituaient bien des conditions de la licence dont le respect pouvait être exigé sur le fondement du copyright, et non de simples obligations contractuelles. Selon la Cour, le licencié qui ne respecte pas ces conditions perd l'autorisation d'utiliser, de copier ou de distribuer le logiciel. La poursuite de ces actes constitue alors une contrefaçon. L'arrêt a ainsi consacré le principe fondamental selon lequel les licences open source peuvent être défendues sur le fondement du copyright, permettant aux concédants de solliciter des mesures d'interdiction ou d'exécution, dont la portée dépasse celle d'une simple indemnisation. Cette affaire a fondamentalement changé la manière dont les entreprises perçoivent le risque de non-conformité aux licences open source.

2.3 Actions visant à faire respecter la GPL de BusyBox (2007-2010, États-Unis)

Les affaires BusyBox ont été déposées par le Software Freedom Law Center (SFLC) devant les tribunaux de district fédéraux américains et se sont généralement réglées avant jugement.

Il s'agit des premières actions en justice engagées aux États-Unis pour faire respecter la GPL. BusyBox est une collection d'utilitaires Unix couramment utilisés dans les systèmes embarqués, sous licence GPLv2. Le SFLC, agissant au nom des développeurs de BusyBox Erik Andersen et Rob Landley, a déposé la première poursuite en septembre 2007 contre Monsoon Multimedia. Monsoon avait distribué du code BusyBox dans le firmware de son produit Hava digital TV sans fournir le code source comme l'exige la GPL. L'affaire a été réglée en octobre 2007, Monsoon acceptant de se conformer à la GPL, de nommer un responsable de la conformité open source et de verser une somme non divulguée aux demandeurs.

Cette affaire a été suivie par des poursuites supplémentaires contre d'autres entreprises, dont Xterasys, High-Gain Antennas, et finalement quatorze défendeurs en 2009. En 2010, la Software Freedom Conservancy a obtenu le premier jugement rendu par défaut dans une affaire relative à la GPL aux États-Unis : le tribunal a définitivement ordonné au contrevenant de cesser de distribuer BusyBox. Ces affaires ont établi que la GPL pouvait être invoquée devant les juridictions américaines et que les entreprises ne pouvaient pas ignorer les obligations de copyleft dans les systèmes embarqués (embedded systems). La campagne menée autour de BusyBox a fortement sensibilisé ce secteur aux exigences de la GPL.

2.4 Free Software Foundation c. Cisco Systems (2008-2009, États-Unis)

En décembre 2008, le Software Freedom Law Center (SFLC) a déposé une poursuite pour contrefaçon au nom de la Free Software Foundation (FSF) contre Cisco Systems pour des violations de la GPL et de la LGPL devant le tribunal de district des États-Unis pour le district sud de New York. Les violations concernaient la division Linksys de Cisco, qui distribuait des produits contenant des logiciels sous licence GPL sans fournir le code source correspondant. Le problème était connu depuis au moins 2003, lorsque des passionnés ont découvert que le routeur sans fil Linksys WRT54G contenait du code sous licence GPL, notamment le noyau Linux et BusyBox. Malgré des années de discussions, Cisco n'avait pas réussi à atteindre une conformité totale sur l'ensemble de ses gammes de produits.

L'affaire a été réglée en mai 2009 avec un accord à l'amiable, Cisco acceptant de nommer un administrateur chargé d'assurer la conformité des produits Linksys aux licences de logiciels libres, de publier le code source de tous les produits Linksys contenant des logiciels sous licence GPL et verser une somme d'argent à la FSF. Cette affaire a été particulièrement significative car elle impliquait une grande entreprise technologique (Cisco avait acquis Linksys pour 500 millions de dollars) et a démontré que même les plus grandes sociétés ne sont pas à l'abri de l'application de la GPL. L'accord à l'amiable a également établi un modèle de conformité selon lequel les entreprises nomment des responsables dédiés à la conformité open source, une pratique qui est depuis devenue la norme au sein des grandes entreprises technologiques.

2.5 Artifex Software c. Hancom (2016-2017, États-Unis)

Artifex Software, le développeur de Ghostscript (un interpréteur PostScript et PDF largement utilisé), a poursuivi la société sud-coréenne Hancom pour avoir utilisé Ghostscript dans sa suite Thinkfree Office sans se conformer à la GPL ni acheter une licence commerciale. Ghostscript est à double licence : les utilisateurs peuvent soit acheter une licence commerciale, soit l'utiliser sous la GPL, qui exige que toute œuvre dérivée soit également distribuée sous la GPL. Hancom a distribué Ghostscript dans le cadre de son produit propriétaire sans acheter de licence commerciale et sans respecter les exigences de la GPL, notamment l'absence des mentions requises et le défaut de distribuer le code source correspondant.

Dans une décision importante de 2017, le tribunal fédéral du district nord de la Californie a rejeté la requête de Hancom tendant au rejet de l'action et jugé que la GPL constituait à la fois une licence et un contrat susceptible d'exécution forcée. Selon le tribunal, sa violation pouvait fonder aussi bien une action en contrefaçon qu'une action en responsabilité contractuelle. Ce double fondement expose les contrevenants à une responsabilité potentielle sur deux terrains juridiques distincts et accroît donc sensiblement le risque. L'affaire a finalement été réglée, mais la décision sur la double nature de la GPL continue d'être citée dans les affaires de licences open source.

2.6 Software Freedom Conservancy c. Vizio (2021-aujourd'hui, États-Unis)

En octobre 2021, la Software Freedom Conservancy (SFC) a intenté une action en justice contre Vizio Inc., un fabricant de téléviseurs, pour des violations de la GPL et de la LGPL. Les produits SmartCast TV de Vizio contiennent des logiciels sous licence GPLv2 et LGPLv2.1, notamment le noyau Linux et d'autres composants. Vizio avait refusé à plusieurs reprises de fournir le code source correspondant comme l'exigeaient ces licences. Ce qui rendait cette affaire unique est que la SFC a intenté l'action non pas en tant que titulaire du droit d'auteur mais en tant que tiers bénéficiaire de la GPL, en faisant valoir que toute personne recevant un logiciel sous licence GPL devait avoir le droit de faire respecter les clauses de cette licence. Il s'agissait là d'une théorie juridique novatrice qui n'avait encore jamais été mise à l'épreuve devant les tribunaux américains.

Vizio a d'abord tenté de porter l'affaire devant une juridiction fédérale en invoquant le copyright, mais l'affaire a été renvoyée devant les juridictions californiennes après que la cour a jugé que le Copyright Act ne faisait pas préemption sur la demande en rupture de contrat. En décembre 2023, la Cour supérieure de Californie a rejeté la requête en jugement sommaire de Vizio sur la question du tiers bénéficiaire, jugeant qu'il existait une question litigieuse devant être tranchée au procès quant à savoir si la SFC était un bénéficiaire voulu de la GPL. La cour a estimé que permettre aux destinataires de faire respecter leur droit à recevoir le code source est « essentiel et nécessaire » aux objectifs de la GPL, dans la mesure où les titulaires de droits d'auteur n'auraient aucune incitation économique à faire respecter eux-mêmes cette clause.

En décembre 2025, la même cour a fait droit à la requête en jugement sommaire partiel de Vizio (summary adjudication) sur une question plus étroite, jugeant que la GPLv2 et la LGPLv2.1 n'imposent pas aux fabricants de permettre aux utilisateurs de réinstaller un logiciel modifié sur leurs appareils tout en préservant leur fonctionnement. L'obligation se limite à fournir le code source sous une forme permettant aux utilisateurs de l'obtenir et de le modifier pour d'autres usages. Il convient de noter que cette clarification ne vaut que pour les licences en version 2 : la GPLv3 et la LGPLv3 exigent explicitement des distributeurs qu'ils fournissent les informations d'installation pour certains produits destinés aux utilisateurs. La question centrale, celle de la qualité de la SFC à faire respecter la GPL en tant que tiers bénéficiaire, restait non tranchée, l'affaire se dirigeant vers un procès (initialement prévu en janvier 2026). Si la SFC obtient gain de cause sur cette question, cela ouvrirait la possibilité pour les utilisateurs en aval et les consommateurs, et non plus seulement pour les titulaires de droits d'auteur, de faire appliquer les licences open source. Cela élargirait ainsi considérablement le champ de leur application.

2.7 IT Development SAS c. Free Mobile SAS (2019, CJUE)

Bien qu'il ne s'agisse pas d'une affaire relative à l'open source, cet arrêt de la Cour de justice de l'Union européenne (CJUE) a tranché une question centrale : la violation d'une licence logicielle n'expose-t-elle qu'aux voies de droit contractuelles, ou également aux sanctions plus sévères de la contrefaçon du droit d'auteur ? IT Development SAS, titulaire des droits d'auteur sur le logiciel ClickOnSite, reprochait à son licencié Free Mobile SAS d'avoir modifié le code source sans autorisation. Free Mobile soutenait qu'il s'agissait d'une simple question de responsabilité contractuelle relevant du droit français, et la cour d'appel de Paris a posé une question préjudicielle à la CJUE, lui demandant si une telle modification non autorisée relève de la directive 2004/48/CE relative au respect des droits de propriété intellectuelle et de la directive 2009/24/CE concernant la protection juridique des programmes d'ordinateur, ou si elle relève uniquement de la responsabilité contractuelle.

Dans son arrêt du 18 décembre 2019 (affaire C-666/18), la CJUE a jugé que la modification non autorisée d'un logiciel par le licencié peut constituer une atteinte aux droits de propriété intellectuelle, et non un simple manquement contractuel. La directive 2009/24/CE réservant au titulaire des droits le droit exclusif d'autoriser les modifications du programme, un même fait peut constituer à la fois un manquement contractuel et une contrefaçon, ce qui permet au titulaire d'invoquer les moyens de sanction renforcés de la directive 2004/48/CE (mesures d'interdiction, dommages-intérêts, mesures de conservation des preuves). Ce raisonnement rejoint celui de l'affaire Jacobsen c. Katzer (section 2.2) et a préparé le terrain pour Entr'Ouvert c. Orange (section 2.8) : en droit de l'Union, la violation des conditions d'une licence relève de la contrefaçon, et pas seulement du droit des contrats.

2.8 Entr'Ouvert c. Orange S.A. (2011-2024, France)

Cette affaire française oppose Entr'Ouvert, petite entreprise qui développe Lasso, une bibliothèque libre d'authentification SAML diffusée sous double licence, GNU GPL ou licence commerciale, à Orange S.A. (anciennement France Telecom). Après un appel d'offres de l'État, Orange a intégré Lasso dans sa plateforme de gestion d'identités et vendu la solution à l'État français à ses propres conditions, sans respecter la GPL. Entr'Ouvert l'a assignée en contrefaçon de droits d'auteur et en parasitisme. Le litige a duré plus de dix ans autour d'une question centrale : la violation de la GPL relève-t-elle, en droit français, de la contrefaçon ou du manquement contractuel ? Les réparations ouvertes différaient fortement selon la qualification retenue.

Après un jugement du tribunal de grande instance de Paris en juin 2019, la cour d'appel de Paris a déclaré, en mars 2021, l'action en contrefaçon irrecevable : au nom du principe de non-cumul des responsabilités, un manquement aux clauses d'une licence ne pouvait relever que de la responsabilité contractuelle, et non de la contrefaçon, de nature délictuelle. Elle a néanmoins condamné Orange à 150 000 € pour parasitisme, celle-ci ayant exploité sans contrepartie le savoir-faire et les investissements d'Entr'Ouvert pour remporter un marché important.

Par un arrêt du 5 octobre 2022, la Cour de cassation a partiellement cassé cette décision. Elle a confirmé la condamnation pour parasitisme, l'évaluation du préjudice relevant de l'appréciation souveraine des juges du fond, mais a censuré l'irrecevabilité de l'action en contrefaçon. S'appuyant sur l'arrêt IT Development SAS c. Free Mobile SAS (section 2.7) et sur les directives 2004/48/CE et 2009/24/CE, elle a jugé que la violation d'une clause de licence constitue une atteinte aux droits de propriété intellectuelle. Le titulaire doit donc pouvoir bénéficier des garanties du droit de l'UE, comme la saisie-contrefaçon et les règles spécifiques d'évaluation des dommages-intérêts, dont l'action contractuelle est dépourvue. Le non-cumul ne fait ainsi pas obstacle à l'action en contrefaçon, et l'affaire a été renvoyée devant la cour d'appel.

Statuant sur renvoi après cassation, la cour d'appel a rendu en février 2024 une décision de référence jugeant qu'Orange avait porté atteinte aux droits d'auteur d'Entr'Ouvert sur Lasso et enfreint la GPL. Elle lui a accordé environ 860 000 € : 500 000 € de préjudice économique, 150 000 € de préjudice moral, 150 000 € au titre des bénéfices réalisés par Orange et 60 000 € de frais de procédure. C'est l'une des condamnations les plus lourdes jamais prononcées dans un contentieux de licence open source, et elle montre qu'une violation de la GPL peut coûter cher.

2.9 Sebastian Steck (et SFC) c. AVM (2023-2025, Allemagne)

En 2023, le développeur de logiciels allemand Sebastian Steck, avec le financement et le soutien de la Software Freedom Conservancy, a poursuivi AVM, un fabricant berlinois d'équipements réseau (notamment les célèbres routeurs FritzBox). Steck reprochait à AVM de ne pas avoir fourni l'intégralité du code source correspondant aux composants sous licence LGPL utilisés dans ses produits, comme l'exige la LGPL. Plus précisément, les scripts et les informations nécessaires à la compilation croisée et à l'installation sur l'appareil faisaient défaut. Steck a fait valoir que le droit de modifier et de réinstaller des logiciels modifiés sur des appareils dont on est propriétaire est un droit fondamental accordé par la LGPL, et que la distribution incomplète du code source par AVM empêchait de fait les utilisateurs d'exercer ce droit.

La procédure s'est achevée en janvier 2025 après qu'AVM a fourni les informations nécessaires à la réinstallation de logiciels modifiés sur ses appareils. Bien que la sanction pécuniaire ait été symbolique, l'affaire est importante à plusieurs égards. Elle compte parmi les premières actions fondées sur la LGPL qui portent précisément sur le droit de réinstaller un logiciel modifié, c'est-à-dire l'obligation de fournir les « informations d'installation ». Elle a été engagée par un utilisateur plutôt que par un titulaire de droits d'auteur et elle a produit un résultat concret au bénéfice de tous les utilisateurs d'appareils AVM. La SFC l'a présentée comme une victoire du « droit à la réparation » appliqué aux logiciels open source. Elle confirme que les entreprises doivent fournir non seulement le code source, mais aussi les scripts de compilation, les informations relatives à la chaîne d'outils et les procédures d'installation permettant d'utiliser effectivement le logiciel modifié.

2.10 Action visant au respect de l'AGPL de GlobaLeaks (Italie, 2020)

GlobaLeaks est une plateforme de lancement d'alerte placée sous AGPLv3+, développée par le Hermes Center for Transparency and Digital Human Rights. Après avoir reçu un prototype, ANAC (l'Autorité nationale italienne anti-corruption) a republié une version modifiée du logiciel sous le nom « OpenWhistleblowing » et l'a relicenciée de l'AGPLv3 à l'EUPL, modifiant les mentions d'attribution et de droit d'auteur, supprimant les mentions raisonnables de l'interface graphique, et ne se conformant pas pleinement aux obligations de disponibilité du code source. Les dispositions relatives au copyleft de l'AGPL exigent que les œuvres dérivées soient distribuées sous la même licence, ce qui fait de ce changement de licence vers l'EUPL, incompatible avec l'AGPL, une violation des conditions de cette dernière.

Le litige a été réglé à l'amiable créant ainsi ce qui semble être le premier précédent judiciaire relatif au respect de l'AGPL. Cela revêt une importance particulière, car l'AGPL est considérée comme l'une des licences open source les plus restrictives et constitue la licence qui comble le plus directement la « faille SaaS » de la GPL. Alors que la GPL n'exige la distribution du code source que lorsque des binaires sont distribués, l'AGPL, en revanche, l'exige même lorsque le logiciel est simplement utilisé pour fournir un service réseau. Cette affaire confirme que les dispositions de l'AGPL relatives à l'utilisation en réseau sont applicables et que les entreprises proposant des produits SaaS reposant sur du code sous licence AGPL doivent se conformer à ses termes, sous peine de sanctions juridiques.

3. Changements de licence déclenchés par l'exploitation commerciale

Il arrive que les développeurs de logiciels modifient la licence d'un projet d'une version à l'autre. De tels changements peuvent modifier le cadre juridique, ce qui a des répercussions sur la manière dont le code peut être utilisé, distribué et combiné avec d'autres logiciels. Les affaires suivantes démontrent qu'il est crucial pour les développeurs de surveiller les mises à jour potentielles des licences des bibliothèques et outils déjà intégrés dans leurs logiciels.

3.1 Elastic c. Amazon (AWS) - Litige sur la marque Elasticsearch et la licence (2021-2022)

Bien qu'il ne s'agisse pas à proprement parler d'un litige en matière de violation de licence au sens traditionnel du terme, l'affaire Elastic c. Amazon est l'un des exemples les plus marquants illustrant la manière dont les grandes entreprises peuvent tirer parti des licences open source permissives, et comment les développeurs d'origine réagissent. Elasticsearch et Kibana étaient à l'origine sous licence Apache 2.0 (open source). Amazon Web Services (AWS) a pris le code open source d'Elasticsearch et de Kibana et a commencé à l'offrir en tant que service géré (Amazon Elasticsearch Service) sans contribuer au projet ni partager les revenus avec Elastic. AWS a également utilisé la marque « Elasticsearch » dans le nom de son service, entraînant des réclamations pour contrefaçon de marque.

En réponse, Elastic a modifié la licence d'Elasticsearch et de Kibana, passant de la licence Apache 2.0 à un modèle de double licence combinant la Server Side Public License (SSPL) et la licence Elastic, aucune de ces deux licences n'étant considérée comme open source par l'Open Source Initiative (OSI). Cela a déclenché des forks massifs par la communauté, AWS et d'autres entreprises ayant créé OpenSearch, une version dérivée d'Elasticsearch sous licence Apache 2.0. Elastic a également déposé une plainte pour contrefaçon de marque contre AWS pour l'utilisation du nom Elasticsearch. En février 2022, les parties sont parvenues à un accord, AWS acceptant de cesser d'utiliser la marque Elasticsearch et de renommer son service. Cette affaire illustre la tendance générale qui voit les projets open source modifier leurs licences afin de se prémunir contre toute exploitation par les fournisseurs de services cloud, ainsi que les questions juridiques complexes qui se posent lorsque les intérêts commerciaux entrent en conflit avec les principes de l'open source.

3.2 Redis Labs et la Commons Clause (2018-2019)

Redis Labs, la société à l'origine du célèbre magasin de données en mémoire Redis, s'est retrouvée confrontée à une situation similaire à celle d'Elastic. Alors que le cœur de Redis restait sous licence BSD, Redis Labs avait développé des modules supplémentaires sous AGPL. AWS et d'autres fournisseurs de cloud ont commencé à proposer ces modules sous forme de services gérés, entrant ainsi en concurrence directe avec l'offre cloud de Redis Labs sans apporter de contribution en retour. En 2018, Redis Labs a ajouté la Commons Clause à ses modules, une clause de licence qui interdit la vente du logiciel en tant que service sans licence commerciale. Cela a eu pour effet de rendre ces modules « source-available » plutôt qu'« open source ».

La Commons Clause a suscité une vive controverse au sein de la communauté open source. L'Open Source Initiative (OSI) a explicitement déclaré que les logiciels soumis à la Commons Clause ne pouvaient pas être considérés comme open source. En 2019, Redis Labs a remplacé la Commons Clause par la Redis Source Available License (RSAL), puis a également eu recours à la licence SSPL. En mars 2024, Redis Ltd. (la société qui a pris la relève) a modifié la licence de Redis lui-même, passant d'une licence BSD à une double licence sous RSALv2 et SSPLv1, ce qui a provoqué une perturbation majeure de l'écosystème, plusieurs grandes distributions Linux et fournisseurs de cloud ayant créé des forks. Ce cas illustre comment les litiges de licence entre les développeurs d'origine et les fournisseurs de cloud peuvent dégénérer, passant de modifications au niveau des modules à des changements fondamentaux de la licence du projet principal.

4. Problèmes de licence des paquets Python

Bien que les affaires judiciaires concernant spécifiquement des paquets Python soient moins nombreuses (par rapport aux systèmes embarqués, où l'application de la licence GPL est plus courante), l'écosystème Python est confronté à des risques importants en matière de conformité aux licences. Une étude menée par Snyk a révélé que plus de 13 % des paquets Python présents sur le dépôt public officiel PyPI sont distribués sans aucune licence, ce qui, au regard du droit d'auteur, signifie qu'ils ne peuvent légalement être utilisés, modifiés ou distribués sans l'autorisation explicite de l'auteur. Ce risque est d'autant plus grave que le système de gestion des paquets de Python (pip) permet d'installer et de redistribuer très facilement des paquets sans jamais en examiner les conditions de licence. Les cas et incidents suivants illustrent les risques juridiques présents dans l'écosystème Python.

4.1 Tencent accusé de violation de la GPL via un paquet Python (2024)

Dans une affaire remarquable rapportée par Socket.dev, un développeur a accusé Tencent, l'une des plus grandes entreprises technologiques au monde, d'avoir enfreint la licence GPL en modifiant un utilitaire Python et en changeant sa licence, passant de la GPLv3 à la BSD à 3 clauses. La licence GPL interdit explicitement le changement de licence : vous pouvez modifier et distribuer un logiciel sous licence GPL, mais vous devez distribuer vos modifications sous la même licence GPL et conserver les mentions de droits d'auteur d'origine. Il a été constaté que le projet QT4A (Quality Test Framework for Android) de Tencent sur GitHub contenait du code provenant d'un utilitaire Python sous licence GPLv3, mais que le projet avait changé la licence pour la BSD à 3 clauses et supprimé les mentions de droits d'auteur d'origine.

Le problème a été soulevé sur GitHub (Tencent/QT4A issue #132), où le développeur original a fait remarquer que « La GPLv3 ne vous permet pas de changer la licence en BSD 3-Clause. Et elle exige que vous conserviez mes mentions de droit d'auteur originales, qui ont été supprimées. » Cette affaire met en lumière un malentendu courant : celui consistant à penser que l'on peut simplement relicencer du code GPL si on le modifie. En fait, les dispositions copyleft de la GPL l'empêchent spécifiquement, et le faire constitue à la fois une contrefaçon et une violation de la GPL. Bien que cette affaire particulière ait été résolue par la pression de la communauté plutôt que par une procédure judiciaire, elle démontre que même les grandes entreprises technologiques peuvent commettre de graves erreurs de conformité de licence avec des paquets Python, et que les développeurs individuels peuvent et font valoir leurs droits au titre de la GPL.

4.2 Paquets Python sous GPL dans des produits commerciaux - le risque caché

Le riche écosystème de paquets Python offre aux développeurs une multitude d'outils prêts à l'emploi, mais recèle aussi un risque juridique souvent sous-estimé : l'intégration involontaire de dépendances sous GPL dans des produits propriétaires. Installer un paquet avec pip ou l'ajouter à requirements.txt peut soumettre, à votre insu, l'ensemble de votre code aux strictes obligations de copyleft de la licence publique générale GNU. L'incorporation de code sous GPL exige en principe que l'ensemble de l'« œuvre combinée » soit diffusé sous la même licence, avec le risque de devoir mettre à disposition le code source propriétaire.

L'incertitude juridique entourant Python aggrave le danger. Alors que la Free Software Foundation soutient que les liens dynamiques (dynamic linking) crée une œuvre dérivée, d'autres font valoir que l'architecture interprétée de Python, basée sur les importations des bibliothèques extérieures, brouille les pistes, car les modules restent des fichiers distincts chargés lors de l'exécution plutôt que d'être fusionnés de manière statique en un seul binaire. Néanmoins, cette ambiguïté n'est qu'une maigre consolation lorsqu'une équipe juridique identifie une violation. Dans un incident largement cité, une entreprise utilisant une dépendance sous licence AGPL s'est retrouvée face à un ultimatum : ouvrir le code source de son moteur de recommandation propriétaire ou supprimer la bibliothèque. L'équipe d'ingénieurs a choisi de réécrire la fonctionnalité à partir de zéro, un revirement coûteux et chronophage motivé par un risque juridique plutôt que par un échec technique.

Les répercussions financières peuvent être lourdes. Selon un article publié sur Medium, une entreprise de SaaS s'est rendu compte qu'elle utilisait de manière incorrecte une bibliothèque sous licence AGPL et a été contrainte de refaire six mois de développement. Cette réécriture a coûté environ 300000 dollars en heures de travail et a retardé le lancement du produit de trois mois. Au-delà des coûts directs, ces incidents érodent la confiance des clients et des investisseurs, qui s'attendent à des calendriers de lancement prévisibles..

Comme le risque se concrétise souvent bien après la décision initiale relative aux dépendances, un audit préalable est essentiel. Des outils tels que pip-licenses, pip-license-checker et d'autres scanners similaires permettent aux développeurs de mettre en évidence les obligations liées aux licences avant qu'elles ne dégénèrent en crises juridiques. Considérer les licences des dépendances comme une préoccupation majeure, plutôt que comme une réflexion après coup, peut éviter aux équipes d'avoir à faire le choix douloureux entre renoncer à leur propriété intellectuelle et recommencer à zéro des fonctionnalités qu'elles pensaient déjà achevées.

5. Problèmes de licence des paquets Node.js / npm

L'écosystème npm est le plus grand registre de logiciels au monde, avec plus de 2 millions de paquets. Cet écosystème tentaculaire pose des défis uniques en matière de conformité aux licences : en raison de la complexité des arborescences de dépendances, une seule commande npm install peut entraîner l'installation de centaines de paquets, dont beaucoup sont soumis à des licences différentes et parfois incompatibles.

Les recherches sur les violations de licence liées aux dépendances npm se sont multipliées récemment. Des études montrent que, même si très peu de paquets npm présentent des violations directes de licence liées aux dépendances, ces violations peuvent se propager à grande échelle à travers le graphe de dépendances.

5.1 Violations de licence de dépendances npm - le risque systémique

Une étude publiée dans le Journal of Information Processing et intitulée Empirical Study on Dependency-related License Violation in the JavaScript Package Ecosystem a révélé que, bien que seuls 0,644 % des paquets npm présentent des violations directes de licence liées aux dépendances, l'effet de propagation fait qu'un nombre important de paquets sont indirectement affectés. Les schémas de violation les plus courants comprennent : des paquets sous licence permissive qui dépendent de paquets sous licence GPL (ce qui crée une incompatibilité de licence), des paquets sans licence qui dépendent de paquets sous copyleft, et des paquets propriétaires qui incluent des dépendances open source sans respecter les conditions de leur licence. L'étude a souligné qu'en incluant les paquets qui dépendent de ceux présentant des violations, le pourcentage de paquets affectés augmente considérablement.

Une pratique particulièrement dangereuse au sein de l'écosystème npm concerne les paquets soumis à une double licence : à la fois une licence permissive (comme la BSD à 3 clauses) et une licence copyleft (comme la GPL 2.0). Par exemple, le paquet npm extrêmement populaire node-forge, qui fournit une boîte à outils de cryptographie en JavaScript pur, est sous double licence BSD-3-Clause et GPL-2.0. Alors que la licence permissive autorise une utilisation propriétaire, l'option GPL existe également, et si un utilisateur en aval ne fait pas attention à la licence sous laquelle il opère, il pourrait involontairement déclencher des obligations GPL. De plus, le comportement par défaut de npm consistant à utiliser « ISC » comme licence dans package.json lorsqu'aucune n'est spécifiée a été critiqué comme étant dangereux, car cela peut amener les développeurs à croire que leur code est sous une licence permissive alors que l'auteur n'avait prévu aucune licence. Les outils qui aident les développeurs à vérifier la conformité des licences dans leurs arborescences de dépendances npm sont désormais indispensables pour éviter ces écueils.

5.2 L'affaire brepjs-opencascade en 2026 - la licence cachée dans l'arbre de dépendances

L'incident brepjs-opencascade illustre un piège silencieux en matière de conformité qui guette le développement logiciel moderne. Le paquet indiquait une licence MIT dans son fichier package.json, mais les binaires WASM précompilés qu'il contenait avaient été générés à partir d'OpenCascade.js, sous licence LGPL-2.1, sans fichier LICENSE, sans NOTICE et sans aucune mention de cette licence nulle part dans le paquet. La chronologie des événements rend le danger concret : le paquet a été lancé en revendiquant la licence MIT, les développeurs l'ont installé de bonne foi, et ce n'est que lorsqu'un contributeur externe a signalé le ticket n° 238 en février 2026 que cette incohérence a été mise au jour.

Le responsable du projet a réagi en fusionnant la PR n° 257, en modifiant la licence du sous-paquet de MIT à LGPL-2.1-only et en ajoutant les fichiers LICENSE et NOTICE appropriés, tandis que la bibliothèque racine brepjs, qui n'intègre pas directement le WASM, est restée sous licence Apache 2.0. Tous les développeurs ayant installé le paquet entre la sortie de la version et cette correction distribuaient, à leur insu, du code sous licence LGPL et s'exposaient à des obligations dont ils ignoraient l'existence. C'est précisément pour cette raison qu'il ne suffit pas de se fier à la licence indiquée au niveau supérieur d'un paquet : le fichier package.json d'une dépendance peut mentionner la licence MIT alors que ses artefacts compilés comportent des obligations de copyleft à deux ou trois niveaux de profondeur. Avant d'adopter une bibliothèque, en particulier une bibliothèque fournissant des binaires précompilés, les développeurs doivent auditer l'arborescence complète des dépendances transitives et vérifier que ce qu'un paquet déclare correspond bien à ce qu'il distribue réellement.

6. Problèmes de licence Docker

Docker est une plateforme qui regroupe les applications et leurs dépendances dans des conteneurs portables. Elle est largement utilisée pour accélérer les déploiements, faciliter le passage à l'échelle et optimiser l'utilisation des ressources. Docker présente des risques de conformité particuliers, car il associe des logiciels open source (Docker Engine/Moby), un logiciel propriétaire (Docker Desktop) et les licences propres aux logiciels contenus dans les images des conteneurs (les modèles). L'évolution juridique la plus notable a été la décision de Docker Inc. de modifier les conditions applicables à Docker Desktop, créant de nouvelles contraintes pour les entreprises.

6.1 Changement de licence Docker Desktop (août 2021)

Le 31 août 2021, Docker Inc. a annoncé un changement fondamental de ses conditions d'abonnement : Docker Desktop ne serait plus gratuit pour les utilisateurs professionnels (enterprise users). Plus précisément, les organisations comptant plus de 250 salariés ou réalisant plus de 10 millions de dollars de chiffre d'affaires annuel devaient souscrire un abonnement payant à Docker Desktop pour continuer à utiliser le logiciel. Le changement est intervenu avec une période de grâce jusqu'au 31 janvier 2022. Il ne s'agissait pas d'un changement des composants open source de Docker. Le Docker Engine (désormais appelé Moby) reste open source. En revanche, Docker Desktop, qui comprend l'application propriétaire Docker Desktop permettant d'utiliser le moteur open source via une interface graphique et des intégrations pour macOS et Windows, est devenu un produit payant destiné aux entreprises.

Ce changement de licence a immédiatement suscité des inquiétudes quant à la conformité chez de nombreuses entreprises. Comme le rapporte ServeTheHome, Docker « commence brusquement à facturer de nombreux utilisateurs en les mettant en situation de non-conformité aux conditions de licence, avec effet immédiat. » De nombreuses organisations utilisaient Docker Desktop sans abonnement payant et se sont soudainement retrouvées en situation de violation des nouvelles conditions. Bien qu'aucune action en justice n'ait été intentée publiquement pour violation de la licence de Docker Desktop, le risque est bien réel : le Contrat de service d'abonnement de Docker inclut des droits d'audit permettant de « vérifier les habitudes d'utilisation, de déterminer si une utilisation dans le cadre des abonnements au service personnel est autorisée et d'exiger la migration vers un abonnement payant approprié après notification. » Cette situation a conduit de nombreuses entreprises à migrer vers des alternatives telles que Podman, Rancher Desktop et Colima, ou à utiliser directement Docker Engine sous Linux (où Docker Desktop n'est pas nécessaire).

Il est important de bien comprendre la distinction : Docker Engine sous Linux reste gratuit et open source. Docker Desktop est l'application propriétaire pour macOS et Windows qui offre une interface graphique pratique et une intégration avec le système d'exploitation hôte. Le changement de licence ne s'applique qu'à Docker Desktop, et non au moteur Docker lui-même. Cependant, comme Docker Desktop est le principal moyen utilisé par la plupart des développeurs pour interagir avec Docker sous macOS et Windows, ce changement a touché un grand nombre d'organisations. Les entreprises qui continuent d'utiliser Docker Desktop sans abonnement valide enfreignent les conditions d'utilisation de Docker, ce qui pourrait les exposer à des poursuites judiciaires, notamment pour rupture de contrat et violation du droit d'auteur.

6.2 Conformité des licences d'images Docker - un risque caché

Au-delà des questions de licence liées à Docker Desktop, il existe un risque de non-conformité distinct et souvent négligé concernant les logiciels contenus dans les images Docker. Lorsque vous créez et distribuez une image, vous générez une œuvre composite intégrant tous les paquets qui y sont installés : le système d'exploitation de base, les dépendances et leurs dépendances transitives. La licence applicable à une image est régie par la licence la plus restrictive parmi tous les logiciels inclus, et la combinaison la plus dangereuse est celle d'un logiciel sous licence GPL associé à du code propriétaire. L'obligation est déclenchée par la distribution : tout ce qui est publié sur Docker Hub est légalement considéré comme distribué et doit respecter toutes les exigences de licence correspondantes, pourtant, Docker Hub lui-même attribue explicitement la responsabilité de la conformité à l'utilisateur de l'image, et non au registre.

L'ampleur des cas de non-conformité est alarmante. Une étude portant sur 776 images Docker a révélé que :

• Prévalence au niveau des paquets : parmi les 2 167 paquets logiciels identifiés dans l'ensemble des images, 71,3 % étaient compatibles avec la licence GPL, mais une proportion significative de 28,7 % (621 paquets) était incompatible avec celle-ci. La licence incompatible la plus courante était Apache v2, suivie de BSD4 et MPL v1.1.

• Problèmes au niveau des images : un pourcentage frappant de 58,9 % (457 sur 776) de toutes les images Docker comportaient au moins un problème d'incompatibilité avec la licence GPL. Plus inquiétant encore, 76,3 % (119 sur 156) des images Docker officielles (largement réutilisées comme couches de base) présentaient de tels problèmes. La combinaison incompatible la plus fréquente était celle de la licence GPL v2+ associée à la licence BSD4.

Dirk Hohndel, figure de proue de la communauté open source, a souligné que les images de conteneurs contiennent souvent bien plus de logiciels que ne le pensent les développeurs. Il a par exemple recensé 650 paquets dans l'image d'une application simple à trois niveaux, et a averti que cette complexité cachée posait d'importants défis en matière de conformité aux licences.

Un véritable point de rupture s'est produit en 2015, lorsque Matthew Garrett, militant pour les logiciels libres, programmeur et contributeur majeur à une série de projets de logiciels libres, notamment le noyau Linux et diverses distributions Linux, a fait valoir que que la distribution de toute image Docker modifiée basée sur Ubuntu sans l'autorisation explicite de Canonical enfreignait sa politique en matière de propriété intellectuelle. Canonical, le créateur d'Ubuntu, a répondu de manière informelle mais n'a publié aucune clarification contraignante, laissant ainsi des milliers d'images sur Docker Hub dans une situation juridique floue. Bien qu'il n'existe pas encore de jurisprudence spécifique à Docker, un arrêt rendu par un tribunal berlinois en 2011, selon lequel le micrologiciel d'un routeur est soumis au copyleft de la licence GPL en tant qu'œuvre collective, constitue le précédent le plus proche.

Les conditions d'utilisation de Docker Hub imposent également des exigences supplémentaires. En 2022, Docker a mis en place des limites de débit pour le téléchargement d'images et a commencé à appliquer ses conditions de manière plus stricte, notamment en exigeant que les organisations ayant une utilisation à grande échelle souscrivent à un abonnement Docker Business. Docker Hub propose également des images sous diverses licences, et l'utilisation de ces images sans respecter les conditions de leur licence peut engager la responsabilité juridique de l'utilisateur. La combinaison des conditions de licence propres à Docker et des licences des logiciels contenus dans les images crée un défi de conformité à plusieurs niveaux que de nombreuses organisations ne parviennent pas à relever de manière exhaustive.

7. Problèmes de licence N8N

N8N est un outil d'automatisation des workflows qui a connu un grand succès après avoir intégré des fonctionnalités d'intelligence artificielle. Il présente un cas particulièrement intéressant en matière de conformité aux licences. N8N est distribué sous la Sustainable Use License (SUL), une licence « fair-code » qui n'est pas considérée comme une licence open source. Le texte de la SUL limite l'utilisation à des « fins professionnelles internes » ou à un usage non commercial/personnel, et n'autorise la distribution gratuite qu'à des fins non commerciales. Dans sa propre FAQ sur la licence, N8N précise qu'en pratique, cela signifie que toute utilisation est autorisée, sauf si vous vendez un produit, un service ou un module dont la valeur découle entièrement ou en grande partie des fonctionnalités de N8N, par exemple en proposant N8N en marque blanche ou en l'hébergeant sous forme de service payant pour vos clients. Cela signifie que si vous hébergiez vous-même N8N et le proposiez à vos clients en tant que service géré d'automatisation des workflows, vous enfreindriez la licence SUL.

7.1 Évolution de la licence N8N et préoccupations de conformité

À l'origine, N8N avait été publié sous la licence Apache 2.0 avec la Commons Clause, qui limitait l'utilisation commerciale et restreignait également, par inadvertance, les services de conseil et d'assistance. Le 17 mars 2022, N8N est passé à la SUL, une licence personnalisée créée par N8N et basée sur la licence Elastic 2.0 avec l'autorisation d'Elastic. Le modèle « fair-code » a été conçu par le fondateur de N8N, Jan Oberhauser, qui dirige faircode.io. La principale restriction de la SUL est qu'elle interdit toute utilisation lorsque « la valeur découle entièrement ou substantiellement des fonctionnalités de N8N », ce qui va au-delà de la simple interdiction de la concurrence directe. La licence établit également une distinction entre le logiciel N8N de base (couvert par la SUL) et les fichiers ee (édition entreprise), qui sont couverts par une licence propriétaire distincte.

La difficulté en matière de conformité avec la licence N8N réside dans le fait que la frontière entre les « fins professionnelles internes » et l'utilisation commerciale restreinte n'est pas toujours claire. Par exemple, si une entreprise utilise N8N en interne pour automatiser des workflows mais propose également des services de conseil en automatisation des workflows, cela constitue-t-il une violation ? Qu'en est-il d'une entreprise qui héberge N8N pour ses clients sans facturer spécifiquement le service N8N ? Les community forums de N8N contiennent de nombreux fils de discussion émanant de développeurs et d'entreprises cherchant des éclaircissements sur ces cas limites, ce qui indique que les conditions de la licence créent une grande incertitude pour les utilisateurs commerciaux.

Bien qu'aucune action en justice concernant la licence SUL de N8N n'ait été rendue publique, le risque est bien réel. Les clauses des licences logicielles sont juridiquement contraignantes : comme le montre la jurisprudence évoquée dans le présent article, les tribunaux de différents pays ont confirmé la validité de ces clauses et imposé des sanctions concrètes aux contrevenants. Le mouvement « fair-code », qui regroupe N8N et d'autres projets « source available », représente une catégorie croissante de risques liés au respect des licences pour les développeurs qui pourraient supposer que tous les logiciels présents sur GitHub sont open source et librement utilisables. Les développeurs et les entreprises utilisant N8N doivent examiner attentivement la SUL et, s'ils proposent une quelconque forme d'automatisation des workflows en tant que service, déterminer si leur utilisation pourrait relever des utilisations commerciales restreintes.

Ce qui m'a personnellement semblé particulièrement préoccupant sur les forums de la communauté N8N, c'est que le fondateur de N8N répond régulièrement aux questions des utilisateurs concernant ce qu'ils peuvent ou ne peuvent pas faire avec N8N dans le cadre de la licence SUL. D'un point de vue juridique, ces réponses ne peuvent constituer une interprétation officielle de la licence, même si elles émanent de son rédacteur d'origine. Si l'utilisation de N8N par une personne s'avère par la suite enfreindre la licence SUL, celle-ci ne pourra pas invoquer ces réponses du forum pour bénéficier d'une protection juridique, car le texte de la licence lui-même, tel qu'un tribunal pourrait l'interpréter, reste la seule source de vérité.

8. Enseignements clés pour les entreprises et les développeurs

8.1 Open source ne signifie pas libre de toute obligation

Le principal enseignement de ces affaires est que les licences open source ont force obligatoire et peuvent être invoquées en justice. Des juridictions en France, en Allemagne, en Italie et aux États-Unis ont confirmé que la violation d'une licence open source pouvait constituer une contrefaçon et/ou un manquement contractuel. Les développeurs et les entreprises qui considèrent les logiciels open source comme librement utilisables à toutes fins, sans lire leur licence, s'exposent à des risques juridiques importants : mesures d'interdiction ou d'exécution, dommages-intérêts élevés et la divulgation forcée du code source.

8.2 Les licences copyleft exigent une conformité active

La GPL, la LGPL et l'AGPL imposent toutes des obligations spécifiques à ceux qui distribuent des logiciels incorporant du code sous licence GPL. Ces obligations comprennent la mise à disposition du code source correspondant, la préservation des mentions de droits d'auteur et (pour l'AGPL) la mise à disposition du code source aux utilisateurs qui interagissent avec le logiciel via un réseau. La conformité n'est pas passive. Elle nécessite des mesures actives telles que le maintien d'une offre écrite de mise à disposition du code source, l'inclusion de mentions de licence appropriées et la garantie que les scripts de compilation et les informations d'installation sont fournis. L'affaire Steck c. AVM démontre que la simple mise à disposition du code source est insuffisante si les utilisateurs ne peuvent pas réellement compiler et installer le logiciel.

8.3 Les écosystèmes de paquets créent des risques cachés

Les écosystèmes Python (pip) et Node.js (npm) permettent d'installer très facilement des centaines de dépendances à l'aide d'une seule commande, mais chaque dépendance est soumise à sa propre licence. Des études ont montré qu'un pourcentage significatif de paquets ne dispose d'aucune licence (plus de 13 % sur PyPI) et que des violations de licence liées aux dépendances existent dans les deux écosystèmes. Les développeurs devraient utiliser des outils d'audit de licence (pip-licenses, Snyk, Socket.dev) pour analyser régulièrement leurs arborescences de dépendances, et les entreprises devraient mettre en place des politiques de conformité des licences permettant de vérifier toutes les nouvelles dépendances avant leur ajout à un projet.

8.4 Les licences source-available et fair-code ne sont pas open source

Les conditions d'abonnement de Docker Desktop, la licence SUL de N8N et les licences similaires de type « fair-code » ou « source-available » ne sont pas approuvées par l'Open Source Initiative et contiennent des restrictions qui vont au-delà de ce qu'autorisent les licences open source. L'utilisation de logiciels sous ces licences d'une manière qui enfreint leurs restrictions (comme l'utilisation de Docker Desktop dans une grande entreprise sans abonnement, ou la proposition de N8N en tant que service concurrent) peut vous exposer à une responsabilité juridique, tout comme le ferait la violation d'une licence open source. Les développeurs doivent lire et comprendre les conditions de licence réelles de chaque logiciel qu'ils utilisent, plutôt que de supposer que tout ce qui est disponible sur GitHub est librement utilisable.

8.5 Les actions de mise en conformité se multiplient et gagnent en efficacité

Les actions visant à faire respecter les licences open source deviennent manifestement plus fréquentes et plus efficaces. Les premières affaires, telles que celle de BusyBox, ont fait figure de tournant car elles ont établi le caractère exécutoire de la licence GPL. La liste des entreprises reconnues coupables d'avoir enfreint la licence GPL s'étend bien au-delà des cas détaillés dans cet article. Rishab Aiyer Ghosh a rapporté dans son article publié dans The WIPO Journal que Fujitsu-Siemens, Asus, Belkin, Samsung, Best Buy, Verizon Communications et Dell, parmi des centaines d'autres, ont été reconnus coupables d'avoir enfreint ces licences. Le projet de lutte contre les violations gpl-violations.org, fondé par Harald Welte à la suite de son affaire Sitecom, a poursuivi et documenté les violations commises par des entreprises, y compris des géants de la technologie. Des affaires plus récentes, telles que Entr'Ouvert c. Orange, qui s'est soldée par une condamnation à 860 000 €, et SFC c. Vizio, qui a élargi le champ d'application de la GPL, démontrent que les conséquences des violations deviennent plus sévères et que le nombre d'acteurs susceptibles de faire respecter ces licences ne cesse de croître. De plus, l'affaire GlobaLeaks en Italie montre que l'AGPL, que de nombreuses entreprises considèrent comme trop risquée à utiliser et trop difficile à faire respecter, peut en réalité faire l'objet d'une action en justice. Ces évolutions montrent que le respect des licences ne fera que gagner en importance avec le temps et que les développeurs et les entreprises qui ignorent leurs obligations en matière de licences open source s'exposent à un risque juridique croissant.

---

Sources

1. The GPL prevails: An analysis of the first-ever Court decision on the validity and effectivity of the GPL, SCRIPT-ed, Volume 1, Issue 4,December 2004
   https://journals.ed.ac.uk/script-ed/article/view/11054

2. Open Source and the Age of Enforcement, UC Law Science and Technology Journal, Volume 4, Number 2 Summer 2012
   

   https://repository.uclawsf.edu/hastings_science_technology_law_journal/vol4/iss2/5/

3. Open Source Software: Economics, Innovation, Law and Policy, The WIPO Journal, Volume 2 Issue 1 2010
   https://tind.wipo.int/record/28665/files/wipo_journal_2_1.pdf

4. Berne Convention for the Protection of Literary and Artistic Works
   https://www.wipo.int/en/web/treaties/ip/berne/index

5. Neo4j, Inc. v. PureThink, LLC: Court ruling
   https://law.justia.com/cases/federal/district-courts/california/candce/5

   /335295/216/

6. The Open Source Definition by the OSI
   https://opensource.org/osd

7. Welte v. Sitecom: District Court of Munich judgment (GPL)
   https://www.ifross.org/Fremdartikel/judgment_dc_munich_gpl.pdf

8. Jacobsen v. Katzer: Federal Circuit ruling (2008)
   https://www.cafc.uscourts.gov/opinions-orders/08-1001.pdf

9. BusyBox v. Monsoon Multimedia: SFLC announcement (2007)
   https://softwarefreedom.org/news/2007/oct/30/busybox-monsoon-settlement/

10. BusyBox additional lawsuits: SFLC announcement (2007)
    https://softwarefreedom.org/news/2007/nov/20/busybox/

11. BusyBox first default judgment in a GPL case: SFC (2010)
    https://sfconservancy.org/news/2010/aug/03/busybox-gpl/

12. Software Freedom Law Center (SFLC)
    https://softwarefreedom.org/

13. FSF v. Cisco Systems: SFLC lawsuit announcement (2008)
    https://softwarefreedom.org/news/2008/dec/11/cisco-lawsuit/

14. Free Software Foundation (FSF)
    https://www.fsf.org/

15. FSF v. Cisco Systems: Settlement announcement (2009)
    https://softwarefreedom.org/news/2009/may/20/fsf-cisco-settlement/

16. Artifex Software v. Hancom: Court ruling (2017)
    https://dockets.justia.com/docket/california/candce/3

    /305835

17. Artifex and Hancom reach settlement: Artifex blog
    https://artifex.com/blog/artifex-and-hancom-reach-settlement-over-ghostscript-open-source-dispute

18. Software Freedom Conservancy: Past lawsuits
    https://sfconservancy.org/copyleft-compliance/past-lawsuits.html

19. SFC v. Vizio: Lawsuit page
    https://sfconservancy.org/copyleft-compliance/vizio.html

20. Entr'Ouvert v. Orange S.A.: Paris Court of Appeal ruling (2024)
    https://www.courdecassation.fr/decision/65cdbcdf2425a70008258563

21. Sebastian Steck v. AVM: SFC lawsuit page
    https://sfconservancy.org/copyleft-compliance/avm.html

22. SFC celebrates AVM copyleft lawsuit resolution (2025)
    https://sfconservancy.org/news/2025/jan/09/avm-copyleft-lawsuit-resolved-with-install/

23. GlobaLeaks AGPL Enforcement: Joint Statement ANAC-Hermes Center (in Italian)
    https://pre.anticorruzione.it/documents/90592/96571/comunicato+congiunto+ANAC-HERMES+CENTER.pdf/015de9f3-fdc3-f35e-95e6-456cbbe63989

24. First AGPL compliance precedent: Calendify session
    https://calendify.com/session/EQVO23WBMkZ?theme=dark

25. Elastic and Amazon reach agreement on trademark infringement lawsuit: BusinessWire (2022)
    https://www.businesswire.com/news/home/20220216006113/en/Elastic-and-Amazon-Reach-Agreement-on-Trademark-Infringement-Lawsuit

26. Redis Labs modules license changes: Redis blog
    https://redis.io/blog/redis-labs-modules-license-changes/

27. Over 10% of Python packages on PyPI are distributed without any license: Snyk
    https://snyk.io/blog/over-10-of-python-packages-on-pypi-are-distributed-without-any-license/

28. PyPI: Python Package Index
    https://pypi.org/

29. Developer accuses Tencent of copyright violation: Socket.dev
    https://socket.dev/blog/developer-accuses-tencent-of-copyright-violation

30. Tencent/QT4A issue #132: GitHub
    https://github.com/Tencent/QT4A/issues/132

31. The Open Source License That's Quietly Bankrupting Companies: Medium
    https://medium.com/@sohail_saifi/the-open-source-license-thats-quietly-bankrupting-companies-1ab583f853be

32. Empirical Study on Dependency-related License Violations in the JavaScript Package Ecosystem: Journal of Information Processing
    https://www.jstage.jst.go.jp/article/ipsjjip/29/0/29_296/_article/-char/en

33. node-forge: npm package
    https://www.npmjs.com/package/node-forge

34. brepjs Issue #238: GitHub
    https://github.com/andymai/brepjs/issues/238

35. brepjs PR #257: GitHub
    https://github.com/andymai/brepjs/pull/257

36. Docker updates product subscriptions: Press release (2021)
    https://www.docker.com/press-release/docker-updates-product-subscriptions/

37. Docker abruptly starts charging many users for Docker Desktop: ServeTheHome
    https://www.servethehome.com/docker-abruptly-starts-charging-many-users-for-docker-desktop/

38. Docker Subscription Service Agreement
    https://www.docker.com/legal/docker-subscription-service-agreement/

39. TL;DR: Docker and legal compliance: Alfresco blog
    https://hub.alfresco.com/t5/alfresco-content-services-blog/tldr-docker-and-legal-compliance/ba-p/315453

40. Containers and open source license compliance: FOSSA blog
    https://fossa.com/blog/containers-open-source-license-compliance/

41. Ubuntu: Docker Hub official image
    https://hub.docker.com/_/ubuntu

42. Research paper on Docker image license compliance: IEEE
    https://ieeexplore.ieee.org/document/9825809

43. Container images often include far more software than developers expect: LWN.net
    https://lwn.net/Articles/752982/

44. Matthew Garrett says Ubuntu container images are breaking copyright: Softpedia
    https://news.softpedia.com/news/gnome-s-matthew-garrett-says-ubuntu-container-images-are-breaking-copyright-probably-487418.shtml

45. Canonical says Ubuntu-based Docker images are not a copyright violation: Softpedia
    https://news.softpedia.com/news/canonical-says-ubuntu-based-docker-images-is-not-a-copyright-violation-488038.shtml

46. AVM GPL violation: FSFE
    https://fsfe.org/activities/avm-gpl-violation/avm-gpl-violation.en.html

47. Docker Terms of Service
    https://www.docker.com/legal/docker-terms-service/

48. N8N Sustainable Use License: FAQ
    https://docs.n8n.io/sustainable-use-license/

49. Announcing the new Sustainable Use License: N8N blog
    https://blog.n8n.io/announcing-new-sustainable-use-license/

50. FairCode
    https://faircode.io/

51. N8N enterprise edition license: GitHub
    https://github.com/n8n-io/n8n/blob/master/LICENSE.md

52. N8N community forums: A new license for n8n
    https://community.n8n.io/t/a-new-license-for-n8n/11873

53. N8N community forums: Founder's response on license usage
    https://community.n8n.io/t/a-new-license-for-n8n/11873/4

54. gpl-violations.org
    https://gpl-violations.org/

55. SFC v. Vizio survives motion for summary judgment on third-party beneficiary issue: DLA Piper
    https://www.dlapiper.com/en-fr/insights/publications/2024/01/sfc-v-vizio-survives-motion-for-summary-judgment-on-third-party-beneficiary-issue

56. SFC v. Vizio ruling on General Public License compliance: Key takeaways: DLA Piper
    https://www.dlapiper.com/en-fr/insights/publications/2026/01/sfc-v-vizio-ruling-on-general-public-license-compliance-key-takeaways

57. IT Development SAS c. Free Mobile SAS (affaire C-666/18) : arrêt de la CJUE, EUR-Lex (2019)
    https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX

58. Entr'Ouvert c. Orange S.A. : arrêt de la Cour de cassation, première chambre civile, 5 octobre 2022 (pourvoi n° 21-15.386), Légifrance
    https://www.legifrance.gouv.fr/juri/id/JURITEXT000046389115