„Entweder Forken oder gehen“, Linus Torvalds kontert die AI-Gegner scharf: Linux macht kein „Anti-AI“

Von der Aussage, dass „90% nur Marketing-Hype sind“, bis hin zur ausdrücklichen Anerkennung, dass KI mittlerweile ein nützliches Werkzeug ist – die Haltung von Linus Torvalds, dem Schöpfer von Linux, zur KI hat sich offenbar deutlich gewandelt.

Betrachtet man jedoch seine öffentlichen Äußerungen der letzten zwei Jahre zusammen, wird klar: Was Linus wirklich ablehnt, war nie die KI selbst, sondern ungeprüfter Code, wertlose Fehlerberichte und Personen, die die Kosten der Code-Prüfung auf die Open-Source-Maintainer abwälzen.

Linus Torvalds, Linux-Schöpfer und oberster Maintainer des Kernels, hat auf seine charakteristische Weise erneut die Grenzen für den KI-Kurs der Linux-Kernel-Gemeinschaft festgelegt.

In einer Diskussion auf der Linux-Kernel-Mailingliste am 14. Juli stellte Linus angesichts des Widerstands einiger Entwickler gegen Large Language Models klar, dass Linux kein „Anti-KI-Projekt“ ist.

Wer mit dieser Richtung nicht einverstanden ist, kann den Kernel nach den Regeln der Open-Source-Welt forken oder das Projekt einfach verlassen.

„Linux gehört nicht zu diesen Anti-KI-Projekten. Wenn jemand damit nicht einverstanden ist, kann er das Projekt nach Open-Source-Regeln forken.“

„Oder einfach gehen.“

Linus betonte, dass er als oberster Maintainer des Linux-Kernels bereit sei, in dieser Frage „entschlossen Stellung zu beziehen“. Seiner Ansicht nach ist KI, genau wie Compiler, statische Analysetools und Codesuchwerkzeuge, in erster Linie ein Hilfsmittel. Es ist nicht perfekt und erzeugt neue Probleme – aber heute ist seine Nützlichkeit nicht mehr eine Frage, über die man streiten muss.

Eine Debatte um KI-gestützte Code-Prüfung

Diese Mailinglisten-Diskussion drehte sich um ein Projekt namens Sashiko.

Laut offizieller Beschreibung ist Sashiko ein Agent-basiertes Prüfsystem für Code-Änderungen am Linux-Kernel. Es liest Patches von der Kernel-Mailingliste oder aus Git-Repositories, analysiert den Code mit spezifischen Prompts, Protokollen und Tools für den Linux-Kernel und erzeugt Prüfungsbewertungen. Das Projekt ist nicht an einen bestimmten Modellanbieter gebunden und kann mit verschiedenen Large Language Models konfiguriert werden.

Der Auslöser der Kontroverse war der Linux-Entwickler Laurent Pinchart, der argumentierte: Wenn Maintainer auf Basis der von Sashiko erzeugten Prüfergebnisse handeln wollen, sollten sie diese Ergebnisse zuerst selbst sichten und verifizieren, bevor sie den ursprünglichen Patch-Autor kontaktieren. Er verwies zudem auf die Empfehlungen der Software Freedom Conservancy (SFC) zur KI-gestützten Open-Source-Entwicklung.

Ein anderer Entwickler, Roman Gushchin, widersprach dieser Ansicht.

Er meinte: Wenn von Maintainern, die Sashiko nutzen, verlangt wird, jede einzelne von der KI generierte Bewertung vollständig zu prüfen, bevor sie den Autor kontaktieren, dann wird das ursprüngliche Ziel von Sashiko – „Maintainern zu helfen“ – kaum erreichbar sein. Das Problem sollte nicht so dargestellt werden, als gehe es nur darum, zusätzliche Prüfschritte in jedem Anwendungsfall hinzuzufügen. Stattdessen sollte direkt diskutiert werden: Ist Linux überhaupt ein Projekt, das Large Language Models grundsätzlich ablehnt?

Genau in diesem Kontext gab Linus eine deutliche Antwort: Nein, Linux vertritt keine Anti-KI-Haltung.

Bemerkenswert ist, dass die in die Debatte verwickelten SFC-Empfehlungen kein einfaches „KI-Verbot“ darstellen.

Die SFC stellt klar, dass die Open-Source-Gemeinschaft Entwickler unterstützen sollte, die Large Language Models vollständig ablehnen. Niemand darf unter Druck von Arbeitgebern oder Projekten gezwungen werden, KI zu nutzen – und Projekte können je nach Wartungskapazität entscheiden, keine KI-generierten Beiträge anzunehmen.

