Interview mit Rico Barth, Vorstandsmitglied OSBA
„Wir bekommen eine maximale Rechtsunsicherheit“
Mit dem Cyber Resilience Act verfolgt die Europäische Union das Ziel, Hardware wie auch Software sicherer zu machen. Zwar ist Open Source-Software auf den ersten Blick von dieser Regelung ausgenommen, auf den zweiten Blick könnten sich jedoch einige Unsicherheiten für die Community ergeben. Rico Barth, Vorstandsmitglied der Open Source Business Alliance, erklärt im Interview, welche das sind.
Herr Barth, im Juli hat die Open Source Business Alliance ein Statement zum europäischen Cyber Resilience Act (CRA) veröffentlicht, in dem Sie einige Passagen kritisch sehen. Wie blickt die Open Source Community allgemein auf die Regelungen des CRA?
Rico Barth: Grundsätzlich ist der Cyber Reslience Act eine wichtige Regulierung. Die Absicht, Software sicherer zu machen und von europäischer Seite Sicherheitsanforderungen in der Software-Produktionskette zu verankern, ist absolut zu begrüßen. Es ist wichtig, dass Software sozusagen ein CE-Kennzeichen erhält und wir als Verband stehen auch dahinter.
Dennoch befürchten Sie negative Auswirkungen auf die Open-Source-Landschaft, warum?
Die Problemlage ergibt sich aus einzelnen Formulierungen im aktuellen Entwurf des Cyber Resilience Acts. Insbesondere geht es um Formulierungen, in denen es um kommerzielle Interessen, bzw. die kommerziellen Aspekte von Open Source-Software geht. Diese Formulierungen sind derzeit sehr nachteilig für die Open Source-Industrie.
Was stört Sie daran?
Die Formulierung ist zu schwammig. Denn so kann der CRA zum einen für Organisationen gelten, die Open Source-Software herstellen, in einer Community entwickeln und Spenden bekommen – schon das kann einen kommerziellen Aspekt darstellen. Dieser kann aber auch gegeben sein, wenn eine Software auf Dienstleistungsbasis genutzt wird. Das heißt, ein Unternehmen ist gar nicht selbst Hersteller der Software oder Teil der Entwicklungs-Community, bietet aber Dienstleistungen auf Basis der Software an. Auch dann würde nach der jetzigen Lesart ein kommerzieller Aspekt greifen. Auf der anderen Seite haben wir natürlich Software, die von vielen freien Entwicklern, die beispielsweise in ihrer Freizeit zum Quellcode beitragen, entwickelt wird. Auch sie wären betroffen. Wenn die Formulierung so kommt, bekommen wir eine maximale Rechtsunsicherheit. Der Thin[gk]athon, veranstaltet vom Smart Systems Hub, vereint kollaborative Intelligenz und Industrie-Expertise, um in einem dreitägigen Hackathon innovative Lösungsansätze für komplexe Fragestellungen zu generieren. ‣ weiterlesen
Innovationstreiber Thin[gk]athon: Kollaborative Intelligenz trifft auf Industrie-Expertise
Was würde das für die Community bedeuten?
Das, was momentan aufgebaut wird, nämlich ein digital souveränes Europa mit eigenen Softwarelösungen, von europäischen Unternehmen entwickelt und durch europäische Organisationen auditiert, würden wir quasi wieder einreißen und somit den großen Software-Anbietern in die Hände spielen. Aber gerade diese Abhängigkeiten wollen wir ja auflösen. Der europäische Open Source-Software Markt ist sehr mittelständisch geprägt. Das heißt, die Beteiligten sind, bis auf wenige Ausnahmen, kleine bis mittelständische Softwareunternehmen, die mit der Regulierung überfordert wären. Daher fordern wir als Open Source Business Alliance, zusammen mit anderen Verbänden, dass die Definition der kommerziellen Nutzung konkreter gefasst wird.
Welche Pflichten bzw. Änderungen könnten konkret auf die Unternehmen bzw. Entwickler zukommen?
Die zwei wichtigsten Themen sind die Einführung einer Stückliste für Software, eine sogenannte Software Bill of Materials (SBOM), in der sämtliche Komponenten der Software aufgeführt sind, sowie Sicherheitsmaßnahmen in der Software-Lieferkette. Werden Sicherheitslücken bekannt, bin ich verpflichtet, diese selbst zu bewerten und entsprechende Maßnahmen zu treffen. Im Falle der SBOM gibt es aktuell Entwicklungen, mit denen sich diese automatisch erstellen lässt – das ist tatsächlich unproblematisch. Beim zweiten Aspekt muss ich mich um Sicherheitslücken, die bekannt geworden sind oder die ich selber finde, aktiv kümmern, diese bewerten, Risikomaßnahmen treffen, entsprechend beheben und dann regelmäßig Updates und Sicherheits-Patches liefern. Zwar muss man dies als Unternehmen ohnehin schon tun. Es muss jedoch eine Formulierung gefunden werden, damit nicht die breite Masse getroffen wird, die zwar mitentwickelt, aber keine Gewinnerzielungsabsichten hat.
Welche Auswirkungen hätte der CRA auf den Open Source-Einsatz in der Industrie?
Allgemein lässt sich sagen, dass kaum ein Produkt mehr ohne Open Source-Software vorstellbar ist. Und sei es nur eine kleine Open Source-Bibliothek, die irgendwo für die Verschlüsselung sorgt oder dafür, dass der Webserver richtig läuft. So ist in vielen Industrieanlagen Open Source-Software im Hintergrund verbaut. Beispielsweise wird auf vielen Embedded Systemen Linux eingesetzt.
Wie könnte eine geeignete Fassung aussehen?
Es gilt, diejenigen zu betrachten, die tatsächlich Open Source-Software in einem Distributionsmodell in Verkehr bringen. Und nicht diejenigen, die an irgendeiner Stelle in der Lieferkette eingebunden sind und dies vielleicht aus privaten Stücken tun. Daher wäre es aus unserer Sicht wichtig, dass eine klarere Abgrenzung formuliert wird, die das Inverkehrbringen mit Gewinnerzielungsabsicht in den Vordergrund stellt. Das betrifft dann die Unternehmen, die die Subscription- und Maintenance-Verträge für diese Software anbieten und damit Geld verdienen.
Können Sie uns da etwas zum aktuellen Stand sagen?
Tatsächlich nein. Es gibt mehrere Vorschläge, wobei der Vorschlag vom Europäischen Rat aus unserer Sicht wohl am besten ist. Dennoch ist da noch Luft nach oben. Es ist jedoch wichtig, dass darüber gesprochen wird. Wir, und auch andere Verbände, haben Vorschläge erarbeitet und müssen jetzt abwarten, Brüssel entscheidet. Und da die unterschiedlichen Verbände und Organisationen hier an einem Strang ziehen, ist es aus meiner Sicht unmöglich, dass das Europäische Parlament das übersieht.
