Richtlinien für den Einsatz von KI-Assistenztools bei Beiträgen zum Linux-Kernel

• Offizielle Linux-Kernel-Dokumentation von Linus Torvalds: Beim Beitragen mit KI-Coding-Tools müssen der bestehende Kernel-Entwicklungsprozess und der Coding-Style unverändert befolgt werden
• KI darf kein Signed-off-by-Tag hinzufügen — rechtlich kann nur ein Mensch dies bestätigen, und menschliche Entwickler tragen die volle Verantwortung für die Prüfung, Lizenzkonformität und rechtliche Haftung von KI-generiertem Code
• Bei Code, zu dem KI beigetragen hat, müssen Modellname:Version und Analysewerkzeuge in einem Format wie Assisted-by: Claude:claude-3-opus coccinelle sparse angegeben werden
  • Grundlegende Entwicklungswerkzeuge wie git, gcc und make sind von dieser Kennzeichnung ausgenommen
• Alle Beiträge müssen mit GPL-2.0-only kompatibel sein, und ein SPDX-Lizenzbezeichner ist erforderlich

[GN⁺]

Hacker-News-Kommentare

• Die Grundregel lautet, dass man AI verwenden darf, die Verantwortung für den Commit aber vollständig beim Menschen liegt
  Dass der Code die Lizenzanforderungen erfüllen muss, klingt nach gesundem Menschenverstand. Dem dürften die meisten Entwickler zustimmen.

  • Das ist wirklich eine normale und fast schon langweilig vernünftige Richtlinie
    Überraschend ist eher, dass man so etwas überhaupt ausdrücklich festhalten muss.
    Inzwischen laden viele AI-generierten Code in Open Source hoch, ohne ihn überhaupt zu verstehen, und wenn später Probleme auftreten, entziehen sie sich der Verantwortung mit „die AI war’s“.
    Dass Maintainer unter solchen Umständen AI-Code skeptisch sehen, ist nur natürlich.
  • In der Linux-Community gibt es viele Menschen, die AI-unterstützte Commits extrem ablehnen
    Manche sehen Torvalds wegen dieser neuen Richtlinie sogar als Verräter, andere sagen, sie würden nie wieder beitragen, falls AI-generierter Code gemergt wird.
  • Falls AI-Ausgaben nicht unter der GNU GPL stehen, ist fraglich, ob sie allein dadurch GPL-Code werden, dass ein Linux-Entwickler noch etwas ergänzt.
  • AI ist doch nur ein Werkzeug (tool); ich verstehe nicht, warum man sie unbedingt als Urheber kenntlich machen sollte.

• Ich hatte gerade erst gesehen, dass Greg KH den Sashiko-AI-Reviewer auf alle Patches angewendet hat, deshalb wirkt diese Richtlinie im Vergleich etwas kontrastreich.
  AI-Reviewer helfen tatsächlich, und trotzdem dreht sich die Diskussion noch immer um „Verantwortung für AI-Code“.
  Der wirklich gefährliche Teil sind Race Conditions oder Locking-Probleme, bei denen AI mit großer Sicherheit falschliegt.
  Ich frage mich, ob diese Richtlinie eine langfristige Lösung ist oder nur ein Provisorium, bevor Systeme wie Sashiko auf Maintainer-Seite die Filterung verschärfen.

• Die von Torvalds angekündigte Richtlinie legt klar fest, dass Menschen AI-Code prüfen, abzeichnen und dafür Verantwortung übernehmen müssen.
  Vermutlich wurde sie juristisch geprüft und könnte künftig ein Maßstab für AI-unterstützte Entwicklung werden.

  • Das eigentliche Dokument wurde allerdings von Sasha Levin auf Basis der Diskussionen der Linux-Maintainer verfasst.
  • „Signed-off-by“ ist bereits heute oft nur noch ein formaler Schritt, den viele neue Beitragende anfügen, ohne die Bedeutung zu kennen.
    Mir ist tatsächlich schon passiert, dass mein Name automatisch in einem Refactoring einer anderen Person auftauchte, weil mein Patch darin enthalten war.
    Im Grunde kann fast jeder „Co-developed-by“ oder „Signed-off-by“ ergänzen, und rechtlich bindend ist das kaum.

