Ceux qui oublient l'histoire la répète souvent par négligence.
Lien vers l’article original : https://sfconservancy.org/blog/2022/jun/30/give-up-github-launch/
Ceux qui oublient l'histoire la répète souvent par négligence. Certains d'entre nous se souviennent qu'il y a vingt et un ans, le site d'hébergement de code le plus populaire, un site entièrement libre et ouvert (FOSS) appelé SourceForge, a rendu tout son code propriétaire - pour ne plus jamais le rendre libre. Les principaux projets FOSS ont peu à peu quitté SourceForge car il s'agissait désormais d'un système propriétaire, contraire à l'éthique FOSS. Les communautés du logiciel libre ont appris que c'était une erreur de permettre à une société de logiciels propriétaires à but lucratif de devenir le site de développement collaboratif dominant du logiciel libre. SourceForge s'est lentement effondré après le crash de la bulle internet, et aujourd'hui, SourceForge est plus un site bourré de liens publicitaires qu'un site hébergeant du code. Nous avons appris une leçon précieuse qu'il était un peu trop facile d'oublier, surtout lorsque les entreprises manipulent les communautés du Libre à leurs propres fins. Nous devons maintenant réapprendre la leçon de SourceForge avec GitHub de Microsoft.
Au cours des dix dernières années, GitHub est parvenu à dominer le développement FOSS. Il y est parvenu en créant une interface utilisateur et en ajoutant des fonctions d'interaction sociale à la technologie Git. (Pour sa part, Git a été spécialement conçu pour que le développement de logiciels soit distribué sans un site centralisé). Ironiquement, GitHub a réussi là où SourceForge a échoué : ils nous ont convaincus de promouvoir et même d'aider à la création d'un système propriétaire qui exploite les logiciels libres. GitHub profite de ses produits propriétaires (et parfois de clients qui l'utilisent pour des activités problématiques). Plus précisément, GitHub profite principalement de ceux qui souhaitent utiliser les outils GitHub pour développer des logiciels propriétaires en interne. Pourtant, GitHub apparaît encore comme un bon acteur en insistant sur le fait qu’ils fournissent des services à tant d'entreprises du Libre. Mais nous avons appris des nombreuses offres gratuites de la Big Tech : si vous n'êtes pas le client, vous êtes le produit. La méthodologie de développement FOSS est le produit de GitHub, qu'ils ont rendu propriétaire et reconditionné avec notre aide active (bien que souvent involontaire).
Les développeurs FOSS ont été pendant trop longtemps comme la grenouille dans une casserole dont l'eau chauffe lentement. La grenouille s'étourdit à mesure que l’eau chauffe avant de finir ébouillantée. Le comportement de GitHub s'est progressivement aggravé, et nous avons excusé, ignoré ou autrement acquiescé à la dissonance cognitive. Nous, à la Software Freedom Conservancy, avons nous-mêmes fait partie du problème ; jusqu'à récemment, même nous étions devenus trop à l'aise, complaisants et complices de GitHub.
Abandonner GitHub demandera du travail, des sacrifices et peut prendre beaucoup de temps, même pour nous : à la Software Freedom Conservancy [SFC], nous avons historiquement auto-hébergé nos principaux dépôts Git. Nous avons également utilisé GitHub comme miroir. Nous avons vivement conseillé à nos projets membres et aux membres de la communauté d'éviter GitHub (et tous les services et infrastructures de développement de logiciels propriétaires), mais ce n'était pas suffisant. Aujourd'hui, nous adoptons une position plus ferme. Nous mettons fin à nos propres utilisations de GitHub et annonçons un plan à long terme pour aider les projets FOSS à migrer hors de GitHub. Bien que nous n'obligions pas nos projets membres existants à migrer pour le moment, nous n'accepterons plus de nouveaux projets membres qui n'ont pas de plan à long terme pour migrer hors de GitHub. Nous fournirons des ressources pour soutenir tous les projets membres qui choisissent de migrer, et nous les aiderons de toutes les manières possibles.
Il y a tellement de bonnes raisons d'abandonner GitHub, et nous en énumérons les principales sur notre site Give Up On GitHub. Nous envisagions nous-mêmes cette action depuis un certain temps déjà, mais l'événement de la semaine dernière a montré que cette action arrivait déjà trop tard.
Plus précisément, l'organisation Software Freedom Conservancy a communiquée activement avec Microsoft et sa filiale GitHub au sujet de nos préoccupations concernant "Copilot" depuis son lancement il y a presque exactement un an. Notre premier appel en chat vidéo (en juillet 2021) avec les représentants de Microsoft et de GitHub a donné lieu à plusieurs questions auxquelles ils ont déclaré ne pas pouvoir répondre à ce moment-là, mais qu'ils allaient y "répondre bientôt". Après six mois sans réponse, Bradley a publié son essai, If Software is My Copilot, Who Programmed My Software ? - qui soulève publiquement ces questions. GitHub n'a toujours pas répondu à nos questions. Trois semaines plus tard, nous avons lancé un comité d'experts chargé d'examiner les implications morales des logiciels assistés par l'IA, ainsi qu'un débat public en parallèle. Trois semaines plus tard, nous avons mis en place un comité d'experts chargé d'examiner les implications morales des logiciels assistés par l'IA, ainsi qu'un débat public parallèle. Nous avons invité les représentants de Microsoft et de GitHub à une discussion publique, mais ils ont ignoré notre invitation. La semaine dernière, après que nous ayons rappelé à GitHub les questions en suspens auxquelles nous avions attendu une année pour qu'ils répondent et leur refus de se joindre à la discussion publique sur le sujet, ils ont répondu une semaine plus tard, disant qu'ils ne se joindraient à aucune discussion publique ou privée sur ce sujet parce que "une conversation plus large [sur l'éthique des logiciels assistés par l'IA] semblait peu susceptible de modifier votre position [SFC], ce qui est la raison pour laquelle nous [GitHub] n'avons pas répondu à vos questions détaillées [SFC]". En d'autres termes, la position finale de GitHub sur Copilot est la suivante : si vous n'êtes pas d'accord avec GitHub sur les questions de politique liées à Copilot, vous ne méritez pas de réponse de Microsoft ou de GitHub. Ils ne se donneront la peine de vous répondre que s'ils pensent pouvoir modifier immédiatement votre position politique pour l'aligner sur la leur. Mais Microsoft et GitHub vous laisseront en plan pendant un an avant de vous le dire !
Néanmoins, nous étions auparavant satisfaits de laisser tout cela au bas de la liste de nos priorités. Après tout, pendant sa première année d'existence, Copilot semblait être plus un prototype de recherche qu'un produit. Les choses ont changé la semaine dernière lorsque GitHub a annoncé que Copilot était désormais un produit commercial à but lucratif. Le lancement d'un produit à but lucratif qui manque de respect à la communauté du logiciel libre comme le fait Copilot rend le poids du mauvais comportement de GitHub trop lourd à supporter.
Nos trois principales questions pour Microsoft/GitHub (c'est-à-dire les questions auxquelles ils nous promettaient des réponses depuis un an, et auxquelles ils refusent maintenant formellement de répondre) concernant Copilot étaient les suivantes :
- Quelle jurisprudence, le cas échéant, avez-vous invoqué dans la revendication publique de Microsoft & GitHub, déclarée par le PDG (de l'époque) de GitHub, selon laquelle : "(1) l'entraînement de systèmes de Machine Learning sur des données publiques est un usage légitime, (2) la résultante appartient à l'opérateur, tout comme un compilateur" ? Dans l'intérêt de la transparence et du respect de la communauté FOSS, veuillez également fournir à la communauté votre analyse juridique complète sur les raisons pour lesquelles vous pensez que ces déclarations sont vraies. Nous pensons que nous pouvons maintenant considérer le refus de Microsoft et de GitHub de répondre comme une réponse en soi : ils s'en tiennent manifestement à la déclaration de leur ancien PDG (la seule qu'ils aient faite sur le sujet), et refusent simplement de justifier leur théorie juridique non défendue auprès de la communauté par une analyse juridique réelle.
- Si, comme vous le prétendez, il est permis d'entraîner le modèle (et de permettre aux utilisateurs de générer du code basé sur ce modèle) sur n'importe quel code sans être lié par une quelconque licence, pourquoi avez-vous choisi d'entraîner le modèle de Copilot uniquement sur des logiciels libres ? Par exemple, pourquoi les codebases de Microsoft Windows et Office ne figurent-elles pas dans votre ensemble de données ? Le refus de répondre de Microsoft et de GitHub laisse également entrevoir la véritable réponse à cette question : Alors que GitHub exploite volontiers les logiciels libres de manière inappropriée, ils accordent beaucoup plus de valeur à leur propre "propriété intellectuelle" qu'aux logiciels libres, et se contentent d'ignorer et d'éroder les droits des utilisateurs de logiciels libres mais pas les leurs.
- Pouvez-vous fournir une liste des licences, y compris les noms des détenteurs de droits d'auteur et/ou les noms des dépôts Git, qui figuraient dans l'ensemble de données utilisé pour Copilot ? Si ce n'est pas le cas, pourquoi ne communiquez-vous pas ces informations à la communauté ? Nous ne pouvons que spéculer librement sur les raisons pour lesquelles ils refusent de répondre à cette question. Cependant, de bonnes pratiques scientifiques signifieraient qu'ils pourraient répondre à cette question de toute manière. (Les bons scientifiques prennent des notes minutieuses sur les paramètres exacts de leurs expériences). Puisque GitHub refuse de répondre, notre meilleure supposition est qu'ils n'ont pas la capacité de reproduire soigneusement leur modèle résultant, donc ils ne savent pas réellement la réponse à la question de savoir quels droits d'auteur ils ont violé, quand et comment.
En raison des mauvaises actions de GitHub, nous demandons aujourd'hui à tous les développeurs FOSS de quitter GitHub. Nous reconnaissons que répondre à cet appel exige des sacrifices et de grands désagréments, et prendra beaucoup de temps. Pourtant, refuser les services de GitHub est le principal pouvoir dont disposent les développeurs pour envoyer un message fort à GitHub et à Microsoft concernant leurs mauvais agissements. Le modèle économique de GitHub a toujours été l'"enfermement propriétaire" (proprietary vendor lock-in). C'est précisément ce type de comportement que les logiciels libres ont pour but d'enrayer, et c'est pourquoi il est souvent difficile d'abandonner un logiciel propriétaire en faveur d'une solution libre. Mais n'oubliez pas : GitHub a besoin que les projets FOSS utilisent leur infrastructure propriétaire plus que nous n'avons besoin de leur infrastructure propriétaire. Des alternatives existent, bien qu'avec des interfaces moins familières et sur des sites moins populaires - mais nous pouvons aussi aider à améliorer ces alternatives. Et, si vous nous rejoignez, vous ne serez pas seuls. Nous avons lancé un site Web, GiveUpGitHub.org, où nous fournirons des conseils, des idées, des méthodes, des outils et un soutien à ceux qui souhaitent quitter GitHub avec nous. Consultez ce site et notre blog tout au long de l'année 2022 (et au-delà !) pour en savoir plus.
Plus important encore, nous nous engageons à offrir des alternatives aux projets qui n'ont pas encore d'autre endroit où aller. Nous annoncerons d'autres options d'instance d'hébergement et un guide pour le remplacement des services GitHub dans les semaines à venir. Si vous êtes prêt à relever le défi et à abandonner GitHub dès aujourd'hui, nous notons que CodeBerg, qui est basé sur Gitea, met en œuvre de nombreuses fonctionnalités de GitHub (mais pas toutes). Par conséquent, nous allons également travailler sur encore plus de solutions, continuer à examiner d'autres options FOSS, et publier et/ou conserver des guides sur (par exemple) la façon de déployer une instance auto-hébergée de GitLab Community Edition1.
Pendant ce temps, le travail de notre comité continue d'étudier attentivement la question générale des outils de développement de logiciels assistés par l'IA. Une conclusion préliminaire récente est que les outils de développement de logiciels assistés par l'IA peuvent être construits d'une manière qui respecte par défaut les licences FOSS. Nous continuerons à soutenir le comité dans son exploration de cette idée et, avec son aide, nous surveillons activement ce nouveau domaine de recherche. Alors que GitHub de Microsoft a été le premier à agir dans ce domaine, à titre de comparaison, les premiers rapports suggèrent que le nouveau produit d'Amazon nommé CodeWhisperer (également lancé la semaine dernière) cherche à fournir une attribution appropriée et des informations sur les licences pour les suggestions de code[^2].
Cela renvoie à des problèmes de longue date avec GitHub, et la raison principale pour laquelle nous devons ensemble abandonner GitHub. Nous avons vu avec Copilot, avec le service d'hébergement de base de GitHub, et dans presque tous les domaines d'activité, le comportement de GitHub est sensiblement pire que celui de ses homologues. Nous ne pensons pas qu'Amazon, Atlassian, GitLab ou tout autre hébergeur à but lucratif soient des acteurs parfaits. Cependant, si l’on compare le comportement de GitHub à celui de ses concurrents on ne peut que constater que le comportement de GitHub est bien pire. GitHub a également la réputation d'ignorer, de rejeter et/ou de déprécier les plaintes de la communauté sur un si grand nombre de sujets que nous devons encourager tous les développeurs de logiciels libres à quitter GitHub dès que possible. S'il vous plaît, rejoignez-nous dans nos efforts pour revenir à un monde où le FOSS est développé en utilisant les logiciels libres.
Nous nous attendons à ce que ce blog post en particulier suscite de nombreuses discussions. Nous vous invitons à interagir avec le personnel de SFC sur notre liste de diffusion publique au sujet de cet article.
Crédits
Le contenu de cet article est en Licence Libre Creative Commons Cet article est une traduction issue du site de sfconservancy.
Notes de bas de page
#FOSS #Git #GitLab #Github #Froggit #IA #Sécurité
- Chez Lydra nous vous conseillons d'héberger votre code en France, pour cela vous avez la possibilité d'aller chez Framagit, un des CHATONS et, bien sûr, Froggit car nous allons lancer un programme pour les projets Libres après notre lancement commercial. [^2]: Cependant, nous n'avons pas analysé CodeWhisperer en profondeur et nous ne pouvons pas dire avec certitude si la mise en œuvre d'Amazon est conforme aux licences respectives. Néanmoins, le comportement d'Amazon dans ce domaine contraste fortement avec celui de GitHub de Microsoft : Amazon reconnaît le fait évident qu'il existe des obligations de licence qui méritent attention et soin lors de la construction de solutions de développement assisté par l'IA. ↩
