IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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
Dont ils ferment le code

Le , par Patrick Ruiz

2PARTAGES

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

Source : SFC

Et vous ?

Quel commentaire faites-vous du positionnement de la SFC ?

Voir aussi :

Richard Stallman revient au conseil d'administration de la Free Software Foundation après avoir démissionné en 2019 et déclare qu'il n'a pas l'intention de démissionner une seconde fois
Richard Stallman annonce qu'il est « toujours à la tête du projet GNU », car « le projet GNU et la Free Software Foundation ne sont pas les mêmes », dit-il
Richard Stallman démissionne du CSAIL au MIT ainsi que de son poste de président de la Free Software Foundation, à la suite à ses commentaires sur l'affaire Jeffrey Epstein
« Richard Stallman ne parle pas et ne peut pas parler au nom du mouvement du logiciel libre », a déclaré la Software Freedom Conservancy qui désapprouve ses commentaires sur l'affaire Jeffrey Epstein
Richard Stallman était invité à prendre la parole au siège de Microsoft Research, l'initiateur du mouvement du logiciel libre partage son expérience

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 02/07/2022 à 17:36
Les polémiques précédentes sur GitHub étaient dues au fait que pas mal de gens ont perdus leur comptes, sous prétexte que ces gens seraient localisés dans des pays ou les sociétés US n'ont pas le droit de fournir des services, genre l'Iran par exemple, et cela a créé la confusion car pas mal de bons contributeurs open source ont été virés du jour au lendemain, et que certains projets open sources ont été aussi anéantis par cette politique US.

Le nouveau scandale vient de Copilot, qui est désormais disponible, sauf que non content de piller le travail de toutes les bonnes poires qui postent naïvement sur GitHub, sans vraiment être d'accord explicitement avec ce pillage, le résultat de ce travail volé est "vendu", oui vendu, c'est payant ! C'est à dire que Github pille le code des gens, puis le revend au prix fort

Donc du coup de plus en plus de développeurs appellent au boycott, parce que trop c'est trop...
13  0 
Avatar de Chouteau
Membre du Club https://www.developpez.com
Le 04/07/2022 à 16:50
J'utilise Copilot depuis quelques mois maintenant (language c#), après l'effet Wahooo , il y a pas mal de fois ou le code qui m'a été proposé était au mieux complètement à coté de la plaque, ou au pire buggé.

