Kurzantwort: Für die meisten Teams macht die Nutzung eines AGPL-3.0-Werkzeugs zum Bau eigener Software Ihre Software nicht zu AGPL – die Lizenz deckt das Werkzeug, nicht den Code, den Sie damit schreiben. Die Pflicht, die überrascht, ist die Netzwerkklausel: Wenn Sie das Werkzeug ändern und andere Ihre geänderte Version über ein Netzwerk nutzen lassen, müssen Sie ihnen deren Quellcode anbieten. Dies ist allgemeine Information, keine Rechtsberatung; klären Sie Ihren Fall mit einem Anwalt.
Open-Source-KI-Coding-Plattformen erscheinen zunehmend unter der GNU Affero General Public License v3.0. Sie ist eine starke Copyleft-Lizenz, und ihr Ruf macht manche Engineering-Verantwortliche nervös, überhaupt AGPL-Werkzeuge einzuführen. Diese Sorge entspringt meist der Vermischung zweier sehr unterschiedlicher Dinge: die Software nutzen und sie ändern und weiterverbreiten.
Was AGPL-3.0 ist – und was sie besonders macht
AGPL-3.0 ist die stärkste netzwerkzeitalter-Copyleft-Lizenz der GPL-Familie. Sie trägt die üblichen GPLv3-Pflichten – wenn Sie die Software oder eine geänderte Version weitergeben (verbreiten), müssen Sie den entsprechenden Quellcode unter derselben Lizenz bereitstellen – und fügt einen weiteren Auslöser hinzu.
Dieser Zusatz ist Abschnitt 13, „Remote Network Interaction“. Laut dem von der Free Software Foundation veröffentlichten Lizenztext müssen Sie, wenn Sie das Programm ändern und Nutzer aus der Ferne über ein Computernetzwerk mit Ihrer geänderten Version interagieren lassen, diesen Nutzern die Möglichkeit geben, den entsprechenden Quellcode Ihrer geänderten Version zu erhalten. Das ist die AGPL-Netzwerknutzungsklausel, und sie schließt das „SaaS-Schlupfloch“, das die gewöhnliche GPL offen lässt.
Die Unterscheidung, die die meiste Sorge auflöst
Hier liegt der Punkt, den Teams am häufigsten falsch verstehen. Ein Programm auszuführen ist nicht dasselbe wie ein abgeleitetes Werk davon zu erstellen. Laut der GNU-Lizenz-FAQ der FSF ist die Ausgabe eines Programms in der Regel nicht durch die Lizenz des Programms abgedeckt, es sei denn, die Ausgabe selbst enthält Teile des Programms.
Im Klartext: Wenn Sie eine AGPL-3.0-Coding-Plattform als Werkzeug nutzen, um Ihre eigene Anwendung zu schreiben, gehört Ihnen Ihre Anwendung. Die AGPL deckt den Quellcode der Plattform, nicht den Quellcode, den Sie damit erzeugen. Das ist dieselbe Logik wie in Wem gehört KI-generierter Code – die Lizenz des Werkzeugs und das Eigentum an Ihrer Ausgabe sind getrennte Fragen.
Das praktische Risiko ist also nicht „AGPL-Software zu übernehmen infiziert unsere Codebasis“. Es ist enger und konkreter: Was passiert, wenn wir das Werkzeug selbst ändern, und wie verbreiten oder exponieren wir diese geänderte Version?
Wann die Pflichten tatsächlich gelten
Aus dem Lizenztext heraus betrachtet, verhalten sich drei grobe Situationen sehr unterschiedlich. (Nochmals: allgemeine Information, keine Rechtsberatung.)
- Interne, unveränderte Nutzung. Sie betreiben das Werkzeug innerhalb Ihrer Organisation und ändern oder verbreiten es nicht. Das ist der leichteste Fall; die Netzwerkklausel wird ausgelöst, indem eine geänderte Version externen Nutzern bereitgestellt wird.
- Sie ändern das Werkzeug. Sobald Sie den Quellcode ändern, greifen die Copyleft-Pflichten auf diese Änderungen, wenn und sobald Sie die geänderte Version verbreiten oder sie gemäß Abschnitt 13 Remote-Nutzern zugänglich machen.
- Sie bieten es als Netzwerkdienst an. Wenn Sie eine geänderte Version hosten und externe Nutzer über ein Netzwerk damit interagieren lassen, verlangt Abschnitt 13, dass Sie ihnen den entsprechenden Quellcode Ihrer Änderungen anbieten.
Die entscheidende Achse ist nicht „intern vs. extern“ – sondern unveränderte Nutzung vs. ändern-und-exponieren.
Eine praktische Compliance-Checkliste
- Inventarisieren Sie, welche KI-Werkzeuge in Ihrem Stack AGPL-3.0 sind, einschließlich transitiver Komponenten.
- Trennen Sie Werkzeug und Produkt: Bestätigen Sie, dass Ihre Anwendung es als eigenständigen Dienst/Werkzeug einbindet, statt seinen Quellcode in Ihren zu kopieren.
- Verfolgen Sie Änderungen. Wenn Sie ein AGPL-Werkzeug forken oder patchen, halten Sie diese Änderungen identifizierbar und unter Versionskontrolle.
- Entscheiden Sie über die Exposition. Falls Sie eine geänderte Version externen Nutzern über ein Netzwerk anbieten könnten, planen Sie, den entsprechenden Quellcode Ihrer Änderungen zu veröffentlichen.
- Bewahren Sie Hinweise und Lizenzdateien; entfernen Sie nicht die Namensnennung oder die LICENSE.
- Holen Sie eine Rechtsprüfung ein, bevor Sie sich für eine kommerzielle Bereitstellung darauf verlassen. Siehe die direkten Antworten, was AGPL-3.0 für MonkeyCode bedeutet und ob es kommerziell genutzt werden kann.
Wo MonkeyCode passt
MonkeyCodes Repository steht unter GNU AGPL-3.0, das heißt, der Code ist prüfbar und forkbar mit den oben genannten Pflichten. Für die meisten Anwender, die es betreiben, um ihre eigene Software zu entwickeln, ist das eine handhabbare, gut verstandene Konstellation – dasselbe Profil wie bei vielen Open-Source-Infrastrukturwerkzeugen. Der Lizenzleitfaden legt den sachlichen Überblick und die Grenze der Rechtsprüfung dar, und was eine Open-Source-Plattform teamreif macht deckt die operative Seite der Einführung ab.
Fazit
AGPL-3.0 ist strenger als MIT oder Apache-2.0, aber im häufigen Fall – das Werkzeug zu nutzen, um Ihr eigenes Produkt zu bauen – berührt sie Ihren Code nicht. Der einzige Ort, an dem Sie bewusst handeln sollten, ist Änderung plus Netzwerkexposition, wo Abschnitt 13 verlangt, den Quellcode Ihrer Änderungen zu teilen. Inventarisieren Sie Ihre AGPL-Werkzeuge, halten Sie Änderungen identifizierbar, entscheiden Sie früh über Ihr Expositionsmodell und lassen Sie die Details Ihrer Bereitstellung von einem Anwalt bestätigen.
Verwandte Leitfäden dieser Reihe
- Was eine Open-Source-KI-Coding-Plattform teamreif macht
- Selbst gehostete KI-Entwicklungsplattform: eine Bewertungs-Checkliste
- Air-Gapped KI-Coding: ohne ausgehenden Internetzugang betreiben
Quellengrenze: Die AGPL-3.0-Pflichten sind aus dem Lizenztext und der GNU-Lizenz-FAQ der Free Software Foundation zusammengefasst (geprüft am 20. Juli 2026) und als allgemeine, bildende Information ausgelegt. Dies ist keine Rechtsberatung, und die Lizenzauslegung hängt von Ihren konkreten Umständen ab – konsultieren Sie qualifizierten Rechtsbeistand, bevor Sie sich für eine kommerzielle Bereitstellung darauf verlassen. MonkeyCodes Lizenz ist in seinem öffentlichen Repository angegeben und sollte anhand der aktuellen LICENSE-Datei bestätigt werden.