Open Source – Carrabelloy ' Meine Hobbys sind so vielseitig

Open Source als Standard? Deutschlands neue Beschaffungsregeln sind noch keine Wende

Deutschland hat 2026 zwei echte Schritte in Richtung digitaler Souveränität gemacht. Öffentliche Vergabestellen dürfen digitale Souveränität ausdrücklich als Zuschlagskriterium berücksichtigen. Außerdem wurden acht EVB-IT-Vertragsmuster modernisiert, damit Open-Source-Software rechtssicher beschafft werden kann.

Das klingt nach einer Open-Source-Wende. Es ist aber noch keine.

Der entscheidende Unterschied steckt in einem einzigen Wort: kann. § 58 Absatz 2 der Vergabeverordnung erlaubt, Aspekte digitaler Souveränität bei der Zuschlagsentscheidung zu berücksichtigen. Die Vorschrift verpflichtet Vergabestellen nicht dazu. Im verkündeten Regelungstext des Vergabebeschleunigungsgesetzes kommen die Begriffe „Open Source“, „Software“ und „Quellcode“ nicht vor. [3][4]

Die Bundesregierung hat eine Tür geöffnet. Ob Verwaltungen hindurchgehen, entscheidet sich in Ausschreibungen, Verträgen, Budgets und im späteren Betrieb.

Was seit Juli 2026 tatsächlich gilt

Das Gesetz zur Beschleunigung der Vergabe öffentlicher Aufträge trat am 1. Juli 2026 in Kraft. Sein Hauptzweck ist eine schnellere und einfachere öffentliche Beschaffung. Die Reform erhöht unter anderem Direktauftragsgrenzen, flexibilisiert Gesamtvergaben, verringert Nachweispflichten und beschleunigt Nachprüfungsverfahren. [3][6]

Für digitale Souveränität ist die Änderung von § 58 Absatz 2 VgV relevant. Neben Preis und Kosten können qualitative, umweltbezogene oder soziale Kriterien einfließen. Neu genannt werden „Aspekte der digitalen Souveränität“. [4]

Das erweitert den Spielraum. Eine Behörde kann künftig deutlicher bewerten, ob sie Daten exportieren, Schnittstellen dokumentiert nutzen oder einen Betreiber wechseln kann. Sie kann Abhängigkeiten und Kontrollrechte in die Zuschlagsentscheidung einbeziehen, statt nur auf den kurzfristig niedrigsten Preis zu schauen.

Belegte Tatsache: Digitale Souveränität ist nun ausdrücklich als mögliches Zuschlagskriterium genannt.

Ebenso belegt: Eine allgemeine gesetzliche Pflicht zu Open Source enthält der veröffentlichte Normtext nicht.

Genau an diesem Punkt formuliert der am 28. Juli 2026 veröffentlichte Deutschland-Bericht des europäischen Open Source Observatory, kurz OSOR, zu stark. Der Bericht beschreibt Deutschland als führendes Beispiel für Open Source im öffentlichen Sektor. Er behauptet jedoch auch, das Gesetz verpflichte Beschaffungsstellen zur Berücksichtigung digitaler Souveränität bei nicht preislichen Kriterien. Zudem soll ein Anhang Open Source und offene Standards als Beispiele nennen. Im verkündeten deutschen Regelungstext lässt sich diese Darstellung nicht bestätigen. [1][2][3]

Nachprüfung vom 31. Juli 2026: Die Fußnote 37 des OSOR-Berichts verweist ausschließlich auf BGBl. 2026 I Nr. 137. Der dort veröffentlichte 19-seitige Regelungstext enthält keinen Anhang und keinen Treffer für „Open Source“, „offene Standards“, „Software“ oder „Quellcode“. Damit ist die Behauptung durch die vom OSOR selbst genannte Quelle nicht gedeckt. Sie wird in diesem Entwurf als fehlerhafte Darstellung des Länderberichts behandelt, nicht als Inhalt des geltenden Gesetzes.

