pylapp

FLOSS

Les piĂšges de certains composants open source

đŸ‡«đŸ‡· – dimanche 9 janvier 2022

Mots clés : #opensource, #FLOSS, #GitHub, #licences, #social

D'ordinaire nous aimons utiliser des bibliothĂšques tierces dans nos projets, ces “librairies” que l'on retrouve par exemple sur des forges logicielles publiques comme GitHub et GitLab. Rares sont les logiciels qui ne possĂšdent pas une once de FLOSS (Free Libre and Open Source Software) Ă  l'intĂ©rieur. Le plus souvent, on retrouve dans chaque projet des composants FLOSS, que ce soit pour se faciliter la vie, Ă©crire des tests unitaires ou gĂ©rer une base de donnĂ©es par exemple. On a vite tendance Ă  prendre l'outil le plus connu, le plus rĂ©pandu, ou Ă  faire des rĂ©flexions trop rapides pour choisir ce dont on a besoin, et pourtant il y a des piĂšges Ă  Ă©viter.

Tout le monde est juriste, Ă©videment !

Beaucoup (trop) d'entre nous ne considĂšrent pas suffisamment la licence qui est appliquĂ©e Ă  la libraire choisie ; par paresse intellectuelle, par pure fainĂ©antise, par certitude de bien comprendre les licences, par oubli, ou par excĂšs de confiance. On fait tous la boulette, et on en tire des leçons ensuite, ce n'est pas si anormal quand encore aujourd'hui dans les Ă©tablissements de formation Ă  l'ingĂ©nierie logicielle ou “les Ă©coles de codage” on en parle assez peu, ou pas assez, voire pas du tout. Merci les formations au rabais vendeuses de rĂȘves laissant leurs apprenants se fracasser sur le mur de la rĂ©alitĂ©.

Toutefois, parmi les piÚges dans lesquels chacun et chacune peuvent plonger, il y en a particuliÚrement qui sont beaux. Et grossiers. Et pourtant, beaucoup de personnes se font avoir, et ne finissent par réagir que lorsque le sujet est médiatisé. Avant de se jeter sur le dernier composant à la mode, regardons en détails les piÚges, en commençant par les licences évidemment.

Des clauses déloyales dans les licences

Par exemple, il y a quelques annĂ©es, on pouvait trouver les frameworks React de Facebook / Meta sous une curieuse licence “BSD + Patents”. Le truc, c'est que cette licence possĂšde des clauses relatives aux brevets (une vague idĂ©e ici). Si j'exagĂšre et grossis les choses, le fait de chercher des noises en justice Ă  Facebook Ă  l'Ă©poque pouvait faire tomber le droit que vous aviez d'utiliser ses cadriciels (j'adore ce mot). Pot de terre contre pot de fer dans du bĂ©ton armĂ©, embĂȘter Big F peut revenir Ă  vous interdire d'utiliser ses technos, donc Ă  retirer beaucoup de produits. Une fois la chose mĂ©diatisĂ©e, finalement Facebook changea son fusil d'Ă©paule et utilisa la licence MIT.

Bref, attention aux clauses déloyales des licences !

Des changements radicaux de licences

RĂ©cemment encore, c'est HashiCorp qui changea brutalement la licence de son produit phare nommĂ© Terraform, et l'entreprise est dans son bon droit. Le passage de la licence MPL 2.0 Ă  la Business Source License a Ă©tĂ© fait avec fracas, justifiĂ© maladroitement par l'entreprise et dĂ©criĂ© par la communautĂ© open source. MongoDB a eu droit aussi auparavant Ă  son concert de casseroles avec le passage Ă  la SSPL. Pour aller plus loin, MariaDB propose cette page de FAQ sur la BSL. Benoit Sibaud (un chouette collĂšgue chez Orange !) a rĂ©digĂ© et diffusĂ© un billet abordant les “virevoltantes valses de licences libres et non libres dans les bases de donnĂ©es”, trĂšs instructif ! En d'autres termes, attendez-vous Ă  peut-ĂȘtre voir des revirement de situations dingues sur les licences appliquĂ©es !

Le truc, c'est que quand bien mĂȘme une entreprise dĂ©cide d'agir ainsi, elle reste tout de mĂȘme lĂ©galement dans l'obligation de satisfaire les demandes qui concernent les licences anciennement appliquĂ©es. Autrement dit, si Ă  un instant T un composant C Ă©tait sous une licence libre L (admettons GPL 3.0), mais que plus tard cette licence passe Ă  une bullshit licence BL, si vous avez eu le composant sous licence L vous ĂȘtes en droit de demander les sources (si L l'autorise Ă©videment), mĂȘme si elles ne sont pas accessibles publiquement. Bon courage donc.

