Emacs-Patch wegen offengelegtem Vibecoding abgelehnt

• Ein kleiner Patch zur Performance-Verbesserung von Emacs für macOS wurde bei emacs-devel eingereicht, aber wegen der GNU-Richtlinie, keine LLM-unterstützten Arbeiten anzunehmen, nicht akzeptiert
• Der Beitragende legte offen, dass GLM 5.2 das Problem gefunden und einen Entwurf erstellt hatte, erklärte aber zugleich, dass er selbst die Analyse von Korrektheit und Auswirkungen, Änderungen, manuelle Tests und die persönliche Verantwortung übernommen habe
• Der abgelehnte Patch hatte einen engen Umfang und war nur 92 Zeilen lang; da man die LLM-Nutzung auch hätte verschweigen können, kritisierte er, dass die Richtlinie ehrliche Offenlegung gegenüber der Nutzung benachteilige
• Die Bedenken auf GNU-Seite gingen eher in Richtung Offenheit und rechtliche Verwendbarkeit von LLM-Ausgaben; er widersprach dem jedoch unter Verweis auf Open-Weight-Modelle und reale Einsatzfälle in der Industrie
• Er erklärte, nicht weiter an Emacs zu arbeiten, und veröffentlichte nur einige kürzlich geprüfte Patches von rund 40 Performance-Verbesserungen, die auf seiner Festplatte lagen

---

Arbeit an Performance-Verbesserungen für Emacs unter macOS

• Przemysław Alexander Kamiński arbeitete mehrere Monate daran, die Performance von Emacs unter macOS zu verbessern, und investierte Zeit in Instrumentierungs-Anbindungen und Benchmarks
• Er gab mehreren LLMs die Emacs-Codebasis und ließ sie nach bestimmten Problemen suchen, doch die Ergebnisse waren meist nicht gut
  • Bei der Analyse der Patches zeigte sich oft, dass ihre Auswirkungen gering waren oder dass das Problem falsch verstanden wurde
• Seine damalige Einschätzung zu Performance-Engpässen war wie folgt
  • Unter macOS sind die Hauptprobleme Rendering-Issues sowie Memory Thrashing durch schnelles Allokieren und Freigeben
  • Die System-malloc-Strategie von macOS führt wegen fehlender Speicherkompression zu aufgeblähtem virtuellem Speicher und Verlust von Cache-Lokalität
  • Auch im Emacs-Core bestehen weiterhin Performance-Probleme
  • Die Verarbeitung von regulären Ausdrücken wird an vielen Stellen genutzt, sodass Verbesserungen die Gesamtperformance beeinflussen können

Mit GLM 5.2 gefundener Patch und Einreichungsprozess

• Über einen Freund erhielt er Zugang zum z.ai-Max-Plan und konnte GLM 5.2 nutzen; er schätzte das Modell als recht kompetent bei Code-Optimierung ein
• Auf Basis seines bereits aufgebauten Wissens stellte er konkrete Fragen zu Emacs und ließ GLM 5.2 nach Issues suchen und Analysen erstellen
• Nach etwa 3 Stunden erhielt er mehrere Berichte, prüfte die Vorschläge und den Code, testete die Auswirkungen der einzelnen Punkte und führte Benchmarks aus
• Da die Aufbereitung für eine Patch-Einreichung Zeit kostet, wählte er den vielversprechendsten Punkt aus, arbeitete daran und schickte ihn zwei Tage vor dem Schreiben des Artikels an die Mailingliste emacs-devel
• Am nächsten Tag erfuhr er, dass GNU eine Richtlinie hat, nach der LLM-unterstützte Arbeiten nicht angenommen werden, und dass der Patch deshalb nicht akzeptiert werde

In der Einreichungsmail offengelegter Umfang der LLM-Nutzung

• Beim Senden des Patches an die Mailingliste nannte er sowohl die LLM-Nutzung als auch den Umfang seiner eigenen Prüfung
  • Die Entdeckung des Issues und der Patch-Entwurf stammten von GLM 5.2; er wies darauf hin, dass GLM 5.2 ein chinesisches Open-Weight-Modell ist
  • Er analysierte selbst die Korrektheit und Auswirkungen des Issue-Berichts
  • Er prüfte und überarbeitete den Patch
  • Er testete den Patch manuell
  • Für rechtliche Zwecke erklärte er die Urheberschaft der Einreichung und gab an, bereit zu sein zu begründen, dass sein eigener Beitrag größer sei als der des LLM
  • Er erklärte, die volle persönliche Verantwortung für die Einreichung zu übernehmen