Bewertung: Wer Open Source stärken will, sollte ein „kann“ nicht zum „muss“ aufblasen. Die Übertreibung verdeckt gerade jene Umsetzungslücke, über die politisch gestritten werden muss.

Die EVB-IT können mehr bewirken als eine Sonntagsrede

Praktisch womöglich wichtiger als der neue Gesetzessatz sind die modernisierten EVB-IT. Diese ergänzenden Vertragsbedingungen und Muster werden von Bund, Ländern und Kommunen für IT-Leistungen eingesetzt.

Das Bundesministerium für Digitales und Staatsmodernisierung erklärte am 20. März 2026:

Acht Vertragsmuster wurden für die rechtssichere Beschaffung von Open Source überarbeitet.
Die Entwicklung und Bereitstellung neuer Softwareprojekte als Open Source wird als Standard in den Mustern abgebildet.
Die Muster bieten Optionen für mehr Transparenz, darunter die Übergabe einer Software Bill of Materials, kurz SBOM.
Proprietäre Software bleibt weiterhin beschaffbar. [5]

Standardklauseln lösen ein reales Problem. Eine Beschaffungsstelle muss nicht für jedes Open-Source-Projekt eine individuelle juristische Konstruktion erfinden. Das senkt Aufwand und Unsicherheit.

Aber ein Mustervertrag ist nur ein Werkzeug. Ob daraus Freiheit entsteht, entscheidet der ausgefüllte Vertrag.

Ein Auftrag kann etwa die Übergabe von Quellcode verlangen. Ohne Build-Anleitung, dokumentierte Abhängigkeiten, Testfälle und Release-Prozess kann ein anderer Betreiber daraus trotzdem kein lauffähiges System erzeugen. Eine SBOM zeigt, welche Komponenten verbaut wurden. Sie spielt aber kein Sicherheitsupdate ein und benennt nicht automatisch die verantwortliche Wartungsstelle.

Bewertung: Die EVB-IT sind ein starker Hebel, weil sie in die tägliche Verwaltungspraxis eingreifen. Ihre Wirkung muss jedoch an realen Verträgen gemessen werden: Welche Klauseln werden übernommen, welche abgewählt, und welche Übergaben werden tatsächlich abgenommen?

Souveränität ist mehr als Serverstandort und Lizenz

Der Begriff „digitale Souveränität“ bleibt gefährlich dehnbar. Ein europäischer Anbieter mit einem deutschen Rechenzentrum kann geschlossene Formate, undokumentierte Schnittstellen und ein proprietäres Kontrollpanel einsetzen. Der Standort allein verändert dann die Machtverteilung nicht.

Umgekehrt ist auch eine freie Lizenz keine Betriebsgarantie. Ein Open-Source-Dienst bleibt abhängig, wenn nur ein Integrator die Konfiguration kennt oder eine einzige Person über privilegierte Zugänge verfügt.

Das lässt sich am Community-Betrieb gut erkennen.

Eine Matrix-Instanz kann vollständig auf Synapse und anderer freier Software beruhen. Wenn Admin-Tokens, Raumrechte, Signaturschlüssel, .well-known-Einträge und Wiederanlaufprozedur nicht dokumentiert sind, kann die Community den Betreiber trotzdem nicht sicher wechseln.

Eine offene Webanwendung kann hinter Nginx laufen. Wenn Reverse-Proxy-Regeln, Zertifikatserneuerung, Datenbankmigration, Monitoring und Secrets beim bisherigen Dienstleister bleiben, ist der Auftraggeber weiterhin gefangen.

Ein Backup kann jeden Abend erfolgreich gemeldet werden. Wenn niemals geprüft wurde, ob Datenbank, Dateien, Konfiguration, Schlüssel und passende Softwareversion auf einer frischen Umgebung wiederhergestellt werden können, ist dieses Backup nur eine Hoffnung.

