Unter freier und quelloffener Software ist eine Software zu verstehen, deren Quellcode offen geteilt wird und in deren Lizenz alle erforderlichen Rechte vorgesehen sind, um sie frei zugänglich, nutzbar, veränderbar und weiterverteilbar zu machen. Freie und quelloffene Software wird offen entwickelt, gepflegt und verteilt, auch über Online-Plattformen. In Bezug auf Wirtschaftsakteure, die in den Anwendungsbereich dieser Verordnung fallen, sollte nur freie und quelloffene Software, die auf dem Markt bereitgestellt und somit zum Vertrieb oder zur Nutzung im Rahmen einer Geschäftstätigkeit verfügbar gemacht wird, in den Anwendungsbereich dieser Verordnung fallen. Die bloßen Umstände, unter denen das Produkt mit digitalen Elementen entwickelt wurde, oder die Art und Weise, wie die Entwicklung finanziert wurde, sollten daher bei der Bestimmung des kommerziellen oder nichtkommerziellen Charakters der entsprechenden Tätigkeit nicht berücksichtigt werden. Insbesondere sollte für die Zwecke dieser Verordnung und in Bezug auf die Wirtschaftsakteure, die in ihren Anwendungsbereich fallen, die Bereitstellung von Produkten mit digitalen Elementen, die als freie und quelloffene Software eingestuft und von ihren Herstellern nicht zu Geld gemacht werden, nicht als Geschäftstätigkeit betrachtet werden, damit sichergestellt ist, dass klar zwischen der Entwicklungs- und der Lieferphase unterschieden wird. Darüber hinaus sollte die Lieferung von Produkten mit digitalen Elementen, die als freie und quelloffene Softwarekomponenten eingestuft werden und zur Integration durch andere Hersteller in ihre eigenen Produkte mit digitalen Elementen bestimmt sind, nur dann als Bereitstellung auf dem Markt betrachtet werden, wenn die Komponente von ihrem ursprünglichen Hersteller zu Geld gemacht wird. Beispielsweise sollte allein der Umstand, dass ein Produkt quelloffener Software mit digitalen Elementen von den Herstellern finanziell unterstützt wird oder dass Hersteller zur Entwicklung eines solchen Produkts beitragen, für sich genommen nicht ausschlaggebend für die Feststellung sein, dass die Tätigkeit kommerzieller Art ist. Fernerhin sollte das bloße Vorhandensein regelmäßiger Veröffentlichungen von Versionen für sich genommen nicht zu der Schlussfolgerung führen, dass ein Produkt mit digitalen Elementen im Rahmen einer Geschäftstätigkeit geliefert wird. Schließlich sollte für die Zwecke dieser Verordnung die Entwicklung von Produkten mit digitalen Elementen, die als freie und quelloffene Software eingestuft werden, durch gemeinnützige Organisationen nicht als kommerzielle Tätigkeit betrachtet werden, sofern die Organisation so angelegt ist, dass sichergestellt ist, dass alle Einnahmen nach Abzug der Kosten zur Verwirklichung gemeinnütziger Ziele verwendet werden. Diese Verordnung gilt nicht für natürliche oder juristische Personen, die mit Quellcode zu Produkten mit digitalen Elementen beitragen, die als freie und quelloffene Software eingestuft sind und nicht ihrer Verantwortung unterliegen.
Erwägungsgrund 18
Verordnung (EU) 2024/2847 — veröffentlicht 10. Dezember 2024 · Letzte Prüfung durch Kunnus: März 2026
Auslegung der EU-Kommission
Guidance vom 27. Juli 2026Die EU-Kommissions-Guidance vom 27. Juli 2026 enthält offizielle Auslegungshinweise zu dieser Vorschrift. Jeder Abschnitt: Kurzfassung, Kernaussagen und was das konkret für Sie bedeutet.
Abschnitt 3.1 – 3.2Open Source: Wann ist FOSS „in Verkehr gebracht“?
Entscheidend ist die Monetarisierung durch den Verantwortlichen (Maintainer), nicht die Finanzierung der Entwicklung: Preis für Binaries, Monetarisierung anderer Dienste über die Software, verpflichtende Datenverarbeitung oder kostenpflichtige Versionen mit Support-Vorteilen bedeuten Inverkehrbringen. Freiwillige Donations, optionale Beratung und Dritt-Sponsoring lösen für sich genommen keinen CRA-Scope aus.
Kernaussagen
- FOSS-Definition (Art. 3 Nr. 48) verlangt kumulativ eine FOSS-Lizenz mit allen Rechten und öffentlich geteilten Quellcode — Code nur für zahlende Kunden ist kein FOSS.
- Verantwortlich ist, wer Releases, Roadmap und Distribution kontrolliert; Contributors ohne diese Kontrolle unterliegen dem CRA nicht, selbst mit Commit-Rechten (Beispiel 13).
- Community-Version und kostenpflichtige (Open-Core-)Version sind zwei verschiedene Produkte — die kostenlose Version bleibt außerhalb des Markts.
- Optionale bezahlte Services (Consulting, Training, Deployment-Hilfe) sind unschädlich; kostenpflichtiger Zugang zu einer Version mit technischem Support ist dagegen Monetarisierung (Beispiele 17/18).
- Donations sind erst kritisch, wenn sie de facto Zugangsbedingung sind — etwa Releases oder Security-Fixes nur für Spender (Beispiele 21/22); Kostendeckung inkl. angemessener Lebenshaltungskosten ist zulässig.
- Dritt-Finanzierung (Grants, Bug Bounties, bezahlte Feature-Entwicklung) macht FOSS nicht kommerziell (Erwägungsgrund 18, Beispiel 23).
Für die Praxis
Gehen Sie Ihre Open-Source-Projekte einzeln durch und beantworten Sie zwei Fragen: Kontrollieren wir Releases und Distribution? Und verdienen wir an genau dieser Version (Preis, Monetarisierung über die Software, Pflicht-Datenverarbeitung, Bezahlversion mit Support)? Nur bei zweimal Ja sind Sie Hersteller. Donations-Link, Sponsoring und optionale Beratung ändern daran nichts.
Abschnitt 3.4 – 3.5Contributors, Integration und die FOSS-Szenarien
Wer FOSS-Komponenten in eigene Produkte integriert, wird dadurch nicht für deren eigene CRA-Konformität verantwortlich — auch nicht durch Code-Beiträge zu deren Pflege. Es gelten die Due-Diligence-Pflicht (Art. 13 Abs. 5) und die Upstream-Pflichten (Art. 13 Abs. 6). Acht Szenarien (Beispiele 27–34) spielen die typischen Konstellationen aus Entwicklern, Foundations und integrierenden Herstellern durch.
Kernaussagen
- Einzelentwickler mit Donation-Link: keine CRA-Pflichten; integrierende Hersteller schulden Due Diligence (Beispiele 27, 34).
- FOSS, das für die Integration durch andere Hersteller bestimmt ist und nicht monetarisiert wird, gilt nicht als in Verkehr gebracht — der Publisher ist ggf. Steward (Beispiele 25/26, 29).
- Der CRA-Status einer FOSS-Komponente ändert sich nicht dadurch, dass Hersteller sie in monetarisierte Produkte integrieren.
- Auch Paket-Repositories treffen keine CRA-Pflichten (Beispiel 34).
Für die Praxis
Führen Sie eine Liste aller integrierten FOSS-Komponenten mit Version, Bezugsquelle und Maintainer-Kontakt. Das ist die Arbeitsgrundlage für Ihre Due Diligence (Art. 13 Abs. 5) und für Upstream-Meldungen samt Fix-Sharing (Art. 13 Abs. 6) — für die Konformität der Komponente selbst sind Sie dagegen nicht verantwortlich.
EU-Kommissions-Guidance (C(2026) 5252 final) — Die Guidance gibt die Auslegung der Europäischen Kommission wieder und ist rechtlich nicht bindend. Eine verbindliche Auslegung des EU CRA kann nur der Gerichtshof der Europäischen Union vornehmen.
Dieser Text wurde aus der Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 übernommen. Die Darstellung dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar. Maßgeblich ist allein der im Amtsblatt der Europäischen Union veröffentlichte Wortlaut. Originaltext auf EUR-Lex