Zum Hauptinhalt springen

Irrtümer

Was Teams annehmen und was Lizenzen verlangen

Open Source wird oft als Erlaubnis zum Ausliefern behandelt. In der Praxis ist jede Bibliothek, Schriftart, jedes SDK oder Skript, das Sie bündeln, eine Lizenz mit Hinweis-, Namensnennungs- oder Copyleft-Regeln, die sich je nach Komponente unterscheiden.

Die Übersicht unten zeigt gängige Annahmen und die tatsächlichen Lizenzpflichten, bevor Kunden, Auditoren oder Käufer nachfragen.

Zuletzt aktualisiert: 2. Juli 2026

Open Source bedeutet nicht, dass es keine rechtlichen Pflichten gibt.

Es bedeutet, dass die Pflichten standardisiert, öffentlich und durchsetzbar sind, oft ohne dass irgendjemand im Team sie gelesen hat.

  • Annahme

    „Es ist Open Source. Wir können es ausliefern.“

    Realität

    Jede Komponente kommt mit Bedingungen. Freizügige Lizenzen verlangen trotzdem Copyright- und Lizenzhinweise bei der Weitergabe. Copyleft-Lizenzen können Quellcode-Angebote, Lizenz-Weitergabe und Verbreitungsanalyse verlangen. Keine Fußnote in einem Wiki.

  • Annahme

    „Wir sind SaaS, also gelten Lizenzen nicht für uns.“

    Realität

    Manche Pflichten sind bei reiner Netzwerknutzung leichter; viele nicht. GPL, LGPL, Apache-Namensnennung in Installern, Weiterverbreitung von Schriftarten und Asset-Namensnennung zählen weiterhin. Und Kunden fragen weiterhin, was Sie ausliefern und was Sie bündeln.

  • Annahme

    „Recht kümmert sich darum, wenn es wichtig ist.“

    Realität

    Recht kann nicht in geregelte Abläufe überführen, was das Entwicklungsteam nie erfasst hat. Paketlisten ändern sich mit jedem Sprint; Schriftarten, Icons und SDKs tauchen darin oft nie auf. Bis der Rechtsbeistand einbezogen wird, ist das Release bereits draußen.

  • Annahme

    „Wir haben eine LICENSE-Datei im Repository.“

    Realität

    Die Lizenz Ihres Repositorys ist Ihre eigene. Nicht die Ihrer Abhängigkeiten. Eine einzelne Namensnennungsdatei von vor drei Jahren beschreibt nicht, was Kunden heute herunterladen.

  • Annahme

    „npm update ist nur ein Patch, an der Compliance ändert sich nichts.“

    Realität

    Ein Versions-Update kann die geltende Lizenz ändern, Copyleft hinzufügen oder Pflichten komplett austauschen. Routineupdates sind einer der häufigsten Wege, wie Compliance ausgehebelt wird, ohne dass es jemand bemerkt.

Nächster Schritt

Wenn Sie vom Lesen zur Umsetzung übergehen möchten:

Leitfaden zum Prüf-Workflow

Cookies auf sourcetrust.dev

Wir verwenden essenzielle Cookies für die Sicherheit, einschließlich der Missbrauchsprävention bei unserem Website-Scan und dem Anfrageformular für Live-Demos. Mit Ihrer Einwilligung nutzen wir außerdem optionale Analyse und Diagnostik (Google Tag Manager auf dieser Website und das Sentry-Browser-SDK in der SourceTrust-Anwendung, sofern konfiguriert). Siehe unsere Cookie-Richtlinie.