KI-generierter Code und Open-Source-Lizenzen: das IP-Risiko im Griff behalten

Wenn es um KI-Coding-Tools und Risiko geht, dreht sich fast alles um Sicherheit oder Datenschutz. Das Thema, das weniger Beachtung findet und sich später schwerer wieder einfangen lässt, sind die Schutzrechte: Wem gehört eigentlich der Code, an dem ein KI-Tool mitgeschrieben hat, und steckt darin womöglich eine Open-Source-Lizenz, der Ihr Unternehmen nie zugestimmt hat?

Das ist kein theoretisches Problem. KI-Coding-Modelle werden auf riesigen Mengen öffentlichen Codes trainiert, darunter auch Code unter restriktiven Lizenzen. Meistens ist ein Vorschlag eigenständig genug, um unbedenklich zu sein. Manchmal aber ist er eine nahezu wortgleiche Wiedergabe von Trainingsdaten. Und stammten diese Daten aus GPL- oder anderem Copyleft-lizenziertem Code, kann die Annahme des Vorschlags Pflichten in Ihre Codebasis einschleppen, die nie jemand geprüft hat.

Wir unterstützen Entwicklungsteams dabei, das zu beherrschen, ohne ein juristisches Großprojekt daraus zu machen, das die Auslieferung lahmlegt. Das Risiko ist real, aber überschaubar, und die Kontrollen sind praxistauglich. So sollten Sie an die Sache herangehen.

Dies ist eine praktische Entwicklersicht, keine Rechtsberatung. Die Rechtslage ist hier ungeklärt und unterscheidet sich von Land zu Land; die endgültige Position für Ihre Organisation verantwortet Ihre Rechtsabteilung.

Zwei Risiken, die man auseinanderhalten muss

Hinter „IP-Risiko durch KI-Code“ stecken zwei verschiedene Probleme, die jeweils eine eigene Antwort brauchen.

Beim ersten geht es um Pflichten, die Sie sich unwissentlich aufladen könnten. Beim zweiten darum, ob der Code überhaupt von Anfang an sauber Ihnen gehört. Beides ist wichtig, und beides wird leicht durcheinandergeworfen.

Eingehend: wenn ein Vorschlag eine Lizenz mitbringt

Das Kontaminationsrisiko verteilt sich nicht gleichmäßig, es ballt sich. Am größten ist es, wenn ein Modell ein wiedererkennbares Stück Trainingsdaten reproduziert, am ehesten bei bekannten Algorithmen, charakteristischen Utility-Funktionen oder großen Blöcken, die aus einem dürftigen Prompt entstanden sind.

Die Gefahr: Copyleft-Lizenzen wie die GPL wirken „viral“. Wird ihr Code in Ihr Produkt eingebaut und verteilt, kann die Lizenz verlangen, dass Sie Ihren eigenen Quellcode unter denselben Bedingungen offenlegen. Für eine proprietäre Codebasis ist das ein ernstes Problem, und im Moment der Annahme sieht man es nicht, weil der Vorschlag ganz ohne Herkunftsangabe eintrifft. Der Entwickler sieht Code, der funktioniert. Er sieht nicht, woher er kommt.

Die Gegenmaßnahmen sind konkret:

• Nutzen Sie die Duplikats- oder Filterfunktion des Anbieters. Mehrere Enterprise-KI-Coding-Tools erkennen, wenn ein Vorschlag öffentlichem Code stark ähnelt, und blockieren ihn entweder oder weisen die Quelle aus. Schalten Sie das ein. Das ist mit Abstand die wirksamste Einzelmaßnahme.
• Bevorzugen Sie Tools mit IP-Freistellung. Manche Enterprise-Anbieter stellen Kunden vertraglich von Schutzrechtsansprüchen Dritter frei, die aus den Vorschlägen ihres Tools entstehen, bei den dafür qualifizierten Plänen und aktiviertem Duplikatsfilter. Das verlagert einen spürbaren Teil des Risikos und sollte bei der Tool-Auswahl mit ins Gewicht fallen.
• Lassen Sie eine Lizenzprüfung in der CI laufen. Software Composition Analysis und Lizenz-Scanner fangen bekannte Problemmuster ab und markieren Lizenz-Header, egal, ob der Code von einem Menschen oder einem Modell stammt.
• Bei großen, wortgleichen Blöcken ist besondere Vorsicht geboten. Eine komplett am Stück generierte Funktion verdient mehr Prüfung als eine zeilenweise Vervollständigung, die der Autor selbst geformt hat.

Ausgehend: gehört Ihnen die Ausgabe wirklich

Die zweite Frage ist, ob der KI-generierte Code sauber Ihnen gehört. Dahinter stecken zwei Punkte.

