# GitHub-Code in einem kommerziellen Produkt: Lizenzen und was du prüfen solltest > Permissive Lizenzen wie MIT, Apache und BSD, Copyleft-Lizenzen wie GPL/AGPL, das Fehlen einer LICENSE-Datei und die Prüfung der Herkunft von durch KI hinzugefügtem Code. Source: https://ailoot.ai/blog/de/github-code-commercial-licenses/ Canonical: https://ailoot.ai/blog/de/github-code-commercial-licenses/ Language: de Publisher: Ailoot (https://ailoot.ai/) Translation: guide-177 Revision: sha256-3adaa7c5b8da1a97b6abdaefc2d7e734967855eef1f3d394c70656d0f7774e04 Du entwickelst ein Produkt und findest auf GitHub etwas Fertiges: eine Bibliothek, eine Vorlage, ein ganzes Projekt, das genau das tut, was du brauchst. Claude schlägt vor, es in dein Projekt aufzunehmen. Und dann hältst du inne: Der Code scheint öffentlich verfügbar zu sein, aber darfst du ihn tatsächlich verwenden, geschweige denn ein Produkt verkaufen, das ihn enthält? Könnte der Autor später gegen dich vorgehen? Ich gehe der Reihe nach vor: warum offener Code auf GitHub nicht automatisch eine Erlaubnis ist, welche Lizenzen die Nutzung von Code und den Verkauf eines Produkts erlauben, welche Copyleft-Bedingungen entsprechenden Quellcode eines erfassten Werks verlangen können, und wie du eine Lizenz in einer Minute prüfst, bevor du den Code verwendest. Kein „das kommt auf die Situation an“. [Praktische Informationen zur Arbeit mit Ailoot findest du in der Dokumentation](https://ailoot.ai/docs/).
Achtung Dieses Material dient der Orientierung; ich bin kein Anwalt. Im Folgenden beschreibe ich die Bedingungen gängiger Lizenzen und Regeln mit Links zu Primärquellen. Prüfe deine konkrete Situation jedoch anhand des Lizenztexts und bei einem großen kommerziellen Produkt zusätzlich mit einem Anwalt. Du triffst die Entscheidung selbst.
## Stimmt es, dass man Code kostenlos verwenden darf, wenn er auf GitHub steht?
Das Wichtigste Nein. Dass Code angesehen werden kann, bedeutet nicht, dass du ihn in deiner eigenen Arbeit verwenden darfst. Standardmäßig ist jeder Code urheberrechtlich geschützt, und du darfst ihn nicht verwenden, sofern der Autor nicht ausdrücklich eine Erlaubnis erteilt hat. Die Veröffentlichung auf GitHub erlaubt anderen für sich genommen nur, das Repository anzusehen und innerhalb von GitHub eine Kopie davon zu erstellen. Das Recht, den Code in dein Produkt aufzunehmen, ergibt sich aus der Lizenz, die der Autor dem Repository beigefügt hat. GitHub selbst erteilt dieses Recht nicht.
Die größte Falle ist hier das Wort „offen“. Du kannst den Quellcode sehen und denkst deshalb, dass du ihn verwenden darfst, weil er nicht verborgen ist. Diese Schlussfolgerung ist falsch. „Zum Lesen offen“ und „zur Nutzung lizenziert“ sind zwei verschiedene Dinge. Standardmäßig ist jedes schöpferische Werk, einschließlich Code, ab dem Moment seiner Entstehung urheberrechtlich geschützt. Solange der Autor nicht ausdrücklich eine Erlaubnis erteilt, darfst du es nicht verwenden. So beschreibt GitHub es auf seiner eigenen Lizenz-Referenzseite.

Wenn du ein schöpferisches Werk erstellst (und Code ist ebenfalls ein schöpferisches Werk), ist es standardmäßig durch das ausschließliche Urheberrecht geschützt. Wenn du keine Lizenz beifügst, die etwas anderes besagt, kann niemand sonst dein Werk kopieren, verbreiten oder ändern, ohne eine Klage oder rechtliche Ansprüche zu riskieren.