Technische Bewertung: Souverän ist ein Dienst erst, wenn eine zweite Organisation ihn mit den übergebenen Daten, Rechten und Unterlagen unabhängig wieder in Betrieb nehmen kann.

Zehn Mindestanforderungen für souveräne Verträge

Eine belastbare öffentliche Ausschreibung sollte mindestens folgende Punkte verlangen:

vollständigen Quellcode unter einer anerkannten freien Lizenz;
offene Datenformate und dokumentierte Schnittstellen;
reproduzierbare Bereitstellung, Build-Anleitung und dokumentierte Abhängigkeiten;
eine aktuelle SBOM sowie klare Zuständigkeiten für Sicherheitsmeldungen und Updates;
vollständigen Export von Daten, Konfigurationen, Rollen und Berechtigungen;
kontrollierte Übergabe und Rotation von Domains, Schlüsseln, Zertifikaten und Admin-Zugängen;
unabhängige Betriebs-, Prüf- und Weiterentwicklungsrechte;
Wartungsbudget und einen geregelten Umgang mit Upstream-Projekten;
vertragliche Unterstützung beim Anbieterwechsel;
einen praktisch bestandenen Migrations- und Restore-Test.

Diese Anforderungen machen Beschaffung zunächst aufwendiger. Sie verhindern aber, dass niedrige Einstiegspreise mit späteren Wechselkosten erkauft werden. Der Exit muss von Anfang an Teil der Gesamtbetriebskosten sein.

Der Deutschland-Stack ist ein Aufbau, kein fertiger Zustand

Der Deutschland-Stack soll eine gemeinsame, interoperable und europäisch anschlussfähige Grundlage für Bund, Länder und Kommunen schaffen. Als Leitlinien nennt das Ministerium offene Standards, Open-Source-Lösungen, Wiederverwendbarkeit und die Verringerung externer Abhängigkeiten. Zu den ersten Bereichen gehören Identität, Postfach und Interaktion, Datenaustausch, Nachweisabruf sowie Ein- und Auszahlung. [7]

Bund und Länder verständigten sich im IT-Planungsrat im März 2026 auf Eckpunkte für einen gemeinsamen Plattformkern und ein initiales Portfolio. Gleichzeitig beschreibt das Ministerium einen schrittweisen Aufbau bis 2028. Roadmap, Steuerung, Umsetzung und Beschaffung werden weiterentwickelt. [7][8]

Das ist ein politischer Aufbauplan, kein Beleg für eine abgeschlossene bundesweite Migration.

Gemeinsame Komponenten können Doppelarbeit vermeiden. Sie schaffen jedoch neue kritische Abhängigkeiten. Fällt eine zentrale Identitäts- oder Austauschkomponente aus, können viele angebundene Dienste gleichzeitig betroffen sein. Deshalb müssen offene Schnittstellen, alternative Implementierungen, Schlüsselrotation, Fehlerzustände und unabhängige Wiederherstellung zum Plattformkern gehören.

Bewertung: Der Deutschland-Stack sollte nicht nur an Konten oder angeschlossenen Diensten gemessen werden. Entscheidend sind nachgewiesene Interoperabilität, alternative Betreiber und bestandene Ausfall- und Migrationstests.

Die Gegenargumente sind berechtigt – aber kein Freifahrtschein

Open Source ist nicht automatisch sicher. Offener Quellcode garantiert keine Prüfung, kein Update und keine schnelle Reaktion auf Schwachstellen. Dafür braucht es gepflegte Meldewege, bezahlte Wartung, nachvollziehbare Builds und klare Verantwortung.

Open Source ist auch nicht automatisch billiger. Schulung, Integration, Support und Bereitschaft kosten Geld. Ein fairer Vergleich muss jedoch auch Preissteigerungen, Datenrückgewinnung und Anbieterwechsel einbeziehen.

