Flathub erlaubt keine LLM-basierten Einreichungen

• Bei der Prüfung von Flathub-Einreichungen nahm die Zahl LLM-basierter Einreichungen niedriger Qualität zu, was die ehrenamtlichen Reviewer stärker belastete und den Hintergrund für die Klarstellung der Richtlinie bildet
• Ausnahmen gelten wahrscheinlich für Projekte mit Community-Beteiligung, Release-Zyklus, CI und erkennbaren Spuren, dass sie nicht in kurzer Zeit mit wenig Aufwand entstanden sind
• Die bisherigen Kriterien wie bestehende Entwicklungshistorie und Projektgesundheit allein konnten den Review-Aufwand nicht senken und führten nur zu mehr Streit über die Auslegung der Regeln
• Die neue Richtlinie zielt nicht darauf ab, ausgereifte FOSS-Apps mit teilweiser LLM-Nutzung oder bestehende proprietäre Apps pauschal zu verbieten, sondern darauf, Low-Effort-Einreichungen zu verhindern
• Manche befürchten eine erneute Fragmentierung der Distribution im Flatpak-Ökosystem und eine Vermeidung von Flathub durch Unternehmen und schlagen statt eines Totalverbots Gebühren vor

---

Änderung der Richtlinie für LLM-Einreichungen bei Flathub

• Die zunehmende Zahl LLM-basierter Einreichungen niedriger Qualität bei der Prüfung von Flathub-Einreichungen und die dadurch steigende Belastung für ehrenamtliche Reviewer sind der zentrale Hintergrund der Richtlinienänderung
• Sjoerd Stendahl meint, in der Liste der Flathub-PRs habe es viele „AI-slop“-Einreichungen gegeben, und angesichts dieses Ausmaßes könnte diese Maßnahme die bessere Wahl sein
• Bart Piotrowski erklärte, dass Projekte wahrscheinlich Ausnahmen erhalten, wenn es Community-Beteiligung, einen Release-Zyklus, CI und Anzeichen dafür gibt, dass sie kein in kurzer Zeit erzeugtes minderwertiges Ergebnis sind
• Schon bisher versuchte man, minderwertige Einreichungen anhand ausreichender Entwicklungshistorie und der allgemeinen Projektgesundheit abzuwehren, doch der Review-Aufwand sank nicht, stattdessen entstanden nur Streitigkeiten über die Auslegung der Regeln

Ausnahmen und Reifegradkriterien

• Nexi hält das Problem von Low-Effort-Flathub-Einreichungen für real, sieht aber ein pauschales Verbot aller KI-generierten oder KI-unterstützten Codes als überzogen an
• Falls selbst bestehende Projekte wie Firefox, VSCode oder Chromium ohne Ausnahme von der Entfernung betroffen sein könnten, schlägt er objektive Metriken für die Projektreife vor, um minderwertige Einreichungen herauszufiltern
• Bart Piotrowski entgegnete, dass Reifegradkriterien de facto bereits existierten, letztlich aber die Review-Belastung nicht verringert hätten
• Nexi meint, die Ausnahmekriterien könnten klar in die Richtlinie aufgenommen werden, zusammen mit dem Hinweis, dass bei zu niedriger Codequalität auch ohne weitere Erklärung abgelehnt werden kann
• Sjoerd Stendahl meint, die neue Richtlinie sehe Ausnahmen für ausgereifte und gut gepflegte Projekte vor und ziele nicht darauf ab, verifizierte FOSS-Anwendungen mit teilweiser LLM-Nutzung oder bestehende proprietäre Anwendungen insgesamt zu verbieten

Auswirkungen auf das Ökosystem und Sorgen um Distributionswege

