Kaum eine Software-Codebase kommt 2026 noch ohne Open Source aus — und das ist ökonomisch sinnvoll. Was viele Unternehmen unterschätzen: Open Source ist gebührenfrei nutzbar, aber nicht bedingungslos. Wer die Lizenzbedingungen ignoriert, verliert das Nutzungsrecht und begeht eine Urheberrechtsverletzung wie bei jeder anderen unlizenzierten Software-Übernahme. In M&A-Transaktionen ist OSS-Compliance heute ein eigenständiger Audit-Workstream — wer ihn versemmelt, gefährdet den Deal.

Open Source = kostenfrei, nicht bedingungslos

Open-Source-Lizenzen sind privatrechtliche Verträge zwischen Rechteinhabern und Nutzern. Jede Lizenz stellt Bedingungen auf, die einzuhalten sind:

  • Nennung von Urheber und Lizenz — bei nahezu allen OSS-Lizenzen Pflicht
  • Mitlieferung des Lizenztextes — typischerweise als Beilage in der Distribution
  • Erhalt von Copyright-Hinweisen im Quellcode — wer den Code modifiziert, darf bestehende Urheberrechtsvermerke nicht entfernen
  • Bei Copyleft-Lizenzen zusätzlich: Offenlegung abgeleiteter Werke unter derselben Lizenz

Wer diese Bedingungen verletzt, verwendet die Software ohne Lizenz — und das ist eine Urheberrechtsverletzung im Sinne des UrhG, mit allen damit verbundenen Ansprüchen.

Permissive vs. Copyleft — der Unterschied im Alltag

Die wichtigste praktische Unterscheidung:

Permissive Lizenzen — etwa MIT, BSD, Apache 2.0:

  • Erlauben praktisch jede Nutzung, auch in proprietären Produkten
  • Pflicht meist nur: Lizenztext und Urheberhinweise mitliefern
  • Apache 2.0 zusätzlich: explizite Patentlizenz, Hinweispflicht bei Modifikationen
  • Geringes rechtliches Risiko, solange die Hinweispflichten eingehalten werden

Copyleft-Lizenzen — die zwei wichtigsten Familien:

  • GPL (GNU General Public License) — wer GPL-Code in seine Software einbindet und das Produkt vertreibt, muss den gesamten Quellcode unter GPL offenlegen
  • AGPL (GNU Affero GPL) — verlangt Offenlegung sogar dann, wenn die Software nur als Server-Dienst läuft (kein klassischer Vertrieb erforderlich) — kritisch für SaaS-Anbieter
  • LGPL — milderer Copyleft, erlaubt Linkung mit proprietärem Code unter bestimmten Bedingungen

Die Einordnung im konkreten Fall ist nicht trivial: Dynamisches vs. statisches Linken, Plug-In-Architekturen, Container, Microservice-Trennung — all das beeinflusst, ob ein „abgeleitetes Werk” vorliegt oder nicht.

Häufige Verstöße in der Praxis

Aus unserer Beratungspraxis und der internationalen OSS-Klagslandschaft lassen sich vier typische Konstellationen ableiten:

  • Fehlende Lizenz-Hinweise. Auch ein an sich permissiv lizenzierter Code (etwa eine MIT-lizenzierte JavaScript-Library) löst eine Urheberrechtsverletzung aus, wenn der Lizenztext und die Urhebernennung nicht mit dem Endprodukt ausgeliefert werden — typisch in mobilen Apps und in Docker-Images.
  • GPL-Code in proprietären Produkten. Wer GPL-lizenzierten Code in eine kommerziell vertriebene Software statisch einlinkt und die GPL-Pflichten nicht erfüllt, riskiert die Pflicht zur Offenlegung des eigenen Quellcodes.
  • AGPL und SaaS. Viele Cloud-/SaaS-Anbieter sind sich nicht bewusst, dass AGPL-Komponenten auch im Server-Betrieb die Offenlegungspflicht auslösen — anders als bei klassischer GPL.
  • Lizenz-Inkompatibilitäten. Bestimmte OSS-Lizenzen lassen sich rechtlich nicht miteinander kombinieren. Wer naheliegende, aber rechtlich unverträgliche Komponenten mischt, verstößt gegen mindestens eine der beiden Lizenzen.

M&A-Risiko: Was Käufer prüfen

In Software-M&A-Transaktionen ist OSS-Compliance heute ein eigenständiger Workstream der Due Diligence:

  • SBOM-Erstellung (Software Bill of Materials) mit automatisierten Scanner-Tools
  • Lizenz-Mapping — welche Lizenzen werden verwendet, in welcher Architektur-Position
  • Risiko-Bewertung — Copyleft-Pflichten, Lizenz-Inkompatibilitäten, fehlende Hinweise
  • Remediation-Plan — was muss vor Closing repariert werden, was kann post-Closing folgen

Findet ein Käufer nicht erkannte AGPL- oder GPL-Verwendung in einer kommerziellen Codebase, sind Kaufpreis-Reduktionen, Kaufpreis-Einbehalte oder im Extremfall ein Abbruch der Transaktion realistische Konsequenzen. Wer als Zielgesellschaft frühzeitig aufräumt, vermeidet Last-Minute-Streit am Verhandlungstisch.

Compliance aufbauen — pragmatischer 5-Punkte-Plan

Aus unserer Beratungspraxis empfehlen sich folgende Schritte:

  • Bestandsaufnahme — automatisiertes Scanning der bestehenden Codebase (ScanCode, FOSSology, Black Duck, FOSSA u. a.) zur Identifikation aller OSS-Komponenten und ihrer Lizenzen
  • Risiko-Triage — welche Lizenzen sind unkritisch, welche brauchen Aufmerksamkeit, welche sind im aktuellen Einsatz problematisch
  • Compliance-Hygiene — Lizenztexte mit Endprodukten ausliefern, Urhebernennungen sicherstellen, Distribution-Channels prüfen (auch App-Stores, Container-Images)
  • OSS-Policy — interne Richtlinie, welche Lizenzen für welche Verwendungsarten zugelassen sind und wer das vor Aufnahme einer neuen Komponente prüft
  • Continuous Compliance — SBOM-Generation in den CI/CD-Prozess einbinden, statt einmalige Großaktion alle paar Jahre

Unsere Rolle

Tonninger Schermaier & Partner berät Software-Unternehmen zur Open-Source-Compliance — von der präventiven Architektur-Beratung über M&A-Due-Diligence-Begleitung bis zur Verteidigung bei OSS-Verletzungs-Vorwürfen.

Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung im Einzelfall dar.