de
Support
Eine LICENSE-Datei im Repository reicht nicht: Copyright, Lizenz und Haftungsausschluss gehören in jede einzelne Quelldatei. Das forderte Dr. Johannes Loxen, Head of OSPO der SerNet, am 10.11.2026 auf der fünften DENIC Spark in Frankfurt am Main, der Mitarbeiterkonferenz der DENIC eG, die die .de-Domains verwaltet. Seine Beispiele kamen direkt aus der Arbeit von SerNet: von Samba, das unter Linux Windows-Dateidienste und Active Directory bereitstellt und das SerNet als SAMBA+ ausliefert, und von verinice, einer Open-Source-Plattform für Informationssicherheits-Management (ISMS), die SerNet seit 2006 entwickelt.
“Gerade weil alles frei ist, sind Lizenz-Regeln wichtig, damit die Software dauerhaft frei bleibt, die Haftungsfragen geklärt sind und man Ende nächsten Jahres 2027 mit dem CRA – Cyber Resilience Act – nicht in eine böse Falle tappt”, sagt Loxen.
Freie Software einsetzen und weitergeben
Der erste Teil seines Vortrags galt dem Einsatz freier Software im Unternehmen: wer über Download und Installation entscheidet, wie die Leitung Lieferkettenrisiken bewertet und warum NIS2 nicht nach der Lizenz fragt. Der zweite Teil richtete sich an Entwickelnde, die eigenen Code weitergeben. Eine Lizenz lässt sich schwer ändern, sobald andere beitragen. Samba wechselte 2007 dennoch auf die GPLv3, weil der Header “Version 2 oder später” erlaubte; verinice ging 2018 auf die AGPLv3.
Wie schwer ein Wechsel ist, hängt davon ab, wer in der Copyright-Zeile steht. Beim persönlichen Copyright, wie bei Samba und verinice, behält jede Person ihr Recht; ein Lizenzwechsel braucht dann die Zustimmung aller oder eine Lizenzklausel, die auch jede höhere Version der Lizenz zulässt (“or any later version”). Beim Firmen-Copyright kann das Unternehmen umlizenzieren oder dual lizenzieren. Ein Copyright Assignment überträgt dieses Recht per Vertrag auf den Arbeitgeber – juristisch sauber, in der Community unbeliebt.
Unabhängig vom Modell gilt Loxens Kernforderung: Header in jeder Datei halten die Lizenzinformation auch an einer herauskopierten Datei fest. Wie das aussieht, zeigt das Repository verinice-veo mit Headern sowie LICENSE, README, SECURITY und NOTICE. Für KI-generierten Code gilt dasselbe: Loxen zeigte eine Datei, die Claude in seinem Auftrag geschrieben hat, mit Projekt-Header und ihm in der Copyright-Zeile.
Die Lizenz legt außerdem fest, wer den Quellcode verlangen darf. Unter der GPL ist das, wer ein Binary bekommt; die AGPLv3, unter der verinice steht, dehnt den Anspruch auf alle aus, die die Software über ein Netzwerk nutzen. Eine Pflicht zur Veröffentlichung gibt es in beiden Fällen nicht.
Was der Cyber Resilience Act verlangt
Zu den Pflichten aus der Lizenz kommen inzwischen gesetzliche. Seit dem 11.09.2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle binnen 24 Stunden über die Meldeplattform der ENISA melden; ab dem 11.12.2027 gelten alle übrigen CRA-Pflichten einschließlich CE-Kennzeichnung. Hersteller ist, wer Open-Source-Komponenten in Produkte einbaut und diese vertreibt; reine Anwender verpflichtet der CRA nicht direkt. Open-Source-Stewards haben eine leichtere Rolle, nicht-kommerzielle Entwicklung ist ausgenommen.
Hier treffen CRA und Header aufeinander: Der CRA verlangt eine SBOM und einen Meldeweg für Schwachstellen, und belastbar wird die SBOM erst mit sauberen Lizenzangaben in jeder Datei. Prüfen lässt sich das mit REUSE, ScanCode oder ORT, als SBOM-Formate dienen SPDX und CycloneDX. Wie SerNet verinice darauf vorbereitet, lässt sich in den Folien nachvollziehen.
Folien und Kontakt
Die Vortragsfolien enthalten Quellen, Header-Beispiele und Werkzeuge für Lizenzprüfung und SBOM.
Fragen zu Open-Source-Lizenzen, SBOM und CRA beantwortet und diskutiert das Open Source Program Office (OSPO) der SerNet unter ospo@sernet.de oder telefonisch unter 0551 370000-0.