On peut ainsi imaginer jouer la prudence, et se dire que si on utilise des composants FLOSS, dans le doute, au cas oĂč, on pourrait garder une copie du code source. J'apprĂ©cie beaucoup cet article de Geoffrey Dorme qui vous donnera davantage de motivations Ă  le faire. En plus cloner les dĂ©pĂŽts Git d'une organisation GitHub c'est facile pour l'instant.

Imaginez maintenant, malgrĂ© les trahisons prĂ©cĂ©dentes, que certaines technos soient si rĂ©pandues qu'elles en deviennent presque indispensables pour des entreprises, au hasard les frameworks comme React. Rien n'empĂȘche Facebook / Meta du jour au lendemain de changer la licence, de rendre l'exploitation de l'outil payante, et de monter un vrai business model dessus. Un magnifique coup Ă  jouer maintenant que le place est faite dans l'Ă©cosystĂšme logiciel. Impossible ? C'est vite oublier le ramdam lorsque Oracle avait mis en place son JDK payant.

Mais il y a d'autres piĂšges plus gros encore...

L'ajout de clauses additionnelles

Prenons par exemple une librairie Java bien connue, qui est utilisĂ©e en production : Realm Java (la situation a Ă©tĂ© corrigĂ©e depuis, mais a trainĂ© un bon moment tout de mĂȘme pour que ce soit notable).

À premiùre vue, si on regarde le README vaguement, on voit ceci :

Extrait du README annonçant que le composant est sous licence Apache 2.0

On peut alors en dĂ©duire que le composant est sous licence open source Apache 2.0. Sauf que trop de gens s'arrĂȘtent lĂ . Car que si on jette un Ɠil au fichier de licence, on trouve certes des rĂ©fĂ©rences Ă  la licence Apache 2.0, mais aussi un autre Ă©lĂ©ment d'enfoirĂ© : l'export compliance.

Extrait du README annonçant que le composant est sous licence Apache 2.0 et qu'il y a une clause additionnelle

Vous pouvez retrouver le diff du commit sur GitHub, je vous met ci-dessous le contenu scélérat de cette clause, qui rend la licence non conforme à la définition donnée par l'OSI, donc plus open source du tout.

Clause indiquant que des Ă©lĂ©ments peuvent ĂȘtre soumis Ă  la loi amĂ©ricaine et que si l'entreprise, le pays ou une personne de la sociĂ©tĂ© est sur liste noire l'usage du composant est prohibĂ©

Pour celles et ceux qui n'ont plus assez de caféine dans le sang pour comprendre, voici un résumé : si on se retrouve sur une liste noire du gouvernement américain, que ce soit dans un pays, ou individuellement, ou dans une entreprise détenue par une personne dans cette liste noire, on ne peut pas utiliser ce produit.

En soit, quel est le soucis ?

Et bien le soucis est que l'on peut avoir des applications critiques ou indispensables, ou son produit tout bĂȘtement qui, si un jour le client, l'Ă©diteur, le pays, les actionnaires etc. sont dans le collimateur des États Unis d'AmĂ©rique, peuvent ĂȘtre dĂ©gagĂ©es des boutiques d'applications, avec toutes les consĂ©quences que ça implique.

On peut espérer que ça n'arrivera jamais, ceci dit l'Úre Trump a montré qu'il ne fallait pas grands choses pour que des fous furieux mettent la pagaille à l'échelle mondiale en interdisant l'usage de produits. Et le contexte international actuel ne rassure pas non plus vis à vis de la Russie. Demandez leur avis aux iraniens, cubains, ukrainiens ou chinois.

Bref, dit autrement, quand vous utilisez une librairie FLOSS, regardez sur GitHub la section dĂ©diĂ©e Ă  la licence. Si le texte “View licence” apparaĂźt au lieu du nom de la licence, il y a deux cas de figure :

  • le texte a Ă©tĂ© modifiĂ© (souvent les copyrights) ou dĂ©corĂ© faisant que GitHub s'y perd ;
  • il y a du texte en plus dans le fichier. Ceci pouvant ĂȘtre des dĂ©tails sur d'autres licences appliquĂ©es ou d'anciens contributeurs, ou des clauses additionnelles.