• Die Einreichung war in der Umsetzung sehr eng begrenzt und auch klein im Umfang
  • Der veröffentlichte Patch umfasst 92 Zeilen und enthält in den Kommentaren den Grund für seine Existenz
• Er ist der Ansicht, dass man diesen Patch nicht als „slop“ einordnen könne, fügte aber hinzu, dass das jeder selbst beurteilen könne

Widerspruch gegen die GNU-Richtlinie

• Er respektiert die GNU-Richtlinie, stimmt ihr aber nicht zu und hält sie für nicht ausreichend begründet
• Er hätte die LLM-Nutzung verschweigen können, legte sie aber ausdrücklich offen und sieht darin den Grund, dass seine Einreichung benachteiligt wurde
  • Daher kritisiert er, dass diese Richtlinie nicht die LLM-Nutzung selbst, sondern ehrliche Offenlegung bestrafe
  • Da er LLMs überhaupt nicht vertraue, brauche LLM-unterstützte Arbeit aus seiner Sicht nicht weniger, sondern mehr Prüfung und mehr Augen
• Der vollständige Kontext der Richtlinie sei nicht bekannt, da er auf internen GNU-Listen diskutiert werde; aus früheren Gesprächen habe er als Bedenken vor allem mitgenommen, ob LLM-Beiträge ausreichend offen und rechtlich verwendbar seien
• Der Argumentation, die Offenheit von Open-Weight-Modellen infrage zu stellen, stimmt er nicht zu
  • Eine Unterscheidung nach dem Muster, dass Qwen 3.6 in einer lokalen Umgebung in Ordnung sei, über OpenRouter aber nicht, hält er für absurd
  • GLM 5.2 sei ein Open-Weight-Modell; mit 256 GB RAM und 24 GB VRAM könne man es lokal ausführen und damit dem Argument ausweichen, dass „SaaS geschlossen“ sei
  • Da es im Internet viele unfreie Inhalte gebe, fragt er zurück, ob man nach derselben Logik beim Erstellen von Einreichungen auch den Internetzugang verbieten müsse
• Auch den rechtlichen Bedenken stimmt er nicht zu
  • Er sagt, Spielefirmen seien bei IP und LLMs noch sensibler, dennoch sei dort LLM-Nutzung zu beobachten; ChatGPT habe eine Milliarde aktive Nutzer, und Hunderttausende bis Millionen Organisationen nutzten täglich LLM-Ausgaben
  • Unter dem Vorbehalt, dass er kein US-Anwalt sei, verstehe er das Problem der Copyright-Registrierung so, dass es bei der Seite liege, die Copyright-Hinweise anbringt
  • Er stimmt der Haltung nicht zu, dass GNU den eigenen Anwälten und der eigenen Meinung das größte Gewicht beimisst

Ende der Emacs-Arbeit und veröffentlichte Patches

• Er sagt, GNU habe die Freiheit, selbst zu entscheiden, und er habe die Freiheit zu kritisieren
• Er kritisiert, dass eine intern diskutierte Richtlinie, die für Nutzer nicht transparent ist, nur ungefähr so offen sei wie interne Entscheidungen von Meta über die Richtung von Facebook
• In der Folge erklärte er, nicht weiter an Emacs zu arbeiten
  • Er sagt, er möge es nicht, bei freiwilliger Arbeit zu hören, dass er „das falsche Ende des Stocks halte“
• Auf seiner Festplatte liegen etwa 40 Patches zur Performance-Verbesserung; einige überschneiden sich, und bei einigen ist die tatsächliche Wirkung noch nicht belegt
• Nur einige kürzlich geprüfte Patches, die funktionieren und eine sinnvolle Wirkung zeigten, hat er veröffentlicht; er sagt, diese Patches machten tatsächlich einen Unterschied

[GN⁺]

