Entre fermer et partager le code, est-ce « fair » ?
Dans le domaine du logiciel libre, la licence d'ouverture du code peut rapidement faire débat. Rejetées par ce milieu qui considère que leurs logiciels ne sont pas assez libres pour être qualifiés d' « open », des startups comme Sentry poussent un nouveau terme : « fair source ».
Le 24 septembre à 08h31
5 min
Logiciel
Logiciel
Mise à jour mardi 24 septembre, 10h50 : ajout de la réaction de l'April en fin d'article.
Est-ce qu'un logiciel peut être équitable ? Et qu'est ce que ça veut dire ? Après avoir vu fleurir dans nos magasins des produits « fair trade », va-t-on voir nos logiciels s'afficher « fair source » ? Les histoires de licences dans le logiciel sont toujours délicates.
C'est en tout cas cette expression, « fair source », que certaines startups comme Sentry ou Keygen utilisent pour qualifier leur logiciel. Dans un billet de blog, Sentry, startup qui était valorisée à plus de 3 milliards de dollars en 2022, donne sa définition du terme :
« Un logiciel "Fair source" est un logiciel qui :
- est lisible publiquement ;
- permet l'utilisation, la modification et la redistribution avec un minimum de restrictions afin de protéger le modèle commercial du producteur ;
- et fait l'objet d'une publication Open Source différée (delayed Open Source publication, DOSP) »
L'entreprise cite plusieurs licences qui seraient compatibles avec cette définition. La sienne en première, la Functional Source License (FSL), évidemment, mais aussi la Core License de Keygen et la Business Source License (BSL) de MariaDB.
La FSL, par exemple, convertit automatiquement au bout de deux ans le code publié vers une licence libre Apache 2.0 ou MIT et revendique d'éviter le phénomène du « passager clandestin » (le renvoi vers la page Wikipédia est fait par Sentry sur le site de la licence).
Réponse à un bad buzz de l'année dernière
Sentry est une entreprise qui propose des logiciels de monitoring de code et de diagnostic de bugs. Son logiciel phare, comme l'explique TechCrunch, est notamment utilisé par des entreprises comme Microsoft et Disney. En 2019, elle en a changé sa licence en passant de la 3-Clause BSD à BSL créée par MariaDB.
Sentry a aussi racheté Codecov fin 2022 et, en aout 2023, a utilisé le terme d' « open source » pour qualifier son code qui était sous Business Source License aussi, récoltant les critiques de la communauté car cette licence n'est pas approuvée par l'Open Source Initiative (OSI). Adam Jacob, créateur du logiciel libre Chef, a suggéré que les entreprises qui voulaient utiliser des licences comme BSL s'associent pour créer une « confédération informelle » d'utilisateurs de licences avec des clauses évitant la concurrence. C'est en le prenant au mot que Sentry propose le terme de « fair source » et sa définition.
Sentry justifie son choix de ne pas utiliser une licence libre. « L'open source n'est pas un modèle commercial - l'open source est un modèle de distribution, c'est avant tout un modèle de développement de logiciels », affirme le responsable « open source » de l'entreprise, Chad Whitacre, à TechCrunch. « De fait, elle limite considérablement les modèles économiques possibles, à cause des conditions de licence », ajoute-t-il.
Le danger de la confusion ?
Mais introduire un nouveau terme peut parfois ajouter de la confusion. Caricaturalement, lorsqu'on demande à Deepl la traduction de « fair source », le service traduit le terme par « logiciel libre ».
Amanda Brock, CEO d'OpenUK, répondait en mai dernier à Adam Jacob qu'il n'y avait pas besoin de compliquer les choses et expliquait que ce que qualifie Sentry de « fair code », « c'est n'importe quelle licence non approuvée par l'OSI qui partage la source ». On peut aussi se poser la question de l'utilisation du terme « fair ». Un code qui n'est pas dans une licence « fair code » serait-il injuste ?
Interrogé par Next, le lobby des entreprises du logiciel libre CNLL, nous fait part de son attachement « aux définitions précises de l'OSI (pour "open source") et de la Free Software Foundation (pour le "logiciel libre"), tout en notant qu'elles varient justement dans leur degré de précision et la latitude qu'elles laissent à l'interprétation » dont il considère les définitions comme équivalentes « en pratique ».
Pour son co-président, Stéphane Fermigier, « des acteurs qui appartiennent à l'écosystème open source / du logiciel libre peuvent effectivement proposer des définitions différentes qui répondent à leur besoin de créer des licences spécifiques à leur business ou alors leurs choix éthiques. Pour moi il n'y a pas de mal à cela tant que cela ne crée aucun risque de confusion. De ce point de vue, "Fair Source" semble respecter ce principe qui me semble fondamental, à condition que personne n'aille impliquer qu'il s'agit de la nouvelle définition de l'open source, par exemple. Il est possible que de nombreux éditeurs open source adoptent cette définition et l'une des nouvelles licences qui la respectent, ce qui aura forcément un impact négatif sur l'écosystème open source "strict" et probablement aussi pourrait engendrer une érosion de la marque "open source" (ou "logiciel libre") ».
De son côté, interrogée par Next, l'April affirme que « l'objectif de Fair Source est de légitimer, de rendre honorable, une politique de licence rejetée notamment par la Free Software Foundation et l'Open Source Initiative, en lui trouvant une famille d'adoption. Celle-ci n'existant pas, les éditeurs l'ont créée de toutes pièces et ont même trouvé une bannière – Fair Source – qui entretient la confusion (comme à la grande époque du programme "shared source" de Microsoft, même si les licences Fair Source sont bien moins toxiques que les licences de Microsoft) ». Elle rajoute que « Fair Source relève de la pure campagne de communication, qui durera jusqu'à ce que le terme revête une connotation péjorative ».
Entre fermer et partager le code, est-ce « fair » ?
-
Réponse à un bad buzz de l'année dernière
-
Le danger de la confusion ?
Commentaires (52)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 24/09/2024 à 09h07
Ils ne sont pas les premiers et certainement pas les derniers à jouer à ce jeu.
Le 24/09/2024 à 12h07
Donc on vous dit "c'est open source" mais je ne peux rien en faire, et c'est livré en VM ou en conteneur.
Enfin si, je peux en faire autant que du "fair code": espérer que le code fourni correspond au binaire que j'ai.
Le 24/09/2024 à 12h56
Le 24/09/2024 à 16h24
Les solutions cloud "opensource" sont souvent impossible à démarrer depuis les sources (exemple: pas de script de création de la BDD...)
Dernièrement, en recherchant des solutions nocode et en souhaitant en tester en local avant achat, sur 5 solutions, je n'ai pas réussi à en démarrer 2. Le code source semble là, mais il ne fonctionne pas, ne suffit pas, et c'est un immonde spaghetti.
Modifié le 24/09/2024 à 09h22
Le 24/09/2024 à 14h21
Le 24/09/2024 à 09h23
- Non non... C'est du Fair Source...
- Ah bah j'aime mieux çà. Pas confiance."
Le 24/09/2024 à 09h23
En fait, pendant longtemps, les licences de logiciels se classaient dans 2 catégories :
- licences libres ou open-source : qui respecte les 4 libertés fondamentales
- licences propriétaires ou privatrices : licences qui ne sont pas libres / open-source.
On constate alors qu'une seule catégorie avait réellement une définition, et l'autre étant définie "par opposition".
Il suffisait alors d'avoir une licence avec restriction pour qu'elle soit considérée comme privatrice (comme la SSPL).
Depuis quelques années, nous avons maintenant aussi le source available, qui permet de désigner un code ouvert au sens propre du terme (=source disponible).
La notion de fair source rajoute un pont supplémentaire entre le source available et le libre, et protège également les utilisateurs en cas de défaillance de l'entreprise, puisque le code basculera automatiquement sur une licence libre au bout d'un certains laps de temps, sécurisant la modification et la distribution du code après une liquidation d'une entreprise ou l'arrêt d'un produit par exemple (cf. les exemples plus ou moins récent au sujet de la domotique !)
Maintenant, l'avis de la FSF ou du CNLL, ne m'étonne guère, puisque pour eux, le saint graal est le libre / open-source et toute licence non libre est de facto propriétaire.
Le 24/09/2024 à 09h46
Il est normal que ces groupes protègent leurs appellations.
Le 24/09/2024 à 10h11
Le monde open-source a une vision très manichéenne où soit c'est libre, soit c'est privateur.
Sauf que les éditeurs de logiciels et développeur sont libres de choisir la licence qu'ils souhaitent. Les licences libres présentent certains avantages indéniables, mais sont très mauvaises pour la viabilité commerciale d'un produit.
Les licences de types source available et fair source permettent d'ajouter des nuances de type propriétaire entre le libre et le privateur, là où le libre souhaite dire que propriétaire = privateur.
Le 24/09/2024 à 10h24
Donc Sentry a bien essayé de faire passer du code pour de l'open source alors que ça n'en était pas. Ici le terme fair source est donc effectivement plus approprié, plus clair et sûrement plus intéressant que du code en source fermée.
Le 24/09/2024 à 10h43
C'est quand même à l'opposé de certaines sociétés qui ont changé la licence de leur logiciel pour passer d'open source vers une licence source available (comme Elastic Search ou MariaDB par exemple) et ont donc plutôt un esprit de fermeture.
Note : pour ma part, je trouve que le terme "open source" est mal choisi par l'OSI, car ne véhicule pas toutes les idées qui y sont liées. Pour beaucoup de non professionnel, open source = source disponible. Les libertés liées à la modification et à la diffusion n'apparaissent pas. Mais ça, c'est un avis très personnel, et je fais avec ^^
Le 24/09/2024 à 10h32
Pour le reste, tu mélanges tout, le monde opensource n'est pas manichéen, le mouvement opensource s'est éloigné très fort du discours politique du libre pour mieux fonctionner justement avec les entreprises commerciales. L'opensource relève plus d'un modèle de collaboration (et non de distribution comme radoté par Sentry dans son blog). Par contre il ne faut pas s'attendre d'eux qu'ils cautionnent l'enfumage de sentry, ni le modèle proposé.
Le libre de son côté ne va pas non-plus cautionner un logiciel non-libre par essence.
Ce que tu sembles demander, c'est que des gens qui ont des principes et les défendent deviennent soudainement "raisonnables" ...
Pourquoi ne pas exiger des végétariens qu'ils rajoutent une dose minimale de viande dans leur alimentation pour soutenir l’élevage tant qu'on y est, ou que les homosexuels aient au moins une relation hétéro par mois.
Le 24/09/2024 à 10h54
Dans un sens, tu as raison lorsque tu dis que l'open-source relève de la collaboration, car l'open-source se focalise sur des considérations techniques et n'est pas fermé quant à l'usage de logiciel non open source (contrairement au principe du libre, notamment les licences GPL).
Non. Ce que je demande, c'est que les gens qui ont des principes tolère des principes différents avec des appellations différentes.
Comparaison foireuse. Ici, on est plutôt sur des végétariens qui refuseraient l'existence même du terme flexitarien, car cela ajouterait, d'après eux, de la confusion (ou l'existence du terme bisexuel pour continuer sur ton analogie avec les homosexuels).
Le 24/09/2024 à 11h13
Le seul qui soit intolérant ici, c'est toi, tu ne cesse de dépeindre le monde opensource comme des extrémistes.
Et franchement renseigne toi un peu sur ces sujets, car tu continues à tout mélanger, comme par exemple:
"n'est pas fermé quant à l'usage de logiciel non open source (contrairement au principe du libre, notamment les licences GPL)."
Tu fais référence à quoi? Tu parles d'utilisation ou de redistribution? Tu pense que les libristes ont un problème à utiliser des logiciels sous licence non-gpl? Un peu de précision...
Le 24/09/2024 à 11h51
Si, pour toi, le fait de dire que ce soit bien qu'il existe des notions intermédiaires entre les libres/open-source et les licences propriétaires, et critiquer la position du CNLL ou de l'OpenUK qui fustige la confusion que l'existence même de "fair source" entrainerait, alors oui, je suis intolérant.
On est dans un contexte commercial, donc je parle ici de redistribution.
Maintenant, je suis peut être "extrémiste", mais :
- FSF : On appelle logiciel privateur, ou logiciel non libre, un logiciel qui ne respecte pas la liberté des utilisateurs et leur communauté.. Autrement dit : tout logiciel non libre est privateur (un logiciel comme ElasticSearch est donc tout autant privateur pour la FSF que Windows par exemple).
- L'OSI est très loin d'être aussi extrêmiste, puisqu'il se contente de dire qu'une licence qui ne respecte pas l'open source definition n'est pas open-source. Par contre, et comme je le disais dans un autre commentaire, le terme "open source" me parait très mal choisi, car ne se réfère au final qu'à la règle 2 sur les 10 règles permettant de qualifier une licence comme étant open source.
Aujourd'hui, si on dit qu'on ouvre le code source ou qu'on libère le code source, sans pour autant que cela soit une licence libre / open source, alors on se fait mettre au pilori par une partie de la communauté (cas de Sentry avec codedev en 2023 par exemple) en étant accusé d'openwashing. En effet, Open source est un terme déposé par l'OSI. Mais qu'en est-il des termes dérivés ? Opening the source par exemple ? Dans le langage courant, c'est ouvrir les sources, pas licencier sous une licence open-source. Et pourtant, ça suffit pour être accuser d'openwashing.
Alors, quand je vois le débat sur "fair source" et la notion de fair de la part de défenseur de l'open-source, alors qu'on a exactement la même problématique entre open source et la notion d'ouverture, j'ai vraiment l'impression que c'est l'hôpital qui se fout de la charité.
Le 24/09/2024 à 12h51
Pour le reste, tu ne te fera mettre au pilori que si ta communication est en contradiction avec tes actions. Si tu publies ton code source donner de libertés autres que la consultation ou en gardant le contrôle sur le droit d'exécution ou de modification, ne prétend pas avoir "libéré" ton code.
Ceux qui jouent avec les mots pour se prévaloir de qualités qu'ils n'ont pas méritent de se faire dénonce pour imposture. De même, si tu vantes les valeurs de l'opensource, ton engagement pour l'opensource, et quen suite tu fais du "fair source", ne t'étonne pas qu'on ne te donne pas les points de karma.
Le 24/09/2024 à 13h33
Pour beaucoup de non informaticiens (en tout cas, autour de moi) :
- logiciel libre = gratuit
- logiciel open source = source disponible
- logiciel libre != logiciel open source
Le 24/09/2024 à 15h10
à mal nommer les choses...
Le 24/09/2024 à 15h15
Le 24/09/2024 à 15h34
Le 24/09/2024 à 10h45
"Les licences libres présentent certains avantages indéniables, mais sont très mauvaises pour la viabilité commerciale d'un produit."
Est un peu gratuit et léger comme affirmation, il y a plein de contre-exemples. Adhérer à de l'opensource ou du libre nécessite de réfléchir à l'adéquation de ces licences et du discours pour un projet spécifique et pour l'entreprise, si ce n'est pas des modèles qui marchent bien pour tout, ils peuvent marcher dans de nombreux cas.
Modifié le 25/09/2024 à 09h13
Même de plus gros projet ont des difficultés, et par exemple, Mozilla fermerait sans doute ses portes sans le partenariat qu'il a avec Google et qui lui fourni 90% de ses revenus.
Ce n'est pas pour rien non plus que des projets comme
MariaDBMongoDB ou Elastic Search ont changé de licence pour passer à du libre vers du non-libre.Il y a bien sur des projets qui ont réussi à trouver un business modèle viable. Mais il en existe beaucoup d'autres qui n'y arrive pas non plus.
Et ce n'est pas étonnant dans un sens, puisque les licences libres/open-source s'intéressent à celui qui reçoit le code, pas à celui qui le donne. De facto, même si par principe ce n'est pas interdit par les licences, il est très difficile de vendre le logiciel en lui-même. Il faut, par exemple, fournir du service autour, encore faut-il que le logiciel s'y prête.
Ou encore le double-licensing, où le produit open-source est un produit d'appel et le produit commercial contient les fonctionnalités les plus avancées. On y retrouve des logiciels comme nginx, gitlab, etc. Mais là encore, il faut que le logiciel s'y prête.
[edit]
Correction suite à la remarque de judicieuse de ragoutoutou sur la confusion MongoDB/MariaDB
Le 24/09/2024 à 12h17
Il est évident qu'avoir une activité commerciale dans le logiciel serveur est devenu beaucoup plus précaire avec la montée en puissance des GAFAM qui contrôlent les plateformes cloud public. Il faut pouvoir réussir à encore motiver les utilisateurs à acquérir du support tout en devant se battre contre des Amazon, Microsoft, Google et autres qui souvent fournissent des services SAAS avec un support minimal, voire uniquement sur papier.
L'industrie est devenue beaucoup plus violente, et ceux qui ne font pas d'opensource n'ont pas la garantie non-plus de pouvoir conserver sur la durée un avantage commercial face aux logiciels opensources poussés par les gafam ou surtout les solutions propriétaires dérivées de l'opensource développées par ceux-ci.
Si ElasticSearch est passé sous licence propriétaire, c'est à cause de ce dernier point: Amazon avait siphonné le projet et commençait à le vendre avec sa propre sauce secrète, en passant vers ESL, elasticsearch a bloqué Amazon, mais s'est aliéné les contributeurs tiers, en passant vers AGPL, Elasticsearch a renoué avec sa communauté tout en forçant Amazon à ne plus faire de la concurrence sur le code lui-même.
Le 24/09/2024 à 12h47
Quelques précisions : Tout à fait. De ce que j'ai lu (mais sans vraiment creuser pour recouper), c'est qu'ElasticSearch a été forké par les cloud providers (notamment AWS) pour le faire évoluer en fonction de leurs besoins propres, et donc fournissent maintenant une solution compatible ElasticSearch, mais qui n'est pas ElasticSearch.
ElasticSearch aurait cherché à faire prendre des licences aux clouds provider (d'où l'usage de la SSPL) via un premier changement de licence. Mais cela n'a pas marché, car la solution a été forkée. Du coup, maintenant que le fork a été fait, et que les cloud providers utilisent leur propre solution, ils ont de nouveau changé de stratégie pour repasser sur une licence libre, adaptée aux spécificités du Web (et donc des SAAS).
Précision : c'est toi qui a employé le terme d'extrémiste (et je l'ai repris dans un de mes commentaires pour te répondre, j'avoue). Je me contente de dire que la vision de la FSF est très binaire : ou la licence est libre, ou la licence est privatrice. Aucune nuance entre les deux.
Le 24/09/2024 à 15h13
Le 24/09/2024 à 15h18
Le 24/09/2024 à 16h38
Le 24/09/2024 à 16h51
Le github annonce bien une licence fair-source pour certains produits comme leur produit éponyme.
Certains projets sont annoncés comme open-source, car ils le sont réellement (Apache-2.0).
Non, sérieusement, donne moi des exemples précis montrant cette ambiguïté dont tu parles, car, pour l'instant, après 5min de recherche, je n'en vois pas.
Le 24/09/2024 à 10h47
Il y a un minuteur dans gitlab?? Qui nous dit que lors de la liquidation de la société que le compte Gitlab ne serait pas supprimé??
La valeur de cette société est dans son logiciel à l'instant t. Dans son domaine, un logiciel vieux de 2 ans possède peu de valeur. Qui va s'amuser à vérifier si les sources vielles de 2 ans sont réellement ce que la boîte affirme?? (pour compatibilité entre du matériel et du logiciel des sources vielles de 2 ans je ne dis pas, mais ce n'est pas le marché de cette boîte).
Le 24/09/2024 à 10h58
Le 24/09/2024 à 11h19
Liste non exhaustive, cela va s'en dire ;)
Modifié le 24/09/2024 à 10h24
Je me rappelle également bien des débats définition FSF vs définition BSD.
Le 24/09/2024 à 10h38
Il y a pas mal de débats possibles entre BSD et GPL, mais ces deux licences sont libres et opensources.
Le 24/09/2024 à 16h28
Sinon, on se retrouve avec de l'open source avec un modèle d'IA au coeur du bousin .
Le 24/09/2024 à 16h37
Le 24/09/2024 à 09h38
Le 24/09/2024 à 10h12
Le 24/09/2024 à 11h42
Où ai-je mal compris la news ?
Donc j'aime bien le dernier paragraphe de la news et le communiqué de l'April et la parfaite mauvaise foi qui l'accompagne.
Sinon une entreprise qui ferait affaire avec Sentry et qui demanderait l'obtention des codes dans le cahier des charges verrait directement si la licence correspond à leurs attentes ou pas non ?
Le monde de l'open-source et du libre se réserve le droit d'interdire toute licence qui ne leur plait pas ?
Modifié le 24/09/2024 à 13h57
Le 24/09/2024 à 15h30
Cela me conforte quand même dans ma position, où pour une bonne frange de la communauté libre/open-source, tout modèle alternatif est à rejeter. Mais bon, dire ça, apparemment, c'est faire preuve d'intolérance...
En théorie, non, puisqu'une des clauses d'une licence fair source serait justement que le code devienne, à terme, open source au sens OSI du terme
Une licence fair-source est, grosso modo, une licence source available avec promesse à terme d'être open source.
Car pour ceux qui ne serait pas au courant, une licence open source (au sens OSI du terme) ne se limite pas à l'accès au code source, mais confère des droits supplémentaires, notamment de modification et de redistribution.
Le 24/09/2024 à 17h27
Modifié le 25/09/2024 à 05h36
Je lis cet article de Next (https://next.ink/151204/entre-fermer-et-partager-le-code-est-ce-fair/) dans lequel l'APRIL donne la position suivante :
Ma position depuis 20 ans a toujours été de défendre le logiciel libre. Cependant, Je voudrais vous faire part de ma position de chef d'entreprise alors que nous réfléchissons depuis près de 7 ans à faire monter nos équipes en puissance, cela sur financement interne, faute de faire comprendre aux investisseurs que nous préparons l'avenir des échanges et du partage sécurisé des données sensibles en chiffrement de bout-en-bout (avec toutes les fonctions de sécurité connexes) sur un produit innovant et en rupture dont nous sortons ce 1ᵉʳ octobre dans sa nouvelle refonte rust en V3 (3 ans de travail interne et d'investissement).
Il est très dur de faire de la vraie innovation en numérique, même en s'appuyant sur les briques libres. Je parle de réelles innovations, et pas de produits logiciels construits à partir de l'intégration classique de briques libres.
Nous avons pris connaissance de ce qui s'est passé pour un certain nombre de produits innovants forkés par des grands comptes qui mettent ensuite les moyens : en résumé, l'innovateur et concepteur galère pendant les premières années et, quand la validité du nouveau concept devient une évidence, les gros acteurs du numérique se mettent à concurrencer la solution avec leurs moyens démesurés.
Nous y avons beaucoup réfléchi, et nous sommes arrivés (pour le moment, car nous sommes petits encore) à la solution que pour construire des biens communs immatériels en mettant l'innovateur dans une situation d'avantage, en protégeant la jeune pousse, ce qui est juste, il fallait introduire un mécanisme de libération différé. C'est pourquoi, nous avons opté pour la BSL. Ce n'est pas une position définitive.
Voilà, je voulais vous faire part de mon expérience de terrain. C'est pourquoi, je suis un peu plus en phase avec la position du CNLL : Il ne s'agit pas comme vous dites de rendre honorable une "politique de rejet de licence libre". Il s'agit de trouver une voie juste pour permettre à ceux qui innovent dans le libre de trouver les moyens de faire grossir leurs équipes pour développer plus vite leur roadmap. Nous avons, sur la base de notre noyau technologique, une roadmap énorme pour créer l'équivalent d'un "Teams" en Zero Trust (E2EE++). Sauf qu'actuellement, nous n'avons pas encore suffisamment de ressources financières pour recruter tout le monde : il faut laisser eux entreprises naissantes les moyens de financer leur croissance sans devoir faire appels aux investisseurs, qui trop souvent ne comprennent pas grand-chose à ce qu'on veut faire (ils comprennent surtout les mots "marché" et "ARR").
Amitiés. Thierry Leblond"
Le 25/09/2024 à 05h44
Le code source de Winamp a été publié sur GitHub.
Il semblerait déjà y avoir des soucis avec la mise à dispo d'éléments protégés (Dolby...) mais ce qui anime le plus les discussions, c'est la "Winamp Collaborative License (WCL) Version 1.0"
No Distribution of Modified Versions: You may not distribute modified versions of the software, whether in source or binary form.
No Forking: You may not create, maintain, or distribute a forked version of the software.
Official Distribution: Only the maintainers of the official repository are allowed to distribute the software and its modifications.
(désolé, j'ai du mal avec les balises)
Modifié le 25/09/2024 à 08h42
Si les termes Fair-Source, BSL et autres n'ont pas une bonne aura dans la communauté, c'est aussi à cause de cette question de la collaboration. Si par exemple on prend MongoDB, ElS, et assez récemment tous les produits hashicorp, on a vu des entreprises qui ont décidé de refermer leurs applications afin de maximiser temporairement leurs profits, mais s'aliénant les contributeurs qui avaient contribué à un bien commun dont soudain on essayait de les déposséder.
Dans le cas de Hashicorp, l'attaque contre la communauté a été particulièrement sournoise: hashicorp a fait disparaître toute trace de son historique opensource: tous les dépôts publics de cette entreprise sur github ont été purgés de leur historique pour que le contenu donne l'impression que la version précédente sous licence opensource n'avait jamais existé et empêcher tout nouveau fork d'être créé depuis leur historique.
Et lorsque la communauté à tout de même remonté un fork de Terraform, Hashicorp a commencé à crier au vol de propriété intellectuelle sous prétexte que des nouvelles fonctionnalités de la version BSL avaient été volées et intégrées dans la version opensource (les mainteneurs de la version opensource soutiennent que le contenu en question était déjà dans une autre branche sous licence opensource avant la grande purge, ce qui semble plausible puisque toute référence à ce code et à son cycle de vie ont été purgés par hashicorp)
La leçon générale que la communauté opensource/libre est occupée à tirer de tout ça est que, en tant que contributeur:
- il faut se protéger des entreprises qui font du libre ou qui font de l'erzats de libre: ne pas accepter de contributor agreement donnant à l'entreprise le droit de redistribuer les contributions sous une licence non-libre, et si ce n'est pas possible,
- il faut garder des preuves concernant le cycle de vie des contributions pour pouvoir faire face à des agressions comme celle de Hashicorp.
- si on ne veut pas être traité comme main d’œuvre gratuite, il faut éviter de contribuer à des projets qui ne sont pas basés sur une licences validée par l'OSI et/ou la FSF.
- En tant qu'employeur/OSPO , ne pas engager de ressources pour contribuer à des projets sous BSL et autres, c'est de l'investissement perdu.
En tant qu'utilisateur, il faut aussi se protéger, si on va vers de l'opensource, il est important de regarder la communauté des solutions visées: une bonne communauté permettra de retomber sur ses pattes si l'entreprise à l'origine d'un projet provoque volontairement ou involontairement un changement drastique des conditions d'utilisation.
Le 25/09/2024 à 09h44
Dans le cas de Winamp, c'est d'autant plus sujet à controverse qu'interdire le fork est contraire aux conditions de GitHub. Ils auraient pu au moins choisir une autre plateforme pour publier leur code.
Le 25/09/2024 à 11h11
Déjà, en niant les apports que peuvent faire les entreprises en libérant un projet complet, et en mettant en avant les contributions d'un projet. Qu'un projet reçoive 80% de contributions (plutot rare) ou juste 0,01% (très courant), c'est loin d'être la même chose.
Et ça me fait toujours rire quand je lis qu'il s'agit d'une attaque à la communauté, alors que la communauté ne voit pas le pied de nez qu'elle fait à l'entreprise en l'exploitant sans contrepartie, alors que l'entreprise gère 99,9% des coûts, que l'entreprise comptait effectivement sur les contributions (notamment financière) pour pouvoir vivre, et que l'absence d'un modèle viable parce que 99% des utilisateurs profites sans quasiment rien donner en retour l'oblige à changer son business modèle.
Attention : je ne dis pas qu'il n'existe pas des acteurs vertueux dans la communauté, car c'est le cas (et heureusement !). Ils sont juste trop peu nombreux. Je ne dis pas non plus que l'entreprise n'a pas fait d'erreur dans sa stratégie initiale et qu'elle n'attendait pas "trop" de la communauté. Non, je dis que c'est du donnant-donnant, et s'il l'équilibre est rompu ou n'est pas trouvé, il est normal de changer les conditions pour essayer de (re)trouver cet équilibre. Et c'est un peu le souci, ai-je envie de dire, avec les licences libres/open source, qui s'intéressent uniquement à ceux qui reçoivent. Il est, dès lors, difficile de trouver un équilibre, notamment financier, pour les entreprises (mais pas que, c'est vrai aussi pour les développeurs indépendants comme celui de XZ par exemple, qui n'a pas trouvé de business model pour ne serait-ce qu'avoir un salaire pour lui alors que son projet est utilisé sur des centaines de millions de système)
De plus, les attaques que tu mentionnes en donnant Hashicorp en exemple, ne sont pas juste l'apanage des entreprises. Tout projet, avec une licence permissive, peut subir le même sort ! Par exemple, curl (avec sa licence très permissive) pourrait tout à fait subir suivre le même chemin. Cela dépend du bon vouloir de son créateur et mainteneur.
On a vu des développeurs retirer des paquets sur un coup de tête, ou suite en représailles à un conflit (exemple de left-pad sur npm si ma mémoire est bonne), provoquant une mini-paralysie pendant quelques heures de tout un écosystème.
Dans ce que tu décris, tu rejettes entièrement la responsabilité sur l'entreprise et la communauté n'est qu'une pauvre victime, donc il faut se protéger des entreprises. C'est extrêmement réducteur. En fait, dès qu'on utilise des produits open-source, édités par des entreprises ou non, il faut prendre un minimum de précautions, à commencer par faire une copie du code (soit directement, soit disponible via des miroirs. C'est peut être de la parano, mais c'est ce que je fais !)
Pour terminer, je rajouterai qu'on a déjà vu par le passé des forks à cause de changement de licence, même d'une licence libre à licence libre (j'ai en tête X.org / XFree86)
Le 25/09/2024 à 11h54
Au passage, dans la grande majorité des cas, les contributeurs sont des entreprises qui payent des devs pour améliorer des fonctions spécifiques d'un programme opensource.
Que les entreprises éditrices veuillent protéger leur travail et leurs revenus, c'est légitime, que les contributeurs veuillent aussi pérenniser leur investissement dans l'amélioration d'un produit tiers, c'est aussi légitime, c'est tout.
L'opensource permet dans une certaine mesure d'organiser un cercle vertueux, ce cercle se fragilise au fur et à mesure que l'équilibre des forces bascule franchement vers l'éditeur du logiciel avec des licences comme le BSL ou le fair-source.
Le 25/09/2024 à 12h37
Pour moi, l'open-source / libre, en ne s'intéressant qu'à celui qui reçoit le logiciel, ne donne pas les bases nécessaires pour avoir un équilibre des forces et pouvoir obtenir un cercle vertueux (ce qui ne signifie pas que ce n'est pas possible, juste, très difficile).
Les licences comme BSL ou le fair-source sont justement là pour essayer de rétablir un peu l'équilibre. Comment ? En gros, en limitant seulement l'exploitation commerciale (j'ose espérer d'ailleurs que cette notion sera bien définie dans la licence, car cela peut vite être flou).
Le 25/09/2024 à 13h41
Le BSL n'est pas "rétablir l'équilibre" il fait pencher franchement la balance du côté de l'éditeur au détriment et des utilisateurs et des contributeurs. Le BSL ne crée ni un contexte pour la collaboration ni un contexte où une communauté peut maintenir la solution après un changement drastique chez l'éditeur. C'est juste du propriétaire avec des jolies couleurs.
Prenons un cas simple, imaginons à quoi ressemblerait l'écosystème Java si au lieu de choisir la licence GPL, Sun Microsystems avait pris BSL ... à ton avis, quel aurait été l'impact?
Le 25/09/2024 à 15h33
C'est ta vision. Je l'accepte. Mais ce n'est pas la mienne. La BSL ne change rien pour une grande majorité des utilisateurs.
A mon avis ? Pas beaucoup de différence. Java était déjà massivement adopté. Le passage sous GPL s'est fait tardivement (2006).
Même en considérant une application stricte de la licence BSL, les programmes compilés ne seraient pas concernés pour la très grande majorité des acteurs par la clause de non utilisation en production.
La question se poserait par contre pour la machine virtuelle. Soit HotSpot (la VM à l'époque) aurait connu une exception pour l'exécution des programmes (ce que permet la BSL), soit un autre type de licence source avialable aurait été choisi. Ou alors, ceux qui souhaiteraient continuer d'utiliser HotSpot le ferai avec quelques version de retard (et quand on voit les serveurs Java utilisé en production aujourd'hui sur les serveur par exemple, on voit bien que cela n'aurait pas été un frein pour nombre d'entre eux).
L'idée de Sun à ce moment là était de privilégier l'ouverture, pas de contraindre l'utilisation.
Maintenant, je te retourne la question : qu'est-ce qu'une licence de type fair source aurait changé à Java ? Je précise que pour moi, la BSL n'est pas une licence de type fair source. La BSL a une clause de non utilisation en production qui est assez restrictive (même trop à mon gout).
Modifié le 30/09/2024 à 06h48
L'alcool NON, mais l'eau FAIRugineuse, OUI !