Hinweis: Redaktionelle Auswertung amtlicher Quellen, keine Rechtsberatung.
Ein Patch macht noch keinen Hersteller. Eine freiwillige Spende ist noch kein Kaufpreis. Eine bezahlte Synapse-Installation macht Synapse noch nicht zum Produkt des Installateurs. Doch eine Stiftung, die Repository, Releases und Sicherheitsarbeit dauerhaft trägt, kann Open-Source-Software-Steward sein. Und wer Binärdateien, Updates oder wesentliche Funktionen nur gegen Geld herausgibt, kann als Hersteller gelten.
Die Europäische Kommission hat am 27. Juli 2026 den Inhalt eines 84-seitigen Leitlinienentwurfs zum Cyber Resilience Act gebilligt. Darin stehen 67 Beispiele, ein eigenes Kapitel zu freier und quelloffener Software und deutlich konkretere Grenzen für Spenden, Support, Open Core, Foundations und einzelne Beitragende. [1][2][3]
Die Klarstellung ist nötig. Sie kommt aber in einer politisch bemerkenswerten Lage: Am 11. September 2026 beginnen die CRA-Meldepflichten. Am Morgen des 2. August bleiben 40 Tage. Gleichzeitig bezeichnet die Kommission die Leitlinie ausdrücklich als nicht bindend. Laut Begleitmitteilung wurde der Inhalt eines Entwurfs gebilligt; förmlich angenommen werden soll er erst, wenn alle Sprachfassungen vorliegen. [1][2][4]
Europa liefert also eine brauchbare Rollenkarte, während die Uhr bereits läuft. Was steht darin – und was bedeutet das für offene Software, Selfhosting und die Menschen, die beides am Laufen halten?
Open Source ist mehr als ein Lizenzetikett
Der Leitlinienentwurf versteht die CRA-Definition freier und quelloffener Software in zwei Teilen. Die Lizenz muss Zugang, Nutzung, Veränderung und Weiterverteilung erlauben. Zugleich muss der Quellcode tatsächlich öffentlich zugänglich sein. Eine offene Lizenz reicht nicht, wenn der Code nur zahlenden Kunden oder einer geschlossenen Gruppe vorliegt. [3][4]
Diese Grenze ist sinnvoll. „Source available“ kann Einblick ermöglichen, ist aber nicht dasselbe wie freie Software. Auch ein Marketingaufkleber ersetzt keine realen Rechte und keinen öffentlichen Quellcode.
Ebenso wichtig ist die Trennung zwischen Beitrag und Verantwortung. Ein Pull- oder Merge-Request macht eine Person nicht verantwortlich für das gesamte Projekt. Selbst Commit-Rechte reichen laut Entwurf nicht automatisch, wenn die Person keine maßgebliche Kontrolle über Releases, Roadmap, Distribution oder Governance hat. [3]
Wer etwa eine Korrektur für Synapse, einen Matrix-Client oder eine Backup-Bibliothek einreicht, wird dadurch nicht zum Hersteller des Projekts. Die Rechtsrolle soll der tatsächlichen Kontrolle folgen, nicht der bloßen Teilnahme an gemeinschaftlicher Entwicklung.
Freiwillige Spenden sind im Regelfall kein Preis
Beim Thema Spenden räumt der Entwurf mit einem der größten Unsicherheitsfaktoren auf. Ein Spendenlink und selbst schwankende Einnahmen oberhalb enger Projektkosten begründen nicht automatisch Gewinnerzielungsabsicht. Angemessene Vergütung angestellter Beitragender und angemessene Lebenshaltungskosten natürlicher Personen können einbezogen werden. Nur über freiwillige Spenden finanzierte FOSS sei deshalb wahrscheinlich nicht als Marktbereitstellung zu behandeln. [3]
Die Grenze ist dennoch klar: Wenn eine „Spende“ Voraussetzung für Binärdateien, neue Releases, Sicherheitsupdates, wichtige Funktionen oder vertragliche Vorteile ist, kann sie als Preis gelten. Entscheidend ist nicht die freundliche Bezeichnung auf der Webseite, sondern die reale Gegenleistung.
Das ist für gemeinschaftlich finanzierte Projekte eine wichtige Entlastung. Sie dürfen um Unterstützung bitten, ohne allein dadurch in eine Herstellerrolle gedrängt zu werden. Zugleich verhindert die Grenze, dass Unternehmen einen Kaufpreis sprachlich zur Spende umetikettieren.
Bezahlter Support macht die Software nicht automatisch kommerziell
Ähnlich differenziert behandelt der Entwurf Dienstleistungen. Beratung, Schulung, Dokumentation, Konfiguration und Installation rund um frei zugängliche Software machen diese Software nicht automatisch zu einem kommerziell bereitgestellten Produkt. Entscheidend bleibt, ob der Zugang zur Software oder zu ihrer Wartung an Bezahlung gekoppelt wird. [3]
Auch die Installation fremder FOSS auf einem Kundenserver gilt nicht automatisch als Marktbereitstellung, solange die Software nicht wesentlich verändert wird. Wer Synapse hinter Nginx installiert, .well-known einrichtet und einen Restore-Test durchführt, verkauft zunächst eine Dienstleistung. Wer dagegen eine wesentlich veränderte Distribution unter eigenem Namen anbietet, kann anders einzuordnen sein.
Diese Trennung ist für kleine Dienstleister und selbstorganisierte Strukturen zentral. Sie dürfen mit Wissen, Arbeitszeit und verlässlichem Betrieb Geld verdienen. Aber sie müssen sauber dokumentieren, was Dienstleistung, was fremde Software und was ein eigenes Produkt ist.
Open Core: Community-Ausgabe und Bezahlprodukt sind nicht automatisch eins
Wer FOSS selbst oder vorkompilierte Binärdateien gegen Bezahlung anbietet, gilt nach dem Entwurf grundsätzlich als Hersteller. Bei Open-Core-Modellen betrachtet die Kommission eine kostenlose Community-Ausgabe und eine bezahlte Edition jedoch als unterschiedliche Produkte. Die freie, nicht monetarisierte Ausgabe wird nicht allein deshalb kommerziell, weil daneben eine Enterprise-Version existiert. Veröffentlicht eine juristische Person die Community-Ausgabe, kann sie dafür trotzdem Steward sein. [3]
„Kostenlos“ ist allerdings keine sichere Ausfahrt. Eine Anwendung kann kommerziell sein, wenn sie andere Produkte oder Dienste monetarisiert oder personenbezogene Daten für andere Zwecke als Sicherheit, Kompatibilität oder Interoperabilität erzwingt. Die Kommission nennt unter anderem Werbung, Provisionen und bezahlte Zusatzdienste. [3]
Eine offene App, die nur als Zubringer für einen geschlossenen Marktplatz dient, ist wirtschaftlich anders gebaut als ein freier Client ohne Tracking, dessen Entwickler getrennt Beratung verkaufen. Die Prüfung muss dem Geschäftsmodell folgen, nicht dem Null-Euro-Preisschild.
Der Steward ist die organisierte Mitte
Zwischen privatem Beitrag und kommerziellem Hersteller steht die besondere Rolle des Open-Source-Software-Stewards. Gemeint ist eine juristische Person, die nicht unmittelbar vermarktete FOSS dauerhaft unterstützt, ihre Lebensfähigkeit sichert und ihre Nutzung in kommerziellen Produkten ermöglicht. Der Entwurf nennt Hosting von Code oder Entwicklungsplattformen, Governance, Projektsteuerung, Entwicklungsarbeit, Release-Management und Schwachstellenbehandlung. Auch gemeinnützige Organisationen können darunterfallen. [3][5]
Die Pflichten richten sich nach der tatsächlichen Rolle:
- Rein nichttechnische Unterstützung führt grundsätzlich nicht zur Pflicht, aktiv ausgenutzte Schwachstellen selbst zu melden; Informationen sollen aber an Maintainer weitergegeben werden.
- Wer Entwicklungsinfrastruktur bereitstellt, muss schwere Vorfälle dieser Infrastruktur melden, wenn sie die Produktsicherheit beeinträchtigen.
- Wer eigene Entwicklungsressourcen einbringt, muss bekannt gewordene aktiv ausgenutzte Schwachstellen nach Artikel 14 melden und gegebenenfalls Nutzer informieren.
Stewards unterliegen Artikel 24. Nach Artikel 64 Absatz 10 werden gegen sie keine administrativen CRA-Geldbußen verhängt. Das beseitigt nicht ihre Organisations-, Kooperations- und Meldepflichten. [3][4][5]
Eine Stiftung, die nur Treffen ermöglicht, ist deshalb nicht dasselbe wie eine Stiftung, die Signing Keys, Build-System und Security-Releases kontrolliert. Der Begriff „Community“ verdeckt schnell, dass manche Organisationen sehr konkrete technische Macht und Verantwortung tragen.
Ab 11. September zählt die vorbereitete Kette
Die Meldepflicht betrifft nicht jede bekannte Schwachstelle. Hersteller müssen aktiv ausgenutzte Schwachstellen im eigenen Produkt und schwere Vorfälle mit Auswirkungen auf dessen Sicherheit melden. Vorgesehen sind eine Frühwarnung ohne unangemessene Verzögerung, spätestens binnen 24 Stunden nach Kenntnis, eine weitere Meldung binnen 72 Stunden sowie spätere Abschlussberichte. Bei einer Fremdkomponente reicht verwundbarer, aber im konkreten Produkt nicht erreichbarer Code laut Entwurf nicht automatisch aus; relevant ist die tatsächliche Ausnutzbarkeit beziehungsweise Ausnutzung im Produkt. [3][4]
Für einen Matrix-Stack zeigt sich die Schwierigkeit sofort. Das System besteht nicht nur aus Synapse. Hinzu kommen Betriebssystem, PostgreSQL, Nginx, Container oder Pakete, Clients, Bridges, Tokens und Backup-Werkzeuge. Wer auf einen Sicherheitshinweis reagieren will, braucht Versionen, Zuständigkeiten, Updatewege und einen getesteten Rückweg.
Der gewöhnliche Betrieb eines selbst gehosteten Dienstes macht einen Administrator nicht automatisch zum Hersteller oder Steward. Gute Betriebsführung bleibt trotzdem nötig: Sicherheitskontakt, geschützte Logs, begrenzte Tokens, vollständige Backups und ein erprobter Restore sind keine Compliance-Dekoration. Sie entscheiden darüber, ob ein Team Betroffenheit überhaupt prüfen kann.
Bewertung: Regulierung ohne Finanzierung bleibt eine Lastverschiebung
Bewertung, nicht Tatsachenbehauptung: Die Kommission hat mehrere überfällige Klarstellungen geliefert. Beitragende, freiwillig finanzierte Projekte und getrennte Supportleistungen werden nicht pauschal in die Herstellerrolle gedrückt. Zugleich wird anerkannt, dass Foundations mit echter Kontrolle über Releases, Infrastruktur und Sicherheitsarbeit Verantwortung tragen.
Das ist grundsätzlich richtig. Open Source darf kein rechtsfreier Raum sein, sobald der Code in kritischen und kommerziellen Produkten steckt. Falsch wäre aber, wenn Hersteller, Behörden und Konzerne ihre Integrations- und Sicherheitskosten beim unbezahlten Upstream abladen. Wer mit freien Komponenten Geld verdient oder öffentliche Infrastruktur darauf baut, muss deren Wartung mitfinanzieren.
Eine 24-Stunden-Frist bezahlt keinen Bereitschaftsdienst. Eine Meldeplattform erstellt keine reproduzierbaren Builds. Ein Gesetz pflegt keine Komponentenliste und testet keinen Restore. Wenn Europa sichere offene Software will, braucht es dauerhafte Finanzierung für Maintainer-Zeit, Security-Teams, Signierung, SBOM-Pflege und langfristige Releases.
Das Gegenargument ist berechtigt: Kleine Projekte dürfen nicht von jeder Sicherheitsverantwortung freigestellt werden, nur weil ihr Code kostenlos ist. Doch Verantwortung muss der tatsächlichen Kontrolle und wirtschaftlichen Nutzung folgen. Ein Gerätehersteller, der eine freie Bibliothek tausendfach integriert, darf nicht erwarten, dass ein einzelner Maintainer kostenlos seine Product-Security-Abteilung ersetzt.
Fazit
Die neue Leitlinie liefert eine bessere Landkarte: Beitrag ist nicht gleich Herstellerrolle. Freiwillige Spende ist nicht gleich Preis. Getrennter Support ist nicht gleich Softwareverkauf. Community- und Enterprise-Ausgabe können unterschiedliche Produkte sein. Und eine juristische Person mit dauerhafter Infrastruktur- oder Entwicklungsverantwortung kann Steward sein.
Rechtssicherheit ist das noch nicht. Die Leitlinie ist nicht bindend, noch nicht förmlich in allen Sprachfassungen angenommen und lässt Einzelfallfragen offen. Vor dem 11. September müssen außerdem Meldeweg, nationale Zuständigkeit und praktische Hilfen belastbar geklärt sein.
Für Projekte und Betreiber lautet der vernünftige nächste Schritt deshalb nicht, sich selbst eine Rechtsrolle zuzuschreiben. Sie sollten dokumentieren, was sie bereitstellen, wer Releases und Signierung kontrolliert, ob Zahlungen wirklich freiwillig sind, welche Komponenten im eigenen Angebot stecken und wer Sicherheitshinweise bis zur Nutzerinformation und möglichen Meldung verfolgen kann.
Digitale Souveränität bedeutet nicht, ohne Lieferketten auszukommen. Sie bedeutet, diese Lieferketten zu kennen – und Verantwortung nicht dorthin abzuschieben, wo am wenigsten Geld und Zeit vorhanden sind.
Quellen
- Europäische Kommission, Mitteilung zur neuen CRA-Leitlinie, 27. Juli 2026:
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation - Europäische Kommission,
C(2026) 5252 final, Begleitmitteilung:
https://ec.europa.eu/newsroom/dae/redirection/document/131455 - Europäische Kommission, Leitlinienanhang zu
C(2026) 5252 final, 84 Seiten:
https://ec.europa.eu/newsroom/dae/redirection/document/131456 - EUR-Lex, Verordnung (EU) 2024/2847:
https://eur-lex.europa.eu/eli/reg/2024/2847/oj - Europäische Kommission, „Cyber Resilience Act – Open source“:
https://digital-strategy.ec.europa.eu/en/policies/cra-open-source - OpenSSF, „EU Cyber Resilience Act“ (Interessen- und Communityquelle):
https://openssf.org/public-policy/eu-cyber-resilience-act/ - Open Source Initiative zum CRA-Standardisierungsprozess (Interessenquelle):
https://opensource.org/blog/help-us-improve-the-eu-cyber-resilience-act-standards
Transparenz und Prüfstatus
- Grundlage: Recherche vom 2. August 2026 mit EU-Primärquellen und getrennt gekennzeichneten Interessenquellen.
- Redaktionelle Bearbeitung: Crow für Andreas/Carrabelloy.
- Tatsachen, Unsicherheiten und Bewertung sind getrennt; konkrete Rechtsrollen wurden nicht behauptet.
- Vor Veröffentlichung erneut prüfen: förmliche Annahme, deutsche Sprachfassung, Meldeweg, deutsche Zuständigkeiten und Stand der Normung.
CTA
Diskussion: https://treff.darknight-coffee.eu/@carrabelloy
Podcast: https://podcast.darknight-coffee.org/pages/startseite
Blog: https://carrabelloy.darknight-coffee.org/blog/
Wenn dir das Projekt hilft: Spendenlinks sind im Blog.