Entre fermer et partager le code, est-ce « fair » ?

Entre fermer et partager le code, est-ce « fair » ?

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 ».

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 ».

Commentaires (52)


Donc Sentry mélange tout et soulève beaucoup de poussière pour essayer de grappiller, dans la confusion, des points de karma auprès des gens qui ne savent pas ce qu'en l'OpenSource et le Libre.

Ils ne sont pas les premiers et certainement pas les derniers à jouer à ce jeu.



Je les trouve "fair": des projets opensource qui n'en sont pas vraiment car il est trop compliqué de monter l'environnement de compilation du soft (le bon node js, le bon python non annoncé, les bon requirements dans l'ordre, les versions disparues des librairies de base à retrouver ou l'environnement linux avec l'ancienne libxxxx ...), j'en ai rencontré pas mal...
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.

Wosgien

Je les trouve "fair": des projets opensource qui n'en sont pas vraiment car il est trop compliqué de monter l'environnement de compilation du soft (le bon node js, le bon python non annoncé, les bon requirements dans l'ordre, les versions disparues des librairies de base à retrouver ou l'environnement linux avec l'ancienne libxxxx ...), j'en ai rencontré pas mal...
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.
Tant qu'ils ouvrent vraiment, c'est pas un très gros problème. Je peux accepter qu'un développeur n'ait pas l'énergie de mettre les formes ou des tutoriels, tant que ce qui est partagé l'est de bonne foi. J'ai plus de problèmes avec IBM-Redhat qui lui prend activement des mesures pour rendre l'exercice des libertés plus difficile en saccageant la transparence.

ragoutoutou

Tant qu'ils ouvrent vraiment, c'est pas un très gros problème. Je peux accepter qu'un développeur n'ait pas l'énergie de mettre les formes ou des tutoriels, tant que ce qui est partagé l'est de bonne foi. J'ai plus de problèmes avec IBM-Redhat qui lui prend activement des mesures pour rendre l'exercice des libertés plus difficile en saccageant la transparence.
Disons qu'ils sont dans la mouvance de "open source washing" actuelle, mais comme ils ont pignon sur rue, on le remarque.
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.
Il faut espérer que leurs SDKs resteront bien open source car j'ai du mal à imaginer leurs clients se mettre à embarquer des boîtes noires dans leurs applications... 🤔
Modifié le 24/09/2024 à 09h22

Historique des modifications :

Posté le 24/09/2024 à 09h21


Fait espérer que leurs SDKs resteront bien open source car j'ai du mal à imaginer leurs clients se mettre à embarquer des boîtes noires dans leurs applications... 🤔

La licence créée par Sentry n'est pas conçue pour les SDKs et ne sera pas utilisée pour ceux-ci, mais même si c'était le cas il n'y aurait aucune « boîte noire » puisque le code source est toujours disponible.
"- Vous allez pas m'installer du logiciel libre, hein ? Ça vaut rien.
- Non non... C'est du Fair Source...
- Ah bah j'aime mieux çà. Pas confiance."
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 ?


On peut se poser exactement la même question avec la notion d'open-source ou de libre.

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.
Non, la réaction du monde OpenSource ou Libre est normale, Sentry essaye d'enfumer le monde et de se faire passer pour ce qu'il n'est pas, ce n'est pas une question d'extrémisme, c'est une question de protéger son identité et de ne pas accepter qu'un acteur ne puisse se prévaloir de valeurs ou de qualités qu'il ne possède pas dans les faits. Soi ça adhère aux quatre libertés et c'est du libre, soit ça n'adhère pas et ce n'est pas du libre; soit correspond aux 10 points de la définition de l'opensource et c'est de l'opensource, soit cela n'en est pas.

Il est normal que ces groupes protègent leurs appellations.

ragoutoutou

Non, la réaction du monde OpenSource ou Libre est normale, Sentry essaye d'enfumer le monde et de se faire passer pour ce qu'il n'est pas, ce n'est pas une question d'extrémisme, c'est une question de protéger son identité et de ne pas accepter qu'un acteur ne puisse se prévaloir de valeurs ou de qualités qu'il ne possède pas dans les faits. Soi ça adhère aux quatre libertés et c'est du libre, soit ça n'adhère pas et ce n'est pas du libre; soit correspond aux 10 points de la définition de l'opensource et c'est de l'opensource, soit cela n'en est pas.

Il est normal que ces groupes protègent leurs appellations.
Ben non, Sentry n'essaie pas de se faire passer pour du libre ou de l'open-source justement. Sentry utilise une terminologie qui n'utilise ni free, ni open source.

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.

fdorin

Ben non, Sentry n'essaie pas de se faire passer pour du libre ou de l'open-source justement. Sentry utilise une terminologie qui n'utilise ni free, ni open source.

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.
Je pense que ragoutoutou faisait référence à ce genre de phénomène :
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).


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.

berléon

Je pense que ragoutoutou faisait référence à ce genre de phénomène :
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).


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.
Dans ce cas, je comprends mieux, et cela reste quand même une polémique pour pas grand chose. Les sources de codecov avant n'étaient pas disponible et ont été rendu disponible en 2023. Si l'usage du terme "open source" est impropre (je le concède volontiers), cela n'en est pas moins une volonté d'ouverture.

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 ^^

