Ist eine Source-Available-Lizenz quelloffen im Sinne des CRA?

Nein, sobald sie eines der vier genannten Rechte beschneidet. Verbreitete Source-Available-Modelle legen den Quellcode offen, untersagen aber die kommerzielle Weiterverteilung oder den Betrieb als Dienst. Damit fehlt die freie Weiterverteilbarkeit, die Artikel 3 Nummer 48 verlangt. Für Ihr Produkt hat das eine unmittelbare Folge: Weder das vereinfachte Verfahren nach Artikel 32 Absatz 5 noch eine künftige Sicherheitsbescheinigung nach Artikel 25 stehen Ihnen offen. An den Herstellerpflichten selbst ändert es nichts. Sie greifen, sobald Sie das Produkt im Rahmen einer Geschäftstätigkeit auf dem Markt bereitstellen. Der Monetarisierungsmaßstab des Erwägungsgrunds 18 hilft Ihnen dabei nicht: Er gilt nur für Software, die die Definition erfüllt.

Wir veröffentlichen eine freie Version und verkaufen daneben eine Enterprise-Edition. Was davon ist erfasst?

Die kostenpflichtige Edition in jedem Fall: Sie wird im Rahmen einer Geschäftstätigkeit bereitgestellt, und wer sie unter eigenem Namen oder eigener Marke vermarktet, ist dafür Hersteller mit allen Pflichten. Für die frei veröffentlichte Version kommt es nach Erwägungsgrund 18 darauf an, ob sie selbst von ihrem Hersteller zu Geld gemacht wird; wie eine daneben vertriebene bezahlte Edition auf diese Bewertung durchschlägt, sagt die Verordnung nicht. Auch die Leitlinien der Kommission nach Artikel 26 fehlen bislang. Wer beide Editionen aus demselben Repository baut, sollte damit rechnen, dass die Trennung im Zweifel nicht anerkannt wird.

Was tun wir, wenn ein Upstream-Projekt auf unsere Schwachstellenmeldung nicht reagiert?

Ihre Pflicht bleibt bestehen. Artikel 13 Absatz 6 verlangt zweierlei nebeneinander: die Meldung an die Person oder Einrichtung, die die Komponente wartet, und die Behebung der Schwachstelle in Ihrem Produkt. Bleibt die Reaktion aus, tragen Sie die Korrektur selbst, sei es als eigener Patch im Build, als Fork oder durch Austausch der Komponente. Die Meldung an das Projekt bleibt trotzdem geschuldet; halten Sie fest, wann und an wen Sie gemeldet haben.

Cyber Resilience Act

Freie und quelloffene Software

Legaldefinition Art. 3 Nr. 48 CRA

„eine Software, deren Quellcode offen geteilt wird und die im Rahmen einer kostenlosen Open-Source-Lizenz zur Verfügung gestellt wird, die alle Rechte vorsieht, um sie frei zugänglich, nutzbar, veränderbar und weiterverteilbar zu machen“

Verordnung (EU) 2024/2847, Art. 3 Nr. 48 CRA

Freie und quelloffene Software ist im Cyber Resilience Act (CRA) eigens definiert. Artikel 3 Nummer 48 stellt auf zwei Merkmale ab: Der Quellcode wird offen geteilt, und die Lizenz räumt alle Rechte ein, um die Software frei zugänglich, nutzbar, veränderbar und weiterverteilbar zu machen. Ob eine Lizenz von einer bestimmten Organisation anerkannt ist, spielt dabei keine Rolle. Der CRA verweist auf keine Lizenzliste.

Diese Definition entscheidet allerdings nicht darüber, ob die Verordnung anwendbar ist. Sie öffnet nur die Tür zu einigen Sonderregeln. Über den Anwendungsbereich entscheidet eine ganz andere Frage.

Nicht die Lizenz entscheidet, sondern die Geschäftstätigkeit

Der CRA gilt nach Artikel 2 Absatz 1 für Produkte mit digitalen Elementen, die auf dem Markt bereitgestellt werden und deren bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung eine Datenverbindung mit einem Gerät oder Netz einschließt. Die Bereitstellung auf dem Markt ist in Artikel 3 Nummer 22 als „entgeltliche oder unentgeltliche Abgabe […] zum Vertrieb oder zur Verwendung auf dem Unionsmarkt im Rahmen einer Geschäftstätigkeit“ definiert. Dass eine Software kostenlos abgegeben wird, hilft also nicht weiter, denn das Kriterium ist die Geschäftstätigkeit.

