Open Source und KI-gestützte Entwicklung: Rechtliche Aspekte

In unserem vorherigen Beitrag dieser Reihe haben wir darüber gesprochen, wie KI die Softwareentwicklung zunehmend verändert. In diesem Follow-up konzentrieren wir uns auf einige der wichtigsten rechtlichen (oder quasi-legalen) Fragen, die Open Source-Entwicklungsteams im Zusammenhang mit der KI-gestützten Entwicklung selbst angesprochen haben. 

Dies ist kein umfassender Überblick über sämtliche rechtlichen Aspekte im Zusammenhang mit KI. Wir gehen beispielsweise nicht auf Bedenken von Kunden hinsichtlich der Einhaltung von KI-Vorschriften oder Haftungsfragen im Zusammenhang mit Verträgen für KI-gestützte Produkte ein. Stattdessen konzentrieren wir uns auf Themen, die Open Source Communities aktiv diskutieren. 

Unsere Ansichten zu diesen Themen spiegeln unser Engagement für einen verantwortungsvollen Einsatz von KI-Technologien und unsere Philosophie „Default to Open“ wider. Wir sind davon überzeugt, dass kollaborative und transparente Konzepte die besten Möglichkeiten bieten, um diese Bedenken konstruktiv anzugehen.

Namensnennung und Kennzeichnung 

Die Namensnennung ist eine zentrale rechtliche und kulturelle Norm in Open Source. Lizenzen erfordern in der Regel, dass Sie Urheberrechts- und Urheberschaftshinweise wahren und irreführende Ansprüche in Bezug auf die Urheberschaft vermeiden. 

KI-gestützte Entwicklung erschwert dies. Da KI-Systeme im Sinne des Urheberrechts nicht als „Urheber“ gelten, gibt es technisch gesehen niemanden, der genannt werden könnte. Dennoch wäre es für Entwickelnde irreführend, umfangreiche KI-generierte Ergebnisse als rein eigene Arbeit darzustellen. 

Aus diesem Grund führen immer mehr Open Source-Projekte Offenlegungsregeln für KI-gestützte Beiträge ein. Dabei orientieren sie sich an Offenlegungsnormen in anderen Bereichen, wie etwa bei der Kennzeichnung synthetischer Medien. Das “Kennzeichnen“ von Beiträgen trägt dazu bei, die rechtliche Klarheit und das Vertrauen der Community zu erhalten, und erleichtert es Prüfenden, den Code im Kontext zu bewerten.

Wir unterstützen Kennzeichnungen, sind aber der Meinung, dass diese nicht übermäßig präskriptiv sein sollten. Relativ unbedeutende Verwendungen von KI (wie das automatische Vervollständigen eines Variablennamens oder das Vorschlagen eines Docstrings) sollten nicht offengelegt werden. Bei umfangreicheren Verwendungszwecken kann die Kennzeichnung so einfach wie ein Quellcodekommentar, ein Hinweis in einer Merge-Anforderung oder ein Commit-Trailer wie Assisted-by: sein (andere Kandidaten, die von einigen Projekten verwendet werden, sind Generated-by: und Co-authored by: ).  

Urheber- und Lizenzierungsformalitäten

So wichtig die Namensnennung auch sein mag, Open Source hängt noch stärker von eindeutigen Lizenzgewährungen ab. Dies wirft eine praktische Frage auf: Wie funktionieren Lizenzhinweise, wenn ein Beitrag nicht urheberrechtlich geschütztes KI-generiertes Material enthält?

In den meisten Fällen sollte sich nichts ändern, wenn Lizenzhinweise bereits in einem Repository oder einer einzelnen Quelldatei vorhanden sind. Aufgrund der hochfunktionellen Natur von Code sind Quelldateien bereits in der Regel eine Mischung aus urheberrechtlich geschütztem und nicht urheberrechtlich geschütztem Material. Zudem finden Open Source-Lizenzen nur auf die urheberrechtlich geschützten Teile Anwendung. Bei umfangreichen KI-generierten Beiträgen ergänzt die Offenlegung durch Kennzeichnung bestehende Lizenzhinweise und ist der richtige Weg, um Irreführung zu vermeiden. 

Der schwierigere Fall ist, wenn KI eine gesamte Quelldatei oder sogar ein gesamtes Repository generiert. Hier ist das Hinzufügen eines Urheberschutz- und Lizenzvermerks möglicherweise unangemessen, es sei denn, menschliche Beiträge wandeln die Datei in ein urheberrechtlich geschütztes Werk um. Angesichts der Norm, dass Open Source-Repositorys eine globale LICENSE-Datei haben sollten, ist es sinnvoll, eine bekannte, äußerst freizügige Open Source-Lizenz (z. B. die Unlicense) als globale Lizenz eines KI-generierten Repositorys hinzuzufügen, auch wenn solche Lizenzen technisch gesehen voraussetzen, dass das Urheberrecht besteht. Wenn menschliche Beiträge hinzugefügt werden, können Projektbetreuende diese ursprüngliche Lizenzwahl überdenken. Aufgrund des Fehlens früherer menschlicher Mitwirkender ist dies einfacher als das typische Szenario, in dem ein Open Source-Projekt neu lizenziert wird. Wir gehen davon aus, dass sich die Praktiken sowohl durch Gesetzesänderungen als auch durch bessere Erfahrungen der Community mit KI-Tools weiterentwickeln werden.  

