KI wirbelt die die Communities von Open-Source-Projekten durcheinander und stellt Entwicklerinnen und Entwickler vor wichtige Fragen. Darf Open-Source-Code zum Trainieren von KI-Modellen uneingeschränkt verwendet werden? Wo hilft KI und wo schadet sie Open-Source-Projekten – beim Beantworten von Fragen zum Code, beim Programmieren und beim Projektmanagement? Was ist Open Washing und welche Rolle spielt Open Source im EU AI Act? Und schließlich die entscheidende Frage: Wird KI Open Source verdrängen? Antworten liefert die Community selbst. Tiefere Einblicke bieten die im Text verlinkten Videos von Vorträgen von Open-Source-Konferenzen der letzten sechs Monate: der Open Community Experience (OCX) mit den Unterkonferenzen EclipseCon und OSGi Summit, dem 38C3 sowie der FOSDEM 2025. Antworten auf diese Fragen liefern zudem Vertreter der Eclipse Foundation, dem Veranstalter der OCX.

Open-Source-Code als KI-Trainingsdaten: (l)egal?

Code macht einen großen Teil der Daten aus, mit denen heutige KI-Modelle trainiert werden. Benötigt wird er nicht nur, um die Modelle für Programmieraufgaben fit zu machen, sondern auch, um deren Schlussfolgerungsfähigkeit, das Reasoning, zu verbessern. Einige Chatbot-Modelle sind zudem in der Lage, anstatt direkt eine Antwort zu geben, Python-Code zu erstellen, der die Antwort teilweise berechnet und – damit er keinen Schaden anrichten kann – in einer Sandbox läuft. Mit der Ausgabe von der Programmausführung generiert dann das Modell die eigentliche Antwort. Dieser Code Interpreter hilft insbesondere bei Fragen, deren Beantwortung komplexere Berechnungen benötigt.

Der Code, der für das Training der Modelle verwendet wird, ist – wie könnte es anders sein – Open Source: in großen Mengen im Netz frei erhältlich. Die Llama-3-Basismodelle von Meta entstanden beispielsweise aus einem Training mit 15 Billionen Token, was mehr als 10 Billionen Wörtern entspricht, 17 Prozent davon Code. Aber wie ist das rechtlich? Ist ein Large-Language-Model ein von dem Code, anhand dessen es trainiert wurde, abgeleitetes Werk? Und wenn ja, unterliegt es dann den jeweiligen Lizenzbedingungen?

Die rechtliche Lage ist unklar. In Hugging Face BigCode (siehe OCX-Vortrag), einer umfangreichen Sammlung von Quelltexten, die aus öffentlichen GitHub-Repositories zusammengesammelt wurden, findet sich kein Code unter der Eclipse Public License (EPL), sondern nur Code unter der Apache-, MIT- und ähnlichen Lizenzen. Bei diesen Lizenzen ist im Gegensatz zur EPL nicht vorgeschrieben, dass abgeleitete Werke unter derselben Lizenz veröffentlicht werden müssen. Mike Milinkovich, Geschäftsführender Direktor der Eclipse Foundation, geht nicht von einer Verletzung der EPL aus, kann sie aber auch nicht sicher ausschließen. Es könne noch einige Jahre dauern, bis die KI-Frage geklärt sei, da das Urheberrecht von Land zu Land zwar weitgehend einheitlich, aber im Detail unterschiedlich sei und es noch keinen starken Konsens darüber gebe, ob es sich um ein abgeleitetes Werk oder um Fair Use handele. Eine EPL Version 3.0, die explizit die Verwendung als Trainingsdaten erlaubt oder verbietet, ist jedenfalls nicht geplant und würde ohnehin nicht rückwirkend für bereits vorhandenen Code gelten.

Unabhängig davon, ob die Verwendung als Trainingsdaten rechtlich unter Fair Use fällt oder nicht, stellt sich die Frage, ob es moralisch in Ordnung ist, Open-Source-Code ungefragt zum Trainieren von KI-Modellen zu verwenden. Wer seinen Code als Open Source veröffentlicht, macht das in der Regel in der Hoffnung auf Beiträge von anderen: Fehlerberichte, Verbesserungsvorschläge und gelegentliche Codebeiträge bis hin zur aktiven Beteiligung am Projekt. Eine Zweckbindung oder ein Verbot der kommerziellen Nutzung ist hier eher hinderlich. Restriktive Nutzungsbedingungen schränken den Kreis der potenziellen Nutzenden ein, aus dem sich wiederum die Mitwirkenden rekrutieren. Durch die Auslagerung eines Open-Source-Projekts an einen herstellerunabhängigen Ort, wie ihn die Eclipse Foundation oder andere Open-Source-Organisationen bieten, gibt man noch mehr Kontrolle ab, macht es aber für Unternehmen und Einzelpersonen attraktiver, sich zu beteiligen. Solange nicht alle, die Open Source direkt nutzen, sich auch daran beteiligen, kann man schlecht von denen, die den Code indirekt als Trainingsdaten nutzen, verlangen, etwas zurückzugeben.

Arbeitserleichterung oder Mehraufwand durch Chatbots?

Aber es ist nicht nur ein Nehmen von Trainingsdaten, sondern auch ein Geben: Chatbots entlasten Entwicklerinnen und Entwickler, indem sie Fragen zu Open-Source-Projekten beantworten. Fragen, die ansonsten in projektinternen Foren oder auf Webseiten wie Stack Overflow gestellt und dort von den Developern selbst oder Anwendern beantwortet worden wären. Kleinere Modelle lassen sich selbst ohne teure Grafikkarte auf dem eigenen Rechner ausführen, wenn man Geschwindigkeitseinbußen in Kauf nimmt: unter anderem mit einem der beiden bekannten Open-Source-Kommandozeilentools MLX von Apple für Apple-Computer oder llama.cpp für macOS, Linux und Windows; mit Ollama, das die Verwaltung von Modellen vereinfacht, oder mit llamafile, welches das Modell und den Code zum Ausführen in einer einzelnen Datei packt und wie Ollama auf llama.cpp basiert.