• Dmitry Mantis befürchtet, dass diese Richtlinie die Linux-Fragmentierung der Distribution zurückbringen könnte, die Flatpak eigentlich beheben soll
• Dass proprietäre Apps wie Slack und Spotify in Flathub in einer Sandbox-Form bereitgestellt werden, sei ein Vorteil; zugleich stellt sich die Frage, ob Closed Source dadurch sogar begünstigt wird, weil man die Entstehungsweise des Codes nicht kennen kann
• Als Gegenargument wurde angeführt, dass neue proprietäre Anwendungen unbekannter Entwickler ohnehin besser nicht sofort auf Flathub veröffentlicht werden sollten, auch unabhängig von dieser Richtlinie
• Dass einige zuvor nur als AppImage verfügbare Apps inzwischen offiziellen Flatpak-Support bieten, gilt als positiv; zugleich gibt es die Sorge, dass Unternehmen nach einer solchen Richtlinie den Einstieg in Flathub vermeiden könnten
• Es wurde auch vorgeschlagen, für KI-basierte Einreichungen eine Gebühr zu erheben, um die Review-Kosten zu decken, statt sie vollständig zu verbieten
• Die Richtlinie könnte als Signal verstanden werden, zunächst anderswo zu distribuieren, bis eine gewisse Nutzerbasis erreicht ist; und wenn gut gepflegte Apps, die LLMs teilweise für Tests oder Dokumentationsautomatisierung nutzen, sich auf anderen Distributionswegen etablieren, sinkt womöglich der Anreiz für einen Wechsel zu Flathub

Gegensätzliche Bewertungen von LLM-Werkzeugen

• Thomas Fuchs sieht das LLM-Problem eher als eines von Menschen und Marketing denn der Technologie selbst
• Er kritisiert, dass LLM-Unternehmen ihre Systeme wie Magie oder persönliche Arbeitssklaven vermarkten und Nutzer diese Behauptungen ungeprüft übernehmen
• Für erfahrene Nutzer, die Stärken und Schwächen kennen und sie für eng begrenzte Zwecke einsetzen, könnten LLMs hervorragende Werkzeuge sein; die Branche bewerbe sie jedoch aggressiv, als würde man „brennende Kettensägen gratis zum Jonglieren verteilen“
• Wolkensteine hält LLMs nicht für völlig nutzlos, meint aber, dass sie in den meisten Fällen nicht hilfreich seien und es noch kein nützliches Modell gebe, das auf ethisch unterstützenswerte Weise entstanden sei
• On-Device-Modelle könnten bei Rechtschreibprüfung oder Wortvorhersage in Smartphone-Tastaturen helfen, doch die Dinge, die sie fehlerfrei erledigen können, seien meist auch für Menschen leicht machbar und lehrreich
• Ember meint, auch solche potenziellen Einsatzfälle seien schon mit Werkzeugen vor generativer KI möglich gewesen, und in seltenen Fällen sei spezialisiertes ML, trainiert auf bestimmte Daten, besser geeignet
• Kroc Camen argumentiert, wegen Code-Diebstahl, inhärenter Voreingenommenheit und Umweltauswirkungen gebe es für LLMs überhaupt keinen legitimen Einsatzbereich

Community-Kultur und Polarisierung der Debatte

• trisweb meint, die Kultur rund um LLM-generierten Code und dessen Nutzer passe oft nicht zu dem freundlichen und kooperativen Ansatz, der zum Erhalt von Open-Source-Communities nötig ist
• ragectl hält eine Art Abkühlphase für neue Apps möglicherweise für sinnvoll; bis mehrere Releases und ein zweiter menschlicher Beitragender vorhanden seien, könnten sie ein höheres Risiko darstellen
• Sjoerd Stendahl mahnt, man müsse Hexenjagden vermeiden, sieht aber im aggressiven LLM-Vorstoß von Big Tech einen Treiber der Gegenreaktion
• Einige Arbeitgeber verlangten unter Androhung von Entlassung den Einsatz von LLMs bei der Arbeit; sogar einfache Funktionen wie Suche seien dadurch beschädigt worden, und die „Agentic future“ bediene eine sehr enge Nachfrage, während viele Produkte sich in etwas verwandelten, das wie Rückstände menschlicher Arbeit wirke
• razze meint, der Einsatz von LLMs für Suche oder Chatbots sei ein anderes Problem als ihr Einsatz für Code; Code sei überprüfbar und die Trade-offs seien klarer, daher müsse das getrennt bewertet werden
• Zeeshan Ali Khan wies auf die Aggressivität des Anti-LLM-Lagers hin, und Bart Piotrowski antwortete, die Polarisierung sei sowohl bei pro-LLM als auch bei anti-LLM stark; auch „vibecoders“ verhielten sich bei Kritik wie Opfer

