Der Cyber Resilience Act, Verordnung (EU) 2024/2847, gilt für freie und quelloffene Software nur, wenn sie „auf dem Markt bereitgestellt“ wird, das heißt „im Rahmen einer Geschäftstätigkeit“ geliefert wird. Die drei Fälle, ein nicht monetarisiertes Projekt, ein Produkt auf Open-Source-Komponenten und der Verwalter quelloffener Software, stammen aus der Verordnung selbst. Was die Verordnung nicht tut, ist zu sagen, wann ein Projekt, das Geld annimmt, Support anbietet, eine bezahlte Stufe betreibt oder von einem Unternehmen finanziert wird, die Linie überschreitet. Die Erwägungsgründe 15 und 18 geben die Richtung vor; die Leitlinien der Kommission vom 27. Juli 2026, C(2026) 5252, Abschnitt 3, Randnummern 42 bis 89, geben die Tests und 22 durchgerechnete Beispiele mit den Nummern 13 bis 34.

Dieser Artikel ist dieser Abschnitt. Er ist für die drei Personen geschrieben, die fragen: den Maintainer mit Spendenlink, das Unternehmen mit Community- und Enterprise-Edition und die Stiftung.

Zuerst: Was überhaupt als Open Source zählt

Artikel 3(48) definiert freie und quelloffene Software als „Software, deren Quellcode offen geteilt wird und die unter einer freien und quelloffenen Lizenz bereitgestellt wird, die alle Rechte vorsieht, sie frei zugänglich, nutzbar, veränderbar und weiterverbreitbar zu machen“. Randnummer 44 liest das als zwei kumulative Bedingungen: eine Lizenz, die den vollen Satz an Rechten gewährt, und Quellcode, der offen geteilt wird. Randnummer 46 zieht die Folge für Source-available- und Nur-Kunden-Modelle: Software, „deren Quellcode nur mit zahlenden Kunden oder einer begrenzten Nutzergruppe geteilt wird (oder geteilt werden darf), ist nicht als FOSS anzusehen“. Die Leitlinien nennen keine Lizenzen. Sie nennen die zwei Bedingungen.

Wer verantwortlich ist: Maintainer, nicht Contributor

Bevor gefragt wird, ob ein Projekt kommerziell ist, fragt Randnummer 48, ob Sie derjenige sind, der es bereitstellt. Randnummer 49: Quelloffene Software steht „unter der Verantwortung“ der Personen, „die sie veröffentlichen und die primäre Kontrolle über ihre Entwicklung, Releases und Vertriebsentscheidungen ausüben (oft ‚Maintainer‘ genannt)“. Contributor, die „Quellcode beitragen, aber Releases, Roadmaps oder Governance-Entscheidungen nicht kontrollieren“, sind nicht verantwortlich, „auch wenn sie Code dazu beigetragen haben“, und „das bloße Bestehen technischer Berechtigungen wie Commit-Zugriff reicht nicht aus“. Beispiel 13 ist der Pull Request: Die Person, die einen Patch einreicht, den Maintainer prüfen und mergen, „ist ein ‚Contributor‘ und unterliegt nicht dem CRA“.

Die Randnummern 86 und 87 schließen den Kreis für Unternehmen: Ein Hersteller, der eine Komponente integriert und zu ihrer Pflege beiträgt, wird nicht für diese Komponente verantwortlich, und die Integration einer Komponente in ein monetarisiertes Produkt „hat keine Auswirkung auf den Status dieser FOSS-Komponente nach dem CRA“. Ob die Verordnung auf eine Komponente anwendbar ist, „hängt allein davon ab, ob die natürliche oder juristische Person, die sie veröffentlicht, sie in Verkehr bringt“.

Die sieben Tests

1. Ein Preis für die Software. Randnummer 51: Für die Software selbst Geld zu verlangen, „z. B. durch einen Preis für die vorkompilierten Binaries“, ist Inverkehrbringen, und wer den Preis verlangt, ist Hersteller.

2. Eine bezahlte Edition neben einer freien, einschließlich Open Core. Randnummer 52 behandelt sie als zwei Produkte. Die bezahlte Version wird in Verkehr gebracht; „die kostenlos bereitgestellte Version (oder Community-Version) ist nicht monetarisiert und gilt daher nicht als in Verkehr gebracht“. Das gilt, „wo die bezahlte Version eine ‚erweiterte‘ kommerzielle Version ist, die die Codebasis der kostenlosen Version erweitert oder diese Version in ein breiteres Produkt einbettet (z. B. wie beim ‚Open-Core‘-Modell)“. Randnummer 53 ergänzt den Haken für Unternehmen: Eine juristische Person, die die Community-Version bereitstellt, ist für sie Verwalter; eine natürliche Person steht dafür außerhalb der Verordnung.

