Cyber Resilience Act: Große Auswirkungen auf Open Source befürchtet
Eigentlich ist der Cyber Resilience Act (CRA) der EU dafür gedacht, die Sicherheit von Produkten der Hard- und Softwareindustrie zu verbessern. Doch prominente Vertreter der Open-Source-Community befürchten als Nebenwirkung schwere Folgen für quelloffene Software und fordern Änderungen an dem Richtlinienvorschlag.
Die erste Ankündigung, dass es einen CRA geben werde, kam im September 2021. Ein Jahr später der erste Entwurf . Zusammgefasst hat die Richtlinie vier Ziele: Hersteller sollen verpflichtet werden, die Sicherheit ihrer Produkte über die gesamte Lebensdauer zu verbessern, es soll einen kohärenten Rahmen geben, an dem sich die Einhaltung messen lässt, die digitale Sicherheit in den Produkten soll transparenter werden und schließlich soll die Richtlinie Kunden in die Lage versetzen, "Produkte mit digitaler Sicherheit zu nutzen" .
Ist die Folgenabschätzung unvollständig?
Die gute Nachricht ist, dass es eine Abschätzung der Folgen gibt, die aus der Einführung entstehen. "Für Softwareentwickler und Hardwarehersteller erhöht sich der direkte Erfüllungsaufwand für neue Cybersicherheitsanforderungen, Konformitätsbewertung, Dokumentations- und Meldepflichten" , heißt es in dem Entwurf.
Beziffert werden diese Kosten auch. 29 Milliarden Euro soll das die Wirtschaft und Behörden kosten. Der Nutzen wird jedoch um ein Vielfaches höher eingeschätzt: Zwischen 180 und 290 Milliarden sollen durch weniger Sicherheitsvorfälle gespart werden.
Doch was ist mit den Entwicklern von Open-Source-Software? Hier könnten Kosten entstehen, ohne dass etwas eingespart wird, einfach weil bei vielen Lizenzen eine Gewährleistung ausgeschlossen ist: Verwenden auf eigene Gefahr.
Ganz so ist das erst einmal nicht. So steht in Erwägungsgrund zehn (Seite 15) des Vorschlags(öffnet im neuen Fenster) "Um Innovation und Forschung nicht zu behindern, sollte kostenlose und quelloffene Software, die außerhalb einer gewerblichen Tätigkeit entwickelt oder bereitgestellt wird, nicht unter diese Verordnung fallen. Dies gilt insbesondere für Software, einschließlich ihres Quellcodes und modifizierter Versionen, die offen geteilt und frei zugänglich, nutzbar, modifizierbar und weiterverteilbar ist."
Die Betonung liegt auf kostenlos
Dass vielen in der Open-Source-Community diese Ausnahme nicht gefällt, liegt daran, was unter Erwägungsgrund zehn noch folgt: "Im Zusammenhang mit Software kann eine gewerbliche Tätigkeit nicht nur durch die Erhebung eines Preises für ein Produkt, sondern auch durch die Erhebung eines Preises für technische Supportleistungen, durch die Bereitstellung einer Softwareplattform, über die der Hersteller andere Dienstleistungen monetarisiert, oder durch die Nutzung personenbezogener Daten aus anderen Gründen als ausschließlich zur Verbesserung der Sicherheit, Kompatibilität oder Interoperabilität der Software gekennzeichnet sein."
Und da liegt das Problem. Dass Open-Source-Software kostenlos weitergegeben und verwendet werden darf, in manchen Fällen sogar wirklich frei ist, heißt nicht, dass sich um diese Software herum nicht Geld verdienen lässt. Und in dem Moment, in dem das passiert, greift die Open-Source-Ausnahme nicht mehr.
Mit anderen Worten bedeutet das: Wer Open-Source-Software kommerziell verwendet, indem sie Teil des Angebots ist oder sich das Angebot einfach nur auf die Software bezieht, ist dazu verpflichtet, die Vorgaben des CRA zu erfüllen.
Auch Open Source hat eine Lobby
Deshalb schrieb zum Beispiel Simon Phipps von der Open Source Initiative (OSI) als Feedback(öffnet im neuen Fenster) zu dem Entwurf, dass der Entwurf für ihn "ein interessanter und wichtiger Vorschlag" sei, er aber Mängel an der Formulierung des Erwägungsgrunds zehn sehe.
Er beginnt mit ein paar feinen Unterscheidungen zwischen den Worten "should" und "shall" , geht dann aber schnell dazu über, dass man doch lieber nicht nur vermeiden solle, "Innovation und Forschung" zu behindern, sondern dort stattdessen Open Source als das zu nennen, was man nicht behindern wolle.
Als drittes passt Phillips das Wort "commercial" nicht, er schlägt stattdessen "deployment for trade" (auf Deutsch etwa: Einsatz für den Handel) vor. Fügt man diese Änderungen zusammen, ergibt sich ein erster Teil des Erwägungsgrunds zehn, bei dem die Einschränkungen aus dem zweiten Teil kaum noch greifen.
Von ungefähr kommt das im Übrigen nicht. Die OSI wurde 1998 mit dem Ziel gegründet, den Begriff Open Source von dem freier Software komplett zu trennen. Doch Phipps ist nicht der Einzige aus der Open Source Community, der Bedenken äußert.
Auch die Eclipse Foundation hat Vorbehalte
Auch Eclipse-Foundation-Direktor Mike Milinkovich äußert sich im Blog der Stiftung(öffnet im neuen Fenster) kritisch. Er schreibt, er sei " zutiefst besorgt darüber, dass der CRA den Gesellschaftsvertrag, der dem gesamten Open-Source-Ökosystem zugrunde liegt, grundlegend ändern könnte: Open-Source-Software, die kostenlos für jeden Zweck zur Verfügung gestellt wird, die kostenlos modifiziert und weiterverbreitet werden kann, jedoch ohne Garantie oder Haftung gegenüber den Autoren, Mitwirkenden oder Open-Source-Distributoren. Es ist vernünftigerweise davon auszugehen, dass eine rechtliche Änderung dieser Regelung durch Rechtsvorschriften unbeabsichtigte Folgen für die Innovationswirtschaft in Europa haben wird."
Das klingt eher besorgt um die Strukturen, in denen Firmen, die Open-Source-Produkte kommerziell nutzen, ja zumindest in den meisten Fällen etwas an die Community zurückgeben, indem sie zum Beispiel für Entwicklungsarbeiten bezahlen, die dann auch in die Open-Source-Projekte fließen.
Doch im folgenden Abschnitt erweitert Milinkovich noch einmal die Dinge, um die er sich besonders sorgt. So fürchtet er den Aufwand, die der Eclipse Foundation für jedes ihrer Projekte entstehen würde. So würde es Pflicht, für jedes Projekt bei der Eclipse Foundation Richtlinien und Verfahren zu "entwickeln, dokumentieren und implementieren" , um sicherzustellen, "dass sie den Anforderungen des CRA entsprechen" .
Und dann müsse man noch "für jedes Projekt bestimmen, ob es der Definition 'Produkt mit digitalen Elementen', 'kritisches Produkt mit digitalen Elementen' oder 'sehr kritisches Produkt mit digitalen Elementen' entspricht."
Das lässt befürchten, dass Milinkovich vielleicht nicht genau genug gelesen haben könnte, denn die Projekte an sich sind erst einmal ausgenommen. Erst wenn für die aus einem Projekt stammende Software oder Dienste um die Software herum kommerzielle Aktivitäten stattfinden, sind die Vorgaben zu erfüllen – allerdings nicht für das Projekt selbst, sondern für die Firma mit den Aktivitäten.