L’open washing : quand l’« ouverture » n’est qu’une façade

Introduction

L’open washing, parfois traduit par « ouvertisation », désigne une stratégie marketing consistant à faire croire qu’une initiative est ouverte et adhère aux principes du libre, alors qu’il n’en est rien. À l’instar du greenwashing (éco-blanchiment) dans le domaine environnemental, l’open washing exploite la valorisation positive de l’« ouvert » pour soigner une image de marque, sans nécessairement respecter la transparence, la collaboration ou le partage de connaissances qui définissent réellement l’open source et la culture libre. Autrement dit, c’est un vernis d’ouverture appliqué à un produit ou service qui demeure largement propriétaire dans les faits.

Avec l’essor du logiciel libre et de l’open source, afficher des valeurs d’ouverture est devenu un atout médiatique. De grandes entreprises technologiques se proclament aujourd’hui championnes de l’ouverture, en publiant par exemple certains codes sources ou données. Cependant, toutes ne jouent pas le jeu jusqu’au bout, d’où l’émergence de ce terme open washing pour dénoncer les écarts entre le discours et la réalité. Dans cet article, nous examinerons en détail l’origine de ce phénomène, les motivations qui poussent certaines entreprises à s’y livrer, ses conséquences juridiques, ainsi que son impact sur l’écosystème du logiciel libre. Nous verrons enfin quelles mesures peuvent être adoptées pour limiter l’open washing et protéger l’intégrité de l’open source.

Origine et émergence du phénomène

Le terme open washing est directement inspiré du greenwashing, pratique où une organisation se donne une image écologiquement responsable de façon trompeuse. De même, on constate une tendance croissante à ce que l’on peut appeler l’open washing, où des organisations proclament leurs données ou logiciels « ouverts » alors que, dans les faits, seuls des accès limités ou partiels sont accordés. L’expression est apparue à la fin des années 2000 : elle aurait été employée pour la première fois en 2009 par Michelle Thorne, spécialiste des politiques Internet (notamment chez Mozilla), par analogie avec l’éco-blanchiment. L’idée était de nommer cette dérive marketing au sein du mouvement open source, à un moment où la demande de transparence et d’ouverture du public commençait à grandir.

Plusieurs exemples ont tôt fait de mettre en lumière l’open washing. En France, dès 2014, le cas de Vélib’ a été pointé du doigt : le célèbre service parisien de vélos en libre-service annonçait fièrement une « nouvelle utilisation de l’open data Vélib’ », alors que les données utilisées provenaient en réalité d’un partenariat non public et n’ont jamais été rendues réellement ouvertes à la communauté. Ce type de fausse ouverture – données disponibles au compte-gouttes, API restreintes, code source publié sans permettre de réutilisation effective – a fait prendre conscience que l’usage abusif du mot “open” risquait de galvauder le concept. Comme dans le greenwashing, l’open washing profite de l’aura positive d’un concept (l’« ouvert ») tout en en vidant le sens.

Les motivations des entreprises

Pourquoi des entreprises pratiquent-elles l’open washing, au risque d’être dénoncées ? Les motivations peuvent être multiples, souvent liées à des avantages d’image et de marché. D’abord, l’open source jouit aujourd’hui d’une excellente réputation. Là où, il y a 20 ans, certaines sociétés voyaient le libre d’un mauvais œil (Steve Ballmer qualifiait Linux de « cancer » en 2001), la tendance s’est inversée. Désormais, afficher du contenu ouvert est perçu comme un gage de modernité, de transparence et d’innovation. Ainsi, l’open washing permet aux entreprises de capitaliser sur la perception positive de l’open source sans réellement s’engager sur la voie de l’ouverture. Cela améliore leur image publique et attire une clientèle sensible aux valeurs de partage, sans les contraindre à ouvrir entièrement leurs technologies.

Ensuite, se présenter comme « ouvert » peut offrir des avantages compétitifs ou réglementaires. Un cas récent concerne l’intelligence artificielle : l’Union européenne envisage d’accorder des exemptions aux modèles d’IA open source dans son futur AI Act. Cette perspective crée un puissant incitatif pour certaines entreprises de qualifier leurs modèles d’ouverts afin d’échapper à des obligations juridiques plus strictes. En d’autres termes, en pratiquant l’open washing, elles espèrent bénéficier d’un régime réglementaire de faveur (moins de contraintes, moins de coûts de mise en conformité, pas d’audit sur leurs données d’entraînement) réservé aux véritables projets open source. On voit ainsi apparaître des modèles d’IA présentés comme open, alors que leurs licences d’utilisation comportent en réalité de sérieuses restrictions (interdiction d’usage commercial, clauses limitant les utilisateurs, etc.).