Und nicht jede Kommune muss jeden Dienst selbst hosten. Ein kompetenter externer Betreiber kann sicherer und wirtschaftlicher sein. Entscheidend bleibt, ob der Auftraggeber Daten, Rechte, Wissen und Wechselmöglichkeiten behält.

Eine sofortige ausnahmslose Open-Source-Pflicht könnte bei spezialisierten Fachverfahren zu Verzögerungen führen. Die bessere Regel wäre ein verbindlicher Vorrang mit begründungspflichtigen Ausnahmen. Dabei müsste öffentlich festgehalten werden, welche offene Lösung welche Anforderung nicht erfüllt, welche Lock-in-Kosten die proprietäre Ausnahme erzeugt und wann die Entscheidung erneut geprüft wird.

Bewertung: Die Alternative zu blindem proprietärem Einkauf ist nicht blinder Open-Source-Einkauf. Die Alternative ist überprüfbare Beschaffung mit offenen Rechten, professionellem Betrieb und einem realen Ausstieg.

Fazit: Deutschland hat Werkzeuge, noch keine Wende

Deutschland hat 2026 Fortschritte gemacht. Digitale Souveränität kann ausdrücklich in die Zuschlagsentscheidung einfließen. Die EVB-IT senken Hürden für Open-Source-Verträge. Der Deutschland-Stack stellt offene Standards und gemeinsame Komponenten ins Zentrum.

Aber aus einer Möglichkeit folgt keine Praxis. Aus einem Vertragsmuster folgt kein guter Vertrag. Aus einem öffentlichen Repository folgt kein übergabefähiger Betrieb.

Jetzt braucht es messbare Zahlen: Wie viele Vergaben gewichten digitale Souveränität? Wie oft werden die neuen Open-Source-Klauseln genutzt? Welche Verträge enthalten Exit- und Restore-Tests? Wie häufig übernimmt tatsächlich ein zweiter Betreiber?

Meine abschließende Bewertung: Die Open-Source-Wende beginnt erst, wenn eine öffentliche Stelle Nein sagen, den Anbieter wechseln und weiterarbeiten kann. Souveränität ist kein Etikett. Sie ist die belegbare Verteilung von Rechten, Wissen, Geld und Kontrolle.

Quellen

Open Source Observatory / Interoperable Europe Portal: Germany 2026 Country Report, 28. Juli 2026: https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/germany-2026-country-report
OSOR: Open Source Software Country Intelligence Report – Germany, 2026: https://interoperable-europe.ec.europa.eu/sites/default/files/inline-files/germany-2026-osor-country-report.pdf
Bundesgesetzblatt: BGBl. 2026 I Nr. 137 – Gesetz zur Beschleunigung der Vergabe öffentlicher Aufträge, 18. Mai 2026: https://www.recht.bund.de/bgbl/1/2026/137/VO.html
Gesetze im Internet: § 58 Vergabeverordnung, insbesondere Absatz 2 Nummer 4: https://www.gesetze-im-internet.de/vgv_2016/__58.html
Bundesministerium für Digitales und Staatsmodernisierung: Open Source rechtssicher beschaffen, 20. März 2026: https://bmds.bund.de/aktuelles/pressemitteilungen/detail/open-source-rechtssicher-beschaffen
Bundesregierung: Einfachere Verfahren mit dem neuen Vergaberecht, 1. Juli 2026: https://www.bundesregierung.de/breg-de/suche/oeffentliche-vergabe-2376854
Bundesministerium für Digitales und Staatsmodernisierung: Deutschland-Stack: https://bmds.bund.de/themen/digitaler-staat/deutschland-stack
Bundesministerium für Digitales und Staatsmodernisierung: Bund und Länder einigen sich auf gemeinsame Umsetzung des Deutschland-Stacks, 19. März 2026: https://bmds.bund.de/aktuelles/aktuelle-meldungen/detail/gemeinsame-umsetzung-des-deutschland-stacks
Deutscher Bundestag: Stärkung der digitalen Souveränität ist Kernanliegen, zur Antwort der Bundesregierung auf Drucksache 21/1264: https://www.bundestag.de/presse/hib/kurzmeldungen-1106074

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.