Sind KI-Tools „Plagiatsmaschinen“ 

Einige Open Source-Entwicklerinnen und -Entwickler stehen der KI-gestützten Entwicklung skeptisch und manchmal sogar feindselig gegenüber und bezichtigen KI-Modelle, „Plagiatsmaschinen“ oder Mechanismen zur „Urheberrechtwäsche“ zu sein. 

Es gibt zwei Versionen dieses Problems. Die erste ist praktisch: Ein KI-Tool könnte heimlich Auszüge von proprietärem (oder mit einer Lizenz nicht kompatiblem) Code in ein Open Source-Projekt einfügen, was potenziell ein rechtliches Risiko für Projektverantwortliche und Nutzende birgt. Die zweite ist allgemeiner und philosophischer: dass Large Language Models, die auf riesigen Mengen an Open Source-Software trainiert wurden, die Arbeit der Community im Grunde zweckentfremden und Ergebnisse produzieren, die die von Open Source-Lizenzen geforderten Verpflichtungen nicht erfüllen.   

Wir sind der Meinung, dass diese Bedenken ernsthafte Beachtung verdienen. Zwar sind Large Language Models in manchen Fällen in der Lage, nicht triviale Auszüge ihrer Trainingsdaten auszugeben. Wenn dies ein häufiges oder unvermeidbares Verhalten wäre, wäre es ein guter Grund, diese Tools gar nicht zu verwenden. 

Die Faktenlage deutet jedoch auf etwas anderes hin. Als GitHub Copilot veröffentlicht wurde, gab es weitverbreitete Aussagen, dass die Vorschläge von Open Source-Projekten kopiert wurden. Soweit diese Aussagen überhaupt fundiert waren, handelte es sich in der Regel um bewusste Bemühungen, das Tool dazu zu bringen, bekannten Code wörtlich zu reproduzieren, was keine gewöhnliche Verwendung ist. Seitdem haben wir keine glaubwürdigen Hinweise darauf gesehen, dass weit verbreitete KI-Entwicklungstools systematisch Teile der Trainingsdaten replizieren, die umfangreich genug sind, um urheberrechtliche Bedenken auszulösen.

Das einem Großteil der Erzählung von „Plagiatsmaschinen“ zugrunde liegende Missverständnis besteht darin, dass generative KI-Modelle eine Art verlustbehaftete Komprimierung ihrer Trainingsdaten darstellen. In der Praxis besteht das normale Verhalten von Modellen darin, neuartige Texte basierend auf erlernten statistischen Mustern zu generieren. Die Tatsache, dass sie anhand von Open Source-Code geschult wurden, bedeutet nicht, dass ihre Ausgabe eine Kopie dieses Codes ist. 

Dennoch darf man die Möglichkeit einer gelegentlichen Replikation nicht ignorieren. Entwicklungsteams, die KI-Tools verwenden, sollten dieses Risiko im Auge behalten und KI-generierte Ergebnisse mit der gleichen Sorgfalt prüfen wie andere Beiträge. Wenn KI-Entwicklungstools eine Funktion zum Erkennen oder Kennzeichnen langer Vorschläge bieten, die mit vorhandenem Open Source-Code übereinstimmen, sollte man diese Funktionen aktivieren. In Kombination mit Offenlegungspraktiken und menschlicher Kontrolle sind diese Schritte eine praktische Möglichkeit, Replikationsprobleme abzumildern, ohne jegliche KI-Nutzung als von Natur aus fehlerhaft zu behandeln. 

KI-gestützte Beiträge und das DCO

Projekte, die das Developer Certificate of Origin (DCO) verwenden, haben besondere Bedenken in Bezug auf KI-gestützte Beiträge geäußert. Das DCO, das wir seit langem als Best Practice für die Open Source-Entwicklung empfehlen, erfordert von Mitwirkenden die Zertifizierung, dass sie das Recht haben, ihre Arbeit unter der Lizenz des Projekts einzureichen. Einige Entwickelnde argumentieren, dass niemand legitim die DCO-Bestätigung für KI-gestützten Code abgeben kann, da die Ausgaben von KI-Tools unbekanntes oder nicht offengelegtes Material enthalten können. Diese Auffassung hat dazu geführt, dass einige Projekte, die DCO verwenden, KI-gestützte Beiträge insgesamt verbieten. 

