Die Frage kommt in drei Formen, und der Cyber Resilience Act, Verordnung (EU) 2024/2847, beantwortet jede anders. Ein Maintainer, der eine Bibliothek auf GitHub veröffentlicht. Ein Unternehmen, dessen Produkt auf dieser Bibliothek aufbaut. Eine Stiftung, die die Bibliothek am Leben hält. Nur einer der drei ist Hersteller, und einer der anderen hat eine eigene Regelung.

Fall eins: Open-Source-Software, die nicht monetarisiert wird

Erwägungsgrund 18: „Nur freie und quelloffene Software, die auf dem Markt bereitgestellt und daher im Rahmen einer gewerblichen Tätigkeit zur Verbreitung oder Verwendung geliefert wird, sollte in den Anwendungsbereich dieser Verordnung fallen.“ Und genauer: „Die Bereitstellung von Produkten mit digitalen Elementen, die als freie und quelloffene Software gelten und von ihren Herstellern nicht monetarisiert werden, sollte nicht als gewerbliche Tätigkeit gelten.“

Erwägungsgrund 20 fügt hinzu, dass das Hosten in einem Repository, einem Paketmanager oder auf einer Kollaborationsplattform „für sich genommen nicht die Bereitstellung auf dem Markt darstellt“, und Erwägungsgrund 18, dass auch die Finanzierung der Entwicklung die Frage nicht entscheidet.

Eine Bibliothek, die unter einer offenen Lizenz veröffentlicht wird, ohne bezahlte Version, ohne daran gebundenen bezahlten Support oder eine gewerbliche Vereinbarung um ihre Lieferung, liegt also außerhalb der Herstellerpflichten. Ihr Autor hat keine CE-Kennzeichnung anzubringen, keine technische Dokumentation, keine Pflicht nach Artikel 14. Artikel 15 erlaubt die freiwillige Meldung von Schwachstellen; nichts verlangt sie.

Fall zwei: ein kommerzielles Produkt, gebaut auf Open-Source-Komponenten

Das Unternehmen, das diese Bibliothek in ein Produkt integriert, das es in Verkehr bringt, ist Hersteller dieses Produkts. Die Lizenz der Komponente ändert nichts. Anhang I gilt für das ganze Produkt, die SBOM führt die Komponente auf, und Artikel 13 Absatz 5 verlangt vom Hersteller Sorgfalt bei der Integration von Komponenten Dritter, einschließlich quelloffener, damit sie die Sicherheit des Produkts nicht beeinträchtigen.

Artikel 32 Absatz 5 gewährt eine Erleichterung: Ein freies und quelloffenes Produkt, das in eine Kategorie des Anhangs III fällt, darf weiterhin das Selbstbewertungsverfahren nutzen, sofern seine technische Dokumentation beim Inverkehrbringen öffentlich gemacht wird. Das gilt für Open-Source-Produkte, die selbst gewerblich in Verkehr gebracht werden, nicht für die Komponenten in einem proprietären.

Erwägungsgrund 21 sieht freiwillige Sicherheitsbescheinigungsprogramme für Open-Source-Komponenten vor, damit die Sorgfaltspflicht eines Herstellers sich auf etwas stützen kann. Eingerichtet ist noch keines.

Fall drei: der Verwalter quelloffener Software

Artikel 3 Nummer 14 definiert einen Verwalter als „eine juristische Person, die kein Hersteller ist und deren Zweck oder Ziel es ist, systematisch und nachhaltig die Entwicklung bestimmter Produkte mit digitalen Elementen zu unterstützen, die als freie und quelloffene Software gelten und für gewerbliche Tätigkeiten bestimmt sind, und die die Tragfähigkeit dieser Produkte sicherstellt“. Erwägungsgrund 19 nennt die Art: bestimmte Stiftungen und Einrichtungen, die freie und quelloffene Software in einem geschäftlichen Kontext entwickeln und veröffentlichen, einschließlich gemeinnütziger.

