Die neue EU Funkgeräterichtlinie verstehen: Was sie für FOSS und SBOMs bedeutet

Die Funkgeräterichtlinie ,,Radio Equipment Directive” (RED)¹, offiziell bekannt als Richtlinie 2014/53/EU, ist der Rechtsrahmen der Europäischen Union für die Regulierung von Geräten, die über Funkwellen kommunizieren. Ihr Hauptziel ist es, sicherzustellen, dass Funkgeräte, die auf den EU-Markt gebracht werden, sicher sind, andere Geräte nicht stören und das Funkfrequenzspektrum effizient nutzen. Die RED gilt für eine Vielzahl von elektronischen Geräten, die drahtlose Kommunikation nutzen, darunter Smartphones, Laptops, WLAN-Router, Wearables und Smart-Home-Geräte. Grundsätzlich gilt: Wenn ein Gerät Funksignale wie Bluetooth, WLAN, mobile Daten oder GPS sendet oder empfängt, fällt es wahrscheinlich unter diese Richtlinie. Ein weiteres wichtiges Ziel der RED ist es, sicherzustellen, dass konforme Geräte im gesamten EU-Binnenmarkt frei gehandelt werden können.²

Am 1. August 2025 trat die Durchführungsverordnung (EU) 2022/30 zur Funkgeräterichtlinie in Kraft, die Herstellern von funkfähigen Produkten neue Cybersicherheitsverpflichtungen auferlegt. Parallel dazu hat die EU die Arbeit an einer weiteren wichtigen Bestimmung derselben Richtlinie wieder aufgenommen. Artikel 3 Absatz 3 Buchstabe i, der bald dazu führen könnte, dass Hersteller Software auf den Endgeräten strenger kontrollieren müssen. Zusammen werfen diese Entwicklungen komplexe rechtliche und technische Fragen zur Integration von freier und quelloffener Software (FOSS) in den europäischen Gerätemarkt auf.

Softwarefreiheit und Tivoisierung verstehen

Freie und Open Source Software (FOSS) wird nicht nur durch den Zugang zum Quellcode definiert, sondern durch vier wesentliche Freiheiten:³

Freiheit 0 – Die Freiheit, das Programm nach Belieben und für jeden Zweck auszuführen.
Freiheit 1 – Die Freiheit, die Funktionsweise des Programms zu studieren und es zu ändern.
Freiheit 2 – Die Freiheit, Kopien weiterzugeben.
Freiheit 3 – Die Freiheit, modifizierte Versionen zu verbreiten.

Diese Freiheiten gewährleisten, dass Nutzer die Kontrolle über die von ihnen verwendete Software haben, nicht nur in der Theorie, sondern auch in praktischer und technischer Hinsicht.⁴ Diese Freiheiten können jedoch durch technische Barrieren untergraben werden, beispielsweise wenn Nutzer daran gehindert werden, modifizierte Software auf ihren Geräten zu installieren.

Um den Kontext zu verstehen, ist es hilfreich, einen Blick in die Vergangenheit zu werfen. Die Geschichte der „Tivoisierung“ reicht bis in die frühen 2000er Jahre zurück, als TiVo, ein US-amerikanischer Hersteller von digitalen Videorekordern, seine Geräte auf Basis des Linux-Kernels entwickelte. TiVo hielt sich zwar an die GPLv2-Lizenz, indem es den Quellcode veröffentlichte, sperrte seine Geräte jedoch so, dass die Nutzer keine modifizierten Versionen der Software installieren konnten. Diese Einschränkung auf Hardware-Ebene führte zur Prägung des Begriffs „Tivoisierung“ und löste eine philosophische und rechtliche Debatte darüber aus, was es bedeutet, Softwarefreiheit wirklich zu respektieren.⁵

Als Reaktion darauf führte die Free Software Foundation im Jahr 2007 die GPLv3-Lizenz ein.⁶ Diese Version enthielt eine wichtige neue Klausel mit dem Titel „Installationsinformationen“, die sich auf alle Methoden, Verfahren, Autorisierungsschlüssel oder sonstigen Informationen bezieht, die erforderlich sind, um modifizierte Versionen des betreffenden Werks in diesem Benutzerprodukt aus einer modifizierten Version seines entsprechenden Quellcodes zu installieren und auszuführen.