— choosealicense.com (GitHub-Referenzprojekt), https://choosealicense.com/no-permission/
Die zweite Ebene ist GitHub selbst. Manche denken, dass sie durch die Zustimmung zu den GitHub-Regeln mit der Veröffentlichung des Codes auch den Code anderer von dort verwenden dürfen. Die Regeln sagen genau das Gegenteil. Indem der Autor ein Repository öffentlich macht, erlaubt er anderen lediglich, es anzusehen und zu forken – also innerhalb von GitHub selbst eine Kopie zu erstellen. Das berechtigt nicht dazu, den Code in der eigenen Arbeit zu verwenden.

Indem du ein Repository öffentlich machst, gewährst du anderen Nutzern eine nicht ausschließliche, weltweite Lizenz, deine Materialien über den Dienst und im Rahmen der GitHub-Funktionen zu nutzen, anzuzeigen und zu vervielfältigen (durch Forks). Zusätzliche Rechte kannst du durch das Beifügen einer Lizenz gewähren.

— GitHub-Nutzungsbedingungen, Abschnitt D, https://docs.github.com/en/site-policy/github-terms/github-terms-of-service
Die entscheidenden Worte stehen im letzten Satz: „im Rahmen der GitHub-Funktionen“ und „zusätzliche Rechte ergeben sich aus einer Lizenz“. Ein Fork bleibt innerhalb von GitHub. Sobald du den Code in deinem eigenen Produkt verwenden willst, geschweige denn ihn verkaufen möchtest, brauchst du eine separate Lizenz des Autors. Keine Lizenz, kein Recht – selbst wenn der Code offen vor dir liegt. ## Wovon hängt es ab, ob du den Code anderer verwenden darfst?
Das Wichtigste Es hängt von der Lizenzdatei im Repository ab, die meist LICENSE oder LICENSE.md heißt. Sie ist die Erlaubnis des Autors und legt fest, was du mit dem Code tun darfst und was nicht. Die Lizenz beantwortet drei Fragen: Darfst du den Code in einem kommerziellen Produkt verwenden? Darfst du ihn ändern? Musst du deinen eigenen Quellcode offenlegen oder darfst du ihn geschlossen halten? Verschiedene Lizenzen beantworten diese Fragen unterschiedlich. Daher solltest du zuerst diese Datei prüfen und erst danach den Code selbst öffnen.
Alles hängt von einer Datei ab. Ein ordentlich gepflegtes Repository enthält eine Lizenzdatei – meist LICENSE, manchmal LICENSE.md oder einen entsprechenden Hinweis direkt in der README. Sie ist die Erlaubnis des Autors und legt die Bedingungen fest, unter denen du den Code verwenden darfst. GitHub zeigt den Namen der Lizenz in der Seitenleiste der Repository-Seite meist schon an, bevor du die Datei selbst öffnest. Damit du dich nicht in der Rechtssprache verlierst, hilft es, die Lizenz anhand von drei Fragen zu deiner Situation zu lesen: 1. **Darfst du diesen Code in einem kommerziellen Produkt verwenden**, für das andere bezahlen? 2. **Darfst du den Code an deine Bedürfnisse anpassen**? 3. **Musst du danach den Quellcode deines Produkts offenlegen**, oder darfst du ihn geschlossen halten? Fast alle Unterschiede zwischen Lizenzen laufen auf unterschiedliche Antworten auf die dritte Frage hinaus. Auf die ersten beiden antworten gängige Open-Source-Lizenzen meist mit „ja“: verwenden, ändern, verkaufen. Doch daran, ob die Lizenz dich zwingt, deinen eigenen Code offenzulegen, scheitern viele. Als Nächstes gehen wir die wichtigsten Arten anhand dieser drei Fragen durch. ## Welche Lizenzen erlauben die Nutzung von Code und den Verkauf eines Produkts?
Das Wichtigste Am geeignetsten für ein kommerzielles Produkt sind permissive Lizenzen: MIT, Apache 2.0 und BSD. Sie erlauben fast alles: den Code zu verwenden und zu ändern, das Produkt zu verkaufen und den eigenen Quellcode geschlossen zu halten. Es gibt eine Verpflichtung: den Lizenztext und die Namensnennung beizubehalten. Apache 2.0 schützt außerdem vor Patentansprüchen und verlangt, geänderte Dateien zu kennzeichnen. Hat der Code eines anderen eine dieser Lizenzen, kannst du ihn sicher in einem kommerziellen Produkt verwenden.
Fangen wir mit der guten Nachricht an. Wenn du ein Produkt entwickelst, das du verkaufen willst, ist eine Gruppe von Lizenzen besonders geeignet: permissive Lizenzen. Es gibt mehrere davon, aber drei sind am weitesten verbreitet: MIT, Apache 2.0 und BSD. Alle drei beantworten die ersten beiden Fragen mit „ja“ und erlauben dir, deinen eigenen Quellcode geschlossen zu halten. Am weitesten verbreitet und am einfachsten ist MIT. Der Text passt in einen einzigen Absatz.