„Für gewerbliche Tätigkeiten bestimmt“ ist der Angelpunkt. Erwägungsgrund 19 sagt, das schließt die Integration in kommerzielle Dienste oder monetarisierte Produkte ein, und dass die Absicht besteht, wo Hersteller, die die Komponente integrieren, regelmäßig zu ihrer Entwicklung beitragen oder sie regelmäßig finanzieren. Eine Stiftung, deren Projekt branchenweit in kommerziellen Produkten steckt, ist Verwalter. Ein Hobbyprojekt ohne solche Beziehung ist es nicht.

Artikel 24 gibt Verwaltern eine Regelung, die die Verordnung selbst als leicht bezeichnet:

Eine Cybersicherheitsrichtlinie, nachprüfbar dokumentiert (Artikel 24 Absatz 1), die sichere Entwicklung und wirksame Schwachstellenbehandlung durch die Entwickler des Projekts fördert, einschließlich Dokumentation, Behandlung und Behebung von Schwachstellen, Austausch von Informationen über entdeckte Schwachstellen in der Community und Förderung der freiwilligen Meldung nach Artikel 15.

Zusammenarbeit mit Marktüberwachungsbehörden auf deren Verlangen (Artikel 24 Absatz 2), und Vorlage dieser Richtlinie bei einer Behörde auf begründetes Verlangen.

Ein eingeschränkter Artikel 14. Artikel 24 Absatz 3: Die Pflicht, aktiv ausgenutzte Schwachstellen zu melden, gilt für Verwalter, „soweit sie an der Entwicklung“ des Produkts beteiligt sind; die Pflicht, schwerwiegende Vorfälle zu melden und Nutzer zu informieren, gilt, „soweit schwerwiegende Vorfälle ... Netz- und Informationssysteme betreffen, die die Verwalter quelloffener Software für die Entwicklung solcher Produkte bereitstellen“. Die Uhren sind dieselben 24 und 72 Stunden, an dasselbe CSIRT und die ENISA.

Was ein Verwalter nicht hat: Pflichten nach Anhang I für das Produkt, eine technische Dokumentation, eine Konformitätsbewertung, eine CE-Kennzeichnung, eine Konformitätserklärung, einen Unterstützungszeitraum. Artikel 24 ist das Ganze. Und Artikel 64 Absatz 10 Buchstabe b sagt, die Bußgelder des Artikels 64 „gelten nicht für“ Verstöße von Verwaltern quelloffener Software gegen die Verordnung; die übrigen Abhilfemaßnahmen einer Marktüberwachungsbehörde bleiben.

Was zu entscheiden und aufzuschreiben ist

Welcher Fall Sie sind. Wenn Sie Open Source veröffentlichen und nichts darum monetarisieren, schreiben Sie das auf, mit Datum, denn „nicht monetarisiert“ ist eine Tatsache über Ihr Geschäft, die sich ändern kann. Wenn Sie ein Produkt auf Open-Source-Komponenten ausliefern, sind Sie in Fall zwei, und die zwölf Schritte gelten vollständig. Wenn Sie ein Projekt tragen, von dem kommerzielle Produkte abhängen, sind Sie Verwalter: Schreiben Sie die Richtlinie nach Artikel 24 Absatz 1, benennen Sie die Person, die einer Behörde antwortet, und entscheiden Sie, wie Sie von einer aktiv ausgenutzten Schwachstelle im Projekt erfahren und sie melden würden.

Die Leitlinien der Kommission vom 27. Juli 2026 machen aus den zwei Erwägungsgründen sieben Tests mit 22 durchgerechneten Beispielen: Wo ein Spendenlink, eine bezahlte Supportstufe, eine Open-Core-Edition und eine Stiftung jeweils landen, ist der Begleitartikel zu diesem.

Quellen

  • Verordnung (EU) 2024/2847, Artikel 3 Nummer 14 (zitiert), Artikel 13 Absatz 5, Artikel 15, Artikel 24 Absätze 1 bis 3 (zitiert), Artikel 32 Absatz 5, Artikel 64 Absatz 10 Buchstabe b; Erwägungsgründe 17 bis 21 (zitiert). Gelesen im Amtsblatt-Text auf EUR-Lex am 11. September 2026.

Das ist keine Rechtsberatung. Die Erwägungsgründe sind der Ort, an dem die Open-Source-Linie gezogen wird, und sie sind oben zitiert, damit Sie sie lesen können, statt unsere Lesart zu übernehmen.