CRA und Open Source: Was gilt für Maintainer?

Kaum ein Thema hat die Open-Source-Community beim Cyber Resilience Act so intensiv beschäftigt wie diese Frage: Bin ich betroffen? Die gute Nachricht: Die Mehrheit der Hobby-Maintainer ist es nicht. Die schlechte: Die Grenze verläuft an einer anderen Stelle als viele denken — und wer sie falsch zieht, riskiert entweder unnötige Panik oder gefährliche Sorglosigkeit.

Dieser Artikel erklärt, wann die OSS-Ausnahme des CRA greift, wann sie es nicht tut, und was die neue Kategorie des “Open Source Software Steward” in der Praxis bedeutet.

Die Grundregel: Art. 16 CRA

Art. 16 CRA enthält eine explizite Ausnahme für Open-Source-Software. Der entscheidende Wortlaut (in der finalen Fassung):

Software gilt nicht als “in Verkehr gebracht” im Sinne des CRA, wenn sie im Rahmen einer “echten freien und quelloffenen Softwareentwicklung” entwickelt wird — also nicht-kommerziell, ohne dass der Entwickler wirtschaftliche Vorteile aus der Verbreitung zieht.

Die Ausnahme gilt für:

Hobby-Projekte ohne kommerzielle Intention
Community-Projekte, die ausschließlich durch freiwillige Beiträge entstehen
Akademische Forschungssoftware ohne Verwertungsabsicht

Was “nicht-kommerziell” bedeutet: Der CRA definiert es negativ. Kommerzielle Aktivität liegt vor, wenn der Entwickler oder eine Organisation, die das Projekt kontrolliert, wirtschaftliche Vorteile aus der Verbreitung zieht — durch Lizenzgebühren, Supportverträge, SaaS-Angebote auf Basis der Software, oder wenn das Projekt primär zur Förderung anderer kommerzieller Produkte entwickelt wird.

Was nicht ausschlaggebend ist: Ob der Quellcode öffentlich zugänglich ist. Ein Public Repository auf GitHub bedeutet keine automatische CRA-freie Zone. Entscheidend ist die Natur der dahinterstehenden Entwicklungsaktivität — nicht die Sichtbarkeit des Codes.

Die OSS-Steward-Kategorie: neues Konzept, neue Pflichten

Art. 16 Abs. 2 CRA führt eine neue Rechtskategorie ein: den Open Source Software Steward. Das ist eine juristische oder natürliche Person, die die Entwicklung eines OSS-Produkts “dauerhaft und systematisch unterstützt” — durch Infrastrukturbereitstellung, Governance, Koordination oder wirtschaftliche Förderung.

Konkret: Trägt eine Stiftung, ein Unternehmen oder eine formelle Organisation ein Open-Source-Projekt, ist diese Organisation ein OSS-Steward — mit eigenen CRA-Pflichten.

Betroffene Strukturen:

Die Linux Foundation als Steward für Linux-Kernel
Die Apache Software Foundation für Apache-Projekte
Unternehmen, die ein OSS-Projekt gründen und primär kontrollieren (z. B. HashiCorp für Terraform, vor der Lizenzänderung)
Gemeinnützige Vereine, die OSS-Projekte hosten und finanzieren

Pflichten des OSS-Stewards nach Art. 16 Abs. 2:

Sicherheitsrichtlinie: Eine dokumentierte Richtlinie für den Umgang mit Sicherheitsschwachstellen im Projekt
Coordinated Vulnerability Disclosure (CVD): Ein klar beschriebener Prozess, über den Sicherheitsforscher Schwachstellen melden können — in der Praxis eine SECURITY.md oder vergleichbares Dokument
Kooperation mit Marktüberwachungsbehörden auf Anfrage

Für große Stiftungen sind das keine trivialen Anforderungen. Viele gut organisierte Open-Source-Projekte erfüllen sie aber bereits heute — oder können es mit überschaubarem Aufwand.

Was OSS-Stewards nicht müssen: Sie sind keine Hersteller. Keine Konformitätserklärung, keine CE-Kennzeichnung, kein Notified Body. Die Pflichten sind leichter als die Herstellerpflichten — aber sie existieren.

Wann die Ausnahme nicht greift

Hier liegt das eigentliche Risiko für viele Entwickler und Unternehmen.

Szenario 1: Das Unternehmen baut auf OSS auf

