Cyber Resilience Act : Der Cyber Resilience Act hat Open Source Software nicht verstanden

Als Branchenverbände der deutschen Digitalwirtschaft begrüßen wir den Vorstoß des Cyber Resilience Acts (CRA), denn unsere Mitglieder sehen sich als kommerzielle Anbieter in der Verantwortung, sichere Software anzubieten. Es ist auch in ihrem Interesse, die Qualität von digitalen Produkten zu gewährleisten, damit das Vertrauen in die Digitalisierung gestärkt wird.

Allerdings berücksichtigt der CRA die Besonderheiten des Open-Source-Ökosystems nicht ausreichend, dadurch drohen Rechtsunsicherheit und Überregulierung. Denn auch Einzelpersonen und Initiativen würden mit in die Haftung genommen und müssten Dokumentationspflichten erfüllen, die eigentlich nicht zur postulierten Zielgruppe des CRA gehören. Dies kann der Open-Source-Branche sowie der gesamten Wirtschaft Schaden zufügen.

Die Besonderheiten des Open-Source-Ökosystems

Der CRA wurde in erster Linie für proprietäre Software geschrieben. Die Entwicklungs- und Vertriebsmodelle von Open Source Software unterscheiden sich jedoch durch den offenen und kooperativen Ansatz sowie durch die Freiheiten, welche die Softwarelizenzen gewähren, zum Teil erheblich von denen proprietärer Software.

Open-Source-Lösungen werden teilweise im Rahmen einer kommerziellen Aktivität (durch bezahlte Angestellte einer Firma mit Gewinnerzielungsabsicht), im Rahmen von Wissenschaft und Lehre, durch die öffentliche Verwaltung und auch durch unzählige Freiwillige in Ihrer Freizeit, ohne eigenes kommerzielles Interesse entwickelt und gepflegt. Oft werden Open-Source-Lösungen auch im Rahmen einer Kooperation zwischen diesen verschiedenen Akteuren entwickelt, sodass sich eine klare Unterscheidung in „kommerzielle Aktivität“ und „nicht-kommerzielle Aktivität“ nicht immer eindeutig vornehmen lässt. Die Verflechtung von ehrenamtlichen und kommerziellen Akteuren macht das Open-Source-Ökosystem aus.

Die Open-Source-Ausnahme, die keine ist

Der CRA strebt eine Ausnahme für Open Source Software an, sofern diese keine kommerzielle Aktivität darstellt. Das Problem liegt jedoch in der Definition von „kommerziell“. Hier gelingt dem CRA keine eindeutige Abgrenzung, dadurch entstehen Unklarheiten, wodurch in der Folge Rechtsunsicherheit droht.

Zahlreiche ehrenamtliche Open-Source-Initiativen, Projekte aus Forschung und Lehre oder Einzelpersonen müssten am Ende die CRA-Anforderungen erfüllen, obwohl diese Akteure keine Ressourcen haben, um aufwändige Dokumentationspflichten zu erfüllen oder die langfristige Pflege für einmal veröffentlichten Code zu gewährleisten. In vielen weiteren Fällen führt die unklar formulierte Ausnahme im CRA und die daraus resultierende rechtliche Unsicherheit dazu, dass kleinere Open-Source-Projekte, die meist keinen professionellen Rechtsbeistand zur Verfügung haben, nicht sicher sein können, ob die Open-Source-Ausnahme für sie greift oder nicht.

Aus Vorsicht und um nicht leistbare Haftungsansprüche zu vermeiden, würden diese Projekte Abstand nehmen von Open-Source-Entwicklungen, von denen Wirtschaft, Wissenschaft und Verwaltung derzeit immens profitieren. Zudem könnten sich außereuropäische Open-Source-Anbieter vom europäischen Markt zurückziehen. So droht durch den CRA ein großer Schaden im gesamten Open-Source-Ökosystem. Da zahllose digitale Produkte und Lösungen auf Open-Source-Komponenten aufbauen, ist mit einem negativen Dominoeffekt für die gesamte Softwarebranche zu rechnen.