3. Andere Dienste über die Software monetarisieren oder personenbezogene Daten verlangen. Randnummer 54: Ein Projekt ist in Verkehr gebracht, wo der Herausgeber darüber „andere Produkte mit digitalen Elementen oder Dienste monetarisiert“ oder „als Nutzungsbedingung die Verarbeitung personenbezogener Daten aus anderen Gründen als ausschließlich zur Verbesserung der Sicherheit, Kompatibilität oder Interoperabilität der Software verlangt“. Beispiel 14 ist eine kostenlose Marktplatz-App, die Provisionen oder Werbung einnimmt; Beispiel 15 ein kostenloser VPN-Client, der Zugang zu zusätzlichen Servern verkauft; Beispiel 16 eine kostenlose Fitness-App, deren Nutzung an Datenverarbeitung für zielgerichtete Werbung geknüpft ist. Alle drei sind auf dem Markt.

4. Supportleistungen. Die Randnummern 55 bis 57 ziehen die Linie, auf der die meisten Open-Source-Unternehmen leben. Bezahlten Support anzubieten macht die Software „als solches nicht“ kommerziell: „Entscheidend ist, ob der Zugang zur FOSS selbst, einschließlich ihrer Wartung, von einer Vergütung abhängig gemacht wird, und nicht das bloße Angebot professioneller Dienstleistungen rund um ein frei verfügbares Produkt“. Beispiel 18, ein frei herunterladbares Kommandozeilenwerkzeug mit optionaler bezahlter Beratung, ist nicht auf dem Markt. Beispiel 17, ein Betriebssystem mit einer bezahlten Version, „die Supportleistungen wie technische Unterstützung oder Leistungsoptimierung enthält“, ist es, und Randnummer 57 sagt das „unabhängig davon, ob funktional gleichwertige Software auch kostenlos verfügbar ist“. Für Einzelpersonen ergänzt Randnummer 58 die Kostendeckungsregel aus Erwägungsgrund 15: Unterstützung mit dem Zugang zu bündeln ist weiterhin nicht kommerziell, „wenn der verlangte Preis nur der Deckung der tatsächlichen Kosten dient“, die „die angemessenen Lebenshaltungskosten der Person einschließen“.

5. Spenden. Randnummer 61, aus Erwägungsgrund 15: „Die Annahme von Spenden ohne Gewinnerzielungsabsicht sollte nicht als Geschäftstätigkeit angesehen werden“, und ein Spendenlink ist keine Gewinnerzielungsabsicht, „selbst wenn der über Spenden gesammelte Betrag die bloßen Kosten übersteigt“, angemessene Vergütung von Beitragenden und Lebenshaltungskosten eingeschlossen. „Eine FOSS, die nur durch Spenden getragen wird, gilt daher wahrscheinlich nicht als in Verkehr gebracht.“ Randnummer 62 nennt die Ausnahme: Spenden, die „de facto dem Verlangen eines Preises gleichkommen“, wo „der Zugang zur FOSS, zu wesentlichen Funktionen oder zu Updates in der Praxis von einer Spende abhängig gemacht wird“. Beispiel 21 stellt Releases und Sicherheitsupdates nur Spendern bereit: auf dem Markt. Beispiel 22 veröffentlicht den Quellcode, gibt aber „vorkompilierte Binaries, regelmäßige Updates und garantierte Sicherheitskorrekturen nur an Spender“: auf dem Markt.

6. Sponsoring und finanzierte Entwicklung. Die Randnummern 63 bis 65: Zuschüsse, Bug Bounties, Sponsoring und bezahlte Feature-Arbeit „sollten bei der Bestimmung des kommerziellen Charakters dieser Tätigkeit nicht berücksichtigt werden“. Beispiel 23 ist ein Unternehmen, das einen einzelnen Maintainer dafür bezahlt, eine Funktion hinzuzufügen, die dann offen geteilt wird; der Maintainer hat nichts in Verkehr gebracht, und das Unternehmen schuldet Sorgfaltspflicht nach Artikel 13(5), wenn es das Ergebnis integriert.

