https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html
Cet article de blog précise les raisons des décisions prises par vote concernant l'usage des IAg au sein de Codeberg.
- Codeberg s'engage à ne pas utiliser les données des projets pour entraîner des IAg.
- Les projets vibcodés ne sont plus les bienvenus sur la plateforme.
Codeberg considère par une décision en assemblée puis votée que les LLMs sont dangereuses pour l'écosystème du libre dans son ensemble.
La deuxième mesure a été votée avec un peu plus de controverse que la première mais à une large majorité de 358 contre 144 et 14 abstention.
L'article commence par rappeler les dégâts causés par le scrapping de données sur la plateforme et l'augmentation des coûts du matériel qui concerne aussi bien les plateformes que les utilisateurs.
Les dégâts environnementaux sont ensuite évoqués, en rappelant qu'a Frankfurt 40% de l'électricité est déjà affectée aux datacenters avec une demande en hausse de rajouter des générateurs à base d'énergie fossile.
Ensuite il parle du ridicule de vibecoder un projet en s'illusionnant sur le fait d'avoir une communauté autour de son projet. Codeberg n'est pas fait pour héberger des projets fantômes.
L'usage des LLMs met le principe de collaboration en danger en favorisant les projets solos ni écrits ni maintenus par quiconque.
L'usage généralisé des LLMs dans les logiciels libres impacte la confiance entre les contributeurs et l'idée d'une collaboration conviviale et met la pression sur les mainteneurs par un afflux de contributions générées par LLM.
On rentre dans un cercle vicieux dans lequel on est de moins en moins incité à collaborer.
Codeberg veut rester une plateforme de collaboration humaine.
Pour terminer il n'y aura pas de chasse aux sorcières, à chacun de jouer le jeu et de retourner sur d'autres plateformes le cas échéant.
Aucune mention n'est faite sur les problèmes de copyright ni avis sur l'efficacité ou non des LLMs.
# la résistance s'organise.
Posté par oau . Évalué à 9 (+8/-1).
Rejoignez la résistance :)
[^] # Re: la résistance s'organise.
Posté par volts (Mastodon) . Évalué à 9 (+8/-1).
Et c'est ainsi que débute le Jihad Butlérien qui changera à jamais la civilisation humaine.
# Quitte ou double ?
Posté par wilk (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Est-ce que la plateforme va voir arriver des projets voulant montrer qu'ils n'utilisent pas de LLMs et souhaitent favoriser la convivialité humaine ou va-t-elle plutôt en perdre par ceux qui considèrent que la technologie est froide et neutre ?
[^] # Re: Quitte ou double ?
Posté par Misc (site web personnel) . Évalué à 2 (+0/-1).
Moi, ce que j'aimerais savoir, c'est ce qui a été fait pour protéger les gens depuis février 2025.
Car bon, y a des thunes (c'est dit dans l'article), y a eu du temps (genre 1 an), et y a eu quoi ? (vrai question, j'ai pas regardé ce qui a été codé, et je précise que je part sur un à priori négatif comme dit à l'époque, avis qui peut changer si en effet, quelque chose a été fait).
Je comprends bien que coder et faire un poste de blog sur un changement de gouvernance, c'est pas incompatible, mais ça décrédibilise pas mal le propos si y a rien eu 1 an après. Et je comprends bien que c'est des volontaires, mais être volontaires n'a jamais empêché de ne pas promettre trop.
[^] # Re: Quitte ou double ?
Posté par oliverpool (site web personnel) . Évalué à 7 (+6/-0).
Ils ont développé des outils permettant de signaler les comportements abusifs pour exclure plus rapidement les comptes problématiques: https://forgejo.org/2025-10-release-v13-0/#reporting-abusive-content
(je contribue à parfois à Forgejo)
[^] # Re: Quitte ou double ?
Posté par Misc (site web personnel) . Évalué à 3 (+0/-0).
Bon, c'est déjà ça.
Mais du coup, je continue de penser que les faits (limitées par les moyens et les ressources, j'entends bien) sont quand même pas à la hauteur des proclamations.
C'est comme la question de la fédération, ça semble pas avancer surtout que la fédération était la principale raison donnée par Loic D pour le fork (ça et le fait de forcer le changement de licence par son faux nez).
(ensuite, je suis surtout salty sur les événements, donc bon, faut sans doute m'ignorer)
[^] # Re: Quitte ou double ?
Posté par oliverpool (site web personnel) . Évalué à 3 (+2/-0). Dernière modification le 24 juillet 2026 à 08:29.
Bon, alors je réponds une dernière fois et après j'arrête :)
À part bloquer les comptes plus rapidement (ce qui a apparemment suffisamment aidé) et prendre position publiquement, je ne sais pas trop ce qu'ils peuvent faire d'autre. Des poursuites en justice pour du spam?
C'est lent, mais c'est mentionné dans pas mal d'articles de blog. Par exemple celui du mois dernier: https://forgejo.org/2026-05-monthly-report/#federation
https://gitea-open-letter.coding.social/ ne mentionne pas la fédération. De mon point de vue, le fork est principalement pour des raisons politiques (gouvernance du projet) et pas pour des raisons techniques.
[^] # Re: Quitte ou double ?
Posté par Misc (site web personnel) . Évalué à 9 (+6/-0).
Je suis d'accord, et fondamentalement, je pense qu'en effet, il faut revoir le logiciel de fond en comble. Pas dans le sens ou tout est à jeter, loin de la, très loin de la, mais dans le sens ou la sécurité doit être intégré dans le design depuis le début.
Car au final, le choix de prendre un logiciel destiné à une forge personnelle/privé pour un service ouvert au public est le péché originel.
Je vais donner 2 exemples sur d'autres logiciels et choix pour illustrer.
Le premier, c'est le fait d'utiliser Slack pour une communauté ouverte au public. En dehors de la question du proprio, c'est un mauvais choix parce que Slack ne permet pas d'ignorer quelqu'un/quelque chose, car on part du principe que dans une entreprise (l'audience visée par Slack), ça se règle via les RH. C'est un design qui a du sens dans son contexte et qui permet d'éviter de surcharger les menus, mais qui pose souci dans un autre (à savoir une commu ouverte à tout le monde avec des gens relous ou qui parlent trop).
Second exemple, les tickets de CoC de Fedora. Fedora utilise sa forge (avant Pagure, maintenant Forgejo) pour ça, et il y a eu plusieurs fois des leaks d'infos à cause de la fonction de notification inline. En l'occurrence, si tu colles un log avec @toto, toto est mis en copie et reçoit un mail, c'est facheux quand tu colles un log irc pour te plaindre de ce que toto a dit si ton log est "@toto> casse toi de la, pov' con". Il y a 5 ans, j'ai découvert le bug en tombant dedans, j'ai corrigé. C'était le 2nd correctif, cf le message de pingou. Il y a 2 semaines, le souci est revenu sur la nouvelle forge. Le fait que ça revienne me fait dire que le souci est dans le design, car on utilise un système de ticket qui n'est pas pensé pour ça à la base.
Soit on veux faciliter la collaboration donc il ne faut pas mettre de friction sur les notifications (le cas actuelle des forges de Fedora), soit on veux avoir plus de controle sur l'information, et ça implique de la friction sur le partage (par exemple, chaque notification demande une confirmation explicite).
Comme pour Slack, tu ne peux pas optimiser un design dans 2 directions.
Et donc pour moi, l'usage d'un logiciel de forge privé/perso afin d’héberger un service pour le grand public, c'est pareil.
L'attaque de spam de 2025, c'était fondamentalement un manquement dans le design initial qui n'a rien prévu pour éviter ça, car l'idée (je suppose) est qu'un probléme de ce genre peut se régler hors du logiciel quand on est dans le cadre d'une forge fermé. Si sur ma forge, je n'ouvre un compte que pour quelqu'un que je connais et ce quelqu'un insulte quelqu'un d'autre, je peut intervenir en dehors, je connais les gens. Si c'est des inconnus qui s'ouvrent eux même leur compte, je peux pas faire grand chose, et peut être qu'il faut permettre de mieux filtrer et traiter la forge comme un réseau social avec tout ce que ça implique, que ça soit en terme de quantité d'interactions, d'affordances à proposer (blocage, reporting, mais aussi rate limitation, quotas, etc). La question du nombre de comptes se pose aussi. Une forge pour un petit/moyen groupe n'est pas une forge pour 1 million de personnes.
Un autre exemple de l'inadéquation d'une forge privée pour un service publique, c'est la gestion des nouveaux comptes. Pour une forge privée, pas de souci, tu crées les comptes, tu ne va pas avoir une tonne de gens à filtre/modérerr. Pas pour une forge publique, et de ce que j'ai compris, c'est chiant à faire (en tout cas, c'était chiant par le passé). Un logiciel pensé pour être un service publique aurait sans doute un module de gestion du spam (ce qui implique un choix autre que go pour la modularité, par exemple), etc, etc.
Ensuite, je pointe ça, mais je comprends bien que c'est un tradeoff. On ne vit pas dans un monde idéal ou refaire de 0 une forge était une option viable, et je pense que le choix de partir sur Gitea à la création de Codeberg était un choix pragmatique, j'aurais sans doute fait pareil.
Disons que pour un projet commencé en 2020 via le projet fedeproxy, on peut dire que c'est un peu lent (et on va pas remonter plus loin, parce que le premier commit sur forgefed, c'était en 2017.
Mais je continue aussi de penser que la fédération est un rêve imprécis (pour avoir été dans les premiers meetings autour de fedeproxy à Paris), et j'ai le sentiment que tout le monde n'est pas d'accord sur ce que ça couvre.
Car tu peux vouloir une forge "distribué" sans SPOF (par exemple, Forgeflux, un design basé sur Matrix qui avait été discuté par le passé) et dire que c'est fédéré. Tu peux avoir un projet sur une forge centrale avec des interactions par des comptes distants, avec donc une authentification fédérée, et dire que c'est fédéré (mais quid du spam, vu que ça a tué openid). Tu peux avoir la possibilité d'avoir des forks distants avec des discussions distantes sur chaque serveur donc des PR/bugs en fédération, et donc un fil de discussion sur 2 serveurs, (quid de la numérotation, etc), etc. C'est des designs différents, mais qu'on peut tous qualifier de fédéré.
Il y a vaguement ce coté égalitaire dans l'idée de la fédération, mais c'est très mal défini, et c'est une des 2 choses qui rend le progrès difficile selon moi. L'autre, c'est que le design initial de la forge n'a pas été prévu pour ça donc c'est dur de changer ça sans casser des choses existantes. Tangled est une forge faite de 0 qui intègre dans la conception la décentralisation](https://docs.tangled.org/). Radicle utilise du p2p pour ça, et intègre ça dans le conception. Les 2 sont des créations récentes (Tangled 2025, Radicle 2023), soit bien après les premières discussions formel de fédération. Les 2 sont fonctionnels et intègre la fédération plus vite car il n'y a pas d'existant à garder.
Oui, alors ça, c'est la raison publique.
En pratique, le fork a démarré comme un "soft fork" pour ajouter la fédération, puis Loic s'est disputé avec les gens de Gitea début 2022 (parmi tant d'autres, il y a aussi eu une dispute avec l'April qui a coïncidé avec la dissolution de la FSF France en 2022, officiellement pour manque d'activité), cf ce que j'ai expliqué par le passé. Les disputes, c'était sur des questions business (à savoir le fait de vouloir financer le travail sur la fédération via un service appelé hostea, mais gitea a fondé sa propre boite en même temps sans l'impliquer en 2022, il a vraiment pas aimé qu'on lui dise "non" puis de faire pareil), mais aussi des questions de caractère (fight avec le designer sans raison autre que mauvaise gestion de ses émotions de ce que je vois).
Et je sais pas si les gens de Gitea ont capté que Loïc avait 2/3 comptes pour voter, mais je pense que je doit pas être le seul qui a constaté que silentcodeg sur github était un faux nez de Loic (qui avait donc 2 votes au TC).
Et c'est un pattern qui se répète vu que earl-warren est Loïc D, cf le leak du whois par Gandi qui était mal anonymisé et qui montre qui a enregistré le domaine en 2022.
# Les ressources
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+17/-2).
Je rajoute un point qui m'a semblé important dans l'annonce de Codeberg mais qui n'apparaît pas dans ton résumé:
Héberger des projets sur Codeberg demande des ressources matérielles: disques durs, processeurs pour la CI, etc. D'une part, l'ambiance générale fait que ce matériel coûte actuellement assez cher. D'autre part, les projets vibe codés ont tendance à être de gros consommateurs de ces ressources, avec une chaîne de CI/CD très complète, la génération de binaires pour tout un tas de plateformes, et, bien sûr, un gros volume de commits.
C'est donc une mauvaise utilisation de ressources communes, qui seraient mieux affectées à d'autres projets qui ont, eux, une vraie communauté de développeurs et d'utilisateurs.
C'est donc un impact encore plus direct que les problèmes de scrapping intensif par des robots d'entraînement d'IA, qui sont également mentionnés.
Du coup, un petit peu quand même?
[^] # Re: Les ressources
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 3 (+2/-0).
Ça me paraît plutôt être positif ça, non ? Je veux dire que je ne qualifierais pas ça de "mauvaise utilisation de ressources communes".
[^] # Re: Les ressources
Posté par wilk (site web personnel, Mastodon) . Évalué à 10 (+11/-0).
Il manque la phrase suivante pour comprendre :
[^] # Re: Les ressources
Posté par Sébastien B. . Évalué à 4 (+2/-0).
C'est bien de supporter plein de plateformes, mais il ne suffit pas que ça compile, si personne n'a jamais testé, ça sert à rien de faire perdre leur temps aux gens en leur faisant croire que ça marchera.
# Et ce n'est pas tout !
Posté par Pierre-Yves Lapersonne (site web personnel, Mastodon) . Évalué à 10 (+14/-0).
D'ailleurs, Codeberg a également modifié ces conditions générales d'utilisation pour exclure les projets relatifs aux cryptomonnaies (cf diff Git).
Software crafter, digital punker
# Question pratique:
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
Je comprends que Codeberg ne le fera pas mais quid des "autres" bien moins intentionnés ?
"Si tous les cons volaient, il ferait nuit" F. Dard
# scrapping
Posté par hippocampe . Évalué à 1 (+1/-0).
En effet, mettre des données au rebut (scrapping) est problématique.
D’autres s’intéressent à la collecte automatisée de données (scraping), autre sujet tout aussi vaste.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.