Lobste.rs-Meinungen

• Es sieht so aus, als habe der Autor missverstanden, was das open in "open weight" bedeutet
  Nur weil der finale Gewichtsblock veröffentlicht ist und sich bis zu einem gewissen Grad feinabstimmen lässt, heißt das nicht, dass auch die Trainingsdaten, mit denen er erstellt wurde, Open Source waren. OSI seems to agree scheint das ähnlich zu sehen, und wenn das so ist, ist das Urheberrechtsproblem überhaupt nicht gelöst
  Ich kann nachvollziehen, dass jemand in guter Absicht und ohne Gegenleistung beitragen will, aber GNU hat die Regeln klar aufgeschrieben, und wenn man dann dorthin geht und sagt: "Ich habe sie nur ein bisschen gebrochen, hier ist trotzdem ein Patch", dann ist eine Ablehnung nicht überraschend. Der Grund für die Ablehnung ist nicht Ehrlichkeit, sondern dass ausdrücklich etwas getan wurde, was man nicht tun soll

  • Sind dann auch Treiber, die auf Datenblättern unter Geheimhaltungsvereinbarung basieren, allesamt keine freie Software? Und wie ist ein Fall zu bewerten, in dem ein Mitarbeiter des Herstellers unter Nutzung interner Dokumente und Fachwissens einen Treiber schreibt?
  • Ich verstehe nicht ganz, warum die Trainingsdaten relevant sein sollen. Wenn sich das Ergebnis frei nutzen, weiterverbreiten und verändern lässt, ist es meiner Ansicht nach ziemlich nah an open

• Ich hoffe, der Autor lernt heute, dass auch Milliarden Menschen falschliegen können. Normalization of deviance rechtfertigt Abweichung nicht, sondern beschreibt nur, wie sich diese Abweichung weiter verbreitet
  Eines der Muster, die man bei chatbot psychosis sieht, ist, dass Menschen, die widersprechen oder eine andere Meinung äußern, als Feinde wahrgenommen werden. Zu den narremes, die der Chatbot gelernt hat, gehört die Perspektive, dass der Nutzer der Protagonist ist, mit einer Kamera über der Schulter und einer leicht lesbaren persönlichen Erzählung. Die nachbearbeiteten bevorzugten Erzählmuster des Chatbots wirken direkt auf den Nutzer ein, indem sie dessen Gefühl, der Hauptcharakter zu sein, verstärken, und wenn der Nutzer erst einmal stark genug ionisiert ist, kann er nicht einmal mehr eine neutrale Position akzeptieren
  In diesem Fall würde ich dem Autor empfehlen, the original discussion, die er weder verlinkt noch zitiert, zu lesen. Die Emacs-Community war dem Autor gegenüber freundlich, aufgeschlossen, stellte Fragen, zeigte Interesse und verhielt sich akzeptierend. Selbst bei der Ablehnung des Patches formulierte sie es sanft und konzentrierte sich eher auf die GNU-Richtlinien als auf Vorwürfe gegen den Autor

  • Dass der Link zur eigentlichen Diskussion nicht im Beitrag enthalten ist, ist ehrlich gesagt ein großes Warnsignal. Kaum zu glauben, dass mir das nicht sofort aufgefallen ist
  • Der Wikipedia-Artikel zu narremes besteht nur aus einem Absatz und ist mit dem Tag [incomprehensible] versehen
    Trotzdem ist aus dem Kontext klar, was gemeint ist, und es wirkt hier wie ein nützliches und treffendes Konzept