fdorin

Ben non, Sentry n'essaie pas de se faire passer pour du libre ou de l'open-source justement. Sentry utilise une terminologie qui n'utilise ni free, ni open source.

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.
Sentry communique énormément sur les valeurs de l'opensource et puis mélange le terme "fair source" au mix... ça a un petit côté enfumage...

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.

ragoutoutou

Sentry communique énormément sur les valeurs de l'opensource et puis mélange le terme "fair source" au mix... ça a un petit côté enfumage...

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.
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.


Je ne mélange rien du tout. L'open source ne s'est jamais éloigné du libre, car ils ont, depuis le début, une conception différente, mais qui s'exprime, grosso modo, de la même manière.

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).
Ce que tu sembles demander, c'est que des gens qui ont des principes et les défendent deviennent soudainement "raisonnables" ...


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.
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.


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).

fdorin

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.


Je ne mélange rien du tout. L'open source ne s'est jamais éloigné du libre, car ils ont, depuis le début, une conception différente, mais qui s'exprime, grosso modo, de la même manière.

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).
Ce que tu sembles demander, c'est que des gens qui ont des principes et les défendent deviennent soudainement "raisonnables" ...


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.
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.


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).
"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."

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...

ragoutoutou

"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."

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 seul qui soit intolérant ici, c'est toi, tu ne cesse de dépeindre le monde opensource comme des extrémistes.


Bah écoute, si tu le prends comme ça, je pense que je vais arrêter la notre conversation.

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.
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...


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é.

fdorin

Le seul qui soit intolérant ici, c'est toi, tu ne cesse de dépeindre le monde opensource comme des extrémistes.


Bah écoute, si tu le prends comme ça, je pense que je vais arrêter la notre conversation.

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.
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...


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 principe privateur "de libertés" est un langage qui marque l'opposition à la suppression des libertés. Quand Stallman, avec d'autres, a créé le mouvement du logiciel libre dans les années 80, c'était en réaction à l'apparition de logiciels propriétaires. Il faut bien se rappeler que dans les années 60/70, les logiciels étaient quasi tous libres, mais vers la fin des années 70, la suppression des libertés commençait à devenir dominante. Le logiciel libre est une réaction à cette privation de liberté.

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.

ragoutoutou

Le principe privateur "de libertés" est un langage qui marque l'opposition à la suppression des libertés. Quand Stallman, avec d'autres, a créé le mouvement du logiciel libre dans les années 80, c'était en réaction à l'apparition de logiciels propriétaires. Il faut bien se rappeler que dans les années 60/70, les logiciels étaient quasi tous libres, mais vers la fin des années 70, la suppression des libertés commençait à devenir dominante. Le logiciel libre est une réaction à cette privation de liberté.

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.
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.


Je pense que c'est là que nous sommes en désaccord. C'est un peu comme le débat chiffrer/crypter qui n'a de sens que pour les "initiés". La confrontation langage courant / langage spécialisé, le lambda moyen n'en a cure.

Pour beaucoup de non informaticiens (en tout cas, autour de moi) :
- logiciel libre = gratuit
- logiciel open source = source disponible
- logiciel libre != logiciel open source

fdorin

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.


Je pense que c'est là que nous sommes en désaccord. C'est un peu comme le débat chiffrer/crypter qui n'a de sens que pour les "initiés". La confrontation langage courant / langage spécialisé, le lambda moyen n'en a cure.

Pour beaucoup de non informaticiens (en tout cas, autour de moi) :
- logiciel libre = gratuit
- logiciel open source = source disponible
- logiciel libre != logiciel open source

Et le prosecco c'est du champagne...

à mal nommer les choses...

ragoutoutou