Freigabe erforderlich: ja
Veröffentlichung erfolgt: nein

Das KI-Label kommt – die Hochrisiko-Kontrolle wartet

Was am 2. August 2026 beim EU AI Act wirklich beginnt, warum Transparenz nicht Kontrolle ersetzt und weshalb Open Source weder Freibrief noch Feindbild ist.

Am 2. August bekommt die europäische KI-Regulierung ein sichtbares Gesicht. Menschen sollen erkennen können, wenn sie mit einem KI-System interagieren. Synthetische Ausgaben sollen maschinenlesbar markiert werden. Deepfakes und bestimmte automatisch erzeugte Texte zu Themen von öffentlichem Interesse müssen offengelegt werden.

Das ist ein Fortschritt. Aber die bequeme Schlagzeile „Jetzt gilt der AI Act“ ist falsch. Die Verordnung trat bereits am 1. August 2024 in Kraft und wird seitdem stufenweise anwendbar. Noch wichtiger: Während die Transparenzregeln jetzt greifen, hat der jüngste AI Omnibus zentrale Pflichten für Hochrisiko-Systeme verschoben. Das sichtbare Label kommt. Die schwierigere Kontrolle wartet.

Was am 2. August tatsächlich passiert

Ab dem 2. August 2026 wird Artikel 50 des AI Act anwendbar. Außerdem beginnt die Durchsetzung wichtiger bereits geltender Vorschriften auf europäischer und nationaler Ebene. Die Regeln für General-Purpose-AI-Modelle gelten schon seit dem 2. August 2025; nun stehen den zuständigen Stellen reale Untersuchungs- und Sanktionsbefugnisse zur Verfügung.

Das europäische AI Office kann laut der offiziellen Übersicht unter anderem Auskünfte verlangen, Zugang zu Modellen und Evaluationen fordern, Korrekturmaßnahmen anordnen und nötigenfalls die öffentliche Verfügbarkeit eines Modells beschränken. Für andere KI-Systeme sind grundsätzlich nationale Marktüberwachungsbehörden zuständig.

Die Kommission nennt je nach Verstoß Höchstgrenzen von bis zu 35 Millionen Euro oder sieben Prozent des weltweiten Jahresumsatzes für verbotene Praktiken sowie bis zu 15 Millionen Euro oder drei Prozent für andere Verstöße. Das sind Maximalwerte. Sie bedeuten nicht, dass jeder fehlerhafte Hinweis automatisch eine Millionenbuße auslöst.

Offen bleibt in der vorliegenden Recherche, welche deutsche Behörde am Stichtag für welchen Systemtyp praktisch zuständig ist, wie konkret Beschwerden eingereicht werden können und ob alle nötigen Fachstellen einsatzbereit sind. Wer dazu mehr behauptet, müsste es mit deutschen amtlichen Quellen belegen.

Artikel 50 ist genauer als das Schlagwort „KI-Kennzeichnung“

Artikel 50 verteilt unterschiedliche Pflichten auf Anbieter und Betreiber.

Anbieter direkt interagierender KI-Systeme müssen Menschen grundsätzlich darüber informieren, dass sie mit KI sprechen, sofern dies nicht ohnehin offensichtlich ist. Anbieter generativer Systeme müssen synthetische Audio-, Bild-, Video- und Textausgaben maschinenlesbar als künstlich erzeugt oder manipuliert erkennbar machen. Die technische Lösung soll wirksam, interoperabel, robust und zuverlässig sein – soweit dies technisch machbar ist.