Hiermit wird jeder Person, die eine Kopie dieser Software erhält, kostenlos die Erlaubnis erteilt, sie uneingeschränkt zu verwenden, einschließlich der Rechte, sie zu nutzen, zu kopieren, zu ändern, zusammenzuführen, zu veröffentlichen, zu verbreiten, Unterlizenzen zu vergeben und Kopien zu verkaufen, sofern der obige Urheberrechtshinweis und dieser Erlaubnishinweis allen Kopien beigefügt werden.

— MIT-Lizenz, opensource.org, https://opensource.org/license/mit
Einfach gesagt erlaubt dir MIT, mit dem Code fast alles zu tun, einschließlich das Produkt zu verkaufen und deinen eigenen Quellcode geschlossen zu halten. Die einzige Verpflichtung besteht darin, den Lizenztext und die Namensnennung beizufügen. Babel, .NET und Rails beispielsweise werden unter MIT veröffentlicht; du hast also mit ziemlicher Sicherheit bereits Code unter dieser Lizenz verwendet. Apache 2.0 funktioniert ähnlich, ergänzt aber zwei wichtige Punkte. Erstens einen ausdrücklichen Schutz vor Patentansprüchen: Die Autoren des Codes versprechen, dich nicht wegen Patenten auf diesen Code zu verklagen. Zweitens einige weitere formale Nutzungsanforderungen.

Du darfst Kopien des Werks oder abgeleiteter Werke in jedem Medium vervielfältigen und verbreiten, mit oder ohne Änderungen, sofern du den Empfängern eine Kopie dieser Lizenz gibst, geänderte Dateien kennzeichnest, Urheberrechts- und Patenthinweise beibehältst und, falls vorhanden, eine lesbare Kopie der NOTICE-Datei beifügst.