7. Gemeinnützige Herausgeber. Randnummer 66: Eine juristische Person, „die so aufgestellt ist, dass alle Einnahmen nach Abzug der Kosten zur Verfolgung gemeinnütziger Ziele verwendet werden“, bringt ihre Software nicht in Verkehr, selbst wo sie direkt monetarisiert wird. Beispiel 24 ist ein Browser, „der direkt über Suchmaschinenpartnerschaften monetarisiert wird“, dessen Einnahmen nach Kosten gemeinnützigen Zielen dienen: nicht auf dem Markt, und der Herausgeber ist Verwalter.

Randnummer 67 ergänzt den Fall, für den das ganze Verwalter-Regime existiert: Software, „die zur Integration durch andere Hersteller in deren eigene Produkte bestimmt ist“, wird nicht in Verkehr gebracht, es sei denn, der Herausgeber monetarisiert sie auch; die juristische Person, die sie veröffentlicht, ist Verwalter, wenn sie nachhaltige Unterstützung leistet. Die Beispiele 25 und 26 sind eine UI-Bibliothek und Referenzimplementierungen, die ein Unternehmen ohne Entgelt veröffentlicht.

Wo die drei jeweils landen

Die Beispielszenarien in Abschnitt 3.5 bilden die Tests auf reale Formen ab, und drei davon decken die meisten Leser ab.

Der einzelne Maintainer mit Spendenlink (Beispiele 27 und 34): nicht auf dem Markt, keine Pflichten nach der Verordnung, wie viele Unternehmen auch vom Projekt abhängen und wie viel sie spenden. Die integrierenden Unternehmen schulden Sorgfaltspflicht nach Artikel 13(5) und, nach Artikel 13(6), dem Maintainer die Meldung gefundener Schwachstellen und die Korrekturen, die sie schreiben.

Das Unternehmen mit Community- und bezahlter Edition (Beispiele 29 und 30): Hersteller für die bezahlte Edition, mit der vollen Verordnung daran, und Verwalter für die Community-Edition, die es kostenlos bereitstellt, mit den leichteren Pflichten des Artikels 24 daran. Die Randnummern 72 bis 74 sagen ausdrücklich, dass eine juristische Person beides zugleich sein kann, Projekt für Projekt, und „für jede einzelne FOSS, die sie veröffentlicht“, entscheiden muss, welches sie ist.

Die Stiftung (Beispiele 28, 32 und 33): Verwalter, ob finanziert durch öffentliche Zuschüsse, Spenden, Partnerschaftsprojekte oder Mitgliedsbeiträge, sofern sie so aufgestellt ist, dass Einnahmen nach Kosten gemeinnützigen Zielen dienen, und sie die Software nachhaltig trägt. Ihre Mitglieder und Geldgeber sind nicht für die Konformität der Software verantwortlich; Hersteller, die darauf aufbauen, schulden Sorgfaltspflicht.

Was Sie aufschreiben

Für jedes Projekt, das Sie veröffentlichen, eine Seite: ob es die zwei Bedingungen des Artikels 3(48) erfüllt; wer die primäre Kontrolle über Releases ausübt; welchen der sieben Tests es gegebenenfalls erfüllt, mit der Nummer des Beispiels, dem es ähnelt; und die daraus folgende Rolle, Hersteller, Verwalter oder keines von beiden. Ein Unternehmen, das mehrere Projekte veröffentlicht, schreibt diese Seite mehrmals, weil Randnummer 74 sagt, dass die Antwort je Projekt gilt. Ein Hersteller, der Open-Source-Komponenten integriert, schreibt sie für diese nicht; er hält stattdessen die Sorgfaltspflicht nach Artikel 13(5) und die Meldungen nach Artikel 13(6) fest, wo die zwölf Schritte sie einordnen.

Quellen

  • Verordnung (EU) 2024/2847, Artikel 3(14) und (48), Artikel 13(5) und (6), Artikel 24, Erwägungsgründe 15, 18 und 19.
  • Europäische Kommission, Leitlinien der Kommission zur Anwendung der Verordnung (EU) 2024/2847, C(2026) 5252 final vom 27. Juli 2026, Anhang, Abschnitt 3, Randnummern 42 bis 89 und Beispiele 13 bis 34.

Dies ist keine Rechtsberatung. Abschnitt 3 umfasst vierzehn Seiten, und die 22 Beispiele sind der Teil, den man lesen sollte; die meisten Projekte erkennen sich in einem davon wieder.