Chatbots laufen Stack Overflow den Rang ab: Seit Erscheinen von ChatGPT Ende November 2022 halbiert sich jährlich die Anzahl neuer Fragen und Antworten auf Stack Overflow. Und auch die Fragen, die noch gestellt werden, verweisen mitunter auf nicht funktionierende Chatbot-Lösungsvorschläge und Dinge, die es nicht gibt und die vermutlich eine KI herbeihalluziniert hat. Auch wenn Chatbots mal daneben liegen, geben sie doch zumeist schneller und freundlicher Auskunft als Menschen auf Stack Overflow und anderswo oder als eine Websuche es vermag. „Let me ask ChatGPT for you“ ist das neue „Let me google that for you“.

Die Kehrseite dieser KI-Helfer ist, dass sie auch Stack-Overflow-Antworten oder Beiträge für Open-Source-Projekte – beispielsweise Curl – generieren, die sich erst bei genauerem Hinsehen als nutzlos erweisen und so unnötigen Aufwand verursachen. Ein weiterer Nachteil von KI-generierten Lösungsvorschlägen ist, dass sie dazu neigen, ältere statt aktueller Frameworks und Tools zu bevorzugen. Neuere Informationen werden zwar berücksichtigt, wenn sie in einer Anfrage mitgegeben werden. Damit die KI sie jedoch sinnvoll anwenden, also generalisieren kann, muss sie zuvor anhand entsprechender Daten in ausreichender Quantität und Qualität trainiert worden sein.

Wenn Fragen nicht öffentlich, sondern an Chatbots gestellt werden, erfahren Projekt-Maintainer außerdem nicht, welche Probleme andere mit ihrer Software haben. Nicht nur das ausbleibende Feedback könnte sich als problematisch für die Projekte erweisen, sondern auch weniger öffentlich verfügbare Fragen und Antworten für das Training zukünftiger Modelle. Langfristig liegt es daher im Interesse beider Seiten, eine Lösung für den zerbrochenen Feedback-Loop zu finden.

KI-Unterstützung beim Programmieren

Neben allgemeinen Chatbots gibt es auch KI-Unterstützung speziell fürs Programmieren: zum Generieren von Code, Code-Kommentaren und Tests sowie zur Fehlerbehebung und Verbesserung von bestehendem Code. Integriert als Chatbot oder – um kontextabhängige Vorschläge auf Basis des umgebenden Codes zu liefern, speziell oder zusätzlich zur Interaktion in Chat-Form trainiert – direkt im Code-Editor als Codevervollständigung, helfen sie auch bei der Verwendung von Open-Source-Frameworks. Durch den hinzugefügten Kontext sind die Anfragen in der Regel länger, der Rechenaufwand dadurch höher. Frei verfügbare Angebote gibt es wenige, die zudem eine Anmeldung erfordern und auf eine bestimmte Anzahl Codevervollständigungsvorschläge und Chat-Anfragen pro Monat begrenzt sind.

Es gibt Open-Source-Tools als Alternativen zum Platzhirsch GitHub Copilot und solche, die sich Copilot zunutze machen, um ein besseres Tooling anbieten zu können. Eclipse Theia ist eine Alternative zu Visual Studio Code mit GitHub Copilot (weitere Informationen hierzu in einem Blogpost und OCX-Vortrag von EclipseSource): Anfragen, die nach außen gesendet werden, werden protokolliert und sind einsehbar; es lassen sich Agenten definieren, bei denen man festlegen kann, welche Zusatzinformation genau enthalten sein soll. Neben GitHub Copilot lassen sich auch lokal auf dem Rechner installierte Modelle verwenden, was bei GitHub Copilot erst seit Kurzem möglich ist.

Ein Vertreter eines mithilfe von GitHub Copilot verbesserten Toolings ist die Visual-Studio-Code-Erweiterung Spring Tools zur Unterstützung beim Programmieren in Java mit dem Webframework Spring (siehe OCX-Vortrag). So erscheinen im Code an bestimmten Stellen „Explain … with Copilot“-Links. Klickt man beispielsweise auf den Link „Explain Query with Copilot“, den Spring Tools bei Spring-spezifischen Annotationen mit einer SQL-Abfrage anzeigt, erhält man die von Copilot generierte Erklärung, ohne selbst eine Frage zu formulieren. Bei manuell erstellten Fragen kann Spring Tools den Prompt um wichtige Hinweise anreichern, bevor dieser an Copilot gesendet wird – beispielsweise, dass bei einem Projekt mit Spring Boot 3 Jakarta EE und nicht mehr Java EE zu verwenden ist.

Auch die von Copilot zurückgesendete Antwort kann Spring Tools um Schaltflächen anreichern, zum Beispiel „Apply Changes“ am Ende einer Antwort mit mehreren Codefragmenten, um alle mit einem Klick an die jeweils richtige Stelle im Projekt zu übernehmen. Copilot-basiertes Tooling besitzt unter anderem die Schwierigkeit, dass Copilot laufend weiterentwickelt wird: Derselbe „Explain … with Copilot“-Link, der heute eine gute Erklärung liefert, kann morgen schon nicht mehr funktionieren. Eine weitere Schwierigkeit entsteht, wenn GitHub Copilot nicht kennt, wonach gefragt wird, weil das verwendete Framework zu neu beziehungsweise der Wissensstand von Copilot zu alt ist. Bei der Anreicherung des Prompts kann auch die Längenbeschränkung ein Problem darstellen.