Affichage des détails du projet GitHub indiquant peu d'infos sur la licence

Et oui, tout ça en droit français est valable.

Mais oĂč ailleurs peut-on se faire avoir ?

La plaie de l'excĂšs de social dans les forges logicielles

Et si on regardait le nombre de commits ?

DĂ©jĂ , pour â€œĂ©valuer” un composant FLOSS, on peut regarder par exemple la vie de son code source. Ainsi, si un projet a des commits faits rĂ©guliĂšrement, on serait en droit de se dire qu'il est toujours vivant. Toutefois la contraposĂ©e est fausse car on peut trĂšs bien avoir des projets FLOSS qui semblent “vivoter”, avec peu de commits rĂ©guliers mais qui fonctionnent trĂšs bien, tout simplement car le projet en lui-mĂȘme peut ĂȘtre maintenu ponctuellement, discrĂštement, mais efficacement.

D'ailleurs regarder la date et le nombre de commits est aussi une fausse bonne idĂ©e, car par exagĂ©ration on pourrait croire qu'un projet qui a beaucoup de commits est un projet de qualitĂ©, et fiable, ce qui est absurde. Dans la mesure oĂč des outils comme Git permettent le squashing, les merge commits et le rebasing, on remarque bien que se fier uniquement Ă  un historique de commits n'est pas viable. De plus, doit-on vraiment prendre en compte les commits et pull requests ridicules qui arrivent lors du Hacktoberfest quand celles et ceux qui les proposent veulent juste profiter du moment pour avoir un joli badge sur le profil GitHub par pur opportunisme ?

Est-ce que pour l'exemple ci-dessous le projet est vivant ou mort ? On peut s'y fier ou pas ? Pour faire des confettis, c'est suffisant ?

Historique Git d'un projet affiché sur GitHub montrant que le projet n'a pas bougé au mieux depuis 10 mois, voire depuis des années

Et Si On RegArDaIt LeS LiKes eT LeS FoLlOwErS ?

Les rĂ©seaux sociaux ont amenĂ© du pire dans GitHub avec les “likes” et les compteurs de “followers”.

Cet autre piĂšge Ă  Ă©viter consiste Ă  se contenter de regarder ces nombres de stars et de forks d'un projet sur la forge logicielle que l'on veut. Avec l'avĂšnement des rĂ©seaux sociaux, on veut “liker”, “booster”, “up-voter” ou “starrer” des projets que l'on aime bien, ou que l'on pourrait aimer, ou pour faire plaisir au gars derriĂšre qu'on connait. Mais en soit, ni le fonctionnel ni la qualitĂ© du projet ne sont par essence et par dĂ©finition concernĂ©s. Il en est de mĂȘme pour les forks ; il est courant de voir des utilisateurs en crĂ©Ă©er juste... au cas oĂč, pour grossir son profil GitHub, ou pour faire une pull request un jour ou pas. Surtout ou pas. Quand au nombre de “followers” du dĂ©veloppeur principal, en quoi le fait qu'il en ait 2 300 au moins soit rassurant ? Le personnage peut ĂȘtre tout Ă  fait exĂ©crable, pĂ©nible voire mĂȘme adepte de la pizza avec des patates dessus, pourquoi afficher cette fausse notoriĂ©tĂ© qui n'apporte rien ?

Est-ce que l'exemple ci-dessous est un gros projet ? Un truc balĂšze ? Non, c'est juste un programme affichant un train Ă  vapeur si on se trompe de commande (moi j'adore).

Compteurs sociaux du projet avec 386 forks et au moins 2 600 forks

Environnement et qualité, beau code ou infect projet

On regarde les issues et requests ?

Un autre Ă©lĂ©ment Ă  considĂ©rer avec prudence est le nombre de issues et de pull requests / merge requests. En effet, un projet qui en possĂšde beaucoup peut ĂȘtre un projet trĂšs vivant, comme aussi un projet qui est trĂšs Ă  l'abandon mais avec une base d'utilisateurs rĂ©clamant des choses ou voulant contribuer sans personne derriĂšre pour valider. Ou alors peut ĂȘtre victime de trolls, comme ce fut le cas pour le dĂ©pĂŽt contenant l'algorithme de recommandations de Twitter. Prudence donc si on ne regarde que ces Ă©lĂ©ments sans les contextualiser.

On regarde les contributeurs ?

Chose intéressante aussi à voir, les contributeurs, ces petites mains visibles fournissant un incroyable travail.

Si vous utilisez un composant FLOSS avec un faible nombre de contributeurs, il est possible que derriĂšre ce projet il n'y ait presque personne en dehors de quelques passionnĂ©s dĂ©vouĂ©s (bĂ©nĂ©volement le plus souvent) Ă  leur projet (pour la gloire plus que pour l'argent). Il faut donc se demander si le fait que le projet repose sur un tout petit nombre de contributeurs est bloquant ou pas. Pour une librairie affichant de confettis c'est peut-ĂȘtre un Ă©lĂ©ment peu pertinent. Mais pour votre couche de chiffrement, est-ce une bonne idĂ©e de compter sur un seul pĂ©quin derriĂšre ?