Betreiber müssen bei Deepfakes offenlegen, dass Bild, Ton oder Video künstlich erzeugt oder verändert wurden. Für Texte, die die Öffentlichkeit über Angelegenheiten öffentlichen Interesses informieren sollen, gilt ebenfalls eine Offenlegungspflicht, wenn sie künstlich erzeugt oder manipuliert wurden.

Doch die Verordnung unterscheidet zwischen automatischer Publikation und verantworteter Redaktion: Hat ein Text einen menschlichen Prüf- oder Redaktionsprozess durchlaufen und übernimmt eine Person oder Organisation die redaktionelle Verantwortung, greift diese besondere Offenlegungspflicht nicht automatisch.

Ein Blogentwurf, den ein Sprachmodell strukturiert und den eine Redaktion anschließend vollständig anhand der Primärquellen prüft, umschreibt und verantwortet, ist damit nicht dasselbe wie ein Bot, der politische Meldungen ohne menschliche Prüfung veröffentlicht. Das ist keine Einladung, Werkzeuge zu verschleiern. Es ist eine notwendige Unterscheidung zwischen technischer Hilfe und ausgelagerter Verantwortung.

Für bestimmte Generatoren, die schon vor dem 2. August 2026 angeboten wurden, kann außerdem eine Übergangsfrist bis zum 2. Dezember 2026 relevant sein. Ein fehlender Marker am 3. August beweist deshalb nicht ohne Einzelfallprüfung einen Rechtsverstoß.

Das Wasserzeichen löst das Wahrheitsproblem nicht

Maschinenlesbare Markierungen können Herkunftsinformationen transportieren. Sie können anzeigen, dass ein System an einer Datei beteiligt war. Sie beweisen aber nicht, dass der Inhalt falsch ist. Sie beweisen auch nicht automatisch, wer ihn erstellt, verändert oder veröffentlicht hat.

In der Praxis werden Bilder komprimiert, Videos transkodiert, Audiodateien neu kodiert und Inhalte als Screenshot weitergereicht. Dabei können Metadaten oder andere Marker verloren gehen. Umgekehrt kann ein sichtbares Label den falschen Eindruck erzeugen, die gesamte Herkunftskette sei damit geprüft.

Die EU hat ergänzend einen freiwilligen Transparenzkodex geschaffen. Unterzeichner können dessen Maßnahmen als anerkannten Nachweisweg verwenden. Wer nicht unterzeichnet, handelt nicht automatisch rechtswidrig, sondern muss gleichwertige eigene Maßnahmen belegen. Ende Juli 2026 hatten sich laut Kommission rund 190 Organisationen angeschlossen. Diese Zahl ist veränderlich und muss vor einer Veröffentlichung erneut geprüft werden.

Redaktionelle Bewertung – von Andreas vor Veröffentlichung zu prüfen: Transparenz wird erst dann zu digitaler Souveränität, wenn die Prüfwerkzeuge offen und unabhängig nutzbar sind. Wenn nur große Plattformen maschinenlesbare Nachweise ausstellen und lesen können, entsteht ein neuer Lock-in. Dann gehört nicht nur das Modell einigen Konzernen, sondern auch die technische Definition von Glaubwürdigkeit.

Eine souveräne Infrastruktur braucht offene Spezifikationen, freie Prüfsoftware, mehrere unabhängige Validierer und die Möglichkeit, Nachweise selbst zu hosten. Ein proprietärer KI-Detektor darf nicht zum Wahrheitsministerium werden.

Der eigentliche politische Konflikt: Hochrisiko kommt später

Der AI Omnibus trat nach Angaben der EU-Kommission am 27. Juli 2026 in Kraft. Er verschiebt die Anwendung der Hochrisiko-Regeln für Systeme aus Anhang III auf den 2. Dezember 2027. Dazu gehören unter anderem Bereiche wie Biometrie, kritische Infrastruktur, Bildung, Beschäftigung, Migration und Justiz. Für KI als Bestandteil regulierter Produkte nach Anhang I ist nun der 2. August 2028 vorgesehen.