Enfin, derrière l’open washing se trouvent souvent des motifs économiques stratégiques. Publier partiellement un code source peut servir à attirer développeurs et clients tout en gardant la mainmise sur le projet. Certaines entreprises adoptent un modèle « open source commercial » : le code est disponible sous licence libre, mais le développement est piloté exclusivement en interne, sans véritable gouvernance communautaire. Les contributions externes, si elles sont acceptées, nécessitent parfois un transfert de copyright à l’éditeur, qui reste ainsi seul maître du logiciel. Cette approche permet de profiter du travail bénévole de la communauté et de la dynamique du libre (retours utilisateurs, corrections de bogues, etc.), tout en conservant un contrôle qui assure un avantage concurrentiel (pouvant monétiser certaines fonctionnalités, vendre du support, ou sortir des versions propriétaires dérivées). Autrement dit, l’entreprise récolte les fruits de l’ouverture (innovation plus rapide, bonnes relations publiques) sans s’exposer à en perdre le contrôle ou les bénéfices. On accuse ainsi ces acteurs de détourner à leur profit le goodwill attaché au label open source, tout en en trahissant l’esprit.

Impacts juridiques de l’open washing

L’open washing soulève des questions juridiques importantes, notamment autour du respect des licences open source et de la frontière entre logiciels libres et composants propriétaires. Sur le plan du droit des licences, présenter un logiciel comme « ouvert » alors que sa licence impose des restrictions peut constituer une pratique trompeuse, et surtout exposer l’entreprise à des litiges si elle viole les obligations des licences libres utilisées.

Problèmes de licences et litiges

Contrairement à une idée reçue, les licences open source ont une valeur légale contraignante. Plusieurs décisions de justice marquantes l’ont confirmé. Aux États-Unis, l’affaire Jacobsen v. Katzer (Cour d’appel fédérale, 2008) a fait date en reconnaissant qu’un manquement aux termes d’une licence libre pouvait s’analyser en une violation du droit d’auteur, et pas seulement en un simple manquement contractuel. En l’occurrence, un développeur (Jacobsen) avait publié son code sous licence Artistic License 1.0 ; un tiers (Katzer) l’avait réutilisé dans un logiciel commercial sans respecter les conditions (notamment l’attribution de la paternité). La cour a jugé que ces conditions de licence étaient opposables : les ignorer revenait à enfreindre le droit d’auteur de l’auteur initial. Ce jugement a donné du poids juridique aux licences libres et a encouragé la communauté à faire respecter les obligations qu’elles contiennent (citation des auteurs, redistribution du code source, etc.).

De même en Europe, la jurisprudence a évolué pour protéger le logiciel libre. En France, un long combat judiciaire entre la société coopérative Entr’ouvert et Orange Business Services a débouché sur un arrêt majeur de la Cour d’appel de Paris en février 2024. Orange avait intégré un composant open source (le logiciel Lasso, sous licence GPLv2, développé par Entr’ouvert) dans une solution fournie à l’État, sans respecter les termes de la licence – notamment en ne publiant pas les améliorations apportées et en commercialisant le tout de façon propriétaire. La cour a condamné Orange pour contrefaçon (violation du droit d’auteur) en constatant le non-respect des obligations de la GPL : Orange aurait dû fournir le logiciel au client final (l’État) à titre gratuit et publier le code source modifié, conformément au principe de partage inhérent au libre. Des dommages et intérêts de plus de 800 000 € ont été prononcés. Cette affaire – doublée d’une validation en 2022 par la Cour de cassation du principe même d’une action en contrefaçon pour violation de licence libre – est emblématique : elle rappelle que ne pas honorer une licence libre (même involontairement) peut coûter cher et être réprimé comme n’importe quelle atteinte au droit d’auteur.