D'ailleurs, question bĂȘte, est-ce que l'on suppose que la source de vĂ©ritĂ© est... fiable ? Car pour ĂȘtre affichĂ©s comme contributeurs sur un projet GitHub, il faut apparaĂźtre Ă  certains endroits dans les commits. Quid des personnes voulant rester anonymes ? Des personnes en pair-programming ? Ou d'une organisation faisant que le mainteneur principal s'acharne maladroitement Ă  garder un historique Git propre et donc fait du copier/coller des pull requests mais en gardant Ă  jour le fichier AUTHORS par honnĂȘtetĂ© intellectuelle ? Ou des robots qui exĂ©cutent des tĂąches automatisĂ©es sur le dĂ©pĂŽt et qui figurent dans les contributeurs ?

Ci-dessous un exemple, avec le projet Amaroq. A-t-on vraiment 13 contributeurs ou 1 seul ? D'ailleurs peut-on vraiment se contenter de mesurer l'activité par le nombre de commits ? Non, évidemment.

GitHub affichant les contributeurs, au nombre de 13
Détails des commits par contributeur montrant que finalement seulement un seul se démarque énormément

En parlant de commits et des contributeurs, peut-on vraiment faire confiance aux contributions ? Il y a des projets FLOSS qui exigent des signatures cryptographiques des commits d'une part, et que le Developer Certificate of Origin soit appliqué d'autre part. Engager les responsabilités de chacun et s'assurer que les commits soient intÚgres ne semble pas une mauvaise idée, mais a-t-on toutes et tous l'habitude de le faire ? Non. Méconnaissance ou fainéantise ?

La doc ?

D'ailleurs, on peut aussi regarder les Ă©changes qui ont lieu dans les issues, les Slack ou Mattermost. Pour ce composant FLOSS qui vous intĂ©resse, peut-ĂȘtre ne seriez-vous jamais amenĂ©s Ă  Ă©changer avec les mainteneurs derriĂšre. Mais si vous voulez contribuer, ĂȘtes-vous prĂȘts Ă  dialoguer avec une Ă©quipe ayant une organisation pyramidale ? Ou concentrĂ©e sur un dĂ©veloppeur quasi-messianique Ă  qui tout le monde demande son avis et attend son accord ? Est-ce que l'ambiance est dĂ©lĂ©tĂšre dans le projet ?

On regarde le code source alors ?

Par ailleurs, jetez un Ɠil aussi au code source en lui-mĂȘme.

Si vous avez un projet iOS Ă©crit en Swift, avec uniquement des compĂ©tences en Swift dans votre Ă©quipe, seriez-vous prĂȘt Ă  soumettre des pull requests sur un composant Ă©crit en bon vieux Objective-C Ă  la papy ? Si une librairie JavaScript vous plait pour faire des jolies animations, ça vous tente vraiment de l'utiliser sachant qu'elle va tirer jQuery et que vous ĂȘtes fiers de vous en ĂȘtre dĂ©barrassĂ©s y'a 2 ans ? Si le CERT signale de vulnĂ©rabilitĂ©s critiques, et que le composant que vous voulez est concernĂ©, comment et Ă  quelle vitesse sont corrigĂ©es ces failles ? Il y en a certaines qui ne le sont toujours pas ? Et ils feront comment si le Cyber Resilience Act passe ? Si on voit plusieurs issues sur des vulnĂ©rabilitĂ©s non corrigĂ©es, remontĂ©es par Dependabot ou Snyk peut-on nĂ©cessairement en conclure que ce composant est dangereux alors qu'un autre sans de telles choses le serait moins mĂȘme si finalement il pourrait n'avoir en place aucun outil de dĂ©tection ?