Nehmen wir ein konkretes Bild: Ein Anbieter von Condition-Monitoring-Lösungen — typisches Industrie-4.0-Umfeld — baut seine Plattform auf einem OSS-Datenbroker auf, verkauft aber Wartungsverträge und bietet Cloud-Hosting an. Das OSS-Framework selbst fällt unter die Ausnahme (angenommen, es ist ein echtes Community-Projekt). Das kommerzielle Produkt aber ist ein “Produkt mit digitalen Elementen” im Sinne des CRA — und das Unternehmen ist der Hersteller.

Was das bedeutet: alle CRA-Pflichten, inklusive der Pflicht, die OSS-Abhängigkeiten in der SBOM zu führen und deren CVEs zu überwachen.

Die Ausnahme schützt den OSS-Maintainer, nicht den kommerziellen Nutzer seiner Software.

Szenario 2: Der “Community”-Maintainer verdient Geld

Stellen Sie sich vor: Ein Entwickler pflegt ein populäres NPM-Paket mit 500.000 wöchentlichen Downloads. Daneben bietet er bezahlte Support-Pakete an und monetarisiert über GitHub Sponsors — in einem Umfang, der über symbolische Anerkennung deutlich hinausgeht.

Hier beginnt es unscharf. Die CRA-Ausnahme ist für die Grauzone zwischen reiner Hobby-Entwicklung und vollständiger Kommerzialisierung nicht präzise kalibriert. Die europäische Gesetzgebungsgeschichte zeigt, dass der Gesetzgeber bewusst auf eine zu harte Linie verzichtet hat — unter anderem wegen massiver Kritik aus der Open-Source-Community. Die genaue Grenzziehung wird in den kommenden Jahren durch Behördenpraxis und Gerichtsurteile konkretisiert werden.

Vorsichtsregel: Wer aus einem OSS-Projekt direkte Einnahmen erzielt oder es primär zur Unterstützung eines kommerziellen Angebots entwickelt, sollte nicht reflexartig von der OSS-Ausnahme ausgehen.

Szenario 3: Dual Licensing

Veröffentlicht ein Unternehmen Software unter einer Open-Source-Lizenz (z. B. AGPL) und bietet daneben eine kommerzielle Lizenz für Unternehmen an, die keine AGPL-Pflichten eingehen wollen — dann greift die OSS-Ausnahme tendenziell nicht.

Das klassische Dual-Licensing-Modell (wie MariaDB, Elastic in früheren Versionen, oder unzählige weitere) fällt tendenziell unter den CRA. Das Unternehmen erzielt wirtschaftlichen Vorteil aus der Verbreitung der Software — nämlich die kommerziellen Lizenzkäufe. Es handelt als Hersteller, nicht als nicht-kommerzieller Community-Entwickler.

Was viele CRA-Berater nicht klar genug sagen: Die Open-Source-Ausnahme ist restriktiver als sie auf den ersten Blick aussieht. Der CRA hat nicht vor, Hobby-Projekte zu regulieren — aber er hat sehr wohl vor, kommerzielle Trittbrettfahrer der OSS-Ausnahme zu erwischen.

Szenario 4: Das Public Repository auf GitHub

Viele Entwickler denken: “Mein Code ist auf GitHub, also ist er Open Source, also bin ich CRA-frei.”

Das ist falsch. Ein Public Repository ist kein Schutzschild. Entscheidend ist:

Liegt echte nicht-kommerzielle Absicht vor?
Wird das Produkt an Endnutzer “in Verkehr gebracht” — also aktiv vertrieben, verteilt oder bereitgestellt?

Wer seine proprietäre Software auf GitHub als “open source” veröffentlicht, aber weiterhin Lizenzen verkauft und Support-Verträge anbietet, ist CRA-pflichtig. Die Sichtbarkeit des Codes ändert daran nichts.

Was das für NPM/PyPI/Maven-Pakete bedeutet

Die große Sorge in der OSS-Community war: Müssen alle Paket-Maintainer plötzlich CRA-konform werden?

Die Antwort ist differenziert:

Für den Maintainer eines reinen Community-Pakets: Wahrscheinlich nein — wenn die Ausnahme des Art. 16 greift. Ein Maintainer, der ein NPM-Paket ohne kommerzielle Absicht entwickelt, ist kein Hersteller.

Für den Hersteller, der das Paket nutzt: Ja, aber indirekt. Wer ein Produkt mit digitalen Elementen in den Markt bringt, muss alle Abhängigkeiten in der SBOM führen — auch OSS-Pakete. Und er muss CVEs in diesen Paketen überwachen und reagieren.