D'ailleurs ça pose une question, est-ce que le code qui est analysé pour l'apprentissage, et ensuite proposé, est couvert par des tests ? (je n'ai vu nulle part cette information)
7  0 
Avatar de Fagus
Membre expérimenté https://www.developpez.com
Le 03/07/2022 à 15:33
Déjà je rejoins OrthodoxWindows sur l'histoire de la mise au pilori de Richard Stallman sur un soutien apporté au chercheur Marvin Minsky pour une allégation non prouvée et contestée.

Concernant les arguments de la Software Freedom Conservancy :

Sur le fond, rien n'oblige à utiliser Github. C'est une forme de centralisation partielle seulement car il y a des alternatives. Ensuite, Github est gratuit pour le FOSS, c'est pratique pour les projets désargentés.

Quant au scandale Copilot, où Microsoft a entraîné une IA sur les codes Github sans prendre en compte les licences, je suppose que cela aurait pu être fait sur n'importe quel code source librement accessible en ligne, ça me semble plus être un scandale séparé.

Le dernier argument est que Github est sous droit américain ...Malheureusement, qu'est-ce qui n'est pas sous droit ou sous le bon vouloir américain ... à par la Chine et la Russie ?
* les Européens ont appliqué les embargos US sous la menace US (ex sur l'Iran, en dehors de tout droit international, et suite à la répudiation de USA de leur propre signature au traité avec l'Iran) (non pas que j'estime beaucoup le gouvernement iranien ; c'est pour illustrer).
* Assange est en prison probablement pour le reste de ses jour pour journalisme à la demande US.
* le cloud souverain français est made in USA grâce aux lobbies sur notre gouvernement.
* les USA ont tout fait pour jeter de l'huile sur le feu en l'Ukraine et la Russie, et maintenant l'Europe sous pression US applique des sanctions manifestement sans effet sur l'agresseur, mais qui feront passer l'Europe en économie de guerre avec régression, pénuries dès la fin de l'année (et commandes massives aux USA...)
4  0 
Avatar de OrthodoxWindows
Membre éprouvé https://www.developpez.com
Le 03/07/2022 à 16:51
Concernant Github, je rejoins Fagus sur le fait qu'aucun développeur n'est obligé de l'utiliser. Github lui-même est fondé sur une plateforme au départ décentralisée ; cela fait toute la différence avec l'époque de SourceForge.
C'est sans doute pour cela que les défauts de Github sont incomparables à ceux de SourceForge.

Ce qui est intéressant ici, c'est la constatation, comme pour Google Chrome, qu'il n'y a plus besoin d'être le seul à répondre à une demande pour assoir un monopole. Avant, un abus de position dominante était lié à une disponibilité plus tardive chez la concurrence, ou alors à des fonctionnalités propriétaires ajoutées dans le but de rendre la concurrence inopérante (cf. IE). Aujourd’hui, un logiciel/service commercial peut arriver après les autres, en étant (et en restant) fondé sur une plateforme libre et open source (donc peu de fonctionnalités propriétaires), sans proposer des miliaires de fonctionnalités supplémentaires, et finir tout de même par assoir un monopole. Pour Github, c'est plus discutable, car des fonctionnalités nouvelles ont été apportées avant les autres, mais pour d'autres logiciels/services, comme Google Chrome, c'est clairement le cas. C'est effrayant, car cela signifie que la concurrence/les alternatives libre peuvent être théoriquement meilleure sur tous les plans, cela ne pourra plus suffire.
1  0 
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 04/07/2022 à 13:52
Sourcehut a l'air super austère à côté d'autre solutions open sources citées... J'ai du mal à comprendre cette mise en avant.
2  1 
Avatar de berceker united
Expert confirmé https://www.developpez.com
Le 06/07/2022 à 11:56
Citation Envoyé par Mingolito Voir le message
C'est un scandale ce Copilot payant !
Proposer à des gogos de truander leur employeur ou leur client, au lieu de faire le boulot, d'insérer du code pourri pris au hasard et sans aucune vérification, c'est la meilleure solution pour créer des logiciels bugués, ou pire encore d'y introduire des failles de sécurité voir des malwares, on a vu ce que ça a donné avec tous les guignols qui font leurs applis en copiant collant du code trouvé au hasard sur Stack Overflow, a savoir une augmentation massive des bugs et des failles logicielles, et la c'est encore pire.

Autrefois les anciens nous on codais nous même, et sans Framewok ! et on testait notre code avant de le livrer, bref le résultat était le fruit d'un dur labeur. La nouvelle génération c'est Copilot ou code Stack Overflow, on teste rien, on livre de la merde, et au lieu de bosser 8 heures par jour on bosse 20 minutes par jour, puis on retourne sous Tiktok ! Mais quelle honte...
"Haaa Simone c'était le bon vieux temps ..."
Avant, il fallait tout faire à la main, en effet mais ça eux sont lot de conséquence non négligeable. Les framework ont permit de réduire le temps de développement car les éléments x fois répété sont déjà développé. Cette couche est "généralement" bien éprouvée et testée.
1  0 
Avatar de marsupial
Expert confirmé https://www.developpez.com
Le 02/07/2022 à 17:27
Rébellion ?
0  0 
Avatar de robertledoux
Membre averti https://www.developpez.com
Le 04/07/2022 à 11:15
Sourcehut vs Github, le premier coût au minimum 2$/mois contre 0 pour le second, sur un projet open source de petite / moyenne taille, je choix est vite fait. Et je parle même pas de l'interface de sourcehut digne des année 90.

On préférera d'autres solutions comme :

- Gitea
- Gitlab
- Bitbucket
1  1 
Avatar de selmanjo
Membre du Club https://www.developpez.com
Le 07/07/2022 à 19:43
Je n'arrive pas à y croire mais j'espère qu'on n'aura pas à trop se salir les mains pour un petit bout de code
0  0 
Avatar de esperanto
Membre émérite https://www.developpez.com
Le 08/07/2022 à 10:15
Citation Envoyé par Mingolito Voir le message
Autrefois les anciens nous on codais nous même, et sans Framewok ! et on testait notre code avant de le livrer, bref le résultat était le fruit d'un dur labeur.
En effet autrefois on savait ce qu'on faisait et ce que la machine faisait quand on écrivait une ligne de code. Aujourd'hui faut raisonner avec cinquante couches d'abstraction qui font qu'on y comprend plus rien et en plus comme elles s'appellent entre elles bonjour les performances...

Citation Envoyé par berceker united Voir le message
Les framework ont permit de réduire le temps de développement car les éléments x fois répété sont déjà développé. Cette couche est "généralement" bien éprouvée et testée.
Franchement non. ça pourrait être le cas si on n'avait pas un nouveau framework à la mode qui chasse le précédent tous les deux ans.
Parce que les frameworks, faut bien les apprendre, et comme ils groupent en un seul point des dizaines de fonctionnalités pas forcément liées entre elles, c'est loin d'être une mince affaire. Alors la plupart du temps on prend le tutoriel et on le suit au pied de la lettre sans réfléchir, ce qui implique qu'une bonne partie du code est inutile (justifiée dans le tutoriel mais comme on n'a pas compris pourquoi, on le reprend partout à chaque fois). Mais pas grave puisqu'avec Eclipse beaucoup de code est généré automatiquement ce qui permet de donner l'illusion qu'on en a écrit beaucoup.
1  1