Aber dasselbe Dokument betont auch: Open-Source-Projekte sollten Mitwirkende, die KI nutzen, nicht ausschließen. Vor dem Einreichen von KI-unterstütztem oder KI-generiertem Code müssen Einreichende ausreichend Zeit für die Prüfung aufwenden, den Code wirklich verstehen und offenlegen, welches Modell, welche Version und wie die KI beteiligt war. Für Szenarien, die die Verbesserung von Open-Source-Software deutlich beschleunigen, beschreibt die SFC die Nutzung proprietärer KI-Tools sogar als akzeptablen „strategischen Kompromiss“.

Daher liegt der eigentliche Unterschied zwischen den beiden Seiten nicht einfach bei „KI befürworten oder ablehnen“, sondern darin, wer die Verantwortung für die Verifizierung der KI-Ausgaben trägt – und wie diese Verantwortung zwischen Tool-Entwicklern, Patch-Einreichenden, Maintainern und ursprünglichen Code-Autoren verteilt werden soll.

Linus erkennt den Nutzen von KI an, gibt aber keine uneingeschränkte Freigabe

Linus verwendete in seiner E-Mail sehr deutliche Worte, plädierte aber nicht dafür, dass der Linux-Kernel bedingungslos KI-generierten Code akzeptiert.

Seine Kernaussage lautet: KI ist bereits ein praktisches, nützliches Ingenieurwerkzeug. Sie erhöht zwar die Arbeitslast der Maintainer und deckt immer wieder peinliche Fehler auf – aber die Lösung besteht nicht darin, so zu tun, als gäbe es diese Tools nicht, oder andere durch prinzipielle Verbote von ihrer Nutzung abzuhalten. Stattdessen müssen Prozesse gestaltet werden, bei denen Large Language Models Maintainern wirklich helfen, statt ihnen nur Probleme zu bereiten.

„Wir zwingen niemanden, es zu nutzen“, erklärte Linus – aber er wird auch diejenigen nicht beachten, die versuchen, andere Entwickler von der KI-Nutzung abzuhalten.

Auf die Kritik, dass KI leicht Fehler macht, antwortete er mit seiner typischen ironischen Art: KI ist nicht perfekt, aber die Kritiker der KI sollten auch vor ihrem eigenen Spiegel stehen – denn „natürliche Intelligenz ist auch nicht immer so toll“.

Anschließend lenkte Linus die Diskussion zurück auf das langjährige Grundprinzip des Linux-Projekts: Der Linux-Kernel ist in erster Linie ein technisches Projekt.

Seiner Ansicht nach sind die sozialen Beziehungen, die Gemeinschaftsidentität und der öffentliche Wert, die durch Open-Source-Kooperation entstehen, wichtig und können Teilnehmer motivieren – aber das sind zusätzliche Vorteile des Projekts, nicht der eigentliche Zweck von Linux.

Die Linux-Kernel-Gemeinschaft hat sich für Open Source entschieden, weil Open Source bessere Technik hervorbringt, nicht wegen einer „religionsähnlichen Überzeugung“. Daher sollten Entscheidungen über KI vor allem auf technischen Ergebnissen basieren, nicht auf Angst vor neuen Tools.

Das ist der Schlüssel zum Verständnis von Linus' Haltung. Er argumentiert nicht darüber, ob KI-Unternehmen Open-Source-Code korrekt nutzen, und leugnet nicht die Umwelt-, Urheberrechts- und Beschäftigungsprobleme durch KI. Er weigert sich nur, dass diese breiten Debatten automatisch zu einer vollständigen Ablehnung von KI-Tools im Linux-Kernel-Projekt führen.

Tatsächlich gibt es im offiziellen Linux-Kernel bereits klare Regeln für KI-Beiträge.

In der Linux-Kernel-Dokumentation heißt es: Wer KI für die Kernel-Entwicklung nutzt, muss weiterhin die normalen Kernel-Entwicklungsprozesse, Codierrichtlinien und Patch-Einreichungsanforderungen einhalten. KI-Agenten dürfen nicht selbst das „Signed-off-by“-Tag hinzufügen – dieses Tag steht für die rechtliche Bestätigung des „Developer's Certificate of Origin“ durch den Einreichenden und kann nur von einem Menschen erteilt werden.

Einreichende müssen den gesamten KI-generierten Code prüfen, die Lizenzkompatibilität bestätigen und die volle Verantwortung für den Beitrag übernehmen. Bei KI-Unterstützung empfiehlt die Dokumentation zudem die Nutzung des „Assisted-by“-Tags, um den Namen des KI-Tools, die Modellversion und relevante professionelle Analysewerkzeuge anzugeben. Mit anderen Worten: Linux erlaubt die Beteiligung von KI an der Entwicklung – aber die endgültige Verantwortung kann nicht an die KI übergeben werden.

Von „90% ist Hype“ zur Anerkennung des unübersehbaren Werts von KI

Interessanterweise steht Linus' klare Befürwortung des KI-Werts in starkem Kontrast zu seinen öffentlichen Bewertungen der KI im Jahr 2024.

