Wann liegt ein „Deployment“ im Sinne von Open‑Source‑Lizenzen vor?

Wann liegt ein „Deployment“ im Sinne von Open‑Source‑Lizenzen vor?

Der Einsatz von Open‑Source‑Software (OSS) ist heute gelebte Praxis – in vielen Unternehmen bestehen moderne Softwareprodukte zu einem erheblichen Teil aus Open‑Source‑Komponenten. Mit der Nutzung gehen jedoch lizenzrechtliche Pflichten einher, deren Auslösung häufig missverstanden wird. Eine der zentralen Fragen lautet:

Wann liegt eine Offenlegung bzw. ein „Deployment“ vor, das Copyleft‑Pflichten – insbesondere die Pflicht zur Quellcodeoffenlegung – auslöst?

Dieser Beitrag gibt eine strukturierte Antwort aus rechtlicher Sicht.

1. „Deployment“ ist kein technischer, sondern ein lizenzrechtlicher Begriff

Weder die GPL noch andere Open‑Source‑Lizenzen verwenden durchgängig den Begriff „Deployment“. Maßgeblich sind vielmehr Begriffe wie:

• Verbreitung (distribution)
• Weitergabe (conveying)
• Zur‑Verfügung‑Stellen an Dritte

Entscheidend ist daher nicht, ob Software „live geht“, sondern wem sie zugänglich gemacht wird und unter welchen rechtlichen Bedingungen.

Open‑Source‑Lizenzen knüpfen ihre Pflichten regelmäßig nicht an die Nutzung, sondern an die Weitergabe der Software oder einer davon abgeleiteten Arbeit.

2. Reine interne Nutzung: grundsätzlich kein Deployment

Wird Open‑Source‑Software ausschließlich intern genutzt – etwa:

• durch Entwickler am eigenen Arbeitsplatz
• auf internen Servern
• für interne Prozesse ohne Zugang Dritter

liegt regelmäßig keine Verbreitung im lizenzrechtlichen Sinn vor.

Konsequenz:Copyleft‑Pflichten (zB Offenlegung des eigenen Quellcodes) werden nicht ausgelöst, solange die Software das Unternehmen nicht verlässt.

Achtung: Das gilt nur, solange keine dritte Rechtsperson Zugriff erhält.

3. Konzerninterne Weitergabe: rechtlich oft ein Deployment

Ein häufiger – und gefährlicher – Irrtum in der Praxis ist die Annahme, dass eine konzerninterne Weitergabe „intern“ und damit lizenzneutral sei.

Rechtliche Realität

• Jede juristische Person ist ein eigenständiger Rechtsträger
• Mutter‑, Tochter‑ und Schwestergesellschaften sind Dritte im lizenzrechtlichen Sinn
• Die Weitergabe von Software an eine andere Konzerngesellschaft ist daher eine Verbreitung

Damit gilt:

Auch eine konzerninterne Offenlegung kann ein Deployment im Sinne von Open‑Source‑Lizenzen darstellen und Copyleft‑Pflichten auslösen.

Diese Sichtweise entspricht der herrschenden Lehre zur Open‑Source‑Compliance und zur Reichweite des Copyleft‑Effekts.

4. Praktische Beispiele aus der Unternehmenspraxis

Beispiel 1: Shared Services

Eine Holding entwickelt ein internes Tool auf GPL‑Basis und stellt es den Tochtergesellschaften zur Verfügung.

➡ Ergebnis:Verbreitung an Dritte → Offenlegungspflicht des (abgeleiteten) Quellcodes.

Beispiel 2: Konzernweite Plattform

Eine Software wird zentral betrieben, Tochtergesellschaften greifen über eigene Benutzerkonten zu.

➡ Ergebnis:Je nach Ausgestaltung kann bereits die Zur‑Verfügung‑Stellung eine lizenzrelevante Weitergabe darstellen.

Beispiel 3: Entwicklertransfer

Ein Entwickler nimmt Code in eine andere Konzerngesellschaft mit.

➡ Ergebnis:Auch hier kann eine lizenzrechtliche Weitergabe vorliegen, wenn der Code dort eigenständig genutzt wird.

5. Besonderheit: AGPL und SaaS‑Modelle

Besonders strikt ist die GNU Affero General Public License (AGPL). Sie erweitert den Copyleft‑Effekt auf Fälle, in denen Software über ein Netzwerk genutzt wird.

Das bedeutet:

• Auch reines SaaS‑Deployment
• auch ohne klassische Softwareüberlassung
• auch konzernintern

kann eine Pflicht zur Quellcodeoffenlegung gegenüber den Nutzern auslösen.

6. Handlungsempfehlungen für die Praxis

Checkliste: Wann besteht erhöhtes Risiko?

• Einsatz von GPL‑ oder AGPL‑Komponenten
• Konzerninterne Softwarebereitstellung
• Shared‑Service‑Modelle
• Zentrale IT‑Plattformen
• SaaS‑ oder Cloud‑Architekturen

Empfohlene Maßnahmen:

• klare Open‑Source‑Policy
• Trennung nach Rechtsträgern, nicht nach Organisationseinheiten
• Lizenzprüfung vor konzerninterner Weitergabe
• Dokumentation der Open‑Source‑Komponenten (SBOM)
• Vermeidung „stiller“ Copyleft‑Infektionen

7. Fazit

Ein „Deployment“ im Sinne von Open‑Source‑Lizenzen liegt nicht erst beim Verkauf oder bei externer Vermarktung vor. Bereits die Weitergabe an eine andere Konzerngesellschaft kann ausreichen, um Offenlegungs‑ und Copyleft‑Pflichten auszulösen.

Gerade im Konzernumfeld ist daher ein juristisch präziser Blick auf Lizenztexte und Rechtsträgergrenzen unerlässlich.

‍