Diese Klausel bedeutet, dass Hersteller den Benutzern die erforderlichen Informationen, wie Schlüssel oder Verfahren, zur Verfügung stellen müssen, um modifizierte Versionen der Software auf dem Gerät zu installieren und auszuführen, damit die Benutzer nicht technisch daran gehindert werden, ihre Freiheit zur Änderung und Neuinstallation des Programms auszuüben. Damit sollte eine Lücke geschlossen werden: Die Bereitstellung des Quellcodes allein reicht nicht aus, wenn die Benutzer technisch daran gehindert werden, ihr Recht auf Änderung und Neuinstallation dieses Codes auszuüben.

Artikel 3(3) (i) RED

Die Debatte um die „Tivoisierung“ flammt nun im Zusammenhang mit der RED wieder auf. Artikel 3 Absatz 3 Buchstabe i der RED sieht vor, dass bestimmte Kategorien von Funkgeräten so konstruiert sein müssen, dass nur konforme Software geladen werden kann. Dies würde wahrscheinlich Mechanismen wie Secure Boot oder kryptografische Signaturen erfordern, die Endnutzer daran hindern würden, modifizierte Firmware zu installieren, sofern diese nicht offiziell genehmigt wurde. Aus rechtlicher Sicht entsteht dadurch ein direkter Konflikt mit Lizenzen wie GPLv3, AGPLv3 und LGPLv3, die alle voraussetzen, dass Nutzer modifizierte Versionen der Software auf ihren eigenen Geräten installieren können.⁷ Wenn Artikel 3 Absatz 3 Buchstabe i in Kraft tritt, könnten Hersteller möglicherweise nicht mehr in der Lage sein, sowohl die RED als auch diese FOSS-Lizenzen einzuhalten. Die Free Software Foundation Europe (FSFE) warnt seit langem davor, dass Artikel 3 Absatz 3 Buchstabe i zu technischen Einschränkungen führen könnte, die die Freiheit der Nutzer und die Rechtmäßigkeit des Vertriebs von Geräten mit Copyleft-lizenzierter Software untergraben. Ihre Sorge ist, dass die Forderung, nur „konforme Software” installieren zu dürfen, dazu genutzt werden könnte, Bootloader-Sperren zu rechtfertigen, wodurch Nutzer effektiv daran gehindert würden, modifizierte Firmware auszuführen.⁸ Auch die Erwägungsgründe von RED offenbaren einen Konflikt zwischen Sicherheit und Software-Offenheit. Erwägungsgrund 16 rechtfertigt die Beschränkung des Ladens von Software, um die fortlaufende Einhaltung wesentlicher Anforderungen wie Sicherheit und Frequenznutzung zu gewährleisten. Erwägungsgrund 19 warnt jedoch davor, dass solche Beschränkungen nicht missbraucht werden dürfen, um Software von Drittanbietern zu blockieren oder unabhängige Entwickler auszuschließen.⁹

Derzeit ist Artikel 3 Absatz 3 Buchstabe i noch nicht in Kraft getreten. Er ist rechtlich Teil der RED, gilt jedoch für keine Produktklasse, bis die Europäische Kommission einen Rechtsakt verabschiedet, in dem festgelegt wird, welche Gerätekategorien dieser Anforderung unterliegen. Dieser Prozess wurde ursprünglich im Jahr 2021 aufgrund der Einführung des Cyber Resilience Act (CRA) ausgesetzt, der sich ebenfalls mit Softwaresicherheit und der Sicherheit digitaler Produkte befasst.¹⁰ Im Jahr 2023 nahm die Kommission jedoch die Arbeit an Artikel 3 Absatz 3 Buchstabe i wieder auf und schränkte dessen Anwendungsbereich ein, um sicherzustellen, dass Software-Updates die Einhaltung der Funkfrequenzvorschriften nicht beeinträchtigen.¹¹ Derzeit wird eine neue Bewertung durchgeführt, die voraussichtlich die Grundlage für das künftige Inkrafttreten der Bestimmung bilden wird. Die Kommission hat außerdem eine Aufforderung zur Einreichung von Belegen veröffentlicht, um die potenziellen Auswirkungen einer Aktivierung von Artikel 3 Absatz 3 Buchstabe i zu bewerten.¹² Insbesondere wurde in der dieser Initiative zugrunde liegenden Studie betont, wie wichtig es ist, Softwarekomponenten von Drittanbietern zu verfolgen und während des gesamten Software-Lebenszyklus Transparenz zu wahren.¹³ Das Konzept der Software-Stückliste (SBOM) wurde als wichtiger Mechanismus zur Verwaltung der Compliance und Risiken in softwaredefinierten Funksystemen hervorgehoben.