• Das GNU Project muss nicht nur US-amerikanische Urheberrechtsfragen berücksichtigen, sondern weltweite urheberrechtliche Bedenken. Selbst das US-Recht ist noch nicht abschließend geklärt
  GNU möchte sicher sein, dass es an wichtigen Beiträgen die Urheberrechte zu 100 % hält. Die Rechtsauslegung des Autors ist hier nicht entscheidend; das GNU Project geht auf Nummer sicher. Andere Bedenken, die es vermutlich gegenüber LLMs hat, sind dabei noch gar nicht berücksichtigt

  • Ehrlich gesagt ist nach der aktuellen Rechtsprechung auch das US-Rechtsverständnis des Autors falsch[1]. Nach bestehender Rechtsprechung ist von LLMs generierter Code nicht urheberrechtlich schützbar, kann daher auch nicht lizenziert werden und fällt automatisch in die Public Domain
    Wenn sich darüber hinaus LLM-generierter Code in einem Repository befindet und dieser Code nicht klar abgegrenzt und gekennzeichnet ist, kann das gesamte Repository als weder urheberrechtlich schützbar noch lizenzierbar angesehen werden
    Anders gesagt: Hätte der Autor gelogen und wäre der Code dadurch committet worden, hätte das die Wirksamkeit der Lizenz der gesamten Emacs-Codebasis gefährden können
    All das ist noch getrennt von der fast wahnhaften Arroganz des Mottos "Ich bin zwar kein Anwalt, aber die Anwälte liegen offensichtlich falsch". Es werden einzelne einschlägige Rechtsvorschriften gelesen und gleichzeitig die Anwälte der Arroganz bezichtigt
    [1] Stand meines letzten solchen Gesprächs mit unserer Rechtsabteilung vor etwa zwei Monaten

• Ich bin nicht sicher, ob "Wenn er gelogen hätte, wäre es angenommen worden" ein tragfähiges Argument ist

  • Dieselbe Logik lässt sich auch auf Lizenzen anwenden. Wenn man etwas aus einer proprietären Codebasis kopiert und dann lügt, man habe es selbst geschrieben, könnte ein Patch angenommen werden. Wenn man die Wahrheit sagt, wird er abgelehnt. Ist die Schlussfolgerung dann also, dass Lizenzen schlecht sind?
  • Ja. Dasselbe Argument "Dann werden die Leute eben einfach lügen" hört man oft zur no-LLM-Politik
    Das sagt doch nichts Gutes über diese Leute aus, oder?
    Ich finde nicht, dass man Maintainer wegen einer Politik für oder gegen LLMs schikanieren sollte. Sie machen ihre Arbeit und haben das Recht zu entscheiden, welche Beiträge sie bewerten, annehmen oder ablehnen
    Natürlich darf man sich beschweren. Diese Person legt ihre Position ja in einem Blogbeitrag dar, und so wird die Diskussion ausgetragen. Mit dem Framing bin ich aber nicht einverstanden. Das Problem hier ist nicht "Ehrlichkeit". Wenn eine no-LLM-Politik angekündigt war, dann liegt die Verantwortung für die verschwendete Zeit, mit LLMs zu einem Projekt beitragen zu wollen, das solche Beiträge nicht will, bei der betreffenden Person selbst
    Das ist nicht anders, als einem Veganer ein Gericht mit Fleisch oder Käse zu geben und sich dann zu beschweren, dass er es nicht isst, obwohl man die Zutaten "ehrlich" genannt hat. "Wenn ich nichts gesagt hätte, hättest du nicht gewusst, dass Milchprodukte drin sind" sieht nicht gut aus, und "Wenn ich nichts gesagt hätte, hättest du nicht gewusst, dass ich ein LLM benutzt habe" genauso wenig
  • Stimme zu. Ich habe den neuen Titel Vibecoding gets Emacs patch rejected vorgeschlagen. Die Ehrlichkeit, Vibecoding zuzugeben, ist ähnlich wie die Ehrlichkeit, eine Urheberrechtsverletzung zuzugeben. Der eigentliche Grund für die Ablehnung ist nicht Ehrlichkeit
  • Ich finde, ein LLM zu nutzen und das ehrlich offenzulegen, ist ein Grund, einen Patch abzulehnen. Ein LLM zu nutzen und darüber zu lügen, ist zusätzlich zur Ablehnung des Patches ein Grund, auch künftige Beitragsversuche zu untersagen