Wichtige Vorhaben der Bundesregierung sowie der EU setzen zur Stärkung der digitalen Souveränität maßgeblich auf Open Source Software. Auch diese Initiativen sind durch den CRA bedroht.

Konsequenzen in der Praxis

Einige Fallbeispiele illustrieren, wie sich die drohende Rechtsunsicherheit und Überregulierung in der Praxis auf Open-Source-Projekte auswirken würden.

Beispiel 1: Eine Entwicklerin ist bei einem Softwareunternehmen angestellt, nach der Arbeit engagiert sie sich aber auch ehrenamtlich in einem nicht gewinnorientierten Open-Source-Projekt. Dadurch, dass diese Entwicklerin hauptberuflich in einem Unternehmen angestellt ist, würde aber auch ihr ehrenamtliches Freizeit-Projekt unter den CRA fallen und müsste für seine nicht-kommerzielle Software hohe Anforderungen erfüllen. Das gibt der Gesetzestext derzeit so vor.

Beispiel 2: Eine Stiftung vertritt eine Open-Source-Community und unter ihrem Dach werden nicht-kommerziell und ehrenamtlich Standards und Software entwickelt. Die Arbeit der Stiftung kommt unterschiedlichsten Projekten und Unternehmen zugute. Ein Unternehmen möchte daher diese Arbeit finanziell unterstützen und spendet regelmäßig an die Stiftung. Nach der aktuellen Definition im CRA würde dadurch auch die Stiftung in den Anwendungsbereich des CRA fallen und müsste die Haftung für ehrenamtlich entwickelte Standards oder Software übernehmen, obwohl sie diese nicht mit einer Gewinnerzielungsabsicht zur Verfügung stellt.

Beispiel 3: Ein Open-Source-Forschungsprojekt an einer deutschen Universität wird mit EU-Mitteln gefördert, außerdem sind weitere internationale akademische Akteure und Partner aus der Wirtschaft beteiligt. Denn die Software, an der hier gearbeitet wird, ist so komplex, dass kein Akteur alleine die Weiterentwicklung vorantreiben könnte. Auch dieses Projekt würde voraussichtlich unter den CRA fallen und die bestehende Kollaboration der beteiligten Organisationen wäre damit gefährdet. Dies hätte weitreichende Konsequenzen für Forschung und Innovation in Deutschland und der EU.

Die Bundesregierung muss Open Source schützen

Der CRA darf Unternehmen, Einzelpersonen und Forschungseinrichtungen nicht mit Zusatzpflichten belegen, wenn sie lediglich Ideen, Quellcode, Texte oder Anleitungen zur freien Nutzung zur Verfügung stellen, aber damit keine Gewinne erzielen. In seiner aktuellen Form droht der CRA den freien Austausch von Ideen und damit die Innovationskraft unserer Gesellschaft massiv einzuschränken. Das würde uns in ein digitales Mittelalter zurückwerfen, in dem jede Form von Wissen potenziell geheim und nur wenigen Eingeweihten zugänglich ist.

Der CRA sollte nicht die (ehrenamtlichen) Ersteller:innen einer Open Source Software in die Pflicht nehmen, sondern die „In-Verkehr-Bringer“, die auf dem fertigen Produkt ein Geschäftsmodell aufbauen. Die klare Abgrenzung von nicht-kommerzieller Open Source Software schützt somit auch Innovation, Kollaboration und Wettbewerb in einer digital vernetzten Welt.

Die Bundesregierung muss sich daher bei den anstehenden Trilog-Verhandlungen in Brüssel dafür einsetzen, dass im CRA die Besonderheiten des Open-Source-Ökosystems berücksichtigt werden, damit die deutsche Wirtschaft und die digitale Souveränität keinen Schaden nehmen.

Simran Mann ist Referentin für Sicherheitspolitik beim Bitkom e. V. und Miriam Seyffarth leitet die politische Kommunikation bei der Open Source Business Alliance – Bundesverband für digitale Souveränität e. V.