In seiner Stellungnahme zu dieser Aufforderung zur Einreichung von Belegen argumentierte Bitkom (der deutsche Verband der Digitalindustrie), dass die Hersteller bereits die Konformität der Software gemäß Artikel 3 Absatz 2 der RED sicherstellen, indem sie entweder die Installation nicht konformer Software technisch blockieren oder konforme Software in ihren Erklärungen und Benutzerdokumentationen ausdrücklich angeben.¹⁴ Daher halten sie zusätzliche Verpflichtungen gemäß Artikel 3 Absatz 3 Buchstabe i für überflüssig. Bitkom empfahl der Kommission, sich auf die Klarstellung bestehender Leitlinien zu konzentrieren, anstatt neue Vorschriften zu erlassen. Außerdem forderte Bitkom die Kommission auf, die Produktkategorien und den Umfang der „Software“, die von einer künftigen Aktivierung von Artikel 3 Absatz 3 Buchstabe i betroffen sind, klar zu definieren.

Der Fall „Bootloader Lockdown“: Von der EU in die USA

Im Juli 2025 entfernte Samsung die Option zum Entsperren des Bootloaders in One UI 8 für seine Geräte in mehreren Regionen, darunter auch in der EU.¹⁵ Obwohl das Unternehmen RED nicht offiziell genannt hat, hat der Zeitpunkt wenige Tage vor Inkrafttreten der RED-Cybersicherheitsbestimmungen Beobachter zu der Schlussfolgerung veranlasst, dass der Druck zur Einhaltung der RED-Vorschriften hinter dieser Entscheidung stehen könnte. Kritiker argumentieren, dass solche Maßnahmen, unabhängig davon, ob sie auf RED zurückzuführen sind oder nicht, der Innovation schaden, die Reparaturfähigkeit beeinträchtigen und die Kontrolle der Nutzer einschränken¹⁶. Andere Anbieter haben die Unterstützung für die Entsperrung des Bootloaders beibehalten, was zeigt, dass die Einhaltung der RED-Vorschriften auch ohne Einschränkung der Benutzerkontrolle möglich ist.

Dieser EU-Fall weist deutliche Parallelen zu den Vereinigten Staaten auf, wo Bootloader-Sperren bereits weit verbreitet sind und viele Smartphones, darunter auch Geräte von Samsung, die Nutzer daran hindern, modifizierte Betriebssysteme zu installieren.¹⁷ Das US-amerikanische Urheberrechtsgesetz (insbesondere DMCA Section 1201) erlaubt zwar Ausnahmen für das Jailbreaking und Rooting persönlicher Geräte, verpflichtet die Hersteller jedoch nicht dazu, das Entsperren zu vereinfachen, und erlaubt auch nicht die legale Verbreitung von Jailbreak-Tools.¹⁸ Diese Spannung zeigt sich am jüngsten Fall von Echelon, einem Hersteller von Fitnessgeräten, der ein Firmware-Update durchführte, um die Nutzung seiner Fahrräder und Laufbänder auf Abonnements über seine eigenen Server zu beschränken, wodurch zuvor funktionsfähige Geräte effektiv blockiert wurden, sofern die Nutzer nicht dafür bezahlen.¹⁹ Obwohl es einem Entwickler gelungen ist, die Fahrräder zu jailbreaken, um die Offline-Funktionalität wiederherzustellen, kann er die Lösung aufgrund von DMCA-Beschränkungen nicht legal weitergeben. Fälle wie dieser verdeutlichen auch in den USA eine wachsende Besorgnis: Die Nutzer mögen zwar Eigentümer ihrer Hardware sein, doch die Kontrolle über die Software verbleibt zunehmend beim Anbieter.²⁰ Ein weiteres Beispiel für diesen Konflikt ist der Fall John Deere. Wie die Software Freedom Conservancy (SFC) dokumentiert hat, hat das Unternehmen wiederholt gegen die GPL verstoßen, obwohl es in seinen landwirtschaftlichen Geräten Software mit Copyleft-Lizenz verwendet. Landwirte haben gemäß den Lizenzbedingungen einen gesetzlichen Anspruch auf den Quellcode und Build-Skripte, doch in der Praxis wird ihnen der Zugang verwehrt.²¹ Wie beim Bootloader-Lockup werfen diese Trends umfassendere Fragen zur Softwarefreiheit und zur Kontrolle der Nutzer über ihre eigenen Geräte auf.

REDs Cybersicherheitsbestimmungen und SBOM-Anforderungen