Die Kommission begründet die längeren Fristen mit fehlenden Standards, Unterstützungsinstrumenten und dem Bedarf an Rechtssicherheit. Das ist ein ernst zu nehmendes Argument. Uneinheitliche Prüfverfahren können gerade kleine Anbieter überfordern, während Konzerne ganze Rechts- und Compliance-Abteilungen finanzieren.

Aber daraus folgt nicht zwingend, dass breite Verschiebungen die einzige Lösung waren. Denkbar wären stufenweise Mindestpflichten, öffentliche Audit-Angebote, klare Beschaffungsregeln und gezielte Unterstützung kleiner und freier Projekte.

Gesichert ist die Verschiebung. Nicht gesichert ist, wie viele konkrete Systeme dadurch länger ohne eine bestimmte AI-Act-Pflicht betrieben werden. Dafür fehlen belastbare öffentliche Bestandszahlen und Einzelfallklassifikationen. Der Satz „Die EU hat Hochrisiko-KI freigegeben“ wäre daher ebenso falsch wie die Behauptung, ab 2. August sei die gesamte Regulierung fertig.

Redaktionelle Bewertung – von Andreas vor Veröffentlichung zu prüfen: Die zeitliche Asymmetrie ist politisch gefährlich. Labels sind sichtbar und leicht zu kommunizieren. Die Kontrolle von Systemen, die über Bildung, Arbeit, Migration oder Justiz mitentscheiden können, ist komplizierter – und wurde vertagt. Transparenz darf nicht als Ersatz für Grundrechtsschutz verkauft werden.

Open Source ist nicht pauschal ausgenommen

Auch bei Open Source lohnt der Blick in den Wortlaut. Artikel 2 Absatz 12 privilegiert Systeme unter freien und offenen Lizenzen grundsätzlich. Im selben Satz stehen jedoch klare Rückausnahmen: verbotene Praktiken, Hochrisiko-Systeme und Systeme, die unter Artikel 50 fallen.

Ein frei lizenzierter Chatbot oder Bildgenerator ist also nicht allein wegen seiner Lizenz von den Transparenzpflichten befreit. Wer ein Modell privat auf dem eigenen Rechner nutzt, befindet sich außerdem in einer anderen Lage als jemand, der einen öffentlichen Dienst betreibt oder Ausgaben automatisiert publiziert. „Selfhosting“ allein beantwortet die rechtliche Rollenfrage nicht.

Für Anbieter von General-Purpose-AI-Modellen enthält Artikel 53 eine engere Erleichterung. Wenn die Lizenz Zugriff, Nutzung, Veränderung und Weitergabe erlaubt und Parameter einschließlich Gewichten, Architektur- und Nutzungsinformationen öffentlich sind, können zwei Dokumentationspflichten entfallen. Die Urheberrechtsrichtlinie und eine öffentliche, hinreichend detaillierte Zusammenfassung der Trainingsinhalte bleiben jedoch Pflicht. Für Modelle mit systemischem Risiko greift die Ausnahme nicht.

Deshalb sind „Open Weights“ und „Open Source“ nicht dasselbe. Ein Download von Gewichten ohne ausreichende Nutzungsrechte und technische Informationen ist kein vollständiger Offenheitsnachweis.

Redaktionelle Bewertung – von Andreas vor Veröffentlichung zu prüfen: Open Source darf weder als Schlupfloch noch als Kollateralschaden behandelt werden. Offene Systeme ermöglichen unabhängige Prüfung, Anpassung und gemeinschaftlichen Betrieb. Offenheit macht riskante Anwendungen aber nicht harmlos. Die richtige Linie ist risikobasierte Verantwortung plus offene öffentliche Compliance-Infrastruktur – kein Freibrief, aber auch keine proprietäre Mautstelle.