[GN⁺]

Lobste.rs-Kommentare

• „Anwendungen, die KI-generierten oder KI-unterstützten Code, Dokumentation oder andere Inhalte enthalten, sind nicht erlaubt“ wirkt ziemlich kompromisslos.
  Flathub ist ein sehr populärer Ort, an dem Linux-Desktop-Nutzer Apps beziehen, bezeichnet sich selbst als „App Store für Linux“ und hat mehr als 1000 Apps.
  Heißt das wirklich, dass keine dieser Apps KI-unterstützten Code verwenden darf? Ist das realistisch? Ist es dafür nicht schon zu spät?

  • Die Formulierung „Ausnahmen können für ausgereifte und gut gepflegte Projekte erlaubt sein“ lässt eher vermuten, dass man verhindern will, dass vollständig per Vibe Coding erstellte Projekte hochgeladen und dann sich selbst überlassen werden.
  • Es ist nie zu spät.
    Selbst Projekte, die bereits auf Flathub sind, können entfernt werden, wenn sich herausstellt, dass sie per Vibe Coding entstanden sind, und damit kann man auch eine klare Botschaft senden.
  • Diese Regel dürfte wohl nach Ermessen durchgesetzt werden.
    Einige bestehende große Anwendungen könnten vermutlich als Ausnahme gelten, und selbst dann würde die Einschränkung wahrscheinlich eher für das unabhängige Flatpak-Paketieren als für den eigentlichen App-Code gelten.

• Dieser harte Ansatz ist vielleicht nicht zu 100 % durchsetzbar, aber in einer Situation, in der Unternehmen die Einführung von LLMs aggressiv vorantreiben, braucht die Community für den minimalen Widerstand wohl so eine starke Haltung.

• Wenn man an die jüngsten Vorfälle rund um die Lieferkette denkt, klingt das nach einer ziemlich nachvollziehbaren Entscheidung.

• Ob ein Projekt LLMs verbietet, Menschen mit grauen Haaren oder Menschen mit exakt 160 cm Körpergröße verbietet: Ich unterstütze zu 100 % die Freiheit, das selbst festzulegen.
  Das heißt nicht, dass ich diese Freiheit einschränken will, aber Paketverwaltung ist eine typische repetitive Arbeit, die stark von LLM-Unterstützung profitieren kann.
  Ich kann bis zu einem gewissen Grad auch Leute verstehen, die ihren Code als Produkt reiner Kunst oder Handwerkskunst sehen, aber warum sollte man ausgerechnet die langweiligsten Aufgaben nicht automatisieren?

  Ich erinnere mich, dass es kurz nach dem Start der AUR von Arch Linux Leute gab, die erfolgreich Hunderte von Paketen gepflegt haben.
  Sie waren immer aktuell und gingen fast nie kaputt; selbstverständlich haben sie das wohl automatisiert aktualisiert.
  Würde man heute dasselbe mit LLM-Unterstützung machen, wäre es mit ziemlicher Sicherheit noch robuster.

  Vielleicht sollte man unterwegs eher Menschen verbieten.
  Was tragen Menschen außer Supply-Chain-Angriffen eigentlich bei? Irgendwann sollte ich mal eine LLM-Distribution bauen, um zu beweisen, ob ich recht habe oder nicht.
  Davor muss ich aber erst diese Programmiersprache fertigstellen, haha.