Wir verstehen diese Bedenken, aber das DCO wurde nie so interpretiert, dass es verlangte, dass jede einzelne Zeile eines Beitrags der persönliche kreative Ausdruck des Beitragenden oder eines anderen menschlichen Entwickelnden sein muss. Viele Beiträge enthalten routinemäßiges, nicht urheberrechtlich geschütztes Material, und Entwickelnde haben sie trotzdem bestätigt. Bei dem DCO geht es eigentlich um die Verantwortung. Der Beitragende ist der Ansicht, dass er das Recht hat, den Beitrag in einem Werk zu verwenden, das (hinsichtlich seiner urheberrechtlich geschützten Elemente) einer bestimmten Open Source-Lizenz unterliegt. Projektverantwortliche haben die berechtigte Erwartung, dass der Mitwirkende die gebührende Sorgfalt hat walten lassen, um die Zertifizierung zu erteilen. Durch Offenlegung und menschliche Aufmerksamkeit – und Kontrolle –, unterstützt durch Tools, die die Code-Ähnlichkeit überprüfen, können KI-gestützte Beiträge vollkommen mit dem Geist des DCO kompatibel sein.

Dies bedeutet jedoch nicht, dass Projekte KI-gestützte Beiträge zulassen müssen. Jedes Projekt hat das Recht, seine eigenen Regeln und sein eigenes Komfortniveau aufzustellen. Wenn ein Projekt beschließt, KI-gestützte Beiträge vorerst zu verbieten, verdient diese Entscheidung Respekt. Projekte, die sich für diesen Weg entscheiden, sollten erkennen, dass die von ihnen geäußerten Bedenken nicht neu oder einzigartig für KI sind. Jahrelang sorgten sich risikoscheue kommerzielle Nutzende von Open Source über „verschleierten“ Code: Beiträge, die urheberrechtlich geschütztes Material unter nicht offengelegten, problematischen Bedingungen versteckten. Mit der Zeit erwiesen sich diese Befürchtungen als unbegründet. Es ist nicht ausgeschlossen, dass ein KI-gestützter Beitrag nicht offengelegtes urheberrechtlich geschütztes Material enthalten kann. Die Erfahrung zeigt jedoch, dass es sich um ein bewältigbares Risiko handelt, das sich nicht kategorisch von den Herausforderungen unterscheidet, mit denen Open Source in der Vergangenheit konfrontiert war und die es bewältigt hat. 

Mit anderen Worten: Das DCO kann bleiben, was es immer war: ein praktisches und effektives Tool zur Aufrechterhaltung des Vertrauens und der rechtlichen Klarheit in der Open Source-Entwicklung, auch im Zeitalter der KI.

Vertrauen schaffen

Vielen Diskussionen um KI in der Softwareentwicklung, sei es rechtlicher, technischer oder ethischer Natur, liegt die Frage des Vertrauens zugrunde. Vertrauen ist ein grundlegendes menschliches Anliegen, das für den Erfolg von Open Source-Projekten unerlässlich ist. Die Einführung von KI in die Open Source-Entwicklung wirft neue Vertrauensfragen in mehreren Dimensionen auf: Vertrauen darauf, dass Mitwirkende KI verantwortungsvoll einsetzen, dass diejenigen, die dies tun, nicht stigmatisiert werden und dass die Unternehmen, die KI entwickeln und fördern, dies in einer Weise tun, die dem Allgemeinwohl dient. Die Erkenntnis, dass diese Unternehmen, einschließlich Red Hat, ein wirtschaftliches Interesse am Erfolg von KI haben, ist auch ein wichtiger Bestandteil der Transparenz ihrer Rolle bei dieser technologischen Transformation.

Die Herausforderung, Vertrauen in Technologie aufzubauen, ist nicht neu. Ken Thompsons wegweisende Vorlesung „Reflections on Trusting Trust“ aus dem Jahr 1984 bleibt ein Prüfstein für das Verständnis, wie tief menschliches Urteilsvermögen und institutionelle Integrität die Software selbst untermauern. KI rückt diese Konzepte wieder in den Vordergrund. Vertrauen muss man sich trotzdem durch konsistente und sichtbare Aktionen erarbeiten. Red Hat schätzt das Vertrauen, das wir zu Upstream Communities aufgebaut haben, und wir sind davon überzeugt, dass unser Open Source-Entwicklungsmodell, das auf Transparenz, Zusammenarbeit und Verantwortlichkeit basiert, weiterhin der beste Weg ist, dies zu erhalten und gemeinsam die Zukunft von KI und Open Source zu gestalten.

Blick in die Zukunft

Die Themen, die wir hier besprochen haben – Kennzeichnung, Lizenzhinweise, Bedenken hinsichtlich der Replikation von Trainingsdaten und das DCO – sind die rechtlichen Fragen, mit denen Open Source-Entwickelnde heutzutage am meisten zu kämpfen haben. Durch die Offenlegung der Nutzung von KI, menschliche Aufsicht und die Einhaltung der Projektregeln kann man die KI-gestützte Entwicklung sowohl mit den rechtlichen Grundlagen als auch mit den kulturellen Werten von Open Source in Einklang bringen. Wir freuen uns über die Zusammenarbeit in Upstream-Projekten an diesen und anderen Ansätzen, die diese Interessen ausgleichen. Jedes Projekt sollte die Freiheit haben, seine eigenen Entscheidungen zu treffen. Open Source Communities werden stärker sein, wenn sie diese Probleme selbst angehen, anstatt abseits von ihnen zu stehen.