Was Betreiber und Communities jetzt praktisch tun können

Für einen kleinen Server- oder Community-Betrieb sind fünf Schritte sinnvoll:

Dokumentieren, wo KI-Systeme tatsächlich eingesetzt werden.
Private Nutzung, internen Betrieb, öffentliches Angebot und automatische Veröffentlichung auseinanderhalten.
Bot-Konten klar benennen, Tokens minimal berechtigen, regelmäßig rotieren und einer verantwortlichen Person zuordnen.
Originaldateien, Quellen, Hashwerte und Prüfprotokolle in getesteten Backups erhalten.
Vor jeder Veröffentlichung zu öffentlichen Themen einen echten menschlichen Freigabeschritt setzen.

Ein Beispiel: Taucht in einem Matrix-Raum ein angebliches Beweisvideo auf, reicht die Meldung eines proprietären Online-Detektors nicht. Belastbarer sind Originaldatei, dokumentierte Quelle, Hashwert, Metadatenprüfung und menschliche Kontextanalyse. Das Werkzeug liefert einen Hinweis. Die Redaktion trägt das Urteil.

Ein zweites Beispiel: Ein lokaler Textgenerator läuft hinter Nginx und wird von einem Synapse-Bot angesprochen. Entscheidend sind nicht die Schlagworte „lokal“ und „Open Source“, sondern Zugänglichkeit, Lizenz, Rolle, Kennzeichnung, Token-Rechte, Protokollierung und ein klarer Abschaltweg.

Fazit

Der 2. August 2026 ist ein wichtiger Stichtag, aber kein Schlusspunkt. Der AI Act macht Transparenz und Durchsetzung konkreter. Das ist gut. Gleichzeitig wurden zentrale Hochrisiko-Pflichten verschoben. Das ist die Lücke, über die politisch gesprochen werden muss.

Ein Label kann zeigen, dass eine Maschine beteiligt war. Es kann nicht erklären, wem das System dient, wie eine Entscheidung angefochten wird oder wer den Schaden trägt. Dafür braucht Europa offene technische Standards, unabhängige Prüfung, klare Zuständigkeiten und durchsetzbaren Grundrechtsschutz.

Transparenz und Kontrolle sind keine Gegensätze. Wir brauchen beides.

Quellen

Europäische Kommission, AI Act – Überblick und Zeitplan: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
Europäische Kommission, „AI Omnibus enters into force“, 27. Juli 2026: https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
EUR-Lex, Verordnung (EU) 2026/1744: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601744
AI Act Service Desk, Umsetzungszeitleiste: https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
AI Act Service Desk, Artikel 50: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
Europäische Kommission, Leitlinien zu Artikel 50: https://digital-strategy.ec.europa.eu/en/policies/guidelines-transparency-ai-generated-content
Europäische Kommission, Transparenzkodex: https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content
Europäische Kommission, Durchsetzungsrahmen: https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act
AI Act Service Desk, Artikel 2: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-2
AI Act Service Desk, Artikel 53: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-53

Transparenz- und Prüfstatus

Dieser Entwurf wurde mit Crow/Codex auf Grundlage der lokalen Recherche vom 1. August 2026 und der dort dokumentierten EU-Primärquellen erstellt. Es wurden keine eigenen Praxistests behauptet. Tatsachen und vorgeschlagene redaktionelle Bewertungen sind getrennt. Fristen, Unterzeichnerstand, amtlicher Wortlaut und deutsche Zuständigkeiten müssen vor Veröffentlichung erneut geprüft werden. Die persönliche Position und Veröffentlichung verantwortet Andreas erst nach ausdrücklicher Freigabe.

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.

Freigabe erforderlich: ja. Veröffentlichung erfolgt: nein.

Spende, Support, Steward: Die EU sortiert Open Source – kurz bevor die Meldeuhr startet

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.