Les gens c'est bien aussi non ?

Truc rigolo, vous connaissez le dĂ©veloppeur / grand chef derriĂšre le composant que vous voulez ? Car peut-ĂȘtre politiquement engagĂ© ou susceptible, ou impulsif, ou infect, et qu'il va saboter son projet ou pas, quitte Ă  se faire virer de GitHub. Impossible ? Voyez plutĂŽt.

Du coup...

Du coup, il n'y a pas de bons ou de mauvais composants FLOSS. Certains sont d'apparence plus fiables que d'autres, il faut les juger par leur efficacitĂ© mais pas uniquement ceci dit. Il faut rester prudent sur les licences altĂ©rĂ©es, batĂąrdes ou simplement sur leur nature intrinsĂšque. S'intĂ©resser Ă  l’environnement, Ă  l'ambiance, aux commits et au code source est une bonne chose Ă©galement.

Il faut aussi envisager le fait qu'un projet finisse par mourir, que sa core team abandonne, que le moteur s'Ă©puise. N'attendez pas pour les soutenir. N'attendez pas pour contribuer. N'hĂ©sitez pas les soutenir s'ils dĂ©fendent des causes justes. L'open source c'est comme une kombucha : c'est super de rĂ©cupĂ©rer une souche mĂšre pour faire vos boissons, mais c'est mieux de partager vos souches filles Ă  d'autres personnes pour qu'elles fassent pareil. À rester dans votre coin tout finira par pourrir et vous n'en tirerez plus grands choses. Prenez, amĂ©liorez, partagez et profitez.

Si vous voulez quelques pistes pour aborder les projets FLOSS, je vous partage ce support documenté, factuel et juste.

Message GitHub indiquant que le projet a été archivé par son propriétaire et qu'il est en lecture seule

— DerniĂšre mise Ă  jour : vendredi 25 aoĂ»t 2023 PrĂ©cĂ©demment sur paper.wf —

Did you enjoy reading this blog? Give me a beer đŸș or use something else â€ïžâ€đŸ”„ Licensed under CC-BY-SA 2.0 Opinions are my own, even if I have some interests.

Et si on parlait de l’hypocrisie vis à vis des GAFAM et du libre ?

đŸ‡«đŸ‡· – jeudi 16 aoĂ»t 2018

Mots clés : #GAFAM, #libre, #opensource, #FLOSS, #tech

Cet article est Ă  considĂ©rer comme un billet d’humeur, et Ă  ce titre les opinions exprimĂ©es ici ne sont que les miennes. Mais je trouve pertinent de prĂ©ciser pour la suite plusieurs choses. Tout d’abord, oui je me considĂšre comme libriste, et partisan de l’open source. Oui, la vie privĂ©e, le partage et l’ouverture sont des sujets qui me prĂ©occupent. Oui, je suis aussi cette annĂ©e prĂ©sident d’un Google Developers Group (GDG). Si vous faites un blocage lĂ -dessus me considĂ©rant comme un dĂ©vot, inutile de continuer Ă  lire vous risqueriez d’avoir un avis nuancĂ© :) Sinon sachez qu’ĂȘtre dans un GDG n’engage Ă  rien, n’impose rien, ne contraint rien, et ne permet que d’avoir accĂšs Ă  beaucoup de contenus, et dans le cadre d’une p’tite association de dĂ©veloppeurs de Lannion comme Code d’Armor, ce n’est pas nĂ©gligeable. Ce billet d’humeur fait suite Ă  ces vagues d’hypocrisie institutionnalisĂ©es et un brin dĂ©magos qui concernent aussi bien les gĂ©ants du web que les solutions alternatives


\( ‱_‱)_† Vade retro GAFAM

Ne nous voilons pas la face, il y a des bons et des mauvais cĂŽtĂ©s chez les gĂ©ants du web, et c’est un fait. Dit autrement, les avis butĂ©s et non nuancĂ©s hurlant au “diable Google” et au “cancer Facebook” sont assez risibles et tristes. Bim, c’est dit.