In der Praxis erleben wir bereits heute: Hersteller von embedded-Software für Heizungssteuerungen oder industriellen MQTT-Gateways beginnen, ihre Dependency-Trees systematisch zu bereinigen — nicht weil der OSS-Maintainer CRA-pflichtig wäre, sondern weil der Hersteller es ist. Ein IoT-Startup, das Firmware für Gebäudeautomation liefert, kann sich “das Paket wird doch von tausenden genutzt” nicht als Argument leisten. Die Haftung liegt beim Hersteller des Endprodukts.

Das schafft einen indirekten Druck auf die OSS-Ökosysteme: Hersteller werden bevorzugt Pakete verwenden, die aktiv gepflegt werden, schnell auf CVEs reagieren und idealerweise selbst eine Sicherheitsrichtlinie haben. Schlecht gepflegte Pakete werden aus produktiven Dependency-Trees herausrotiert — nicht wegen CRA-Pflicht des Maintainers, sondern wegen Compliance-Anforderungen des Nutzers.

Praktische Empfehlungen für Maintainer

Wenn Sie ein reines Community-Projekt betreiben: Wahrscheinlich sind Sie nicht direkt CRA-pflichtig. Sinnvoll trotzdem: Eine SECURITY.md im Repository mit einem einfachen CVD-Prozess. Das kostet wenig und macht Ihr Projekt attraktiver für Hersteller, die CRA-Compliance nachweisen müssen.

Wenn Ihr Projekt von einer Organisation getragen wird: Prüfen Sie, ob Ihre Organisation als OSS-Steward gilt. Wenn ja: Sicherheitsrichtlinie und CVD-Prozess dokumentieren. Überschaubar — und sinnvoll.

Wenn Sie kommerzielle Dienste rund um OSS anbieten: Gehen Sie nicht automatisch von der Ausnahme aus. Dual-Licensing, SaaS-Angebote und Support-Verträge sind Risikoindikatoren — sprechen Sie mit einem auf IT-Recht spezialisierten Anwalt über Ihre konkrete Konstellation. Das klingt nach bürokratischem Aufwand. Ist es auch — aber ein CRA-Verstoß ist teurer.

Wenn Sie als Hersteller OSS-Pakete nutzen: Führen Sie alle Abhängigkeiten in Ihrer SBOM. Implementieren Sie CVE-Monitoring auch für OSS-Abhängigkeiten. “Das ist ja open source” ist keine Verteidigung — die Sicherheitspflicht liegt bei Ihnen als Hersteller des Endprodukts.

Die politische Vorgeschichte: warum die Ausnahme existiert

Als die CRA-Verhandlungen begannen, gab es massiven Widerstand aus der OSS-Community. Die Linux Foundation, die Eclipse Foundation und hunderte individuelle Entwickler machten geltend: Löst jede OSS-Komponente CRA-Pflichten aus, ist das gesamte OSS-Ökosystem in Europa nicht mehr zu betreiben.

Reagiert hat der Gesetzgeber — durch Art. 16, durch die OSS-Steward-Kategorie, und durch eine Auslegungshilfe in den Erwägungsgründen (ErwGr. 18–20), die klarstellt, dass nicht-kommerzielle Entwicklung explizit geschützt ist.

Das war kein Selbstläufer. Es war das Ergebnis intensiver Lobbyarbeit — und es zeigt, dass der CRA die OSS-Community nicht ignoriert, aber auch nicht vollständig befreit. Der Kompromiss ist klar: Hobby-Maintainer bleiben frei. Kommerzielle Strukturen, die OSS als Fassade nutzen, werden erfasst.

Fazit

Die CRA-OSS-Ausnahme schützt das, was sie schützen soll: echte, nicht-kommerzielle Community-Entwicklung. Kein Blankofreifahrtschein für jedes Projekt, das seinen Code öffentlich stellt.

Für die meisten Hobby-Maintainer ist das kein Problem. Für Unternehmen, die auf OSS aufbauen, ändert der CRA nichts an der grundlegenden Regel: Wer ein Produkt in den Markt bringt, ist für dessen Sicherheit verantwortlich — egal welche Lizenzen die verwendeten Komponenten haben.

Die wichtigste praktische Konsequenz für das OSS-Ökosystem: Eine gut gepflegte SECURITY.md, schnelle CVE-Reaktionszeiten und ein dokumentierter CVD-Prozess werden zur Standard-Erwartung an aktiv verwendete Pakete. Nicht wegen gesetzlicher Pflicht der Maintainer — sondern wegen Compliance-Anforderungen ihrer Nutzer.

Weiterführend: