- Un petit patch conçu pour améliorer les performances d’Emacs sur macOS a été soumis à
emacs-devel, mais n’a pas été accepté en raison de la politique de GNU contre les contributions assistées par LLM - L’auteur a indiqué que GLM 5.2 avait trouvé le problème et rédigé une première version, tout en précisant qu’il avait lui-même pris en charge la vérification de l’exactitude, l’analyse d’impact, les corrections, les tests manuels et la responsabilité personnelle
- Le patch rejeté avait une portée limitée, avec 92 lignes seulement, et comme il aurait pu dissimuler l’usage d’un LLM, il critique une politique qui pénalise davantage la divulgation honnête que l’usage lui-même
- Les réserves côté GNU portaient davantage sur l’ouverture des sorties de LLM et leur utilisabilité juridique, mais il dit ne pas être d’accord, en s’appuyant sur les modèles à poids ouverts et les cas d’usage réels dans l’industrie
- Il affirme qu’il ne travaillera plus sur Emacs et n’a publié qu’une partie des quelque 40 patchs d’amélioration des performances présents sur son disque dur, uniquement ceux qu’il a récemment revérifiés
Travail d’amélioration des performances d’Emacs sur macOS
- Przemysław Alexander Kamiński a passé plusieurs mois à améliorer les performances d’Emacs sur macOS, en consacrant du temps au raccordement des outils d’instrumentation et à l’écriture de benchmarks
- Il a fourni la base de code d’Emacs à plusieurs LLM pour leur faire chercher des problèmes précis, mais les résultats ont été globalement peu convaincants
- En analysant les patchs, il constatait souvent soit un impact faible, soit une mauvaise compréhension du problème
- Son diagnostic des goulets d’étranglement de performance à ce moment-là était le suivant
- Sur macOS, les principaux problèmes venaient de problèmes de rendu et du thrashing mémoire causé par des allocations/libérations rapides
- La manière dont le
mallocsystème de macOS fonctionne provoque, faute de compression mémoire, un gonflement de la mémoire virtuelle et une perte de localité de cache - Le cœur d’Emacs présente encore aussi des problèmes de performance
- Le traitement des regexp étant utilisé à plusieurs endroits, l’améliorer peut avoir un effet sur les performances globales
Le patch trouvé avec GLM 5.2 et le processus de soumission
- Grâce à un ami qui lui a offert un abonnement z.ai Max, il a pu utiliser GLM 5.2, un modèle qu’il juge assez compétent pour l’optimisation de code
- En s’appuyant sur les connaissances qu’il avait déjà accumulées, il a posé des questions précises sur Emacs et confié à GLM 5.2 l’exploration et l’analyse des problèmes
- Environ 3 heures plus tard, il a reçu plusieurs rapports, puis a examiné les propositions et le code, testé l’impact de chaque point et exécuté des benchmarks
- Comme la mise en forme pour une soumission de patch prend du temps, il a choisi l’élément le plus prometteur et l’a envoyé sur la mailing list
emacs-develdeux jours avant la rédaction de son billet - Le lendemain, il a appris que GNU avait une politique refusant les contributions assistées par LLM, et que son patch ne serait donc pas accepté
Étendue de l’usage du LLM divulguée dans le mail de soumission
- Lors de l’envoi du patch sur la mailing list, il a explicitement précisé l’usage du LLM et l’étendue de sa propre relecture
- La détection du problème et la première ébauche du patch ont été réalisées par GLM 5.2, qu’il présente comme un modèle chinois à poids ouverts
- Il a lui-même analysé l’exactitude du rapport de problème et son impact
- Il a relu et corrigé le patch
- Il a testé le patch manuellement
- À des fins juridiques, il a déclaré être l’auteur de la soumission et s’est dit prêt à soutenir que sa contribution dépassait celle du LLM
- Il a déclaré assumer l’entière responsabilité personnelle de la soumission
- La soumission avait une portée d’implémentation très étroite et une taille réduite
- Le patch publié fait 92 lignes et inclut, dans les commentaires, la raison de son existence
- Il estime que ce patch ne peut pas être classé comme du « slop », tout en laissant chacun en juger
Réponse aux politiques de GNU
- Il dit respecter la politique de GNU, mais ne pas être d’accord avec elle et ne pas la juger suffisamment fondée
- Il aurait pu dissimuler l’usage du LLM, mais a choisi de le révéler explicitement, et estime qu’au final cela a desservi sa soumission
- Il critique donc une politique qui sanctionne davantage la divulgation honnête que l’usage du LLM en lui-même
- Comme il ne fait absolument pas confiance aux LLM, il considère que le travail assisté par LLM demande non pas moins de relecture, mais plus de relecture et plus d’attention
- Le contexte complet de la politique lui échappe, car les discussions ont lieu sur des listes internes à GNU, et d’après les échanges passés, les interrogations portaient surtout sur le caractère suffisamment ouvert des contributions de LLM et sur leur utilisabilité légale
- Il n’est pas d’accord avec l’argument qui met en cause l’ouverture des modèles à poids ouverts
- Par exemple, il juge absurde de considérer qu’utiliser Qwen 3.6 en local serait acceptable, mais pas via OpenRouter
- GLM 5.2 est un modèle à poids ouverts et, avec 256 Go de RAM et 24 Go de VRAM, il dit qu’on peut l’exécuter localement pour éviter l’argument selon lequel « le SaaS est fermé »
- Internet contient déjà beaucoup de contenus non libres, et il demande donc si, en suivant la même logique, il faudrait aussi interdire l’accès à Internet lors de la préparation d’une soumission
- Il n’adhère pas non plus aux inquiétudes juridiques
- Il affirme que les sociétés de jeux sont encore plus sensibles aux questions d’IP et de LLM, mais que l’usage des LLM y est visible ; que ChatGPT compte 1 milliard d’utilisateurs actifs ; et que des centaines de milliers à des millions d’organisations utilisent chaque jour des sorties de LLM
- Tout en précisant qu’il n’est pas avocat aux États-Unis, il dit comprendre que les problèmes d’enregistrement du copyright concernent surtout la partie qui appose l’avis de copyright
- Il ne partage pas l’idée selon laquelle GNU devrait accorder le plus grand poids à ses propres avocats et à leur avis
Arrêt des travaux sur Emacs et patchs publiés
- Il dit que GNU est libre de prendre ses décisions et qu’il est libre de les critiquer
- Il critique le fait de débattre de la politique en interne, d’une manière peu transparente pour les utilisateurs, en disant que ce n’est guère plus ouvert que Meta décidant en interne de l’orientation de Facebook
- En conséquence, il affirme qu’il ne travaillera plus sur Emacs
- Il explique qu’il n’aime pas qu’on lui dise, dans le cadre d’un travail bénévole, qu’il « tient la barre du mauvais côté »
- Il dit avoir sur son disque dur environ 40 patchs d’amélioration des performances, certains se recoupant et d’autres n’ayant pas encore démontré un impact réel
- Il n’a publié que les patchs qu’il a récemment revérifiés et qui ont montré un impact significatif, ici, et affirme qu’ils font réellement une différence
1 commentaires
Avis sur Lobste.rs
L’auteur semble avoir mal compris ce que signifie open dans « open weight »
Le fait que les poids finaux du modèle soient publiés et puissent être affinés dans une certaine mesure ne veut pas dire que les données d’entraînement utilisées pour les produire étaient elles aussi open source. OSI seems to agree semble aller dans le même sens, et dans ce cas cela ne résout en rien les problèmes de droit d’auteur
J’ai de la sympathie pour quelqu’un qui veut contribuer de bonne foi, bénévolement, mais GNU a énoncé ses règles clairement, et si quelqu’un s’y présente en disant « j’ai juste un peu enfreint les règles, voici mon patch », il n’y a rien d’étonnant à ce qu’il soit refusé. La raison du refus n’est pas l’honnêteté, mais le fait d’avoir fait explicitement ce qu’il était demandé de ne pas faire
J’aimerais que l’auteur apprenne aujourd’hui que des milliards de personnes peuvent avoir tort. Normalization of deviance ne justifie pas l’écart à la règle, cela décrit simplement la manière dont cet écart continue de se propager
L’un des schémas observés dans la chatbot psychosis est la tendance à percevoir comme des ennemis les humains qui s’opposent ou expriment un avis différent. Les narremes appris par les chatbots incluent l’idée que l’utilisateur est le protagoniste, avec une caméra à l’épaule et un récit personnel facile à lire. Le récit préférentiel post-traité du chatbot agit directement en renforçant chez l’utilisateur le sentiment d’être le héros, et si l’utilisateur est suffisamment ionisé, il finit par ne plus pouvoir accepter même une position neutre
Dans ce cas, je recommande de lire the original discussion, que l’auteur ne lie ni ne cite. La communauté Emacs s’est montrée aimable, ouverte, curieuse, attentive et accueillante envers l’auteur. Même au moment de refuser le patch, elle s’est exprimée avec douceur en se concentrant sur la politique de GNU plutôt qu’en blâmant l’auteur
[incomprehensible]Cela dit, je vois ce que ça veut dire dans le contexte, et cela semble être ici un concept utile et bien adapté
Le projet GNU doit prendre en compte non seulement les problèmes de droit d’auteur aux États-Unis, mais aussi les préoccupations mondiales en matière de droit d’auteur. Même le droit américain n’est pas encore totalement stabilisé
GNU veut pouvoir être certain de détenir à 100 % le droit d’auteur sur les contributions importantes. Ici, l’interprétation juridique de l’auteur n’a aucune importance : le projet GNU joue la sécurité. Et cela sans même encore prendre en compte d’autres inquiétudes qu’il peut probablement avoir vis-à-vis des LLM
En outre, si un dépôt contient du code généré par un LLM et que ce code n’est pas clairement distingué et signalé, l’ensemble du dépôt peut être considéré comme ne pouvant ni être protégé par le droit d’auteur ni faire l’objet d’une licence
Autrement dit, si l’auteur avait menti pour faire accepter le commit, il aurait pu mettre en péril l’effet de la licence sur l’ensemble de la base de code d’Emacs
Tout cela est indépendant de cette attitude arrogante, presque délirante, consistant à dire en substance « IANAL mais les avocats ont manifestement tort ». Il regarde quelques extraits de texte juridique tout en traitant les avocats d’arrogants
[1] C’était à jour au moment où j’ai eu cette conversation avec le service juridique de mon entreprise il y a environ deux mois
Je ne suis pas sûr que « ça aurait été accepté s’il avait menti » soit un argument très pertinent
Ce n’est pas vraiment flatteur pour ces personnes, non ?
Je ne vois pas en quoi il serait utile d’ennuyer les mainteneurs à cause de politiques pour ou contre les LLM. Ils font leur travail et ont le droit de choisir quelles contributions ils vont évaluer, accepter ou rejeter
Bien sûr, se plaindre est acceptable. Cette personne expose sa position sur son blog, et c’est ainsi que la discussion s’aligne. En revanche, je ne suis pas d’accord avec la manière de cadrer le sujet. Ici, le problème n’est pas « l’honnêteté ». Si une politique no-LLM avait été annoncée, alors la responsabilité d’avoir perdu du temps à tenter de contribuer avec un LLM à un projet qui ne voulait pas de ce type de contribution lui incombe
Ce n’est pas différent du fait de servir à un vegan un plat contenant de la viande ou du fromage, puis de se plaindre qu’il ne le mange pas parce qu’on a « honnêtement » donné les ingrédients. « Si je ne l’avais pas dit, il n’aurait pas su qu’il y avait des produits laitiers » ne donne pas une bonne image, et « si je ne l’avais pas dit, il n’aurait pas su que j’avais utilisé un LLM » non plus
GNU et la FSF investissent énormément dans des conseils juridiques professionnels. Or ce contributeur potentiel suggère en gros d’ignorer ces conseils professionnels sur la base de ce que dit quelqu’un sur Internet
Si on a payé pour un avis professionnel, il est rationnel de le suivre, et si on n’est pas d’accord, il faut chercher un autre expert. L’ignorer à cause des conseils d’un commentateur lambda sur Internet, ce n’est pas « presque satirique », c’est juste stupide
Indépendamment de ce refus, je pense qu’on verra à l’avenir des cas judiciaires assez intéressants. Les fournisseurs de grands modèles pourraient proposer une certaine forme d’indemnisation et dire « c’est du code que nous avons aidé à produire, donc vous pouvez revendiquer le copyright comme vous voulez », ou au contraire pousser le sujet et affirmer qu’ils en sont propriétaires et qu’une licence est nécessaire pour certains usages. Claude livre aujourd’hui le code à l’utilisateur, mais je ne sais pas quelle garantie ou indemnisation il fournit. Je ne sais pas non plus vraiment pour les autres modèles
Tu savais que ce n’est illégal que si on se fait attraper
Je ne suis pas du tout un fan absolu de GNU, mais les outils de codage LLM, ce n’est pas l’exact opposé de la philosophie GNU ? Ça fait penser à quelqu’un qui amène un chien dans un café à chats puis se met en colère parce qu’on le met dehors
Je trouve très malhonnête d’avoir changé le titre de Honesty gets Emacs patch rejected en Vibecoding gets Emacs patch rejected
Même si, comme l’auteur, on s’est aidé d’outils d’IA, si on a investi autant de temps et de compréhension dans le code, ce n’est clairement pas du vibecoding. Si on avait juste dit à l’IA « rends Emacs plus rapide » puis soumis le résultat les yeux fermés, là ce serait du vibecoding, mais à lire le billet, ce n’est manifestement pas ce qui s’est passé
Moi, j’aurais plutôt mis quelque chose comme Breaking contribution policy gets Emacs patch rejected. C’est toujours un peu sarcastique, mais plus difficile à contester
Ce qui frappe ici, c’est que l’auteur affirme avoir travaillé régulièrement pendant deux mois, tout en expliquant que le modèle qu’il dit avoir utilisé pour trouver et corriger le problème a été lancé il y a 12 jours
Je comprends que l’auteur soit assez en colère, mais au fond, l’open source n’accorde pas vraiment des droits ; c’est plutôt le privilège de pouvoir utiliser du code déjà écrit. S’il y a un avantage, c’est peut-être que ce qu’il a écrit sur macOS est globalement juste, donc les développeurs d’Emacs prendront peut-être le temps d’y jeter un œil. Cela dit, macOS n’est probablement pas leur priorité principale
Il existe une solution simple qui montre à quel point cette politique est absurde : afficher le diff de PR assisté par LLM sur un deuxième écran, puis retaper manuellement les modifications depuis le début sur l’écran principal. Il suffit aussi de changer un peu les noms de variables et le contenu des commentaires
Le code devient alors du code écrit par un humain, donc il peut être fusionné