Free and Open Source Software (FOSS) wird in der Softwareentwicklung massiv eingesetzt — dabei müssen jedoch auch für diesen kostenlosen Code Lizenzbedingungen eingehalten werden. Wir unterstützen Unternehmen bei der Vermeidung zivil- und strafrechtlicher Ansprüche aufgrund von Lizenz- und Urheberrechtsverletzungen.
Anleitung wirksamer Open-Source-Compliance-Prozesse — vom Kick-off über die Prozessgestaltung bis zur dauerhaften Verankerung in Entwicklungs- und Beschaffungsabläufen. Mit Blick auf Skalierbarkeit, Auditierbarkeit und die Realität Ihrer Engineering-Teams.
Bewertung der eingesetzten Open-Source-Lizenzen — von permissiven Modellen (MIT, BSD, Apache 2.0) über schwaches Copyleft (LGPL, MPL) bis zu striktem Copyleft (GPL, AGPL). Wir benennen die Risiken aus jeder Komponente, bevor sie zur Frage im Audit oder im Streitfall werden.
Sicherstellen eines technisch lizenzgerechten Einsatzes — Vermeidung ungewollter Copyleft-Pflichten, Auflösung von Lizenzinkompatibilitäten, Trennung von kombinierten Distributionen. Damit eine vergessene Klausel nicht die Forderung auslöst, das gesamte Produkt quelloffen zu machen.
Erstellung lizenzgerechter Produktmaterialien — Notice-Files, Attribution-Listen, Software Bill of Materials (SBOM) im SPDX- oder CycloneDX-Format, Source-Code-Disclosure-Pakete bei Copyleft-Komponenten. So dass jede Lieferung den Audit übersteht.
Eine vergessene Lizenzklausel
kann die Forderung nach
Quelloffenheit auslösen.
Die JUN Legal GmbH ist Partnerin des OpenChain-Project — der von der Linux Foundation getragenen Initiative, die mit ISO/IEC 5230:2020 einen internationalen Standard für die Open-Source-Compliance in Unternehmen geschaffen hat.
Wir unterstützen Unternehmen beim Aufbau OpenChain-konformer Strukturen, bei der Lückenanalyse gegen den Standard und bei der Vorbereitung einer Selbst- oder Drittzertifizierung — angefangen bei den sechs Kernanforderungen (Programm, Mitarbeiter:innen, Kompetenz, Materialien, Verifikation, Konformität).
Open-Source-Compliance ist nicht primär ein Rechts-, sondern ein Engineering-Problem. Das Recht muss dem folgen. Wir arbeiten direkt mit Ihren Entwickler-, DevOps- und Produktteams: bei der Auswahl von Komponenten, bei der Build-Pipeline-Integration und bei der Definition akzeptabler Lizenz-Stacks für jede Produktlinie.
Dazu richten wir teilautomatisierte Legal Checks ein — Lizenz-Scanner (FOSSology, ScanCode, ORT), SBOM-Generatoren und Policy-Engines, eingebunden in CI/CD-Pipelines. So werden Lizenzfragen erkannt, bevor sie zum Release-Blocker werden.
Schulungsformate für alle, die mit Open Source arbeiten: vom Lizenz-Grundlagen-Modul für gemischte Teams (Was ist Copyleft? Wann werde ich zum Distributor?) bis zur Vertiefung in Lizenz-Kombinationen, Patentklauseln und SBOM-Standards. Auch als Kick-off-Workshop am Beginn einer Compliance-Initiative.
Wenn LLM-Tools Open-Source-Code paraphrasiert in proprietäre Produkte einbauen, treffen zwei Rechtsfelder aufeinander — Open-Source-Lizenzrecht und Urheberrechtsfragen rund um KI-generierten Code. Mehr dazu in unserer Kompetenz KI & Legal Tech.
Aus der Mandatserfahrung in ein Standardwerk übersetzt: das Praxishandbuch zur Open-Source-Compliance, herausgegeben und verfasst von Christian Galetzka, Chan-jo Jun und Yvonne Roßmann — alle aus der JUN Legal GmbH. Erschienen in der Reihe „Kommunikation & Recht“ bei Fachmedien Recht und Wirtschaft (Frankfurt), 415 Seiten.
Bei Lizenzen, die der Open Source Definition entsprechen, ja: Sie erlauben die Nutzung zu jedem Zweck, auch dem gewerblichen. Vieles, was als Open Source bezeichnet wird, fällt aber nicht darunter. Creative-Commons-Lizenzen mit dem Zusatz NC gestatten nur die nicht kommerzielle Nutzung, auch im internen Einsatz. Andere Lizenzen untersagen einzelne Geschäftsmodelle, etwa das Angebot als Cloud-Dienst. Maßgeblich ist die Lizenz jeder einzelnen Komponente.
Nur bei einer Weitergabe der Software. Den Quellcode der GPL-Komponente müssen Sie dann mitliefern oder lizenzgemäß anbieten. Ihr eigener Code ist betroffen, wenn er mit der Komponente ein Gesamtwerk bildet, das auf ihr beruht: Dieses Werk dürfen Sie nur als Ganzes unter der GPL weitergeben. Von selbst quelloffen wird Ihr Code dadurch nicht. Die Abgrenzung hängt von der technischen Einbindung und von Ausnahmeklauseln der Lizenz ab.
Bei der GPL in der Regel nein: Wer die Software nur auf Servern betreibt und den Nutzer:innen keine Kopie überlässt, gibt sie nicht weiter. Anders ist es bei Code, den Sie als Anbieter an die Nutzer:innen ausliefern, etwa JavaScript: Das ist Ihre Weitergabe. Wer den Dienst nur nutzt, gibt nichts weiter. Strenger sind Lizenzen mit Netzwerkklausel: Unter der AGPL-3.0 müssen Sie den Quellcode einer veränderten Fassung allen Nutzer:innen kostenlos anbieten. Prüfen Sie deshalb jede Komponente auf Server und Client.
Am deutlichsten regelt das die GPL: Die Nutzungsrechte erlöschen, sobald Sie die Software entgegen den Lizenzbedingungen weitergeben. Rechteinhaber:innen können dann Unterlassung verlangen und im Eilverfahren durchsetzen, was einen Vertriebsstopp bedeuten kann. Hinzu kommen Abmahnkosten. Liefern Sie das Produkt an Kund:innen, kann darin zudem ein Rechtsmangel liegen, für den Sie nach Gewährleistungsrecht einstehen.
Für Produkte mit digitalen Elementen, die ab dem 11. Dezember 2027 in Verkehr gebracht werden, ja: Hersteller müssen eine maschinenlesbare SBOM erstellen, die mindestens die obersten Abhängigkeiten ausweist (Art. 71 Abs. 2, Anhang I Teil II Nr. 1 der Verordnung (EU) 2024/2847, Cyber Resilience Act). Eine Veröffentlichung verlangt die Verordnung nicht. Für die Lizenzprüfung reicht dieser Umfang nicht: Sie braucht alle Komponenten mit ihren Lizenzen, auch die indirekten Abhängigkeiten.