Que leur devons-nous, Ă  ces grosses entreprises AmĂ©ricaines ? Beaucoup de choses, mais pas tout non plus. Prenons l’exemple d’Apple. Ce membre de GAFAM propose des produits onĂ©reux, mais gĂ©nĂ©ralement efficaces, et faisant partie d’un Ă©cosystĂšme riche et cohĂ©rent pour l’utilisateur. Qui a dĂ©mocratisĂ© (sans inventer) les tablettes numĂ©riques proposant (enfin !) des bons produits ? Apple. Qui Ă©vite de tomber dans la facilitĂ© en limitant son catalogue de smartphones pour ne pas avoir Ă  proposer des appareils bas de gamme bons au rebus au bout de 2 ans ? Apple (pas seulement). Qui met en avant la protection de la vie privĂ©e de ses utilisateurs quitte Ă  avoir des dĂ©boires avec le gouvernement AmĂ©ricain ? Vous avez compris. Il y a certes une prison dorĂ©e et verrouillĂ©e pour les usagers, saupoudrĂ©e d’un peu de marketing bullshit, mais la marque de Cupertino a su rĂ©pondre efficacement Ă  des besoins. Passons du cĂŽtĂ© G des GAFAM. Sans chercher pour autant Ă  faire un catalogue des services de Google/Alphabet, il y a des Ă©lĂ©ments qui se dĂ©marquent dont des projets de X. Le projet Loon pour dĂ©livrer un accĂšs Ă  l’Internet dans des endroits reculĂ©s, le projet Wing pour d’autres modes de transport ou le projet AI, sobrement baptisĂ© pour l’intelligence artificielle. Alors oui, il ne s’agit pas ici de pure philanthropie. Google et Alphabet restent des entreprises, et les revenus de la firme de Moutain View sont essentiellement publicitaires. Mais il y a des efforts pour creuser diffĂ©rents sujets et faire avancer les dĂ©bats sur des thĂšmes qui finiront tĂŽt ou tard par s’imposer.

Je ne vais pas m’amuser Ă  faire une liste des contributions de tous ces gĂ©ants, ni de leurs dĂ©rives vis Ă  vis des donnĂ©es, de la vie privĂ©e ou de la coopĂ©ration avec des États, mais voici quelques Ă©lĂ©ments posĂ©s en vrac qui me font me poser la question suivante : Si nous devons bannir ces entreprises de nos vies, serions-nous prĂȘt Ă  jeter ces produits, ou ceux sur lesquels ils sont basĂ©s, ou encore les outils auxquels des contributions ont Ă©tĂ© apportĂ©es ? Je cite en vrac entre autres les librairies et frameworks Flutter, Angular, Polymer et React, le systĂšme d’exploitation Android, le navigateur Chromium, les langages informatiques GraphQL, Dart, Go et TypeScript, l’outil Kubernetes, TensorFlow et PyTorch pour l’intelligence artificielle, l’Open Handset Alliance, et Google Project Zero pour la sĂ©curitĂ© informatique.

On peut ainsi constater deux choses : nous devons beaucoup d’outils et de produits Ă  ces sociĂ©tĂ©s, certains vraiment formidables d’ailleurs, mais justement, ne nous leur en devons pas trop ? La question reste ouverte.

(╯°□°)╯ Serment d’hypocrite

La raison qui me fait Ă©crire ce billet, est de voir l’augmentation de cas de comportements schizophrĂšnes, ou de syndromes de Stockholm, vis Ă  vis des GAFAM. Comment peut-on rester stoĂŻque quand des Ă©lus torpillant les GAFAM vis Ă  vis de leur ingĂ©rence dans la vie privĂ©e et la collecte de donnĂ©es laissent leurs Ă©coles ou ateliers numĂ©riques s’installer sur le territoire ? Comment ne peut-on pas ĂȘtre affligĂ© quand on voit des personnalitĂ©s politiques scandalisĂ©es par le monopole de ces gĂ©ants, quand on leur laisse des villes, l’Éducation Nationale et le MinistĂšre des ArmĂ©es ? Comment peut-on Ă  la fois critiquer l’omniprĂ©sence des entreprises AmĂ©ricaines dans nos vies quotidiennes, sans pour autant Ă©duquer les citoyens au numĂ©rique et favoriser les solutions alternatives ? Car oui, il y en a ! En cherchant un peu, on peut voir que dans une multitude de situations, des solutions non intrusives, respectueuses et vertueuses existent, et rendent dispensable l’utilisation des produits de GAFAM.