Erwägungsgrund 18 macht daraus einen praktikablen Maßstab: Maßgeblich ist, ob der Hersteller das Produkt zu Geld macht. Nicht monetarisierte quelloffene Software gilt nicht als im Rahmen einer Geschäftstätigkeit geliefert. Bei quelloffenen Komponenten, die zur Integration durch andere Hersteller bestimmt sind, liegt eine Bereitstellung auf dem Markt sogar nur dann vor, wenn die Komponente von ihrem ursprünglichen Hersteller monetarisiert wird.

Was ausdrücklich keine Geschäftstätigkeit begründet

Die Erwägungsgründe 18 und 20 zählen mehrere Umstände auf, die für sich genommen nicht ausreichen:

finanzielle Unterstützung eines quelloffenen Projekts durch Hersteller oder deren Beiträge zu dessen Entwicklung
das bloße Vorhandensein regelmäßiger Veröffentlichungen von Versionen
die Entwicklung durch eine gemeinnützige Organisation, sofern alle Einnahmen nach Abzug der Kosten gemeinnützigen Zielen dienen
das bloße Bereitstellen in offenen Archiven, über Paketverwaltungen oder auf Kollaborationsplattformen (deren Anbieter werden erst dann zum Händler, wenn sie die Software im Rahmen einer Geschäftstätigkeit liefern)

Ebenso wenig erfasst die Verordnung natürliche oder juristische Personen, die Quellcode zu einem quelloffenen Produkt beitragen, das nicht ihrer Verantwortung unterliegt. Wer einen Pull Request in ein fremdes Projekt einbringt, wird dadurch nicht für dessen Konformität verantwortlich.

Diese Klarstellungen stehen in den Erwägungsgründen, nicht im verfügenden Teil. Sie leiten die Auslegung an, haben aber keine eigene bindende Rechtswirkung und lösen deshalb keinen Grenzfall abschließend. Der Gesetzgeber hat das gesehen: Artikel 26 Absatz 2 Buchstabe a verpflichtet die Kommission, in ihren Leitlinien den Anwendungsbereich mit besonderem Schwerpunkt auf Datenfernverarbeitungslösungen und freier und quelloffener Software zu behandeln.

Wer quelloffene Komponenten einbaut, bleibt in der Pflicht

Die Freistellung des Projekts verlagert die Last auf den, der den Code verwendet. Artikel 13 Absatz 5 verlangt vom Hersteller die gebotene Sorgfalt bei der Integration von Komponenten Dritter. Das gilt ausdrücklich auch bei quelloffener Software, die nicht im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wurde. Erwägungsgrund 34 nennt als mögliche Maßnahmen unter anderem die Prüfung, ob eine Komponente regelmäßig Sicherheitsaktualisierungen erhält, den Abgleich mit der europäischen Schwachstellendatenbank und zusätzliche Sicherheitsprüfungen.

Artikel 13 Absatz 6 geht weiter: Stellt ein Hersteller eine Schwachstelle in einer integrierten Komponente fest, auch in einer quelloffenen, so meldet er sie der Person oder Einrichtung, die die Komponente herstellt oder wartet, und behebt sie. Hat er dafür eine Software- oder Hardware-Änderung entwickelt, teilt er den Code oder die einschlägigen Unterlagen dieser Stelle mit, gegebenenfalls in einem maschinenlesbaren Format. Der CRA verlangt also einen Rückfluss ins Projekt, nicht nur einen stillen Fix im eigenen Build.

Erleichterungen für quelloffene Produkte

Für Hersteller, die quelloffene Produkte selbst vermarkten, sieht der CRA zwei Entlastungen vor:

Artikel 32 Absatz 5 knüpft an die Produktklasse an: Anhang III listet die wichtigen Produkte auf, Anhang IV die kritischen. Fällt ein quelloffenes Produkt in eine der Kategorien des Anhangs III, darf sein Hersteller jedes der Verfahren des Artikels 32 Absatz 1 nutzen, einschließlich der internen Kontrolle nach Modul A. Bedingung ist, dass die technische Dokumentation zum Zeitpunkt des Inverkehrbringens öffentlich zugänglich gemacht wird. Das erspart die Einbindung eines Dritten, die für Klasse II sonst ausnahmslos vorgeschrieben ist und für Klasse I immer dann, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Schema für die Cybersicherheitszertifizierung nicht vollständig angewandt werden. Für die kritischen Produkte des Anhangs IV gilt die Erleichterung nicht.
Nach Artikel 25 kann die Kommission durch delegierten Rechtsakt freiwillige Programme zur Sicherheitsbescheinigung für quelloffene Software einführen. Erlassen ist bislang keines; wer darauf bauen will, hat derzeit nichts in der Hand.