• Wenn ein LLM seine Quellen nicht offenlegen kann, ist fraglich, wie sich Lizenzkonformität überhaupt sicherstellen lässt.

  • In Deutschland sind LLM-Ausgaben nicht urheberrechtlich geschützt.
    Urheber könnte der AI-Nutzer sein oder auch der Modellentwickler, die Rechtslage ist also sehr unklar.
    In so einer Situation könnte langfristig sogar die Kernel-Lizenz selbst ausgehöhlt werden.
    Das wird im Beitrag AI and copyright - what is permitted wh... von KPMG Law behandelt.

• Es wirkt merkwürdig, den Tag „Assisted-by:“ zur Kennzeichnung von AI-Modellen umzuwidmen.
  Ursprünglich sollte er die Hilfe von Menschen markieren, jetzt hat er zwei verschiedene Bedeutungen, was für Verwirrung sorgt.
  Üblicher wäre normalerweise ein eigener Tag wie „AI-assistant:“.

• Der richtige Weg für Open Source ist, die Verbindung zwischen Menschen und Agenten klar zu machen, während der Mensch die Verantwortung für die abschließende Prüfung trägt.
  Danke an Linus.

• Es ist erfreulich, dass selbst bei AI-generiertem Code der gesunde Grundsatz gilt: Die Verantwortung liegt beim Menschen.

• Das wirkt wie eine Umkehrung des alten Sprichworts „Ein schlechter Handwerker schiebt es auf sein Werkzeug“.
  Am Ende liegt die Verantwortung für Auswahl und Einsatz des Werkzeugs beim Menschen.

• Diese Richtlinie schützt Linux nicht vor Haftung wegen Urheberrechtsverletzungen.
  Das ist ungefähr so, als würde ein Einzelhändler sagen: „Ich glaube meinem Lieferanten einfach, dass das THC entfernt wurde.“
  Sich selbst für haftungsfrei zu erklären, beseitigt rechtliche Verantwortung nicht.

  • Der Linux-Kernel ist allerdings keine juristische Person, sondern eine Gesamtheit von Beitragenden.
    Selbst wenn verletzender Code enthalten wäre, würden sich Klagen eher gegen Linux-Nutzer oder Unternehmen richten.
    Realistisch betrachtet ist die Wahrscheinlichkeit solcher Klagen gering.
  • Viele Unternehmen verwenden AI-Code, aber das heißt nicht, dass sie deshalb automatisch rechtlich belangt werden.
  • Open-Source-Projekte geben anders als Geschäfte keine Verbrauchergarantie.
    Der Vergleich passt also nicht wirklich.
  • Tatsächlich ist AI-Code nicht automatisch riskanter.
    Wenn ein Mensch wollte, könnte er auch einfach nicht öffentlichen Code per Copy-and-paste einfügen und unterschreiben.
    Das eigentliche Problem ist am Ende der lügende Mensch.

• Es gibt die Klausel „Jeder Code muss mit GPL-2.0-only kompatibel sein“,
  aber bei AI, die auf Code unter vielen verschiedenen Lizenzen trainiert wurde, ist fraglich, wie sich das garantieren lassen soll.

  • Die Antwort ist einfach: Die Person, die AI benutzt, trägt die Verantwortung.
    Wenn die AI Mist baut, liegt auch diese Verantwortung beim Menschen. Wenn man sich unsicher fühlt, sollte man keine AI verwenden.
  • Tatsächlich haben auch menschliche Entwickler nicht ausschließlich GPL-Code gesehen.
  • Die Auslegung des Urheberrechts ist Sache der Gerichte. Torvalds muss solche Fragen nicht vorhersagen.
    Falls AI allerdings zur Laufzeit andere Codebasen referenziert, könnte das riskanter sein.
  • Manche behaupten, von AI erzeugter Code sei Public Domain und verletze deshalb die GPL nicht.
    So ein Ansatz könnte aber eher die Bedeutung von Lizenzen verwässern.
    Ein Hinweis wie „zu 100 % vibecoded, aber von mir geprüft“ hätte rechtlich nur geringe Wirkung.
    Es gab sogar den Vorschlag, bei einem „100% vibecoded“-Projekt ein Issue zur Relizenzierung in die Public Domain zu eröffnen, um auf dieses Problem aufmerksam zu machen.