Laut einem Bericht von *The Register* sagte Linus im Oktober 2024 in einem Interview auf dem Vienna Open Source Summit: KI sei interessant und könne die Welt verändern – aber er hasse den Hype, den die Tech-Industrie um KI aufbaut.

Damals schätzte er, dass rund 90% der KI-Narrative im Markt reines Marketing sind – nur 10% habe echten Wert. Weil der Hype so überhandnahm, ignorierte er KI vorübergehend und meinte, es würde fünf Jahre dauern, bis die Menschen die tatsächliche Nützlichkeit von KI in echten Arbeitsabläufen erkennen würden.

Linus verglich den damaligen KI-Boom zudem mit der früheren Kryptowelle. Seiner Ansicht nach erzeugen Produkte wie ChatGPT schöne Demonstrationen und werden bereits in manchen Anwendungsfällen eingesetzt – aber diese Fakten reichen nicht aus, um die überwiegende Mehrheit der Marktversprechungen zu rechtfertigen.

Knapp zwei Jahre später sagt Linus, dass die Nützlichkeit von KI „außer Frage“ steht – wer daran zweifelt, habe KI wahrscheinlich nie wirklich genutzt.

Im Jahr 2026 liefert KI bereits nachweisbare Ergebnisse bei der Kernel-Fehlererkennung, Patch-Prüfung und Code-Überprüfung. Linus hasst den Hype immer noch und lehnt nach wie vor minderwertige KI-Ausgaben ab – aber er sieht die Frage „Ist KI nützlich?“ nicht mehr als offen an.

Nicht nur Linus hat seine Meinung zu KI geändert: Auch Greg Kroah-Hartman, Maintainer der stabilen Linux-Versionen, äußerte sich im März dieses Jahres anders als früher.

Greg erklärte, dass KI-generierte Fehlerberichte lange Zeit von schlechter Qualität waren und oft nur „Müll“ waren, der die Zeit der Maintainer verschwendete. Anfang 2026 hat sich das aber geändert: KI beginnt, echte, reproduzierbare und hochwertige Fehlerberichte einzureichen – eine Veränderung, die nicht nur im Linux-Kernel, sondern auch in den Sicherheitsteams vieler Open-Source-Projekte zu beobachten ist.

Greg hat entsprechende Tools getestet und etwa 60 Probleme und Lösungsvorschläge erhalten. Davon war ungefähr ein Drittel der Reparaturansätze falsch – wies aber trotzdem meist auf ein echtes Problem hin. Die anderen zwei Drittel der Patches waren im Grunde korrekt.

Natürlich müssen diese Patches immer noch von Menschen bereinigt, verifiziert und nach den Kernel-Prozessen integriert werden.

Die Geschwindigkeit, mit der KI Fehler findet, übersteigt die Geschwindigkeit, mit der Maintainer sie bearbeiten

Linus ist sich der Belastung, die KI für Maintainer bedeutet, nicht blind. Zwei Monate vor dieser Äußerung kritisierte er bereits öffentlich KI-generierte doppelte Berichte und unnötige Patches.

Dieses Jahr im Mai sagte Linus, dass die vertrauliche Sicherheits-Mailingliste des Linux-Kernels eine Flut von Problemen erhält, die von KI-Tools entdeckt wurden. Derselbe Fehler kann von verschiedenen Personen und verschiedenen Tools wiederholt gemeldet werden – sodass die Mailingliste, die für die Bearbeitung sensibler Sicherheitsprobleme gedacht ist, kaum noch verwaltbar ist.

Sein Ratschlag dazu: Wer Probleme per KI entdeckt, sollte nicht einfach die rohen KI-Ausgaben an die Maintainer weitergeben. Melder sollten die zugehörige Dokumentation lesen, das Problem verstehen, prüfen, ob es bereits gemeldet wurde – und am besten versuchen, einen Patch zu schreiben. Einreichende müssen auf den KI-Ergebnissen menschliche Wertschöpfung hinzufügen, statt nur einen „Vorbeigeh-Bericht“ abzugeben.

Bei der Veröffentlichung eines weiteren Kernel-Kandidaten kritisierte Linus zudem einige triviale Reparaturen, die durch KI-Code-Prüfung ausgelöst wurden. Seiner Meinung nach mögen diese Änderungen lokal keine Fehler enthalten – aber es ist nicht notwendig, sie spät im Versionszyklus in den Kernel aufzunehmen. Selbst scheinbar einfache Änderungen können Rückschritte verursachen. Einreichende müssen nicht die Frage beantworten „Hat die KI eine Stelle gefunden, die man ändern kann?“, sondern: Ist dieses Problem schwerwiegend? Führt es zu echten Rückschritten? Und lohnt es sich, es im aktuellen Stadium zu beheben?

Zusammengenommen ergeben diese Äußerungen Linus' umfassende Sicht auf KI: KI kann Fehler finden, Code prüfen und die Entwicklung unterstützen – aber ein theoretisches Problem zu entdecken bedeutet nicht, dass daraus ein berichtenswer