Die LLM-Nutzungsrichtlinie von NLnet Labs

• NLnet Labs beschränkt die Nutzung von LLMs bei Projektbeiträgen und in der Kommunikation; Einreichungen, die gegen die Richtlinie verstoßen, können ohne vorherige Benachrichtigung geschlossen oder gelöscht werden
• Beiträge zu Code und Dokumentation müssen von Menschen selbst verfasst sein; Inhalte, die von LLMs oder anderen probabilistischen Tools erzeugt wurden, dürfen nicht enthalten sein
• Bei Schwachstellen- und Bug-Reports können von LLMs vorgeschlagene Korrekturen ausnahmsweise akzeptiert werden, doch ein menschlicher Beitragender muss das Problem und dessen Schweregrad verifizieren
• Bei der Interaktion mit NLnet Labs, etwa über Issues, Schwachstellenberichte oder Forenbeiträge, muss die Nutzung von LLMs offengelegt werden; auch bei maschineller Übersetzung wird wegen möglicher Fehlübersetzungen eine Offenlegung empfohlen
• LLMs dürfen für Linting, Analyse und Review genutzt werden, die Verantwortung dafür, die Richtigkeit extern geteilter Informationen zu verstehen und zu überprüfen, bleibt jedoch beim Beitragenden

---

Geltungsbereich der Richtlinie und grundlegende Pflichten

• NLnet Labs beschränkt im Kontext der Organisation und ihrer Projekte die Nutzung von Large Language Models (LLMs)
• Einreichungen, die diese Richtlinie nicht einhalten, können ohne vorherige Benachrichtigung geschlossen oder gelöscht werden
  • Dazu gehören PRs, Issues, Kommentare, Forenbeiträge usw.
• Zusätzlich zu dieser Richtlinie sind auch der Code of Conduct sowie die CONTRIBUTING.md des jeweiligen Projekts zu befolgen

Grundsätze für das Verfassen von Beiträgen

• Beiträge zu Code und Dokumentation müssen von Menschen verfasst sein
  • Sie dürfen keine Inhalte enthalten, die von LLMs oder anderen probabilistischen Tools erzeugt wurden
  • Von LLMs vorgeschlagene Korrekturen, die in Schwachstellen- oder Bug-Reports enthalten sind, sind ausnahmsweise erlaubt
  • Diese Ausnahme dient dazu, bei der ersten Prüfung die Ursache des Problems leichter zu finden
• Auch beim Öffnen eines PR werden LLM-generierte Beiträge nicht akzeptiert
  • Der eingereichte Code darf nicht von einem LLM erzeugt worden sein
  • Die PR-Beschreibung sollte knapp und in eigenen Worten verfasst werden
  • Im Allgemeinen sollten PRs für neue Features nicht geöffnet werden, ohne zuvor mit NLnet Labs gesprochen zu haben
  • Ideen für Softwareänderungen können im Community-Forum in eigenen Worten geteilt werden

Offenlegung der LLM-Nutzung und Übersetzung

• Bei der Interaktion mit NLnet Labs muss offengelegt werden, ob LLMs verwendet wurden
  • Dazu gehören das Erstellen von Issues, Schwachstellenberichte und Beiträge im Community-Forum
• Wenn Englisch nicht die Muttersprache ist, kann maschinelle Übersetzung hilfreich sein
  • Wurde maschinelle Übersetzung verwendet, wird eine Offenlegung empfohlen, damit beide Seiten mögliche Kommunikationsprobleme durch Fehlübersetzungen berücksichtigen können
  • Wenn man die Genauigkeit der Übersetzung nicht beurteilen kann, kann man auch in der eigenen Muttersprache schreiben
  • LLM-Übersetzungen werden wegen ihrer generativen Eigenschaften nicht empfohlen, da sie Diskussionen eher verwirren als erleichtern können

Erlaubte Nutzung und Verantwortung für die Prüfung

• Die Nutzung von LLMs für Linting, Analyse und Review ist erlaubt
• Auch wenn ein LLM beim Finden oder Analysieren eines Problems geholfen hat, bleibt der Nutzer dafür verantwortlich, die Richtigkeit der geteilten Informationen zu verstehen und zu überprüfen

Schwachstellenberichte

• NLnet Labs kann Schwachstellenberichte entgegennehmen, die mithilfe von LLMs gefunden wurden
  • Der Bericht kann von LLMs vorgeschlagene Korrekturen enthalten, um die Lokalisierung des Problems zu erleichtern
  • Ein menschlicher Beitragender muss das Problem und den geschätzten Schweregrad verifizieren
  • Bei der Meldung an [e-mail] muss die Nutzung von LLMs offengelegt werden
  • Für das Verfahren zur Meldung von Schwachstellen ist die Seite Security Report zu beachten