— Apache-Lizenz 2.0, Abschnitt 4, https://www.apache.org/licenses/LICENSE-2.0
BSD (in den Versionen mit 2 und 3 Klauseln) ist im Wesentlichen mit MIT vergleichbar: verwenden, ändern, verkaufen und den Urheberrechtshinweis beibehalten. Ich habe alle drei in eine Tabelle gesetzt, damit du den Unterschied auf einen Blick siehst. | Lizenz | Produkt verkaufen | Quellcode geschlossen halten | Was du tun musst | Patentschutz | |----|----|----|----|----| | MIT | ja | ja | Urheberrechtshinweis und Lizenztext beibehalten | keine Klausel | | Apache 2.0 | ja | ja | Urheberrechtshinweis, NOTICE-Datei, Änderungen kennzeichnen | ja | | BSD (2 und 3 Klauseln) | ja | ja | Urheberrechtshinweis beibehalten | nein | So kannst du die Tabelle auf deinen Fall anwenden: Wenn der Code eines anderen MIT, Apache 2.0 oder BSD als Lizenz hat, kannst du beruhigt sein: Du darfst ihn in einem kommerziellen Produkt verwenden und ändern und deinen eigenen Quellcode geschlossen halten. Du musst lediglich darauf achten, die Lizenzdatei und die Namensnennung des übernommenen Teils nicht zu entfernen. ## Welche Quellcodepflichten gelten bei GPL und AGPL?
Das Wichtigste GPL und AGPL erlauben kommerzielle Nutzung. GPL-Quellcodepflichten entstehen bei Weitergabe eines erfassten Werks; gewöhnlicher Serverbetrieb ohne Übertragung einer Kopie ist nicht dieser Auslöser. AGPLv3 ergänzt ein Quellcodeangebot für Nutzer, die mit einer veränderten Version über ein Netzwerk interagieren. Bestimme das erfasste kombinierte Werk: Separate unabhängige Komponenten gehören nicht automatisch alle dazu.
Copyleft hält ein erfasstes Werk und seine Ableitungen bei Anwendung der jeweiligen Bedingungen unter derselben Lizenz. Bei GPLv3 erfordert die Weitergabe von Quell- oder Objektcodekopien eines erfassten beziehungsweise kombinierten abgeleiteten Werks die Einhaltung der Lizenz samt entsprechendem Quellcode. Das gilt nicht automatisch für jedes unabhängige Programm desselben Produkts oder Servers. Beim Webdienstbeispiel erfordert das Hosting einer GPL-Bibliothek auf deinem Server ohne Abgabe von Kopien an Nutzer allein keine Veröffentlichung des gesamten Dienstes. Die Verteilung einer erfassten kombinierten Anwendung an Kunden kann dagegen GPL-Pflichten auslösen. Prüfe Einbindung und Lizenz, bevor du den beizufügenden Quellcode bestimmst. Ein an Nutzer ausgelieferter Browserclient ist eine eigene Verteilungsfrage. AGPLv3 ergänzt eine Netzwerkbedingung: Änderst du das Programm und interagieren Nutzer entfernt mit dieser Version, muss sie diesen Nutzern deutlich ihren entsprechenden Quellcode anbieten. Das ist präziser als die Aussage, Hosting irgendeiner AGPL-Komponente öffne jeden unabhängigen Dienstteil. Prüfe bei einem proprietären Produkt erfasstes Werk, Verbindung der Komponenten, Verteilung von Kopien und gegebenenfalls AGPL-Netzwerkinteraktion. Wähle eine kompatible permissive Alternative oder hole separate Erlaubnis ein, falls du die jeweiligen Pflichten nicht erfüllen kannst. Kommerzielle Nutzung selbst ist erlaubt; entscheidend sind tatsächliche Lizenz und Einbindung. ## Was solltest du tun, wenn das Repository überhaupt keine Lizenzdatei enthält?
Das Wichtigste Ohne Lizenzdatei darfst du den Code nicht verwenden. Das bedeutet nicht „er ist kostenlos“: Im Gegenteil, ohne Lizenz bleibt der Code vollständig urheberrechtlich geschützt, und du hast kein Recht, ihn zu verwenden, zu kopieren oder zu ändern. Die Erlaubnis, ihn innerhalb von GitHub anzusehen und zu forken, hilft hier nicht – sie gibt dir nicht das Recht, den Code in dein Produkt aufzunehmen. Wenn du den Code wirklich brauchst, ist der einzig saubere Weg, den Autor anzuschreiben und um Erlaubnis zu bitten oder zu warten, bis er eine Lizenz hinzufügt.
Ein häufiger Fehler ist die Annahme, dass es keine Einschränkungen gibt und man den Code frei verwenden darf, wenn keine Lizenz vorhanden ist. Das Gegenteil ist der Fall. Keine Lizenz ist keine Erlaubnis; standardmäßig bedeutet es, dass keine Erlaubnis vorliegt. Der Code ohne Lizenz bleibt vollständig urheberrechtlich geschützt, und du darfst ihn nicht verwenden. Die Regel vom Anfang gilt weiterhin: Standardmäßig ist Code urheberrechtlich geschützt, und ohne ausdrückliche Erlaubnis darfst du ihn nicht kopieren, ändern oder verbreiten. Dass du ihn innerhalb von GitHub ansehen und forken kannst, überwindet diese Hürde nicht – dadurch erhältst du nicht das Recht, den Code in deinem eigenen Produkt zu verwenden. Was du praktisch tun kannst, wenn der Code keine Lizenz hat, du ihn aber wirklich brauchst: 1. **Schreibe dem Autor.** Frage direkt im Diskussionsbereich des Repositorys oder per E-Mail, ob du den Code verwenden darfst und unter welchen Bedingungen. Manchmal hat der Autor einfach vergessen, eine Lizenz hinzuzufügen, und ergänzt sie auf Nachfrage. 2. **Suche nach einem Ersatz.** Für fast jede Aufgabe gibt es ein zweites, drittes und zehntes ähnliches Repository – darunter findest du eines mit einer ordentlichen MIT- oder Apache-Lizenz. 3. **Verwende ihn nicht.** Wenn du keine Erlaubnis hast und es keinen Ersatz gibt, gehört der Code nicht dir, und du darfst ihn nicht in ein Produkt aufnehmen, das du verkaufen willst. Der Gedanke „Wer wird das schon herausfinden?“ endet oft schlecht, sobald das Produkt Geld verdient und Aufmerksamkeit erregt. ## Was ist, wenn Claude selbst fremden Code zum Projekt hinzugefügt hat?
Das Wichtigste Das ist ein eigener Fall, den du nicht mit dem direkten Kopieren eines Repositorys verwechseln solltest. Wenn du selbst Code aus einem bestimmten Repository übernimmst, musst du dessen Lizenz einhalten. Wenn Claude oder eine andere KI als Antwort auf deine Anfrage Code generiert, erstellt sie üblicherweise einen eigenen, für die Aufgabe zusammengesetzten Text und kopiert nicht die Datei eines anderen. Dann verschiebt sich die Frage auf die Rechte am generierten Code. Hat die KI jedoch erkennbar einen Teil des lizenzierten Codes eines anderen reproduziert, gelten die Lizenzbedingungen weiterhin. Es lohnt sich, die Herkunft in beiden Fällen zu prüfen.
Hier gibt es eine zweite Ebene, die leicht mit der ersten verwechselt wird. Es ist eine Sache, wenn du ein Repository aufrufst und eine Datei daraus kopierst: Dann bist du unmittelbar für alles oben zur Lizenz verantwortlich. Eine andere Sache ist es, wenn Claude auf eine Anfrage hin Code für dich schreibt. In gewöhnlichen Fällen erzeugt KI einen eigenen, für deine Aufgabe zusammengestellten Text und kopiert nicht die Datei eines anderen. Dann stellt sich eine andere Frage: Wem gehört der generierte Code, und darfst du ihn verkaufen? Das ist ein großes eigenes Thema, das ich in einem Artikel über die Rechte an von KI geschriebenem Code behandelt habe. Es gibt jedoch eine Ausnahme, die du im Hinterkopf behalten solltest. Manchmal erzeugt KI fast wortwörtlich einen erkennbaren Teil des Codes eines anderen – etwa eine ganze Funktion aus einer bekannten Bibliothek. In diesem Fall gilt weiterhin die Lizenz der Bibliothek, unabhängig davon, wer die Tasten gedrückt hat. Große fertige Blöcke, die Claude unverändert übernommen hat, solltest du daher genauso prüfen, als hättest du sie selbst kopiert. ## So prüfst du eine Lizenz, bevor du Code verwendest: die einzelnen Schritte
Das Wichtigste Gehe folgendermaßen vor: Öffne die Repository-Seite und prüfe den Lizenznamen in der Seitenleiste, öffne die LICENSE-Datei selbst, bestimme den Typ – permissiv (MIT, Apache, BSD) oder Copyleft (GPL, AGPL) –, vergleiche ihn mit deiner Situation und entscheide, ob du den Code verwendest oder nach einem Ersatz suchst. Gibt es überhaupt keine Lizenz, verwende den Code nicht. Die ganze Prüfung dauert ein paar Minuten und sollte stattfinden, bevor der Code in dein Projekt gelangt, nicht erst danach.
Fassen wir alles in einer kurzen Checkliste zusammen, mit der du jeden Code von Drittanbietern prüfst, bevor du ihn in dein Projekt aufnimmst. Gehe die Punkte von oben nach unten durch. 1. ### Finde den Lizenznamen auf der Repository-Seite Öffne das Repository auf GitHub. Der Lizenzname ist normalerweise in der rechten Spalte oder unter der Dateiliste zu sehen – zum Beispiel „MIT License“, „Apache-2.0“ oder „GPL-3.0“. Wenn dort nichts steht und es keine Lizenzdatei gibt, ist das bereits ein Warnsignal; prüfe es im letzten Schritt erneut. 2. ### Öffne die Lizenzdatei selbst Suche in der Dateiliste nach LICENSE, LICENSE.md oder COPYING und öffne die Datei. Stelle sicher, dass der Name mit dem in der Seitenleiste angezeigten übereinstimmt und dass die Lizenz für den Code gilt, den du verwendest, und nicht nur für einen separaten Teil des Repositorys. 3. ### Bestimme den Typ: permissiv oder Copyleft MIT, Apache 2.0 und BSD sind permissiv; du kannst den Code in einem geschlossenen kommerziellen Produkt verwenden. GPL und AGPL sind Copyleft. Prüfe erfasstes Werk, Verteilung und eine mögliche AGPL-Netzwerkbedingung vor der Bestimmung der Quellcodepflichten. Der Name allein legt nicht fest, welche unabhängigen Komponenten erfasst werden. 4. ### Vergleiche die Lizenz mit deiner Situation Beantworte drei Fragen: Verkaufst du das Produkt, änderst du den Code, und möchtest du den Quellcode geschlossen halten? MIT, Apache und BSD eignen sich für ein geschlossenes Produkt, das verkauft wird. Bestimme bei GPL und AGPL, für welches erfasste oder kombinierte Werk entsprechender Quellcode nötig wäre und wann die Pflicht ausgelöst wird. Prüfe, ob du diese Bedingungen erfüllen kannst. 5. ### Keine Lizenz bedeutet: nicht verwenden Wenn es keine Lizenzdatei gibt und die README nichts über eine Erlaubnis sagt, darfst du den Code nicht verwenden. Schreibe dem Autor und bitte um Erlaubnis oder suche ein gleichwertiges Projekt mit einer ordentlichen Lizenz. „Er ist öffentlich verfügbar“ ist keine Erlaubnis. Diese Prüfung wirkt mühsam – bis dein Produkt zum ersten Mal wächst, Geld verdient und jemand nach dem darin enthaltenen Code von Drittanbietern fragt. Zwei Minuten zu Beginn kosten weniger als ein späterer Streit. Was du anschließend mit deinem Produkt tun kannst, damit es nach dem Start nicht ins Stocken gerät, beschreibe ich gesondert: [Ich habe ein Produkt mit KI entwickelt – wie geht es weiter?](https://ailoot.ai/blog/de/ai-product-maintenance-after-launch/).
### Häufig gestellte Fragen Darf man ein Produkt verkaufen, das Code eines anderen von GitHub enthält? Ja, wenn der Code eine permissive Lizenz wie MIT, Apache 2.0 oder BSD hat. Diese erlauben dir, den Code in einem kommerziellen Produkt zu verwenden, das Produkt zu verkaufen und deinen eigenen Quellcode geschlossen zu halten. Du musst lediglich den Lizenztext und die Namensnennung beibehalten. Auch GPL und AGPL erlauben kommerzielle Nutzung. Quellcodepflichten hängen vom erfassten Werk und Verteilung beziehungsweise der geltenden AGPL-Netzwerkbedingung ab. Ohne Lizenzdatei darfst du den Code überhaupt nicht verwenden. Was bedeutet es, wenn ein GitHub-Repository keine Lizenz hat? Es bedeutet, dass du den Code nicht verwenden darfst. Keine Lizenz heißt standardmäßig keine Erlaubnis; es bedeutet nicht „kostenlos“. Der Code bleibt vollständig urheberrechtlich geschützt. Dass du das Repository innerhalb von GitHub ansehen und forken kannst, gibt dir nicht das Recht, den Code in deinem Produkt zu verwenden. Wenn du den Code brauchst, schreibe dem Autor und bitte um Erlaubnis oder suche nach einem gleichwertigen Projekt mit einer offenen Lizenz. Wie unterscheidet sich MIT von GPL für mein Produkt? MIT erlaubt dir, den Code zu verwenden und zu ändern, das Produkt zu verkaufen und deinen eigenen Quellcode geschlossen zu halten – die einzige Verpflichtung ist, den Lizenztext beizubehalten. GPL erlaubt ebenfalls kommerzielle Nutzung. Die Weitergabe eines erfassten kombinierten oder abgeleiteten Werks verlangt aber die Einhaltung von Pflichten zu entsprechendem Quellcode und gleicher Lizenz. Bloßes Hosting ohne Kopienübertragung ist anders; separate unabhängige Komponenten sind nicht automatisch erfasst. Muss ich etwas tun, wenn ich Code unter der MIT-Lizenz verwende? Ja, eine Kleinigkeit: Behalte den MIT-Lizenztext und die Namensnennung des Codes bei, den du in deinem Projekt verwendet hast. Üblicherweise ist das dieselbe LICENSE-Datei, die dem Original beigefügt ist. MIT verlangt nichts Weiteres – du kannst den Code ändern, das Produkt verkaufen und deinen Quellcode geschlossen halten. Was ist, wenn Claude selbst Code eines anderen hinzugefügt hat und nicht ich? Du solltest trotzdem die Herkunft prüfen. KI erzeugt üblicherweise einen eigenen Text für deine Aufgabe; dann geht es um die Rechte am generierten Code – ein eigenes Thema. Hat die KI jedoch fast wortwörtlich einen erkennbaren Teil des Codes eines anderen aus einer bekannten Bibliothek reproduziert, gilt weiterhin die Lizenz dieser Bibliothek. Prüfe große fertige Blöcke, die vollständig übernommen wurden, genauso wie eine eigene Kopie.
### Quellen - [choosealicense.com – GitHub-Referenzprojekt zur Auswahl einer Lizenz](https://choosealicense.com/) - [choosealicense.com – was es bedeutet, keine Lizenz zu haben](https://choosealicense.com/no-permission/) - [GitHub-Nutzungsbedingungen, Abschnitt D (Lizenzeinräumung an andere Nutzer)](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service) - [MIT-Lizenz (opensource.org)](https://opensource.org/license/mit) - [Apache-Lizenz 2.0 (apache.org)](https://www.apache.org/licenses/LICENSE-2.0) - [GNU General Public License v3.0 (gnu.org)](https://www.gnu.org/licenses/gpl-3.0.en.html) - [GNU Affero General Public License v3.0 (gnu.org)](https://www.gnu.org/licenses/agpl-3.0.en.html)
[Ailoot öffnen](https://ailoot.ai/). ## Fragen und Antworten ### Zwingt das Hosting einer GPL-Bibliothek zur Veröffentlichung meines ganzen Webdiensts? Hosting allein ohne Kopienweitergabe löst die GPL-Verteilungspflicht nicht aus. Verteilst du eine erfasste kombinierte oder abgeleitete Anwendung, können Quellcodepflichten für dieses Werk gelten. Unabhängige Komponenten sind nicht automatisch erfasst. ### Welche zusätzliche Bedingung bringt AGPLv3 für Webdienste? Ein verändertes AGPL-Programm mit entfernter Netzwerkinteraktion muss diesen Nutzern seinen entsprechenden Quellcode anbieten. Prüfe erfasstes Programm und Integration, statt entweder gar keine Quellcodepflicht oder die Öffnung jedes unabhängigen Diensts anzunehmen. ## Ailoot · Das Unternehmen und sein Projektportfolio Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle. Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe. Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.