Open-Source-Lizenz: 4 Fehler, die Sie vermeiden müssen

In aller Regel ja. Entweder liefern Sie den passenden Quellcode direkt mit oder Sie legen ein schriftliches Angebot bei, über das der Quellcode für einen festgelegten Zeitraum angefordert werden kann. Prüfen Sie, welche Variante Ihre Release‑Prozesse zuverlässig abdeckt, und dokumentieren Sie, wo der Code abrufbar ist.

Bei der AGPL kann die Pflicht zur Quellcode‑Bereitstellung auch dann greifen, wenn Nutzer nur über das Netz mit der Software arbeiten. Prüfen Sie Ihr Service‑Modell, bevor Sie AGPL‑Module einsetzen, und halten Sie eine eindeutige Strategie zur Code‑Bereitstellung bereit.

Nur, wenn sie kompatibel sind. Einige Lizenzen lassen sich problemlos kombinieren, andere schließen sich faktisch aus. Prüfen Sie die Lizenzkombinationen vorab und vermeiden Sie Konstruktionen, bei denen Pflichten nicht gleichzeitig erfüllbar sind.

Das hängt von der Lizenzversion ab. Bei der GPLv2 ist ein schriftliches Angebot möglich; bei anderen Varianten kann die gleichzeitige Bereitstellung verlangt sein. Entscheidend ist, dass die gewählte Option verlässlich funktioniert und dauerhaft auffindbar ist.

Nur, wenn die jeweilige Lizenz und Ihr Verteilmodell das erfordern. Oft genügt es, den Code über einen definierten Kanal bereitzustellen oder auf Anfrage zu liefern. Wichtig ist, dass die gewählte Lösung stabil, dokumentiert und für Empfänger leicht erreichbar ist.

Nein, nicht pauschal. Entscheidend ist, ob Ihr eigener Code als abgeleitetes Werk der Komponente gilt oder nur lose angebunden ist. Je enger die technische Verbindung, desto eher greifen Copyleft‑Pflichten. Saubere Schnittstellen und getrennte Prozesse senken das Risiko.

Bei Verstößen gegen zentrale Lizenzpflichten gilt die Nutzung als unberechtigt. Bei der GPLv3 gibt es allerdings eine Möglichkeit der Wiederherstellung, wenn Sie innerhalb kurzer Fristen vollständig nachbessern. Wichtig ist, schnell zu reagieren und den Nachweis der Abhilfe sauber zu führen.

Das Risiko landet oft beim Produktanbieter. Regeln Sie in Verträgen Pflichten zur Lizenz‑Compliance, Nachweispflichten (z. B. SBOM) und Mitwirkung bei Abhilfe. Führen Sie stichprobenartige Prüfungen durch, damit Verstöße nicht erst beim Kunden auffallen.

Regelmäßig verjähren Ansprüche nach drei Jahren ab Kenntnis. Für bestimmte Konstellationen kann ein Restschadensersatz länger durchsetzbar sein. Halten Sie deshalb Unterlagen und Nachweise so vor, dass Sie Sachverhalte auch Jahre später belegen können.

Nur eingeschränkt. Im B2B‑Bereich sollten Sie Verträge so gestalten, dass Verantwortlichkeiten, Updates, Sicherheitsfixes und Freistellungen klar geregelt sind. So vermeiden Sie Lücken, die in einem Streitfall zu Stillstand oder unnötigen Kosten führen könnten.

Grundsätzlich ja, solange Sie die jeweiligen Pflichten erfüllen. Bei permissiven Lizenzen geht es vor allem um Hinweise. Bei Copyleft‑Lizenzen müssen Sie je nach Verknüpfung mit eigenem Code zusätzliche Pflichten erfüllen. Eine kurze Architektur‑und Lizenzprüfung vor Release spart später Aufwand.

Bei reiner interner Nutzung ohne Weitergabe greifen viele Pflichten zur Verteilung nicht. Sobald Sie aber an Kunden liefern, Geräte mit Software ausgeben oder Dienste öffentlich bereitstellen, gelten die jeweiligen Lizenzanforderungen. Planen Sie den Wechsel von intern zu extern frühzeitig ein.

Sofort den Umfang klären, betroffene Versionen identifizieren, die Veröffentlichung stoppen und eine Abhilfestrategie festlegen (Quellcode bereitstellen, Hinweise ergänzen, Updates planen). Dokumentieren Sie jeden Schritt, informieren Sie nötigenfalls Kunden und prüfen Sie, ob eine Unterlassungserklärung sinnvoll ist.

Führen Sie eine aktuelle Komponentenliste (SBOM), speichern Sie Build‑Stände, Lizenztexte und Hinweise, und dokumentieren Sie, wann und wo der Quellcode zugänglich war. So können Sie Auskunftsansprüche zügig bedienen und interne wie externe Prüfungen bestehen.

Wenn Nutzer über das Netz mit einer AGPL‑Komponente interagieren, kann Quellcode‑Zugang erforderlich sein. Prüfen Sie, ob der betroffene Service isoliert werden kann oder ob eine alternative Komponente mit geringerem Pflichtenumfang verfügbar ist.

Regeln Sie OSS‑Einsatz, Verantwortlichkeiten, Update‑ und Sicherheitspflichten, Mitwirkung bei Abhilfe, Nachweise (SBOM) und Freistellungen. So vermeiden Sie Lücken zwischen Technik und Recht und können im Ernstfall schnell handeln.

Erstellen Sie eine vollständige SBOM, legen Sie Nachweise für Quellcode‑ und Hinweisbereitstellung bei, halten Sie Architekturentscheidungen fest und dokumentieren Sie Prozesse. Ein interner Vorab‑Audit und klare Verantwortlichkeiten beschleunigen spätere Prüfungen erheblich.