Während Artikel 3 Absatz 3 Buchstabe i noch weiterer Maßnahmen bedarf, ist ein anderer Teil der RED bereits in Kraft getreten. Mit dem Rechtsakt von 2022 wurden die Artikel 3 Absatz 3 Buchstaben d, e und f in Kraft gesetzt, mit denen verbindliche Anforderungen für den Netzwerkschutz, den Schutz personenbezogener Daten und die Betrugsbekämpfung in allen neuen funkfähigen Geräten eingeführt wurden.²² Diese Vorschriften gelten ab dem 1. August 2025 und wirken sich bereits jetzt auf die Software-Lieferkette aus. Diese Verpflichtungen werfen wichtige Fragen hinsichtlich der Einhaltung der Vorschriften auf. Hersteller müssen nun sicherstellen, dass Netzwerkstacks, Verschlüsselungsbibliotheken und Datenverarbeitungscodes den EU-Standards für Sicherheit und Datenschutz entsprechen. Code, der gestern noch funktional sicher war, kann heute bereits inakzeptable regulatorische Risiken bergen. In der Praxis wird die Einhaltung der RED-Artikel 3(3)(d), (e) und (f) durch die neu harmonisierten EN 18031-Normen umgesetzt, die konkrete technische Anforderungen für den Netzwerkschutz, die Datensicherheit und die Betrugsbekämpfung festlegen.²³ Insbesondere verlangt die Norm EN 18031 von den Herstellern, für jedes Gerät eine SBOM zu dokumentieren und zu pflegen, die sowohl Open-Source- als auch kommerzielle Komponenten umfasst. Diese Anforderung steht in direktem Zusammenhang mit dem Lebenszyklusmanagement von Software-Schwachstellen und sicheren Aktualisierungsmechanismen. Die SBOM ermöglicht Transparenz, Rückverfolgbarkeit und Konformitätsvalidierung, insbesondere im Zusammenhang mit der Offenlegung von Schwachstellen und Software-Wartungsverpflichtungen.

Was kann man tun?

Die kombinierten Auswirkungen der Entwicklungen im Bereich RED und CRA geben Anlass zur Sorge hinsichtlich der Integration von FOSS in vernetzte Geräten. Für Hersteller gehen die Risiken über potenzielle Lizenzverletzungen hinaus und umfassen auch Schwachstellen in der Cybersicherheit sowie rechtliche Unsicherheiten.

Eine Möglichkeit, wie sich Hersteller auf diese Herausforderungen vorbereiten können, ist die Pflege einer genauen und aktuellen Software-Stückliste (SBOM). Um Sicherheitsrisiken zu bewältigen und die Einhaltung gesetzlicher Vorschriften zu gewährleisten, müssen Hersteller einen vollständigen Überblick über die auf ihren Geräten ausgeführten Softwarekomponenten behalten. Dies ist entscheidend für die Identifizierung bekannter Schwachstellen, die Bewertung von Lizenzverpflichtungen und die Aufrechterhaltung des Vertrauens in die Lieferkette. SBOMs unterstützen dies, indem sie eine strukturierte Bestandsaufnahme aller Softwareelemente einschließlich Open-Source- und Drittanbieterkomponenten bereitstellen.

Sowohl RED- als auch CRA-Rahmenwerke stützen sich zunehmend auf SBOMs als grundlegenden Compliance-Mechanismus. Wie in der EU-Studie zu rekonfigurierbaren Funksystemen betont wird, wird von den Herstellern erwartet, dass sie Transparenz über alle Komponenten von Drittanbietern, von Entwicklungskits bis hin zu eingebetteter Firmware, wahren, um die Produktsicherheit und die Einhaltung der Vorschriften im Laufe der Zeit nachzuweisen.

Bei Bitsea unterstützen wir Unternehmen dabei, diese Komplexitäten zu bewältigen, indem wir detaillierte Code-Audits, Lizenzbewertungen und Software-Komponenten-Mapping durchführen und im Rahmen unseres Audit-Prozesses detaillierte SBOMs erstellen.

Timeline

29. April – 27. Mai 2025 – Die Europäische Kommission führt eine Aufforderung zur Einreichung von Beweismitteln zu Artikel 3 Absatz 3 Buchstabe i durch, um Rückmeldungen von Interessengruppen zu den Auswirkungen der Regulierung zu sammeln

1. August 2025 – Die Delegierte Verordnung (EU) 2022/30 tritt in Kraft. Alle neuen funkfähigen Geräte, die in der EU in Verkehr gebracht werden, müssen den Bestimmungen der Artikel 3 Absatz 3 Buchstaben d, e und f zur Cybersicherheit entsprechen.

Q2 2026 (geplant) – Die Kommission wird voraussichtlich einen delegierten Rechtsakt zu Artikel 3 Absatz 3 Buchstabe i verabschieden, in dem weitere Einzelheiten zu dieser Bestimmung festgelegt werden.

Quellen