En somme, du point de vue légal, l’open washing peut mener à des litiges sur la qualification même de “open source” et à des poursuites en cas de non-respect des licences. Une entreprise qui distribue un logiciel en affirmant qu’il est open source tout en y ajoutant des restrictions non permises par les licences libres prend un risque juridique. Non seulement elle peut être critiquée pour publicité trompeuse, mais elle pourrait faire face à des actions des détenteurs de droits (par exemple, si elle incorpore du code libre en violation de sa licence). Les organisations veillant au respect de l’open source, comme la Software Freedom Conservancy ou la Free Software Foundation (FSF), n’hésitent plus à intenter des actions. On se souvient par exemple des multiples poursuites de la SFLC autour de BusyBox entre 2007 et 2009, ou de la plainte de la FSF contre Cisco en 2008 pour non-respect de la GPL dans des produits Linksys – affaires qui se sont soldées par des règlements obligeant les contrevenants à se conformer aux licences. Chaque fois, le message est clair : la liberté logicielle a force de loi, et la peindre sur un produit ne suffit pas, il faut en respecter les termes concrets.

Compatibilité open source / propriétaire : controverses

L’open washing met aussi en lumière les tensions entre modèles ouverts et propriétaires. Les entreprises en quête de profits élevés cherchent souvent à concilier l’inconciliable : profiter de l’écosystème open source (communauté d’utilisateurs, image positive, base de code éprouvée) tout en conservant des éléments propriétaires pour monétiser leur offre. Cela donne lieu à des modèles hybrides parfois contestés. Par exemple, certaines plateformes publient un socle de code ouvert mais gardent des modules complémentaires fermés (modèle open core). D’autres « ouvrent » leur code mais en interdisant certains usages par la licence (open source « sous conditions » qui n’est plus du véritable open source selon l’OSI).

Ces pratiques floues soulèvent la question de la compatibilité des licences et des écosystèmes. Peut-on, par exemple, intégrer un composant GPL dans une solution propriétaire sans ouvrir l’ensemble du code ? La GPL, licence copyleft, l’interdit en principe, sauf à isoler strictement le composant. Ainsi, dès qu’une entreprise mélange du code libre avec son code fermé, elle doit être vigilante à ne pas créer une incompatibilité de licence. Plusieurs controverses ont éclaté à ce sujet, certains éditeurs tentant de contourner les contraintes. Richard Stallman dénonçait par exemple le « piège diachronique » consistant à publier une version initiale d’un logiciel en open source, puis à rendre payantes les mises à jour suivantes via un format de fichier propriétaire, piégeant ainsi les utilisateurs qui s’étaient habitués à la version ouverte (Openwashing — Wikipédia). Ce type de stratagème brouille délibérément la frontière entre ouvert et fermé, et nuit à la confiance dans le modèle libre.

Un autre cas emblématique est celui de OpenOffice.org après son rachat par Oracle. En 2010, lorsque Oracle a hérité de la suite bureautique open source, la communauté a craint un manque de transparence et une orientation plus fermée du projet. En réaction, une partie des contributeurs a décidé de faire un fork (une branche dissidente) pour créer LibreOffice et la confier à une fondation indépendante (The Document Foundation). Très vite, la majorité des acteurs historiques (Red Hat, Novell, Google, Canonical, etc.) et des développeurs bénévoles ont basculé sur LibreOffice, estimant qu’il s’agissait là du vrai projet communautaire, libéré de la tutelle d’un vendeur unique. Oracle s’est retrouvé isolé, peinant à maintenir OpenOffice.org seul de son côté, au point de finir par en céder le contrôle à la Fondation Apache en 2011. Cette histoire illustre comment une suspicion d’open washing ou de reprise en main propriétaire d’un projet pourtant ouvert peut provoquer une scission de la communauté et affaiblir drastiquement un logiciel.

Enfin, l’actualité la plus récente dans le domaine de l’IA a vu naître de vifs débats sur ce qui constitue réellement un modèle ouvert. La société Meta, par exemple, a publié ses modèles de langage LLaMA 2 et 3 en les qualifiant d’open source, mais la licence associée impose des restrictions d’usage (notamment commerciales) incompatibles avec la définition open source de l’OSI. Cette appropriation du terme a été critiquée comme de l’open washing : l’Open Source Initiative (OSI) a publiquement appelé Meta à cesser d’employer l’appellation « open source » pour LLaMA tant que la licence ne respecte pas les critères établis. Malgré quelques assouplissements de Meta dans la version 3, l’OSI et la FSF estiment que ces licences « communautaires » échouent à garantir les libertés fondamentales des utilisateurs (liberté d’usage pour tout usage, non-discrimination, etc.). Le fait que LLaMA exclue par exemple les utilisateurs résidant dans l’UE (clause étonnante introduite un temps) ou restreigne les domaines d’application a été perçu comme une négation de l’esprit du libre. Ces controverses révèlent une bataille sémantique et juridique autour du label “open source” : face à l’absence de cadre légal strict sur l’utilisation de ce terme, certaines entreprises tentent de redéfinir l’ouverture à leur avantage, au grand dam des défenseurs du logiciel libre.