Et le prosecco c'est du champagne...

à mal nommer les choses...
on est d'accord. Open source n'aurait jamais du s'appeler open source. Trop de confusion :troll:

fdorin

on est d'accord. Open source n'aurait jamais du s'appeler open source. Trop de confusion :troll:
Ils auraient dû rester dans la FSF, ça aurait peut-être un peu tempéré RMS tout en poussant mieux les libertés... :dent:

fdorin

Ben non, Sentry n'essaie pas de se faire passer pour du libre ou de l'open-source justement. Sentry utilise une terminologie qui n'utilise ni free, ni open source.

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.
Sinon, au passage:

"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.

ragoutoutou

Sinon, au passage:

"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.
Léger comme affirmation ? Il suffit pourtant de voir des projets open-source très répandus et utilisés, maintenus par un seul développeur, et qui n'ont jamais réussi à trouver un business model ne serait-ce que pour pouvoir travailler à temps partiel dessus, comme XZ.

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 MariaDB MongoDB 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
Modifié le 25/09/2024 à 09h13

Historique des modifications :

Posté le 24/09/2024 à 11h15


Léger comme affirmation ? Il suffit pourtant de voir des projets open-source très répandus et utilisés, maintenus par un seul développeur, et qui n'ont jamais réussi à trouver un business model ne serait-ce que pour pouvoir travailler à temps partiel dessus, comme XZ.

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 MariaDB 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.

Posté le 24/09/2024 à 12h34


Léger comme affirmation ? Il suffit pourtant de voir des projets open-source très répandus et utilisés, maintenus par un seul développeur, et qui n'ont jamais réussi à trouver un business model ne serait-ce que pour pouvoir travailler à temps partiel dessus, comme XZ.

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 MariaDB MongoDB 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 ragoutou sur la confusion MongoDB/MariaDB

fdorin

Léger comme affirmation ? Il suffit pourtant de voir des projets open-source très répandus et utilisés, maintenus par un seul développeur, et qui n'ont jamais réussi à trouver un business model ne serait-ce que pour pouvoir travailler à temps partiel dessus, comme XZ.

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 MariaDB MongoDB 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
C'est MongoDB qui a changé de licence, pas MariaDB... et tout ce qu'ils ont réeussi à faire, s'est se faire oublier, plus personne ne les considère pour de nouveaux projets... et ElasticSearch est à nouveau sous licence libre grâce à l'AGPL (une de ces licences paraît-il d'extrémistes de la FSF)

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.

ragoutoutou

C'est MongoDB qui a changé de licence, pas MariaDB... et tout ce qu'ils ont réeussi à faire, s'est se faire oublier, plus personne ne les considère pour de nouveaux projets... et ElasticSearch est à nouveau sous licence libre grâce à l'AGPL (une de ces licences paraît-il d'extrémistes de la FSF)

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.
Merci pour la reprise. Il s'agit bien évidemment de MongoDB, pas de MariaDB (j'ai édité mon commentaire en conséquence).

Quelques précisions :
ElasticSearch est à nouveau sous licence libre grâce à l'AGPL


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).
une de ces licences paraît-il d'extrémistes de la FSF


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.

fdorin

Merci pour la reprise. Il s'agit bien évidemment de MongoDB, pas de MariaDB (j'ai édité mon commentaire en conséquence).

Quelques précisions :
ElasticSearch est à nouveau sous licence libre grâce à l'AGPL


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).
une de ces licences paraît-il d'extrémistes de la FSF


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.
Les nuances peuvent exister, juste elles devraient ne pas commencer à faire semblant d'être ce qu'elles n'ont pas. Il y a des fondations qui ont des principes, des chartes de qualité, il n'est pas correct de faire de la fumée pour faire croire qu'on joue le jeu.

ragoutoutou

Les nuances peuvent exister, juste elles devraient ne pas commencer à faire semblant d'être ce qu'elles n'ont pas. Il y a des fondations qui ont des principes, des chartes de qualité, il n'est pas correct de faire de la fumée pour faire croire qu'on joue le jeu.
En quoi ici l'usage de fair source fait semblant d'être ce qu'elle n'est pas ?

fdorin

En quoi ici l'usage de fair source fait semblant d'être ce qu'elle n'est pas ?
La communication tout autour sur le site?

ragoutoutou

La communication tout autour sur le site?
Le billet annonçant que Sentry est maintenant fair source est plutôt bien foutu.

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.

fdorin