• GNU und die FSF investieren ziemlich viel in professionelle Rechtsberatung. Dieser potenzielle Beitragende empfiehlt ihnen nun im Grunde, diese professionelle Beratung zu ignorieren, weil irgendeine Person im Internet das so sagt.
  Wenn man für fachkundige Beratung bezahlt hat, ist es vernünftig, ihr zu folgen, und wenn man nicht einverstanden ist, sollte man andere Fachleute suchen. Das wegen des Rats irgendeines zufälligen Internet-Kommentators zu ignorieren, ist nicht "fast schon satirisch", sondern einfach dumm.

  • Zu einem Projekt beizutragen bedeutet, sich sichtbar zu machen und sich in eine verletzliche Position zu begeben. Besonders wenn "der Code funktioniert" und ein persönliches Ärgernis behebt, kann eine Ablehnung schwerer zu akzeptieren sein.
    Unabhängig von dieser Ablehnung dürfte es künftig einige ziemlich interessante Gerichtsverfahren geben. Große Modellanbieter könnten irgendeine Form von Freistellung anbieten und sagen: "Wir haben geholfen, diesen Code zu erstellen, also könnt ihr nach Belieben Urheberrechte daran beanspruchen"; oder sie könnten im Gegenteil Druck machen und behaupten, er gehöre ihnen und für bestimmte Nutzungen müsse eine Lizenz erworben werden. Claude gibt den Code derzeit an die Nutzer aus, aber ich weiß nicht, welche Freistellung dabei gewährt wird. Bei anderen Modellen weiß ich es ebenfalls nicht.

• Wusstet ihr, dass ein Verbrechen nur dann illegal ist, wenn man erwischt wird?

• Ich bin überhaupt kein glühender GNU-Fan, aber sind LLM-Coding-Tools nicht das genaue Gegenteil der GNU-Philosophie? Das wirkt, als würde man einen Hund in ein Katzencafé mitbringen und sich dann darüber aufregen, hinausgeworfen zu werden.

• Ich halte es für sehr unehrlich, den Titel von "Honesty gets Emacs patch rejected" in Vibecoding gets Emacs patch rejected zu ändern.
  Selbst wenn der Autor wie beschrieben Hilfe von AI-Tools hatte, ist das eindeutig kein Vibecoding, wenn er so viel Zeit und Verständnis in den Code gesteckt hat. Vibecoding wäre es, wenn man der AI einfach "Mach Emacs schneller" hinwirft und das Ergebnis blind einreicht, aber aus dem Text geht klar hervor, dass genau das nicht passiert ist.

  • Der Titel mit "honesty" war ebenfalls unehrlich. Der Patch wurde nicht wegen Ehrlichkeit abgelehnt, sondern wegen eines Verstoßes gegen die Richtlinie.
  • Der Auslegung des Begriffs "Vibecoding" stimme ich zu, aber wenn man sieht, wie unterschiedlich Leute den Begriff verwenden, finde ich das nicht derart unehrlich.
    Ich hätte es eher "Breaking contribution policy gets Emacs patch rejected" genannt. Das wäre immer noch spöttisch, aber schwerer zu widerlegen.

• Auffällig ist hier, dass der Autor behauptet, zwei Monate lang kontinuierlich daran gearbeitet zu haben, gleichzeitig aber erklärt, dass das Modell, mit dem er das Problem gefunden und gelöst haben will, erst vor 12 Tagen veröffentlicht wurde.
  Ich verstehe, dass der Autor ziemlich verärgert ist, aber letztlich sehe ich Open Source nicht als etwas, das einem Rechte verleiht, sondern eher als das Privileg, bereits geschriebenen Code nutzen zu dürfen. Wenn es daran etwas Gutes gibt: Vermutlich schon, und das, was über macOS geschrieben wurde, stimmt größtenteils, also könnten sich die Emacs-Entwickler die Zeit nehmen, es anzusehen. macOS dürfte aber kaum ihr Hauptfokus sein.

• Es gibt eine einfache Lösung, um zu beweisen, wie dumm diese Richtlinie ist: Auf dem zweiten Monitor den LLM-unterstützten PR-Diff offen lassen und die Änderungen auf dem Hauptmonitor von Grund auf per Hand neu schreiben. Variablennamen und den Inhalt der Kommentare dann noch ein wenig ändern.
  Dann wäre es menschengeschriebener Code und könnte gemergt werden.

  • Wenn man sich die urheberrechtlichen und rechtlichen Fragen rund um LLM-Ausgaben in vielen Rechtsordnungen weltweit ansieht, ist das eine sehr naive Sichtweise.