Nombreuses sont les critiques vis Ă  vis de l’hĂ©gĂ©monie d’Android dans le monde des appareils mobiles. Si sa prĂ©sence (indirectement celle de Google) gĂšne autant, quand arriveront les soutiens officiels et concrets Ă  des projets comme eelo ou LineageOS ? Lorsque des villes ont besoin de services en ligne Ă  des fins de gain de productivitĂ© ou de partage, pourquoi ne voit-on pas ou peu de communication sur des solutions comme celles proposĂ©es par Cozy Cloud ou Framasoft ? Quand des personnalitĂ©s politiques tirent sur WhatsApp et Telegram, applications n’ayant pas leur confiance, pourquoi voit-on des travaux sur une app française de messagerie sĂ©curisĂ©e alors que d’autres existent comme Signal ? Devrions-nous nous attendre Ă  des fiascos comme Louvois et SAIP ?

(ლâ•č◡â•čლ ) La route est longue...

Il ne faut cependant pas voir le verre Ă  moitiĂ© vide. Des progrĂšs peuvent ĂȘtre citĂ©s, notamment avec GendBuntu dans la Gendarmerie (systĂšme d’exploitation basĂ© sur Ubuntu) (chacun sa paroisse hein), ou encore la montĂ©e en puissance de Qwant. Des associations et partis continuent de taper du poing sur la table et de dĂ©battre, comme l’April, la Quadrature du Net ou le Parti Pirate. Des projets ont mĂȘme donnĂ© des fruits pas dĂ©gueus comme CHATONS, et DĂ©googlisons Internet.

Le problĂšme est que, au jour d’aujourd’hui, les projets et entitĂ©s qui se soucient de la vie privĂ©e, du numĂ©rique, de la dĂ©centralisation et du partage sont gĂ©nĂ©ralement catĂ©gorisĂ©s dans un coin comme une sorte de militantisme paranoĂŻaque Ă  voir le mal partout, un peu comme ce tonton rĂ©ac’ qu’on invite aux repas de famille mais qu’on Ă©vite de trop laisser parler. Mais ne serait-il pas tant d’essayer ou de promouvoir de nouveaux modĂšles ?

Prenons par exemple la plateforme Patreon. Si des artistes arrivent Ă  ĂȘtre financĂ©s via cette plateforme, pourquoi pas des membres de projets libre et open source ? En France, le mouvement (relativement louable) de la #StartupNation s’installe pour favoriser la crĂ©ation d’entreprises. Et si on avait un mouvement similaire type #FreeNation ? Le nom claque un peu quand mĂȘme. DerniĂšre idĂ©e, les cryptomonnaies. En supposant que l’on place les efforts et dĂ©bats ailleurs que sur la spĂ©culation, la rĂ©gulation ou l’interdiction des cryptomonnaies et des ICO, ne pourrait-on pas par exemple imaginer des tokens permettant de financer des entitĂ©s dĂ©vouĂ©es Ă  l’open source ? Quitte Ă  ĂȘtre disruptif avec ces monnaies alternatives, pourquoi pas l’ĂȘtre Ă  fond et repenser la rĂ©munĂ©ration ?

M’enfin bon. A force de rĂ©flexions de ce genre, et puisque tous ces Ă©lĂ©ments sont gĂ©nĂ©ralement inconnus du public, et que les discours concernant les GAFAM sont systĂ©matiquement binairisĂ©s pro/anti, je me demande s’il n’y a pas finalement un refus de la classe politique et d’une partie de la population de se poser des questions, de soutenir des solutions meilleures pour tous, et de remettre en cause ses habitudes. Personnellement je me dis qu’un jour le message finira par passer. Pas Ă  grands coups d’articles putaclicks, mais plutĂŽt Ă  force d’éditions de Libre en FĂȘte comme Ă  Lannion ou de CafĂ©s Vie PrivĂ©e, ça finirait peut-ĂȘtre par changer
 mais les prises de conscience tardent.

Je terminerai par une belle phrase de Framasoft qui résume tout ça : La route est longue mais la voie est libre...

Entre temps, faütes un tour sur la page du projet Contributopia ;–)

— DerniĂšre mise Ă  jour : mercredi 9 fĂ©vrier 2022 PrĂ©cĂ©demment sur Medium et paper.wf —

Did you enjoy reading this blog? Give me a beer đŸș or use something else â€ïžâ€đŸ”„ Licensed under CC-BY-SA 2.0 Opinions are my own, even if I have some interests.