Ben non, Sentry n'essaie pas de se faire passer pour du libre ou de l'open-source justement. Sentry utilise une terminologie qui n'utilise ni free, ni open source.

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.
Et concrètement, comment cette bascule d'ouverture du code se réalise??

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).

Soriatane

Et concrètement, comment cette bascule d'ouverture du code se réalise??

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).
Aussi, comment ça marche en général? Le code vieux de deux ans est ouvert, ok, mais quid des patches sécurité appliqués il y a deux mois? Si c'est juste pour jeter un code dépassé et pas à jour question sécurité sur la place publique en essayant de se faire passer pour un acteur du libre, ça risque d'être juste vu comme un acte de mauvaise foi.

Soriatane

Et concrètement, comment cette bascule d'ouverture du code se réalise??

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).
Ca va dépendre de la licence. Cela pourrait être un critère temporel (au bout de 2 ans par exemple, avec l'horodatage des commits), ou la sortie d'une nouvelle version x.y.z qui "libère" les versions x.y-1.*

Liste non exhaustive, cela va s'en dire ;)

ragoutoutou

Non, la réaction du monde OpenSource ou Libre est normale, Sentry essaye d'enfumer le monde et de se faire passer pour ce qu'il n'est pas, ce n'est pas une question d'extrémisme, c'est une question de protéger son identité et de ne pas accepter qu'un acteur ne puisse se prévaloir de valeurs ou de qualités qu'il ne possède pas dans les faits. Soi ça adhère aux quatre libertés et c'est du libre, soit ça n'adhère pas et ce n'est pas du libre; soit correspond aux 10 points de la définition de l'opensource et c'est de l'opensource, soit cela n'en est pas.

Il est normal que ces groupes protègent leurs appellations.
Sans vouloir refaire ce débat éternel, ce n'est pas aussi tranché que tu ne le présentes. Les 4 libertés dont tu parles ne sont pas une loi universelle mais une définition proposée par la FSF. Comment qualifier un logiciel n'autorisant que les 3 premières libertés FSF ?
Je me rappelle également bien des débats définition FSF vs définition BSD.
Modifié le 24/09/2024 à 10h24

Historique des modifications :

Posté le 24/09/2024 à 10h24


Sans vouloir refaire ce débat éternel, ce n'est pas aussi clair que tu le présentes. Les 4 libertés dont tu parles ne sont pas une loi universelle mais une définition proposée par la FSF. Comment qualifier un logiciel n'autorisant que les 3 premières libertés FSF ?
Je me rappelle également bien des débats définition FSF vs définition BSD.

Carpette

Sans vouloir refaire ce débat éternel, ce n'est pas aussi tranché que tu ne le présentes. Les 4 libertés dont tu parles ne sont pas une loi universelle mais une définition proposée par la FSF. Comment qualifier un logiciel n'autorisant que les 3 premières libertés FSF ?
Je me rappelle également bien des débats définition FSF vs définition BSD.
Non , c'est tranché, si ça ne suit pas les 4 libertés du libre, ce n'est pas du libre, si ça ne suit pas les 10 points de la définition de l'opensource ce n'est pas opensource.

Il y a pas mal de débats possibles entre BSD et GPL, mais ces deux licences sont libres et opensources.

ragoutoutou

Non , c'est tranché, si ça ne suit pas les 4 libertés du libre, ce n'est pas du libre, si ça ne suit pas les 10 points de la définition de l'opensource ce n'est pas opensource.

Il y a pas mal de débats possibles entre BSD et GPL, mais ces deux licences sont libres et opensources.
Je comprends ton point de vue, mais je suis comme @fdorin : si Sentry a une autre dénomination qui se démarque (et si ils se mettent à être cohérents et honnêtes dans leur communication), ça permet d'être plus clair.

Sinon, on se retrouve avec de l'open source avec un modèle d'IA au coeur du bousin .

Wosgien

Je comprends ton point de vue, mais je suis comme @fdorin : si Sentry a une autre dénomination qui se démarque (et si ils se mettent à être cohérents et honnêtes dans leur communication), ça permet d'être plus clair.

Sinon, on se retrouve avec de l'open source avec un modèle d'IA au coeur du bousin .
si ça se démarque et que dans leur communication ils ne jouent pas l’ambiguïté, pas de problème. Mais ils feraient bien de travailler pour lever les dites ambiguïtés.
Donc, si j'ai bien compris, la GPL v3, avec ses restrictions, est une licence fair source. :transpi:
une belle forme de bullshitance :D
Une licence dite "fair-source" n'est pas "open-source" ?
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 ?
Ils ne l'interdisent pas, ils disent juste que ça n'est pas du libre et pas de l'open source…
Modifié le 24/09/2024 à 13h57

Historique des modifications :

Posté le 24/09/2024 à 13h57


Ils ne l'interdisent pas, ils disent que ça n'est pas du libre et pas de l'open source…

Merci, grâce à toi, j'ai vu que l'article avait été modifié et que la réaction de l'April avait été ajouté.

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...
Une licence dite "fair-source" n'est pas "open-source" ?


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.
Open washing :ouioui:
Extrait de mon courriel à l'APRIL : "Bonjour Frédéric, Bonjour Eienne,

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 :
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 ».

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 :
« 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 [...] ».

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"
Modifié le 25/09/2024 à 05h36

Historique des modifications :

Posté le 25/09/2024 à 05h24


Extrait de ma lettre à l'APRIL : "Bonjour Frédéric, Bonjour Eienne,

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 :

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 ».


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 : « 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 [...] ».

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"

Posté le 25/09/2024 à 05h35


Extrait de ma lettre à l'APRIL : "Bonjour Frédéric, Bonjour Eienne,

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 :

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 ».


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 :
« 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 [...] ».

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"

Posté le 25/09/2024 à 05h35


Extrait de ma lettre à l'APRIL : "Bonjour Frédéric, Bonjour Eienne,

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 :

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 ».


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 :
« 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 [...] ».

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"

Posté le 25/09/2024 à 05h35


Extrait de ma lettre à l'APRIL : "Bonjour Frédéric, Bonjour Eienne,

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 :

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 ».

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 :
« 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 [...] ».

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"

Mon petit apport a cet article: voici un autre cas sur le même sujet.

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"
5. Restrictions

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)
Donc, en gros, ni opensource ni libre, le C dans le nom de la licence est intéressant: avec une licence aussi fermée, où se trouverait la collaboration? Qui aurait envie de contribuer?

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.