Conséquences sur l’écosystème open source et le logiciel libre

Les pratiques d’open washing ne sont pas sans conséquences pour l’ensemble de l’écosystème des logiciels libres et open source. À court terme, elles peuvent semer la confusion et la méfiance ; à long terme, elles risquent d’éroder les bases mêmes du modèle collaboratif. Voici les principaux impacts observés :

Perte de confiance du public et des utilisateurs : En multipliant les annonces marketing trompeuses, l’open washing risque de diluer la crédibilité du label open source. Si tout et n’importe quoi est qualifié d’« ouvert » alors que la réalité est décevante, les utilisateurs peuvent devenir cyniques ou méfiants. Cette pratique abusive « sape la confiance, induit les consommateurs en erreur et dilue l’intégrité des mouvements ouverts » pour reprendre les termes d’analystes. Par exemple, une entreprise qui libère le code source d’un projet mais sans fournir les moyens de le compiler ou en retenant des composants clés va frustrer développeurs et utilisateurs, et entamer la confiance générale envers les logiciels prétendument libres. À terme, cela peut freiner l’adoption des solutions open source par les entreprises ou le grand public, par crainte des faux-semblants ou d’un manque de fiabilité. Un responsable DSI pourrait hésiter à choisir un logiciel soi-disant ouvert s’il craint que la communauté ne le soutienne pas réellement ou que l’éditeur limite finalement ses droits.
Atteinte à la dynamique communautaire : L’open source repose sur ses communautés de contributeurs bénévoles, de testeurs, d’utilisateurs évangélistes. Or, l’open washing peut démotiver ces acteurs. Lorsqu’une communauté se rend compte qu’on cherche à l’instrumentaliser sans véritable partage, elle peut réagir vivement – on l’a vu avec LibreOffice face à Oracle. Les contributeurs tiennent à ce que leurs efforts bénéficient à un projet véritablement ouvert. Dans le cas contraire, ils peuvent bifurquer vers un fork, ou cesser de contribuer. Ainsi, un projet en open washing risque de recevoir moins de contributions externes de qualité, car développeurs et experts préfèreront investir leur temps dans un projet jugé plus transparent et méritant. Au-delà des cas extrêmes de fork, même subtilement, la participation peut s’étouffer : moins de rapports de bogues, moins d’enthousiasme dans la communauté, etc. En somme, l’open washing grippe le moteur collaboratif du libre.
Fragmentation de l’écosystème : Comme évoqué, l’open washing peut conduire à des forks ou à la création de projets concurrents plus ouverts, ce qui fragmente temporairement l’écosystème. Si plusieurs projets revendiquent l’héritage “ouvert” d’un logiciel, les utilisateurs sont dispersés, les efforts dupliqués. Paradoxalement, cette fragmentation est parfois salutaire (exemple : LibreOffice a supplanté OpenOffice.org en offrant un modèle plus sain), mais elle peut aussi créer de l’incertitude et de la dilution des ressources sur le court terme.
Impact sur les modèles économiques à long terme : L’open washing renvoie l’industrie du logiciel libre à ses propres contradictions et peut influencer l’évolution des modèles d’affaires. D’un côté, voir des entreprises abuser du terme open source peut inciter la communauté à redéfinir des lignes rouges et à promouvoir des garde-fous (par exemple, favoriser les licences vraiment libres, ou refuser de collaborer avec des projets à gouvernance opaque). D’un autre côté, la tentation de l’open washing est révélatrice de la difficulté d’adapter le modèle libre à certains contextes lucratifs (cloud computing, IA, SaaS…). Si les entreprises estiment qu’ouvrir totalement leur code menace leurs revenus, elles chercheront des voies intermédiaires. On assiste ainsi à la montée de licences dites source-available (code visible mais avec restrictions d’usage) ou de modèles freemium hybrides. Ces évolutions peuvent être vues soit comme une trahison de l’idéal du libre, soit comme une adaptation pragmatique – selon les points de vue. Quoi qu’il en soit, l’open washing a pour effet de poser la question de la soutenabilité économique du “tout ouvert”. En réaction, certaines communautés s’organisent différemment (création de fondations à but non lucratif, double licences libre/commercial, offres de support payant etc.) pour concilier ouverture et revenus sans tromper l’utilisateur.