[GN⁺]

Meinungen auf Lobste.rs

• Ich würde gern die Begründung hinter solchen Regeln hören.
  Mich interessiert zum Beispiel, ob die Hauptmotivation rechtliche Unsicherheit ist, Bedenken hinsichtlich Qualität oder Wartbarkeit, oder etwas anderes.

  • Wie Alex Band von NLnet Labs in diesem Toot recht zurückhaltend erklärt hat, kann jemand mit einem gut formulierten Prompt 10.000 Zeilen Code erzeugen, die funktional wie beabsichtigt aussehen, um eine großartige und benötigte Funktion beizutragen.
    Entscheidend ist aber, ob vor dem Einreichen als Pull Request beim NLnet-Labs-Team jede erzeugte Zeile geprüft, verstanden und verantwortet wurde. Nach den Erfahrungen des letzten Jahres war das selten der Fall: Code liegt wie ein gut gemeintes Geschenk vor der Tür, aber die Last, ihn zu prüfen, Verantwortung dafür zu übernehmen und in den main-Branch zu mergen, fällt dem Team zu. Wenn man bedenkt, dass diese Software in kritischer Infrastruktur läuft, die das Fundament des Internets bildet, ist das eine große Zumutung. Im Review-Prozess müssen beide Seiten mit gemeinsamem Verständnis des Problemraums und der Details der vorgeschlagenen Lösung miteinander sprechen können; der Einsatz von LLMs verschafft Einreichenden dieses Verständnis nicht und wirkt sich auch negativ auf die langfristige Wartung aus.
  • Der unmittelbare Anlass für dieses Dokument war, die Zeit der Entwickler zu schützen.
    Natürlich wurden auch Urheberrecht, Qualitätskontrolle, langfristige Wartbarkeit und ethische Bedenken berücksichtigt.

• Mir gefällt, dass der Fokus darauf liegt, dass Menschen Patches schreiben und reviewen, und auch, dass Patch-Vorschläge in Schwachstellenberichten ausgenommen sind.
  Wenn solche Vorschläge einfach sind und den Kern treffen, sind sie es wert, gelesen zu werden.

• Ich kann verstehen, warum Menschen von KI-generierten Ergebnissen ermüden, besonders wenn das in größerem Maßstab passiert.
  Selbst in dem kleinen Team, in dem ich arbeite, entstehen nervige Situationen. Wenn man fragt: „Warum haben Sie das so gemacht?“, kommt als Antwort: „Oh, Claude hat das so gemacht“ – und das ist keine Antwort. Menschen schieben damit nicht nur den Denkprozess, sondern auch die Verantwortung auf die Maschine ab. Im Moment ist ein konservativer Einsatz nicht unbedingt schlecht; lockern sollte man erst, wenn wir wissen, wie man diese Technologie in großem Maßstab verantwortungsvoll nutzt. Derzeit weiß das niemand.

• Das ist nur die eigene Richtlinie von NLnet Labs und keine Richtlinie, die Projekte, die von NLnet unterstützt werden, zwingend übernehmen müssen.

• Ich verstehe den Hintergrund dieser Entscheidung, aber die Durchsetzung wirkt fast wie „alles verboten“ und daher engstirnig.

  • Kannst du erklären, woher dieses normative Urteil kommt? Mich interessiert, warum du ein Interesse daran hast, dass andere Leute in ihren Projekten LLM-generierte Einreichungen akzeptieren, und was sie oder die Gesellschaft dadurch gewinnen.
    Ich halte diese Logik für konsistent und vernünftig und in Zeiten wie diesen für eine gesunde Schutzmaßnahme. Mich würde auch interessieren, ob du befürchtest, dass deine Einreichungen aus diesem Grund abgelehnt werden, oder ob dir das bereits passiert ist. Ist es wirklich so schwierig, diese Richtlinie zu befolgen? Bist du selbst langfristiger Maintainer kritischer Infrastruktur und bearbeitest täglich die Flut minderwertigen Rauschens im Issue-Tracker? Wie sollte man deiner Meinung nach in einem menschenzentrierten Workflow die Auswirkungen einer Flut von False Positives verringern und zugleich die Motivation erhalten?
  • Ich würde es eher vorsichtig als engstirnig nennen.
  • Wenn sich zeigt, dass eine betroffene Community nicht mit offenen, komplexen Regeln umgehen kann, die die Interessen aller genauer abbilden, werden ziemlich häufig enge und einfache Regeln festgelegt.
    Das ist nichts Schlechtes. Wenn Entwickler etwas reifer geworden sind, kann man das wieder überprüfen.