Eine eigene Rolle: der Verwalter quelloffener Software

Artikel 24 schafft für den Verwalter quelloffener Software eine schlanke Sonderregelung. Gemeint sind nach Artikel 3 Nummer 14 juristische Personen, die die Entwicklung quelloffener, für kommerzielle Tätigkeiten bestimmter Produkte systematisch und nachhaltig unterstützen und deren Brauchbarkeit sicherstellen, ohne selbst Hersteller zu sein. Ihre Pflichten sind eng: eine überprüfbar dokumentierte Cybersicherheitsstrategie, Zusammenarbeit mit den Marktüberwachungsbehörden auf deren Verlangen und, soweit sie an der Entwicklung beteiligt sind, die Meldepflichten des Artikels 14 Absatz 1. Hinzu kommen Artikel 14 Absätze 3 und 8, soweit schwerwiegende Sicherheitsvorfälle die Netz- und Informationssysteme beeinträchtigen, die der Verwalter für die Entwicklung dieser Produkte bereitstellt. Geldbußen sind für sie ausgeschlossen: Artikel 64 Absatz 10 Buchstabe b nimmt Verwalter quelloffener Software bei jedem Verstoß gegen die Verordnung von den Bußgeldvorschriften der Absätze 3 bis 9 aus.

Die Verordnung gilt ab dem 11. Dezember 2027; die Meldepflichten des Artikels 14 greifen bereits ab dem 11. September 2026.

Fragen aus der Praxis

: Nein, sobald sie eines der vier genannten Rechte beschneidet. Verbreitete Source-Available-Modelle legen den Quellcode offen, untersagen aber die kommerzielle Weiterverteilung oder den Betrieb als Dienst. Damit fehlt die freie Weiterverteilbarkeit, die Artikel 3 Nummer 48 verlangt. Für Ihr Produkt hat das eine unmittelbare Folge: Weder das vereinfachte Verfahren nach Artikel 32 Absatz 5 noch eine künftige Sicherheitsbescheinigung nach Artikel 25 stehen Ihnen offen. An den Herstellerpflichten selbst ändert es nichts. Sie greifen, sobald Sie das Produkt im Rahmen einer Geschäftstätigkeit auf dem Markt bereitstellen. Der Monetarisierungsmaßstab des Erwägungsgrunds 18 hilft Ihnen dabei nicht: Er gilt nur für Software, die die Definition erfüllt.
: Die kostenpflichtige Edition in jedem Fall: Sie wird im Rahmen einer Geschäftstätigkeit bereitgestellt, und wer sie unter eigenem Namen oder eigener Marke vermarktet, ist dafür Hersteller mit allen Pflichten. Für die frei veröffentlichte Version kommt es nach Erwägungsgrund 18 darauf an, ob sie selbst von ihrem Hersteller zu Geld gemacht wird; wie eine daneben vertriebene bezahlte Edition auf diese Bewertung durchschlägt, sagt die Verordnung nicht. Auch die Leitlinien der Kommission nach Artikel 26 fehlen bislang. Wer beide Editionen aus demselben Repository baut, sollte damit rechnen, dass die Trennung im Zweifel nicht anerkannt wird.
: Ihre Pflicht bleibt bestehen. Artikel 13 Absatz 6 verlangt zweierlei nebeneinander: die Meldung an die Person oder Einrichtung, die die Komponente wartet, und die Behebung der Schwachstelle in Ihrem Produkt. Bleibt die Reaktion aus, tragen Sie die Korrektur selbst, sei es als eigener Patch im Build, als Fork oder durch Austausch der Komponente. Die Meldung an das Projekt bleibt trotzdem geschuldet; halten Sie fest, wann und an wen Sie gemeldet haben.

Dieses Glossar dient der Orientierung und ersetzt keine Rechtsberatung. Maßgeblich ist der Wortlaut der Verordnung (EU) 2024/2847.