En définitive, si l’open washing devenait trop répandu, le risque serait de banaliser une érosion des libertés sans que le public ne s’en émeuve, par perte de repères. D’aucuns craignent que sans vigilance, on en vienne à applaudir des solutions pseudo-libres qui enferment à nouveau l’utilisateur dans des silos propriétaires, simplement parce qu’elles se parent du mot “Open”. Maintenir une distinction claire entre vrai open source et simple ouverture de façade est crucial pour la pérennité de l’écosystème.

Pistes pour limiter l’open washing

Face à ces dérives, plusieurs approches complémentaires peuvent être envisagées pour préserver l’intégrité de l’open source et dissuader l’open washing.

Exiger plus de transparence : La première mesure consiste à lever le voile sur ce que recouvre réellement une annonce « open ». Les communautés et les médias spécialisés ont un rôle de vigie : analyser les publications de code ou de données pour voir si elles répondent aux critères d’ouverture. Par exemple, si une entreprise prétend ouvrir ses données, vérifier si celles-ci sont effectivement librement réutilisables (licence ouverte, format exploitable) ou si elles sont simplement consultables sur un portail fermé. De même, lorsqu’un éditeur libère un bout de code, la communauté peut tester s’il est possible de le compiler, de l’utiliser indépendamment, ou si des composants essentiels manquent. Documenter publiquement les écarts entre discours et réalité crée une pression sur l’entreprise pour qu’elle corrige le tir. Une transparence accrue peut aussi venir des entreprises elles-mêmes, via des rapports d’ouverture détaillant ce qui est réellement ouvert (code, données, API) et sous quelles conditions. Enfin, les pouvoirs publics pourraient contribuer en encadrant l’usage de certains termes : par exemple, interdire l’appellation « open source » dans la communication commerciale d’un produit qui n’utilise pas une licence approuvée par l’OSI (ce qui relèverait du droit de la consommation contre la publicité trompeuse).
Renforcer le rôle des licences et de la gouvernance : Les licences open source sont notre outil juridique central. Pour limiter l’open washing, il faut encourager l’usage de licences claires et éprouvées (GPL, MIT, Apache, etc.) et décourager les licences ambiguës ou trop restrictives présentées faussement comme ouvertes. L’Open Source Initiative publie la liste des licences conformes à sa définition (Open Source Definition), ce qui sert de référence. Par exemple, les licences ajoutant une clause “Non Commercial” ou limitant un champ d’usage ne sont pas considérées comme open source. Utiliser des licences approuvées OSI offre donc une garantie de crédibilité. En outre, la gouvernance des projets joue un rôle clé : un projet hébergé par une fondation à but non lucratif, avec un processus de décision communautaire, aura moins de chances d’être accusé d’open washing. Promouvoir des modèles de gouvernance ouverts (comités techniques incluant plusieurs parties prenantes, feuille de route publique, etc.) rend plus difficile le dévoiement du projet à des fins purement propriétaires. Il est également possible d’intégrer dans la gouvernance des chartes de transparence obligeant, par exemple, à signaler clairement les composants non-libres liés au projet ou les sources de financement. Globalement, ancrer contractuellement et institutionnellement les principes d’ouverture (via des fondations, des consortiums, des manifestes signés par les contributeurs) permet de verrouiller l’ADN libre du projet, même si une entreprise y participe.
Sensibiliser et outiller la communauté pour repérer l’open washing : Chaque développeur, chaque utilisateur peut jouer un rôle en étant attentif aux signes d’open washing. Pour cela, diffuser des bonnes pratiques d’identification est essentiel. Par exemple : toujours lire la licence associée à un projet « ouvert » – si elle contient des restrictions inhabituelles ou n’est pas une licence standard connue, méfiance. Vérifier si le code source complet est disponible (et non une portion symbolique). Observer l’activité du dépôt : s’il n’y a pas de contributions externes ou si les décisions semblent prises en cercle fermé, le projet est peut-être “ouvert” de nom seulement. Des outils émergent pour aider à cette vigilance : l’OSI a par exemple proposé une définition de l’Open Source pour l’IA afin de trancher clairement quels modèles peuvent être appelés open source, évitant le flou artistique entretenu par certains acteurs. On pourrait imaginer à terme un label ou un audit indépendant certifiant qu’un projet respecte bien les critères d’ouverture (un équivalent du label OSIA (Open Source AI) pour d’autres domaines). En attendant, la communauté doit continuer à se mobiliser publiquement. Des prises de parole collectives, sur des forums ou des blogs, pour dénoncer des cas d’open washing notoires (à l’image de la lettre ouverte de développeurs à Meta) font souvent réagir les entreprises, soucieuses de ne pas se mettre à dos les talents et les clients technophiles.
Encourager les contributeurs et utilisateurs à soutenir les vrais projets libres : En dernier ressort, c’est aussi par le « marché » que se fera la différence. Si les clients privilégient massivement les logiciels véritablement open source et boudent les offres en open washing, les entreprises auront moins intérêt à ces pratiques. Pour cela, il faut éduquer les décideurs informatiques sur les critères d’un vrai logiciel libre, afin qu’ils ne se laissent pas séduire uniquement par l’étiquette. Par ailleurs, les développeurs sont encouragés à contribuer aux projets dont la gouvernance est saine et ouverte, et à ne pas investir du temps dans des projets qui ne jouent pas franc jeu. La pression communautaire peut ainsi orienter les comportements des entreprises : plusieurs exemples (Oracle/OpenOffice, ou encore certaines bases de données open source face aux dérives de licences “Cloud”) ont montré qu’une entreprise trop fermée finit par perdre l’écosystème qui faisait la force de son produit.

