Der Cyber Resilience Act kennt keine Kategorie „Maintainer“
Der Begriff kommt in den Leitlinien der Europäischen Kommission vor, und zwar an einer Stelle, auf die es ankommt: Quelloffene Software steht in der Verantwortung derjenigen, die sie veröffentlichen und die primäre Kontrolle über Entwicklung, Releases und Vertriebsentscheidungen ausüben — in den Leitlinien ausdrücklich „often referred to as maintainers“. Dieser Satz begründet die Zurechnung. Er ist kein Ausnahmetatbestand.
Stand: September 2026. Diese Seite gibt allgemeine Informationen und keine Rechtsberatung im Einzelfall.
1. Die drei Positionen
Was aus der Rolle folgt, hängt davon ab, wer sie innehat und wofür die Software bestimmt ist. Die Verordnung kennt drei Positionen, und ein Maintainer nimmt eine von ihnen ein.
Außerhalb des Anwendungsbereichs
Nicht erfasst sind natürliche Personen, die quelloffene Software veröffentlichen, ohne sie zu monetarisieren. Ebenfalls nicht erfasst ist, wer Quellcode zu einem Projekt beiträgt, das er nicht kontrolliert — ein Beitrag begründet keine Pflichten, auch wenn er übernommen wird, und ein bloßer Schreibzugriff auf das Repository ist keine Kontrolle.
Verwalter quelloffener Software
Eine juristische Person, die nicht Herstellerin ist und die Entwicklung quelloffener Software, die für kommerzielle Tätigkeiten bestimmt ist, systematisch und dauerhaft unterstützt sowie deren Lebensfähigkeit sichert. Stiftungen und Konsortien sind die naheliegenden Fälle. Unternehmen, die Bibliotheken veröffentlichen, die sie nicht verkaufen, sind die weniger naheliegenden — und die zahlreicheren.
Fundstelle: Artikel 3 Nr. 14 und Artikel 24 CRA.
Hersteller
Wer ein Produkt mit digitalen Elementen unter eigenem Namen oder eigener Marke im Rahmen einer Geschäftstätigkeit bereitstellt. Ein Entgelt für die vorkompilierte Binärfassung des eigenen quelloffenen Projekts ist das Regelbeispiel der Kommission für diesen Kipppunkt. Dass der Quellcode weiterhin frei verfügbar bleibt, ändert daran nichts.
Fundstelle: Artikel 3 Nr. 13 CRA.
2. Veröffentlichen ist kein Inverkehrbringen — und kein Ausgang
Das Teilen quelloffenen Codes in einem öffentlich zugänglichen Repository ist kein Inverkehrbringen. Das gilt ebenso für unfertige Entwicklungsstände, für Beispielcode und für Projekte, deren Entwicklung von Dritten finanziert wurde. Spenden ändern die Einordnung nicht, auch wenn sie die Projektkosten übersteigen — es sei denn, Releases oder Sicherheitsupdates stehen tatsächlich nur Spendern offen.
Nichts davon stellt ein Projekt außerhalb der Verordnung. Die Verwalterkategorie ist gerade für Software geschaffen, die veröffentlicht, aber nicht auf dem Markt bereitgestellt wird — und der Auslöser ist die Zweckbestimmung. Code, der für die Integration in kommerzielle Produkte und Dienste bestimmt ist, bleibt im Zugriff der Verordnung, so offen er auch veröffentlicht wird. Das Fehlen eines Entgelts entscheidet also nur, welche der beiden Positionen greift, nicht ob eine von ihnen greift.
Praktisch folgt daraus: Der Ausgang ist schmal und hängt an der Rechtsform. Verwalter kann nur eine juristische Person sein. Eine natürliche Person, die ein Projekt ohne Monetarisierung veröffentlicht, ist außerhalb. Ein Unternehmen oder eine Stiftung, die dasselbe tut, ist es nicht.
3. Der Status wird je Projekt festgestellt, nicht je Unternehmen
Ein einheitliches Veröffentlichungskonto, eine einheitliche Marke oder ein einheitlicher Repository-Anbieter tragen keinen einheitlichen Status. Die Feststellung erfolgt für jedes Projekt und jeden Vertriebskanal, und dieselbe Organisation kann Verwalterin einer Komponente und Herstellerin einer anderen sein — oder beides in Bezug auf dieselbe Codebasis, wenn eine unentgeltliche und eine entgeltliche Fassung nebeneinander abgegeben werden.
Das ist keine theoretische Konstruktion. Red Hat hat sich im Juni 2026 für fünfzehn Projekte als Verwalter benannt, darunter Ansible, Fedora und CentOS Stream, und bleibt gleichzeitig Herstellerin von RHEL und OpenShift.
4. Fünf Prüfpunkte, die die Einordnung entscheiden
In den von uns durchgeführten Prüfungen entscheidet selten die Sicherheitsorganisation. Es entscheiden Lizenz- und Vertriebsgestaltungen, die Jahre zuvor aus ganz anderen Gründen verfasst wurden.
Release-Modell und Vertriebskanäle. Wer übergibt dem Endnutzer die kompilierte Fassung — die Organisation selbst über eigene Website, Paketregister oder Installationsprogramme, oder ausschließlich Vendoren und Mitglieder?
Lizenzbedingungen. Der Quellcode muss offen geteilt und so lizenziert sein, dass er frei zugänglich, nutzbar, veränderbar und weiterverbreitbar ist. Ein Ermessenskündigungsrecht, eine Pflicht zur Vernichtung von Kopien oder „fair and reasonable terms“ anstelle einer benannten Open-Source-Lizenz zerstören diese Qualifikation jeweils — und bereits die vorbehaltene Befugnis zur Beschränkung genügt, unabhängig davon, ob sie ausgeübt wird.
Quellcode nur für Mitglieder. Quellcode für Mitglieder, Binärfassungen für alle. Das ist der häufigste Befund und zerstört die Qualifikation als quelloffene Software, bevor die Herstellerfrage überhaupt entsteht.
Eigener Name oder eigene Marke. Eine für Software eingetragene Marke, die auf der Komponente selbst geführt wird, verbunden mit einer Geschäftstätigkeit. Beide Merkmale sind kumulativ: Die Markennutzung allein genügt nicht, und die Markenverwaltung ist ausdrücklich eine verwaltertypische Aufgabe.
Rechteketten von Beitragenden und Vendoren. Ob die Rechtekette lizenzgebührenfrei und dauerhaft ist oder ob Gebühren oder ein Wahlrecht für implementierungsnotwendige Patente bestehen bleiben.
Fundstelle: Artikel 3 Nr. 48 CRA zur Definition quelloffener Software.
5. Was jede Position schuldet — und ab wann
Hersteller unterliegen dem vollen Pflichtenprogramm: den grundlegenden Anforderungen, der Behandlung von Schwachstellen im Unterstützungszeitraum, der technischen Dokumentation, der Konformitätsbewertung und der CE-Kennzeichnung ab dem 11. Dezember 2027 — und den Meldepflichten des Artikels 14 bereits ab dem 11. September 2026.
Verwalter schulden eine Cybersicherheitsrichtlinie und die Zusammenarbeit mit den Marktüberwachungsbehörden nach Artikel 24 Abs. 1 und 2 sowie Meldungen im Umfang des Artikels 24 Abs. 3. Wie weit dieser Umfang reicht, hängt von der Tiefe der Beteiligung ab: rein nicht-technische Unterstützung — Markenverwaltung, Governance-Regeln, Community-Veranstaltungen, Spendeneinwerbung — löst keine Meldepflicht aus; die Bereitstellung der Entwicklungsinfrastruktur löst Meldungen für Vorfälle an dieser Infrastruktur aus; eigene Entwicklerressourcen lösen die Meldung aktiv ausgenutzter Schwachstellen aus. Verwalter bringen keine CE-Kennzeichnung an und unterliegen keiner Konformitätsbewertung.
Zum Datum für Verwalter ist die Lage derzeit ungeklärt. Die Umsetzungs-FAQ der Kommission (Fassung 1.4 vom 4. September 2026, Abschnitt 5.5) und die FAQ der ENISA zur einheitlichen Meldeplattform (Stand 9. September 2026) sagen beide, dass die über Artikel 24 Abs. 3 vermittelten Pflichten erst ab dem 11. Dezember 2027 gelten, und die Plattform nimmt derzeit nur Pflichtmeldungen von Herstellern an. Beide Dokumente sind nicht bindend, und der Vollzug ist national. Ist die Verwalterstellung für ein Projekt nicht festgestellt, gilt der Herstellerweg — und Artikel 14 greift ab dem 11. September 2026 unmittelbar, ohne Verweisung und ohne Datumsfrage. Deshalb steht die Statusfrage vor der Datumsfrage.
Fundstelle: Artikel 71 Abs. 2 CRA zur Geltung.
Die Sanktionslage ist nicht symmetrisch. Das Privileg der Verwalter nimmt allein die Geldbußen des Artikels 64 Abs. 3 bis 9 aus. Artikel 64 Abs. 2, der Verstöße gegen Artikel 14 erfasst, bleibt unberührt — bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes. Eine unzutreffend angenommene Verwalterstellung ist daher kein neutraler Irrtum.
6. Was jetzt zu tun ist
Die Einordnung projektweise feststellen und ihre Grundlage dokumentieren — Lizenz, Öffentlichkeit des Quellcodes, kommerzielle Zweckbestimmung, Tiefe der Unterstützung — in einem Verzeichnis, das aktuell gehalten wird.
Die Meldebereitschaft unabhängig von der Datumsfrage herstellen: ein veröffentlichter und überwachter Sicherheitskontakt mit benannter Person und Vertretung, ein Eingangsprotokoll mit Zeitstempel, das zuständige nationale CSIRT bestimmt und ein dokumentierter Weg von der eingehenden Meldung bis zur Ersteinschätzung binnen 24 Stunden. Die Pflicht ist ereignisausgelöst. Zu einem Stichtag ist nichts abzugeben; vorhanden sein muss die Fähigkeit zu reagieren.
Die jeweils aktuellen Fassungen beider FAQ mit Datum zur Akte nehmen. Sie sind im Einzelfall brauchbares Material. Sie sind keine Grundlage, ein Compliance-Datum zu verschieben.
7. Häufige Fragen
Unterliegt ein Maintainer dem CRA?
Nicht als Maintainer — die Verordnung kennt diese Kategorie nicht. Die Rolle bestimmt, wer die Verantwortung für ein Projekt trägt; ob Pflichten folgen, hängt von der Rechtsform ab, davon, ob die Software monetarisiert wird, und davon, ob sie für kommerzielle Nutzung bestimmt ist.
Wir veröffentlichen auf GitHub und verlangen nichts. Sind wir außerhalb?
Ist „wir“ eine natürliche Person: ja. Ist „wir“ ein Unternehmen oder eine Stiftung und ist die Software für die Integration in kommerzielle Produkte bestimmt, greift das Verwalterregime.
Wir verlangen ein Entgelt für die Binärfassung, der Quellcode bleibt frei. Was sind wir?
Herstellerin der entgeltlichen Fassung und möglicherweise Verwalterin der unentgeltlich veröffentlichten. Beide gelten als verschiedene Produkte.
Macht die Annahme von Spenden uns kommerziell?
In der Regel nicht — auch dann nicht, wenn die Spenden die Projektkosten übersteigen. Anders ist es, wenn der Zugang zu Releases, zu wesentlichen Funktionen oder zu Sicherheitsupdates tatsächlich von einer Spende abhängt.
Treffen unsere Beitragenden Pflichten?
Nein. Wer Quellcode zu einem Projekt beiträgt, das er nicht kontrolliert, trägt keine Pflichten, und ein Schreibzugriff auf das Repository begründet für sich keine Kontrolle.
Ab wann muss ein Verwalter melden?
Kommission und ENISA sagen inzwischen beide: ab dem 11. Dezember 2027. Beide Aussagen sind nicht bindend, und gerichtlich geklärt ist die Frage nicht. Ist die Verwalterstellung nicht festgestellt, gilt Artikel 14 in jedem Fall ab dem 11. September 2026.
Beratung
Wir beraten Hersteller, Einführer, Konsortien, Standardisierungsorganisationen und Träger quelloffener Projekte zum Cyber Resilience Act — von der Einordnung als Hersteller oder Verwalter über Lizenz- und Beitragsrahmen bis zu Offenlegungsrichtlinie, Meldeprozess und Governance. Wir arbeiten projektweise, dokumentieren jede Einordnung belastbar und liefern die Instrumente, die daraus folgen.
Ihr Ansprechpartner: Roman Ronneburger, Rechtsanwalt und Fachanwalt für Urheber- und Medienrecht.
Der Cyber Resilience Act kennt keine Kategorie „Maintainer“
Der Begriff kommt in den Leitlinien der Europäischen Kommission vor, und zwar an einer Stelle, auf die es ankommt: Quelloffene Software steht in der Verantwortung derjenigen, die sie veröffentlichen und die primäre Kontrolle über Entwicklung, Releases und Vertriebsentscheidungen ausüben — in den Leitlinien ausdrücklich „often referred to as maintainers“. Dieser Satz begründet die Zurechnung. Er ist kein Ausnahmetatbestand.
Stand: September 2026. Diese Seite gibt allgemeine Informationen und keine Rechtsberatung im Einzelfall.
1. Die drei Positionen
Was aus der Rolle folgt, hängt davon ab, wer sie innehat und wofür die Software bestimmt ist. Die Verordnung kennt drei Positionen, und ein Maintainer nimmt eine von ihnen ein.
Außerhalb des Anwendungsbereichs
Nicht erfasst sind natürliche Personen, die quelloffene Software veröffentlichen, ohne sie zu monetarisieren. Ebenfalls nicht erfasst ist, wer Quellcode zu einem Projekt beiträgt, das er nicht kontrolliert — ein Beitrag begründet keine Pflichten, auch wenn er übernommen wird, und ein bloßer Schreibzugriff auf das Repository ist keine Kontrolle.
Verwalter quelloffener Software
Eine juristische Person, die nicht Herstellerin ist und die Entwicklung quelloffener Software, die für kommerzielle Tätigkeiten bestimmt ist, systematisch und dauerhaft unterstützt sowie deren Lebensfähigkeit sichert. Stiftungen und Konsortien sind die naheliegenden Fälle. Unternehmen, die Bibliotheken veröffentlichen, die sie nicht verkaufen, sind die weniger naheliegenden — und die zahlreicheren.
Fundstelle: Artikel 3 Nr. 14 und Artikel 24 CRA.
Hersteller
Wer ein Produkt mit digitalen Elementen unter eigenem Namen oder eigener Marke im Rahmen einer Geschäftstätigkeit bereitstellt. Ein Entgelt für die vorkompilierte Binärfassung des eigenen quelloffenen Projekts ist das Regelbeispiel der Kommission für diesen Kipppunkt. Dass der Quellcode weiterhin frei verfügbar bleibt, ändert daran nichts.
Fundstelle: Artikel 3 Nr. 13 CRA.
2. Veröffentlichen ist kein Inverkehrbringen — und kein Ausgang
Das Teilen quelloffenen Codes in einem öffentlich zugänglichen Repository ist kein Inverkehrbringen. Das gilt ebenso für unfertige Entwicklungsstände, für Beispielcode und für Projekte, deren Entwicklung von Dritten finanziert wurde. Spenden ändern die Einordnung nicht, auch wenn sie die Projektkosten übersteigen — es sei denn, Releases oder Sicherheitsupdates stehen tatsächlich nur Spendern offen.
Nichts davon stellt ein Projekt außerhalb der Verordnung. Die Verwalterkategorie ist gerade für Software geschaffen, die veröffentlicht, aber nicht auf dem Markt bereitgestellt wird — und der Auslöser ist die Zweckbestimmung. Code, der für die Integration in kommerzielle Produkte und Dienste bestimmt ist, bleibt im Zugriff der Verordnung, so offen er auch veröffentlicht wird. Das Fehlen eines Entgelts entscheidet also nur, welche der beiden Positionen greift, nicht ob eine von ihnen greift.
Praktisch folgt daraus: Der Ausgang ist schmal und hängt an der Rechtsform. Verwalter kann nur eine juristische Person sein. Eine natürliche Person, die ein Projekt ohne Monetarisierung veröffentlicht, ist außerhalb. Ein Unternehmen oder eine Stiftung, die dasselbe tut, ist es nicht.
3. Der Status wird je Projekt festgestellt, nicht je Unternehmen
Ein einheitliches Veröffentlichungskonto, eine einheitliche Marke oder ein einheitlicher Repository-Anbieter tragen keinen einheitlichen Status. Die Feststellung erfolgt für jedes Projekt und jeden Vertriebskanal, und dieselbe Organisation kann Verwalterin einer Komponente und Herstellerin einer anderen sein — oder beides in Bezug auf dieselbe Codebasis, wenn eine unentgeltliche und eine entgeltliche Fassung nebeneinander abgegeben werden.
Das ist keine theoretische Konstruktion. Red Hat hat sich im Juni 2026 für fünfzehn Projekte als Verwalter benannt, darunter Ansible, Fedora und CentOS Stream, und bleibt gleichzeitig Herstellerin von RHEL und OpenShift.
4. Fünf Prüfpunkte, die die Einordnung entscheiden
In den von uns durchgeführten Prüfungen entscheidet selten die Sicherheitsorganisation. Es entscheiden Lizenz- und Vertriebsgestaltungen, die Jahre zuvor aus ganz anderen Gründen verfasst wurden.
Release-Modell und Vertriebskanäle. Wer übergibt dem Endnutzer die kompilierte Fassung — die Organisation selbst über eigene Website, Paketregister oder Installationsprogramme, oder ausschließlich Vendoren und Mitglieder?
Lizenzbedingungen. Der Quellcode muss offen geteilt und so lizenziert sein, dass er frei zugänglich, nutzbar, veränderbar und weiterverbreitbar ist. Ein Ermessenskündigungsrecht, eine Pflicht zur Vernichtung von Kopien oder „fair and reasonable terms“ anstelle einer benannten Open-Source-Lizenz zerstören diese Qualifikation jeweils — und bereits die vorbehaltene Befugnis zur Beschränkung genügt, unabhängig davon, ob sie ausgeübt wird.
Quellcode nur für Mitglieder. Quellcode für Mitglieder, Binärfassungen für alle. Das ist der häufigste Befund und zerstört die Qualifikation als quelloffene Software, bevor die Herstellerfrage überhaupt entsteht.
Eigener Name oder eigene Marke. Eine für Software eingetragene Marke, die auf der Komponente selbst geführt wird, verbunden mit einer Geschäftstätigkeit. Beide Merkmale sind kumulativ: Die Markennutzung allein genügt nicht, und die Markenverwaltung ist ausdrücklich eine verwaltertypische Aufgabe.
Rechteketten von Beitragenden und Vendoren. Ob die Rechtekette lizenzgebührenfrei und dauerhaft ist oder ob Gebühren oder ein Wahlrecht für implementierungsnotwendige Patente bestehen bleiben.
Fundstelle: Artikel 3 Nr. 48 CRA zur Definition quelloffener Software.
5. Was jede Position schuldet — und ab wann
Hersteller unterliegen dem vollen Pflichtenprogramm: den grundlegenden Anforderungen, der Behandlung von Schwachstellen im Unterstützungszeitraum, der technischen Dokumentation, der Konformitätsbewertung und der CE-Kennzeichnung ab dem 11. Dezember 2027 — und den Meldepflichten des Artikels 14 bereits ab dem 11. September 2026.
Verwalter schulden eine Cybersicherheitsrichtlinie und die Zusammenarbeit mit den Marktüberwachungsbehörden nach Artikel 24 Abs. 1 und 2 sowie Meldungen im Umfang des Artikels 24 Abs. 3. Wie weit dieser Umfang reicht, hängt von der Tiefe der Beteiligung ab: rein nicht-technische Unterstützung — Markenverwaltung, Governance-Regeln, Community-Veranstaltungen, Spendeneinwerbung — löst keine Meldepflicht aus; die Bereitstellung der Entwicklungsinfrastruktur löst Meldungen für Vorfälle an dieser Infrastruktur aus; eigene Entwicklerressourcen lösen die Meldung aktiv ausgenutzter Schwachstellen aus. Verwalter bringen keine CE-Kennzeichnung an und unterliegen keiner Konformitätsbewertung.
Zum Datum für Verwalter ist die Lage derzeit ungeklärt. Die Umsetzungs-FAQ der Kommission (Fassung 1.4 vom 4. September 2026, Abschnitt 5.5) und die FAQ der ENISA zur einheitlichen Meldeplattform (Stand 9. September 2026) sagen beide, dass die über Artikel 24 Abs. 3 vermittelten Pflichten erst ab dem 11. Dezember 2027 gelten, und die Plattform nimmt derzeit nur Pflichtmeldungen von Herstellern an. Beide Dokumente sind nicht bindend, und der Vollzug ist national. Ist die Verwalterstellung für ein Projekt nicht festgestellt, gilt der Herstellerweg — und Artikel 14 greift ab dem 11. September 2026 unmittelbar, ohne Verweisung und ohne Datumsfrage. Deshalb steht die Statusfrage vor der Datumsfrage.
Fundstelle: Artikel 71 Abs. 2 CRA zur Geltung.
Die Sanktionslage ist nicht symmetrisch. Das Privileg der Verwalter nimmt allein die Geldbußen des Artikels 64 Abs. 3 bis 9 aus. Artikel 64 Abs. 2, der Verstöße gegen Artikel 14 erfasst, bleibt unberührt — bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes. Eine unzutreffend angenommene Verwalterstellung ist daher kein neutraler Irrtum.
6. Was jetzt zu tun ist
Die Einordnung projektweise feststellen und ihre Grundlage dokumentieren — Lizenz, Öffentlichkeit des Quellcodes, kommerzielle Zweckbestimmung, Tiefe der Unterstützung — in einem Verzeichnis, das aktuell gehalten wird.
Die Meldebereitschaft unabhängig von der Datumsfrage herstellen: ein veröffentlichter und überwachter Sicherheitskontakt mit benannter Person und Vertretung, ein Eingangsprotokoll mit Zeitstempel, das zuständige nationale CSIRT bestimmt und ein dokumentierter Weg von der eingehenden Meldung bis zur Ersteinschätzung binnen 24 Stunden. Die Pflicht ist ereignisausgelöst. Zu einem Stichtag ist nichts abzugeben; vorhanden sein muss die Fähigkeit zu reagieren.
Die jeweils aktuellen Fassungen beider FAQ mit Datum zur Akte nehmen. Sie sind im Einzelfall brauchbares Material. Sie sind keine Grundlage, ein Compliance-Datum zu verschieben.
7. Häufige Fragen
Unterliegt ein Maintainer dem CRA?
Nicht als Maintainer — die Verordnung kennt diese Kategorie nicht. Die Rolle bestimmt, wer die Verantwortung für ein Projekt trägt; ob Pflichten folgen, hängt von der Rechtsform ab, davon, ob die Software monetarisiert wird, und davon, ob sie für kommerzielle Nutzung bestimmt ist.
Wir veröffentlichen auf GitHub und verlangen nichts. Sind wir außerhalb?
Ist „wir“ eine natürliche Person: ja. Ist „wir“ ein Unternehmen oder eine Stiftung und ist die Software für die Integration in kommerzielle Produkte bestimmt, greift das Verwalterregime.
Wir verlangen ein Entgelt für die Binärfassung, der Quellcode bleibt frei. Was sind wir?
Herstellerin der entgeltlichen Fassung und möglicherweise Verwalterin der unentgeltlich veröffentlichten. Beide gelten als verschiedene Produkte.
Macht die Annahme von Spenden uns kommerziell?
In der Regel nicht — auch dann nicht, wenn die Spenden die Projektkosten übersteigen. Anders ist es, wenn der Zugang zu Releases, zu wesentlichen Funktionen oder zu Sicherheitsupdates tatsächlich von einer Spende abhängt.
Treffen unsere Beitragenden Pflichten?
Nein. Wer Quellcode zu einem Projekt beiträgt, das er nicht kontrolliert, trägt keine Pflichten, und ein Schreibzugriff auf das Repository begründet für sich keine Kontrolle.
Ab wann muss ein Verwalter melden?
Kommission und ENISA sagen inzwischen beide: ab dem 11. Dezember 2027. Beide Aussagen sind nicht bindend, und gerichtlich geklärt ist die Frage nicht. Ist die Verwalterstellung nicht festgestellt, gilt Artikel 14 in jedem Fall ab dem 11. September 2026.
Beratung
Wir beraten Hersteller, Einführer, Konsortien, Standardisierungsorganisationen und Träger quelloffener Projekte zum Cyber Resilience Act — von der Einordnung als Hersteller oder Verwalter über Lizenz- und Beitragsrahmen bis zu Offenlegungsrichtlinie, Meldeprozess und Governance. Wir arbeiten projektweise, dokumentieren jede Einordnung belastbar und liefern die Instrumente, die daraus folgen.
Ihr Ansprechpartner: Roman Ronneburger, Rechtsanwalt und Fachanwalt für Urheber- und Medienrecht.