Erstens ist das Urheberrecht an rein KI-generierten Werken ungeklärt. In manchen Rechtsräumen, so auch nach den aktuellen Leitlinien des US Copyright Office, gilt, dass ohne ausreichenden menschlichen Schöpfungsanteil erzeugtes Material möglicherweise gar nicht urheberrechtlich schutzfähig ist. In der Praxis steht Code mit echter menschlicher Steuerung, Bearbeitung und Einbindung auf deutlich sichererem Boden als am Stück und unangetastet übernommener Code. Ein weiterer Grund, warum der Autor jede Änderung verstehen und mitgestalten sollte, statt sie nur durchzuwinken.

Zweitens: Prüfen Sie die Nutzungsbedingungen des Tools selbst. Seriöse Anbieter von Coding-Tools übertragen das Eigentum an der Ausgabe an den Nutzer und beanspruchen keine Rechte am generierten Code, doch das ist eine Klausel, die man pro Tool und Plan nachsehen und nicht einfach voraussetzen sollte. Wenn Sie später das Unternehmen verkaufen oder einen Kundenvertrag mit IP-Gewährleistungen unterschreiben, ist genau das der Punkt, den die Due Diligence unter die Lupe nimmt.

Die Herkunft ist genau das, was die KI weggenommen hat

Tritt man einen Schritt zurück, wird der Kern des Problems sichtbar. In der klassischen Entwicklung ist die Herkunft von Haus aus mitgeliefert: Jede Abhängigkeit ist deklariert, jede Lizenz steht in einem Manifest, jeder Commit hat einen Autor. Sie wissen, woher Ihr Code kommt.

KI-vorgeschlagener Code trifft ohne all das ein. Die Herkunft, also die Kette, woher ein Stück Logik stammt und unter welchen Bedingungen, ist genau das, was das Modell wegschneidet. IP-Risiken zu beherrschen heißt im Kern, diese Herkunftsdisziplin wieder einzuführen.

• Weisen Sie KI-Unterstützung in Ihrem Prozess aus, damit erkennbar ist, welche Arbeit stark KI-getrieben war und vielleicht eine genauere Herkunftsprüfung verdient.
• Halten Sie die Abhängigkeitshygiene streng. Modelle schlagen mitunter vor, ein Paket hinzuzunehmen; dieses Paket bringt seine eigene Lizenz und sein eigenes Lieferkettenrisiko mit, zu bewerten wie jede andere Abhängigkeit auch.
• Pflegen Sie Ihr Lizenz-Inventar. Legen Sie fest, welche Lizenzen in Ihrer Codebasis in Ordnung sind und welche nicht, damit die Prüfung eine Richtlinie hat, gegen die sie durchsetzen kann.

Verankern Sie es in Richtlinie und Tooling, nicht im Gedächtnis

Nichts davon funktioniert als etwas, woran Entwickler mitten in der Arbeit denken sollen. Es funktioniert nur, wenn es fest in den Weg eingebaut ist.

• Freigegebene Tools haben den Duplikatsfilter an, auf Organisationsebene gesetzt, damit ihn niemand klammheimlich abschalten kann.
• Die Lizenzprüfung läuft in der CI und blockiert Merges, die eine unzulässige Lizenz einbringen.
• Die [KI-Nutzungsrichtlinie](/blog/how-to-write-an-ai-usage-policy) hält die Regel fest: welche Lizenzen akzeptabel sind, dass große wortgleiche Blöcke zusätzlich geprüft werden und dass KI-Unterstützung ausgewiesen wird.

So wird aus einer diffusen juristischen Sorge eine Handvoll erzwungener Voreinstellungen, und nur in dieser Form überlebt diese Kontrolle den Kontakt mit einem Liefertermin.

Unsere Sicht

Das Open-Source-Lizenzrisiko durch KI-Coding-Tools ist real, aber handhabbar, und es lässt sich ganz überwiegend über Tooling lösen statt über Wachsamkeit. Das Kontaminationsrisiko ballt sich bei der wortgleichen Reproduktion von Trainingsdaten, und Enterprise-Duplikatsfilter plus Lizenzprüfung in der CI fangen das meiste davon ab. Die Eigentumsfrage ist tatsächlich ungeklärt, und genau das ist der Grund, einen echten menschlichen Schöpfungsanteil im Workflow zu halten und die Bedingungen Ihres Anbieters zu verifizieren.

Worauf es eigentlich ankommt: Die KI hat die Herkunft stillschweigend aus Ihrer Codebasis entfernt. Die Teams, die IP-Risiken gut handhaben, sind die, die sie bewusst wieder hinzufügen, über Filter, Scanner und eine schriftliche Richtlinie, damit die Frage „Woher stammt dieser Code?“ schon beantwortet ist, bevor sie jemand in einer Zeugenvernehmung stellen muss.

• US Copyright Office, Copyright and Artificial Intelligence, Leitlinien zur menschlichen Urheberschaft, abgerufen am 2026-06-10
• Free Software Foundation, GNU General Public License und Copyleft-Pflichten, abgerufen am 2026-06-10
• OWASP, OWASP Top 10 for Large Language Model Applications, zu unsicherer Ausgabe und Herkunft, abgerufen am 2026-06-10
• Linux Foundation / SPDX, Lizenzidentifikation und SBOM-Praxis, abgerufen am 2026-06-10