Modifié le 25/09/2024 à 08h42

Historique des modifications :

Posté le 25/09/2024 à 08h39


Donc, en gros, ni opensource ni libre, le C dans le nom de la licence est intéressant: avec une licence aussi fermée, où se trouverait la collaboration? Qui aurait envie de contribuer?

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'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.


Posté le 25/09/2024 à 08h39


Donc, en gros, ni opensource ni libre, le C dans le nom de la licence est intéressant: avec une licence aussi fermée, où se trouverait la collaboration? Qui aurait envie de contribuer?

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'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.


ragoutoutou

Donc, en gros, ni opensource ni libre, le C dans le nom de la licence est intéressant: avec une licence aussi fermée, où se trouverait la collaboration? Qui aurait envie de contribuer?

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.


Tout à fait d'accord. Je suis curieux de savoir quels sont les infos d'historique archivées par GitHub dans un cas comme celui que tu décris.

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.

ragoutoutou

Donc, en gros, ni opensource ni libre, le C dans le nom de la licence est intéressant: avec une licence aussi fermée, où se trouverait la collaboration? Qui aurait envie de contribuer?

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.


Bien que les faits que tu relates soient vrais, je trouve que tu les présentes de manière très biaisées.

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)

fdorin

Bien que les faits que tu relates soient vrais, je trouve que tu les présentes de manière très biaisées.

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)
Je ne nie pas les apports des entreprises, loin de là, je signale juste le risque que certaines entreprises partent avec le boulot des contributeurs sans aucune contrepartie.

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.

ragoutoutou

Je ne nie pas les apports des entreprises, loin de là, je signale juste le risque que certaines entreprises partent avec le boulot des contributeurs sans aucune contrepartie.

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.
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.


Justement, sur ce point, je ne suis pas spécialement d'accord (mais, ça, je pense que tu l'as compris ;) ).

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).

fdorin

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.


Justement, sur ce point, je ne suis pas spécialement d'accord (mais, ça, je pense que tu l'as compris ;) ).

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 libre met l'accent sur les droits des utilisateurs, pas l'opensource.

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?

ragoutoutou

Le libre met l'accent sur les droits des utilisateurs, pas l'opensource.

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 libre met l'accent sur les droits des utilisateurs, pas l'opensource


Les deux le font. Le libre, par essence même (c'est sa philosophie), l'opensource, c'est plus une conséquence (mais le fait est que cela revient au même au final).
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.


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.
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?


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

Historique des modifications :

Fermer