En combinant ces approches – transparence, licences rigoureuses, gouvernance inclusive, et vigilance collective – l’écosystème open source peut limiter la casse de l’open washing. C’est une sorte de régulation collaborative où chaque acteur, du juriste au développeur, contribue à ce que « open » reste synonyme de libertés concrètes et non de simple poudre aux yeux.

Conclusion

L’open washing est un enjeu à la croisée de la technologie, du droit et de l’éthique. Il reflète l’a popularité grandissante’attrait de l’open source et des données ouvertes, au point que même des acteurs réticents veulent en revêtir l’habit – quitte à en trahir l’esprit. Ses impacts ne sont pas anodins : confiance du public érodée, risques juridiques pour les contrevenants, déceptions au sein des communautés, forks et recompositions de projets, etc. À l’heure où le logiciel libre s’impose comme un pilier de l’innovation, préserver la signification authentique de l’ouverture est crucial. Cela passe par une vigilance collective, soutenue par des outils juridiques (licences, décisions de justice) et des initiatives comme celles de l’OSI pour clarifier les définitions et dénoncer les abus.

Dans les années à venir, on peut s’attendre à ce que la frontière entre ouvert et fermé continue d’être disputée. D’un côté, la communauté open source affûtera sans doute ses mécanismes de défense – on le voit déjà dans le domaine de l’IA où une contre-offensive s’organise pour éviter que le label open ne soit vidé de sa substance. De l’autre, les entreprises chercheront un équilibre entre ouverture et modèle économique, avec l’espoir que transparence et profit ne soient pas incompatibles. L’issue dépendra en grande partie de la mobilisation des acteurs du libre et de leur capacité à promouvoir un modèle où l’ouverture n’est pas qu’un slogan, mais une réalité tangible, bénéfique à tous.

Sources :

Stallman, R. – « Piège diachronique » (article sur les modèles économiques mixant libre et propriétaire).
Thorne, M. (2009) – Concept et première définition de l’open washing (Mozilla).
Villum, C. (2014) – « Open-washing » – Différence entre ouverture et simple accès aux données, Blog OKF.
Vaughan-Nichols, S. J. (2024) – « The open secret of open washing », The Register (opinion).
Riehle, D. (2024) – What is “openwashing” (in software), dirkriehle.com (analyse des modèles open source commerciaux).
Biella, L. (2024) – « Openwashing: Transparency in Open Source AI », Sease.io (cas OpenAI, Meta…).
Open Source Initiative (OSI) – Communiqué « Meta’s LLaMA license is still not Open Source » (2023).
Cour d’appel de Paris – arrêt du 14/02/2024, Affaire Entr’ouvert c. Orange (licence GPL).
Cour de cassation – arrêt n°21-15.386 du 05/10/2022 (violation de licence libre = contrefaçon, aff. Orange).
Jacobsen v. Katzer (Cour d’appel fédérale USA, 2008) – décision pionnière reconnaissant la force exécutoire des licences open source.
Historique OpenOffice/LibreOffice – Article cité par Ars Technica (2011).
Wikipedia – Openwashing (définition générale et exemples).