La Software Freedom Conservancy quitte GitHub pour marquer son désaccord avec les porteurs de projets qui utilisent l'open source pour aboutir à des solutions

[Indigostar]

Dont ils ferment le code

La Software Freedom Conservancy annonce qu’elle arrête de s’appuyer sur GitHub pour l’hébergement de projets open source. Elle exprime ainsi son désaccord avec les porteurs de projets qui utilisent l’open source pour aboutir à des solutions logicielles dont ils ferment le code source. Copilot, l’intelligence artificielle commerciale de GitHub, est au centre de cette décision dont la Software Freedom Conservancy expose les raisons.

L’intégralité de la position de la Software Freedom Conservancy

Ceux qui oublient l’histoire la répètent souvent par inadvertance. 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 et ne l’a plus jamais ouvert à la communauté. Les principaux projets libres et open source ont peu à peu quitté SourceForge car il s’agissait désormais d’un système propriétaire, contraire à l’esprit d’ouverture qui caractérise la communauté. Les communautés du 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 Libre. SourceForge s’est lentement effondré après le crash de DotCom, et aujourd’hui, SourceForge est plus un appât à liens publicitaires qu’un hébergement de 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 le GitHub de Microsoft.

Au cours des dix dernières années, GitHub est parvenu à dominer le développement des logiciels libres. Il y est parvenu en créant une interface utilisateur et en ajoutant des fonctions d’interaction sociale à la technologie Git existante. (Pour sa part, Git a été conçu spécifiquement pour que le développement de logiciels soit distribué sans site centralisé). Dans l’ironie centrale, 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 ces produits propriétaires (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 et encore comme un bon acteur - parce qu’ils soulignent leur largesse en fournissant 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 du Libre est le produit de GitHub, qu’ils ont personnalisé et reconditionné avec notre aide active (bien que souvent involontaire).

Les développeurs de logiciels libres sont depuis trop longtemps la grenouille proverbiale dans l’eau qui bout lentement. 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, nous avons historiquement auto-hébergé nos principaux dépôts Git, mais nous avons utilisé GitHub comme miroir. Nous avons exhorté nos projets membres et les membres de la communauté à é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 libres à migrer loin 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 était attendue depuis longtemps.

Plus précisément, la Software Freedom Conservancy a communiqué 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 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 pour lesquelles ils allaient “bientôt répondre”. 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 parallèle. Nous avons invité les représentants de Microsoft et de GitHub à la discussion publique, mais ils ont ignoré notre invitation. La semaine dernière, après que nous ayons rappelé à GitHub (a) les questions en suspens auxquelles nous avions attendu une année pour qu’ils répondent et (b) 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 des 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 un produit commercial à but lucratif. Le lancement d’un produit à but lucratif qui manque de respect à la communauté du Libre comme le fait Copilot rend simplement le poids du mauvais comportement de GitHub trop lourd à porter.

Nos trois principales questions à 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, s’il y en a une, avez-vous invoquée dans l’affirmation publique de Microsoft & GitHub, déclarée par le PDG (de l’époque) de GitHub, selon laquelle : “(1) l’entraînement de systèmes d’apprentissage machine sur des données publiques est un usage loyal, (2) la sortie appartient à l’opérateur, tout comme avec 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 tout simplement de justifier leur théorie juridique non étayée 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 des conditions de licence, pourquoi avez-vous choisi d’entraîner le modèle de Copilot uniquement sur des logiciels libres ? Par exemple, pourquoi vos bases de code Microsoft Windows et Office ne figurent-elles pas dans votre ensemble d’entraînement ?

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 étaient dans l’ensemble de formation utilisé pour Copilot ? Si non, pourquoi cachez-vous cette information à la communauté ?

Nous ne pouvons que spéculer 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 façon. (Les bons scientifiques prennent des notes minutieuses sur les entrées exactes 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é et quand et comment.

En raison des mauvaises actions de GitHub, nous appelons aujourd’hui tous les développeurs de logiciels libres à quitter GitHub. Nous reconnaissons que répondre à cet appel exige des sacrifices et de grands désagréments, et prendra beaucoup de temps à accomplir. Pourtant, refuser les services de GitHub est le principal moyen dont disposent les développeurs pour envoyer un message fort à GitHub et à Microsoft concernant leur mauvais comportement. Le modèle économique de GitHub a toujours été le “verrouillage des fournisseurs propriétaires”. C’est le comportement même que le logiciel libre a été fondé pour réduire, 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. Surveillez 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). Ainsi, 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 Edition.

Pendant ce temps, le travail de notre comité continue d’étudier attentivement la question générale des outils de développement logiciel assistés par l’intelligence artificielle. 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 libres et open source. 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 système CodeWhisperer d’Amazon (également lancé la semaine dernière) cherche à fournir une attribution appropriée et des informations sur les licences pour les suggestions de code.

Cela rappelle 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 pairs. Nous ne pensons pas qu’Amazon, Atlassian, GitLab ou tout autre hébergeur à but lucratif soient des acteurs parfaits. Cependant, une comparaison relative du comportement de GitHub à celui de ses pairs montre que le comportement de GitHub est bien pire. GitHub a également la réputation d’ignorer, de rejeter ou de déprécier les plaintes de la communauté sur un si grand nombre de sujets que nous devons exhorter tous les développeurs de logiciels libres à quitter GitHub dès qu’ils le peuvent. S’il vous plaît, rejoignez-nous dans nos efforts pour revenir à un monde où les logiciels libres sont développés en utilisant des logiciels libres.

Sources : SFC, open-source.developpez.com