Ein Tier-1-Zulieferer aus dem schwäbischen Mittelstand steht kurz vor der Serienfreigabe eines neuen Steuergerätemoduls. Der Softwarehersteller fordert kurzfristig eine Nachlizenzierung für die im Fahrzeugsteuergerät eingebettete Bibliothek – anderenfalls werde er die Nutzung der Entwicklungsumgebung sperren. Der Produktionsanlauf liegt in drei Wochen. Was wie ein technisches Beschaffungsproblem wirkt, ist in Wirklichkeit ein vertragsrechtlicher Notfall mit unmittelbaren Haftungsfolgen für die Geschäftsführung.
Softwareüberlassung und Softwarelizenzen im Automobilzulieferergeschäft unterliegen einem Zusammenspiel aus Urheberrecht (UrhG), kaufrechtlichen und mietrechtlichen Vorschriften des BGB sowie branchenspezifischen Besonderheiten der AUTOSAR- und ASPICE-Welt. Entscheidend ist, ob ein Nutzungsrecht wirksam eingeräumt wurde, welche Nutzungsart vereinbart ist und wie das Vertragswerk auf die Besonderheiten von Embedded Software, Over-the-Air-Updates (OTA) und die Lieferkettenverpflichtungen gegenüber OEM-Auftraggebern abgestimmt ist. Fehler in der Lizenzgestaltung führen zu Unterlassungsansprüchen, Schadensersatz und – im Extremfall – zum Lieferstopp, der die Vertragsstrafen des OEM-Rahmenvertrags auslöst.
Dieser Branchenreport zeigt, welche Rechtsfragen Geschäftsführer von Automobilzulieferern beim Abschluss und der Pflege von Softwareverträgen kennen müssen, welche typischen Fallstricke in der Praxis auftreten und welche Handlungsoptionen zur Absicherung bestehen.
Rechtsrahmen: Welche Normen regeln die Softwareüberlassung im Automobilumfeld?
Das deutsche Recht kennt keinen einheitlichen „Softwarevertrag". Maßgeblich ist das Urheberrechtsgesetz (UrhG) als Schutzgesetz für die Software selbst sowie das BGB für die schuldrechtliche Einordnung des Überlassungsverhältnisses. Je nach Vertragskonstruktion gilt Kauf-, Miet- oder Werkvertragsrecht – mit erheblichen Konsequenzen für Gewährleistung, Kündigung und Schadensersatz.
Software ist nach § 69a UrhG als Werk der Literatur urheberrechtlich geschützt, sobald sie das Ergebnis eigener geistiger Schöpfung des Herstellers ist. Der Schutz entsteht ohne Anmeldung und ohne Eintragung automatisch. Das Recht zur Nutzung der Software muss vertraglich eingeräumt werden (§ 31 UrhG, sog. Lizenz). Fehlt eine wirksame Einräumung, nutzt der Lizenznehmer die Software rechtswidrig – mit der Folge von Unterlassungs- und Schadensersatzansprüchen des Rechtsinhabers nach §§ 97 ff. UrhG.
Für die schuldrechtliche Einordnung hat der Bundesgerichtshof in einer Reihe von Entscheidungen zur Dauerlizenz für Standardsoftware die kaufrechtlichen Vorschriften der §§ 433 ff. BGB für anwendbar erklärt, wenn dem Lizenznehmer ein dauerhaftes Nutzungsrecht ohne zeitliche Begrenzung eingeräumt wird. Bei befristeten Lizenzen – und das ist im Automobilbereich bei SaaS-basierten Entwicklungswerkzeugen sowie bei abonnierten AUTOSAR-Bibliotheken die Regel – greifen die mietrechtlichen Vorschriften der §§ 535 ff. BGB. Die Unterscheidung ist kein akademisches Problem: Im Kaufrecht gilt eine Verjährungsfrist von grundsätzlich zwei Jahren für Sachmängelansprüche (§ 438 BGB), während im Mietrecht Mangelsrechte anderen Regeln folgen und die regelmäßige Verjährung nach § 195 BGB in der Regel nach drei Jahren eintritt.
In der Mandatspraxis sehen wir regelmäßig, dass Zulieferer diesen Unterschied erst dann erkennen, wenn ein Streit über fehlerhafte Softwarekomponenten bereits eskaliert ist. Die vertragstypologische Einordnung sollte daher schon bei der Vertragsgestaltung geprüft werden, nicht erst im Konfliktszenario.
Nutzungsrechte: Was darf der Zulieferer tatsächlich?
Das Kernproblem vieler Softwareverträge in der Automobilzulieferkette ist die unklare Abgrenzung der eingeräumten Nutzungsarten. Nach dem Spezifitätsprinzip des § 31 Abs. 5 UrhG gilt: Wurden bestimmte Nutzungsarten nicht ausdrücklich vereinbart, verbleiben sie beim Urheber. Im Zweifel erhält der Lizenznehmer nur das Minimum dessen, was für den Vertragszweck unbedingt erforderlich ist.
Für Automobilzulieferer ist das in mehrfacher Hinsicht gefährlich. Erstens: Wird eine Softwarekomponente lizenziert, die in ein Steuergerät (ECU) eingebettet und anschließend an den OEM geliefert wird, stellt die Weitergabe an den OEM-Kunden eine eigene Nutzungshandlung dar. Die Lizenz muss ausdrücklich das Recht zur Vervielfältigung und Weitergabe in eingebetteter Form (sog. Embedded Use) einschließen. Fehlt diese Berechtigung, begeht der Zulieferer mit jeder ausgelieferten Einheit eine Urheberrechtsverletzung.
Zweitens betreffen Over-the-Air-Updates (OTA), mit denen Fahrzeughersteller zunehmend Softwarekomponenten im Fahrzeug nach der Auslieferung aktualisieren, eine neue Nutzungsart, die in klassischen Embedded-Lizenzverträgen nicht vorgesehen ist. Wer eine Softwarekomponente liefert, die OTA-fähig sein soll, benötigt eine Lizenz, die explizit die Aktualisierung und Verteilung über Fahrzeug-Update-Kanäle abdeckt.
Drittens stellt die im Automobilumfeld gängige Arbeitsteilung zwischen Tier-1 und Tier-2-Zulieferern eigene lizenzrechtliche Anforderungen. Der Tier-1 muss sicherstellen, dass er die von Tier-2-Lieferanten zugekaufte Software mit dem Recht weiterverkauft, das er dem OEM schuldet – oder dass er selbst die entsprechenden Lizenzen beim Urheber einholt. In der Praxis existiert hier häufig eine Lizenzkette mit Lücken.
Nach unserer Erfahrung ist der Embedded-Use-Fehler der häufigste und kostspieligste Lizenzverstoß in der Automobilzulieferkette. Die Aufdeckung erfolgt meist anlässlich eines Lieferantenwechsels, einer Due-Diligence-Prüfung oder einer direkten Abmahnung des Softwareherstellers.
Vertragstypen in der Praxis: Kauf, Miete oder Open Source?
Automobilzulieferer begegnen im Alltag drei grundlegenden Lizenzmodellen, die jeweils eigene Risikoprofile mit sich bringen.
Das klassische Dauerlizenzmodell – eine einmalige Zahlung, unbegrenztes Nutzungsrecht – entspricht schuldrechtlich einem Kauf. Es bietet Planungssicherheit, schließt aber die Abhängigkeit von einem einzigen Anbieter nicht aus. Besonders kritisch: Wenn der Softwareanbieter insolvent wird oder sein Produkt einstellt, ist der Zulieferer auf die bei Vertragsschluss erworbene Version angewiesen. Ohne Source-Code-Hinterlegung (sog. Software-Escrow) fehlt im Insolvenzfall die Möglichkeit, Wartung und Weiterentwicklung sicherzustellen.
Abonnement- und SaaS-Modelle folgen mietrechtlichen Regeln. Sie sind im Bereich von Entwicklungswerkzeugen (z. B. AUTOSAR-Konfigurationstools, Hardware-in-the-Loop-Systeme) weit verbreitet. Wesentliches Risiko: Der Anbieter kann nach ordentlicher Kündigung oder nach Ablauf der Vertragslaufzeit die Nutzung einstellen – mit sofortiger Wirkung auf laufende Entwicklungsprojekte. In der Mandatspraxis sehen wir, dass Mindestlaufzeiten und Verlängerungsklauseln in solchen Verträgen häufig übersehen werden, bis kurz vor dem automatischen Auslaufen.
Open-Source-Software (OSS) ist im Automotive-Bereich allgegenwärtig – von Linux-basierten Infotainment-Systemen bis zu AUTOSAR Adaptive Platform-Implementierungen. OSS ist nicht kostenlos, sie ist frei. Sie unterliegt Lizenzbedingungen (z. B. GPL, LGPL, MIT, Apache), deren Nichteinhaltung Urheberrechtsverletzungen begründet und im Extremfall dazu führt, dass proprietäre Eigenentwicklungen des Zulieferers ebenfalls unter die Copyleft-Verpflichtung fallen. Ein systematisches OSS-Compliance-Programm – einschließlich Software-Composition-Analyse und SBOM (Software Bill of Materials) – ist nach unserer Bewertung für jeden Tier-1-Zulieferer eine Pflicht, keine Kür.
Welches Modell im Einzelfall geeignet ist, hängt von der strategischen Bedeutung der Software, dem Investitionsvolumen, der geplanten Nutzungsdauer und der Lieferkettenstruktur ab. Diese Entscheidung sollte nicht allein der IT-Einkauf treffen, sondern unter Einbeziehung rechtlicher Beratung.
Gewährleistung und Haftung: Wer haftet für fehlerhafte Softwarekomponenten?
Softwarefehler können im Automobilumfeld erhebliche Folgekosten auslösen: Rückrufaktionen, OEM-Vertragsstrafen, Produkthaftungsansprüche. Die rechtliche Verteilung dieser Risiken zwischen Softwareanbieter und Zulieferer hängt entscheidend von der Vertragsgestaltung ab.
Bei kaufrechtlich einzuordnenden Dauerlizenzverträgen haftet der Verkäufer nach §§ 434, 435, 437 ff. BGB für Sach- und Rechtsmängel. Ein Sachmangel liegt vor, wenn die Software nicht die vereinbarte Beschaffenheit aufweist – also z. B. nicht die zugesicherten Funktionen erfüllt, nicht die Schnittstellen unterstützt oder systematische Fehler enthält. Ein Rechtsmangel liegt vor, wenn Dritte aufgrund bestehender Rechte (z. B. Schutzrechte) die Nutzung beschränken können.
Haftungsbeschränkungsklauseln in Software-AGB sind allgegenwärtig. Nach §§ 305 ff. BGB unterliegen solche AGB-Klauseln einer Inhaltskontrolle; unangemessene Benachteiligungen führen zur Unwirksamkeit. In der Praxis werden AGB-Haftungsausschlüsse bei grober Fahrlässigkeit und Vorsatz regelmäßig als unwirksam eingestuft, während Haftungsobergrenzen bei einfacher Fahrlässigkeit grundsätzlich anerkannt werden, soweit der Kernbereich vertraglicher Hauptpflichten nicht ausgehöhlt wird.
Für die Geschäftsführung des Zulieferers ist relevant: Wenn der Softwarehersteller seine Haftung wirksam auf einen bestimmten Betrag gedeckelt hat, der weit unter dem möglichen OEM-Schaden liegt, bleibt der Zulieferer selbst auf dem Schaden sitzen. Der Aufbau einer Regressionskette in der Lieferkette – von OEM über Tier-1 bis zum Softwareanbieter – scheitert häufig an diesen vertraglichen Haftungsgrenzen. Wer hier keine eigene Risikobewertung vornimmt, übernimmt unbewusst unversichertes Haftungsrisiko.
OEM-Anforderungen und Supply-Chain-Compliance: Was verlangen die Fahrzeughersteller?
OEM-Rahmenverträge und Einkaufsbedingungen großer Fahrzeughersteller enthalten zunehmend detaillierte Anforderungen an die Softwarelizenzierung ihrer Zulieferer. Diese Anforderungen umfassen in der Regel mindestens drei Bereiche.
Erstens verlangen OEMs die vollständige Bereinigung von Softwarekomponenten von OSS-Lizenzkonflikten und häufig die Vorlage einer SBOM (Software Bill of Materials), die alle lizenzierten und open-source Bestandteile dokumentiert. Zweitens enthalten die Qualitätsmanagement-Anforderungen (IATF 16949, ASPICE) Vorgaben, die mittelbar die Dokumentation von Softwarelizenzen und die Nachverfolgbarkeit von Softwareversionen betreffen. Drittens schließen OEM-Verträge regelmäßig Schutzrechtsfreistellungsklauseln ein: Der Zulieferer sichert zu, dass seine Lieferungen keine Rechte Dritter verletzen, und stellt den OEM von etwaigen Ansprüchen frei.
Diese Freistellungsverpflichtungen können im Ernstfall erhebliche wirtschaftliche Konsequenzen haben. Macht ein Softwarerechteinhaber gegenüber dem OEM Ansprüche geltend, leitet der OEM diese aufgrund der Freistellungsklausel in der Regel an den verantwortlichen Zulieferer weiter. Der Zulieferer steht dann in einem Dreiecksverhältnis: gegenüber dem OEM aus dem Freistellungsversprechen verpflichtet und gegenüber dem Softwareanbieter auf den vertraglichen Haftungsrahmen beschränkt.
Wir beraten regelmäßig mittelständische Zulieferer, die erst im Zuge einer OEM-Lieferantenprüfung oder eines Audits auf diese Lücken in ihrer Lizenzstruktur aufmerksam werden. Eine proaktive Lizenz-Compliance-Prüfung ist erheblich günstiger als die reaktive Schadensbegrenzung im Auditfall.
Typische Fehler in der Vertragsgestaltung: Worauf müssen Geschäftsführer besonders achten?
Aus der Mandatspraxis lassen sich die häufigsten Fehler bei der Gestaltung von Softwareverträgen in der Automobilzulieferkette klar benennen.
Der erste und folgenreichste Fehler ist die unvollständige Beschreibung der Nutzungsrechte. Verträge regeln häufig die Zahlung präzise, aber die Nutzungsart bleibt vage. „Nutzung der Software für betriebliche Zwecke" ist keine ausreichende Beschreibung, wenn Software in Serienprodukte eingebettet, in Hunderttausenden Einheiten ausgeliefert und möglicherweise OTA aktualisiert werden soll. Welche Stückzahlen sind abgedeckt? Welche Derivate und Weiterentwicklungen? Gilt die Lizenz für verbundene Unternehmen?
Ein zweiter struktureller Fehler betrifft Laufzeit- und Kündigungsregelungen. Im Produktentwicklungsgeschäft der Automobilindustrie laufen Fahrzeugprojekte häufig acht bis zwölf Jahre. Wird eine Softwarelizenz mit einer Laufzeit von drei Jahren für ein solches Projekt verwendet, entsteht ein strukturelles Risiko der Lizenzverfügbarkeit. Laufzeit, Verlängerungsoptionen und Preisanpassungsklauseln müssen im Einklang mit dem Fahrzeugprojekt-Zeitplan stehen.
Ein dritter Fehler ist das Fehlen von Quellcode-Hinterlegungsvereinbarungen. Wenn der Softwareanbieter die einzige Partei ist, die den Quellcode beherrscht, und er insolvent wird oder das Produkt einstellt, verliert der Zulieferer die Fähigkeit zur Wartung und Weiterentwicklung. Eine Software-Escrow-Vereinbarung, bei der eine unabhängige Treuhandstelle den Quellcode hält und diesen unter definierten Bedingungen freigibt, schließt diese Lücke.
Schließlich wird die Frage der Datenhoheit bei cloud-basierten Entwicklungstools und vernetzten Testumgebungen regelmäßig unterschätzt. Wer die Entwicklungsumgebung als SaaS-Dienst nutzt, lädt Konstruktionsdaten, Testergebnisse und Parametersätze auf Server des Anbieters. Die Frage, wem diese Daten gehören, wie sie nach Vertragsende zurückgegeben werden und ob der Anbieter sie für eigene Zwecke nutzen darf, sollte vertraglich eindeutig geregelt sein – auch mit Blick auf Betriebsgeheimnisschutz und potenzielle Ansprüche nach dem Geschäftsgeheimnisgesetz (GeschGehG).
Datenschutz und vernetzte Fahrzeugsoftware: DSGVO-Bezüge im Zulieferergeschäft
Softwareüberlassung und Softwarelizenzen sind in der modernen Automobilzulieferkette nicht mehr von Datenschutzfragen trennbar. Steuergeräte, Telematikmodule und Fahrerassistenzsysteme verarbeiten Fahrzeugdaten, die je nach Auslegung auch personenbezogene Daten der Fahrzeugnutzer sein können.
Wenn ein Zulieferer Software liefert, die personenbezogene Daten verarbeitet, ist er in der Regel Auftragsverarbeiter im Sinne der DSGVO, sofern er die Daten im Auftrag des OEM verarbeitet. Dies verpflichtet ihn zum Abschluss eines Auftragsverarbeitungsvertrags (Art. 28 DSGVO) und zur Einhaltung technischer und organisatorischer Maßnahmen. Bei Datenschutzverletzungen drohen Bußgelder bis zu 20 Millionen Euro oder bis zu vier Prozent des weltweiten Jahresumsatzes (Art. 83 DSGVO), je nachdem welcher Betrag höher ist. Datenschutzverletzungen müssen zudem binnen 72 Stunden nach Kenntnisnahme der zuständigen Aufsichtsbehörde gemeldet werden (Art. 33 DSGVO).
Für die Praxis bedeutet dies: Softwareverträge, die datengenerierungsrelevante Komponenten betreffen, müssen nicht nur die Nutzungsrechte, sondern auch die datenschutzrechtliche Verantwortlichkeit klar regeln. Wer datenschutzrechtliche Pflichten aus dem Softwarevertrag herauslässt, riskiert neben Bußgeldern auch eine persönliche Haftung der Geschäftsführung nach nationalen Aufsichtsregeln.
Die Frage, ob und unter welchen Bedingungen Fahrzeugdaten an Dritte weitergegeben werden dürfen – etwa an Softwareanbieter für Diagnosezwecke –, ist eine der zentralen ungelösten Rechtsfragen im Connected-Car-Umfeld. Der europäische Data Act (in Kraft seit September 2023, Anwendbarkeit ab September 2025) wird hier neue Pflichten und Rechte einführen, die auf Zuliefererebene vertraglich antizipiert werden sollten.
Mikro-Fall aus der Mandatspraxis
In einem aktuellen Mandat beriet die Kanzlei ein mittelständisches Tier-1-Unternehmen aus der Automobilzulieferindustrie mit rund 1.500 Mitarbeitern und Werken in Deutschland und Polen. Ausgangslage: Im Rahmen einer OEM-Lieferantenqualifizierung wurde festgestellt, dass mehrere im Serienprodukt eingesetzte Open-Source-Softwarekomponenten unter der GNU General Public License Version 2 (GPL v2) lizenziert waren. Die betreffenden Komponenten waren über mehrere Entwicklungsgenerationen in eine proprietäre Steuergeräte-Software eingebettet worden, ohne dass die Copyleft-Verpflichtungen der GPL v2 beachtet worden waren. Der OEM drohte mit Lieferstopp bis zur vollständigen Lizenzbereinigung. Vorgehen: Die Kanzlei führte gemeinsam mit einem Softwareaudit-Spezialisten eine vollständige Software-Composition-Analyse durch, identifizierte die betroffenen Komponenten, prüfte Ersatzmöglichkeiten mit permissiveren Lizenzen und begleitete die rechtliche Dokumentation gegenüber dem OEM. Ergebnis: Innerhalb von rund acht Wochen konnte die Lizenzbereinigung abgeschlossen und die Lieferantenqualifizierung erfolgreich abgeschlossen werden. Der Lieferstopp wurde abgewendet. Wirtschaftliche Einschränkungen durch die Bereinigungsphase ließen sich erheblich reduzieren, ohne dass konkrete Vertragsstrafen anfielen – konkrete Beträge werden aus Vertraulichkeitsgründen nicht genannt.
Handlungsempfehlungen: Nächste Schritte für Geschäftsführer in der Automobilzulieferkette
Welche Maßnahmen sollten Geschäftsführer von Automobilzulieferern jetzt ergreifen, um ihre Softwarelizenz-Compliance strukturell abzusichern? Aus der Mandatspraxis lassen sich fünf Handlungsfelder benennen.
Erstens: Lizenzbestandsaufnahme. Ohne vollständige Kenntnis der im Unternehmen eingesetzten Software und der dazugehörigen Lizenzbedingungen lässt sich keine Compliance sicherstellen. Dies gilt für Eigenentwicklungen und zugekaufte Komponenten gleichermaßen. Eine SBOM (Software Bill of Materials) ist nicht nur ein OEM-Anforderungsdokument, sondern ein internes Steuerungsinstrument.
Zweitens: Vertragsprüfung auf Nutzungsrechtsumfang. Bestehende Softwareverträge sollten auf Vollständigkeit der Nutzungsrechtsbeschreibung geprüft werden. Insbesondere: Ist Embedded Use explizit geregelt? Ist das Recht zur Weitergabe in Serienprodukte enthalten? Ist OTA-Update-Fähigkeit abgedeckt? Stimmt die Stückzahlbegrenzung mit dem tatsächlichen Serienvolumen überein?
Drittens: Laufzeitabgleich mit Fahrzeugprojekten. Softwarelizenzlaufzeiten sollten mit dem Fahrzeugprojekt-Zeitplan abgestimmt werden. Läuft eine Lizenz vor dem Serienanlauf oder während der Serienphase aus, entsteht ein strukturelles Beschaffungsrisiko, das frühzeitig adressiert werden sollte.
Viertens: Escrow für strategisch kritische Software. Für Software, die in laufende Serienprodukte eingebettet ist und deren Wegfall die Lieferfähigkeit gefährden würde, sollte eine Quellcode-Hinterlegungsvereinbarung mit einer unabhängigen Treuhandstelle geprüft werden.
Fünftens: OSS-Compliance-Programm. Open-Source-Lizenzbedingungen sind nicht verhandelbar – sie gelten kraft Gesetz. Ein formales OSS-Compliance-Programm, das regelmäßige Software-Composition-Analysen und die Dokumentation von Lizenzpflichten umfasst, ist für jeden Zulieferer mit eigenem Softwareentwicklungsanteil ein notwendiges Risikomanagement-Instrument.
Die vorstehende Darstellung betrifft die Regelfälle. Ihr konkreter Fall erfordert die Prüfung von Unterlagen, Vertragswerken, Fristen und der einschlägigen Rechtsprechung. Zur Einschätzung, wo in Ihrem Softwarevertragsportfolio Handlungsbedarf besteht, und für eine erste Durchsicht Ihrer Unterlagen erreichen Sie uns unter info@brandtfalk.com.
Die vorstehende Darstellung umreißt den rechtlichen Rahmen für Softwareüberlassung und Softwarelizenzen in der Automobilzulieferkette. Ob Ihre bestehenden Lizenzverträge OEM-Anforderungen standhält, ob Ihre OSS-Compliance lückenlos dokumentiert ist und wie Sie Open-Source-Risiken strukturell minimieren – das lässt sich nur anhand Ihrer konkreten Unterlagen beurteilen. Für eine erste Durchsicht Ihrer Vertragsunterlagen schreiben Sie an info@brandtfalk.com.
Verwandte Leistungen
Häufige Fragen zur Softwareüberlassung in der Automobilzulieferindustrie
Was ist der rechtliche Unterschied zwischen einer Dauerlizenz und einer Abonnementlizenz bei Software?
Bei einer Dauerlizenz wird dem Nutzer ein zeitlich unbegrenztes Nutzungsrecht eingeräumt; die Rechtsprechung ordnet diesen Vertrag in der Regel als Kauf ein (§§ 433 ff. BGB). Daraus folgen kaufrechtliche Gewährleistungsrechte und eine Gewährleistungsfrist von grundsätzlich zwei Jahren. Bei einer Abonnementlizenz handelt es sich um ein zeitlich befristetes, wiederkehrendes Nutzungsverhältnis, das mietrechtlichen Regelungen unterliegt (§§ 535 ff. BGB). Die Unterscheidung bestimmt, welche Rechte bei Mängeln, bei Kündigung und bei Vertragsende bestehen – und wie lange Ansprüche geltend gemacht werden können.
Reicht eine Standard-Software-Lizenz aus, wenn ich als Tier-1-Zulieferer Software in Serienprodukte einbette und an den OEM liefere?
In der Regel nicht. Standard-Endnutzerlizenzen (EULA) berechtigen typischerweise zur internen Nutzung auf eigenen Systemen. Das Einbetten in ein Serienprodukt und die Weitergabe an einen OEM-Kunden stellt eine eigene Nutzungshandlung dar, die ausdrücklich lizenziert sein muss – insbesondere als sog. Embedded Use oder OEM-Distribution-Recht. Fehlt diese ausdrückliche Berechtigung, liegt mit jeder ausgelieferten Einheit eine Urheberrechtsverletzung vor. Eine anwaltliche Prüfung des konkreten Lizenzvertrags ist unerlässlich.
Was bedeutet Copyleft bei Open-Source-Lizenzen konkret für Automobilzulieferer?
Copyleft-Lizenzen wie die GPL verpflichten dazu, abgeleitete Werke unter denselben Lizenzbedingungen weiterzugeben – einschließlich der Pflicht zur Offenlegung des Quellcodes. Wird GPL-lizenzierte Software in eine proprietäre Steuergeräte-Software eingebettet, kann dies dazu führen, dass die gesamte Steuergeräte-Software unter die GPL fällt. Dies hätte die Pflicht zur Quellcode-Offenlegung gegenüber jedem Empfänger der Software – also auch dem OEM-Kunden – zur Folge. Eine Software-Composition-Analyse und ein formales OSS-Compliance-Programm sind daher für Zulieferer mit Softwareentwicklungsanteil essenziell.
Was ist eine SBOM und warum verlangen OEMs sie?
Eine SBOM (Software Bill of Materials) ist ein strukturiertes Verzeichnis aller Softwarekomponenten, Bibliotheken und deren Lizenzinformationen, die in einem Produkt enthalten sind. OEMs verlangen SBOMs, um ihrer eigenen Open-Source-Compliance nachkommen zu können, Schutzrechtsrisiken in der Lieferkette zu bewerten und bei Sicherheitslücken (CVEs) schnell feststellen zu können, welche Lieferantenprodukte betroffen sind. Für Zulieferer ist die SBOM nicht nur ein Erfüllungsdokument gegenüber dem OEM, sondern ein internes Steuerungsinstrument für Lizenz- und Sicherheits-Compliance.
Wie schütze ich mein Unternehmen, wenn der Softwareanbieter insolvent wird?
Eine Software-Escrow-Vereinbarung stellt die Verfügbarkeit des Quellcodes auch im Insolvenz- oder Einstellungsfall des Anbieters sicher. Dabei hinterlegt der Softwareanbieter den Quellcode bei einer unabhängigen Treuhandstelle, die diesen unter vertraglich definierten Freigabebedingungen – etwa Insolvenz, eingestellten Support oder Produktabkündigung – an den Lizenznehmer herausgibt. Für Softwarekomponenten, die in Serienprodukte eingebettet sind und deren Wegfall die Lieferfähigkeit gefährden würde, ist eine solche Vereinbarung nach unserer Einschätzung ein notwendiger Baustein des Risikomanagements.
Welche datenschutzrechtlichen Pflichten entstehen, wenn meine Steuergeräte-Software Fahrzeugdaten verarbeitet?
Soweit die verarbeiteten Fahrzeugdaten Personen identifizierbar machen – was bei vernetzten Fahrzeugen häufig der Fall ist –, unterliegt die Verarbeitung der DSGVO. Als Softwarelieferant, der im Auftrag des OEM oder Fahrzeughalters Daten verarbeitet, sind Sie in der Regel Auftragsverarbeiter nach Art. 28 DSGVO. Dies erfordert den Abschluss eines Auftragsverarbeitungsvertrags, die Umsetzung technischer und organisatorischer Maßnahmen sowie – bei Datenpannen – die Meldung binnen 72 Stunden. Bei Verstößen drohen Bußgelder bis zu 20 Millionen Euro oder bis zu vier Prozent des weltweiten Jahresumsatzes. Datenschutzrechtliche Verpflichtungen sollten daher integraler Bestandteil von Softwareverträgen sein.
Welche Fristen gelten für Gewährleistungsansprüche bei fehlerhafter Software?
Die Frist hängt von der vertragstypologischen Einordnung ab. Bei kaufrechtlicher Einordnung (Dauerlizenz) beträgt die gesetzliche Verjährungsfrist für Sachmängelansprüche grundsätzlich zwei Jahre ab Ablieferung (§ 438 BGB). Bei mietrechtlicher Einordnung (Abonnement) gilt für Mängelansprüche im Wesentlichen die regelmäßige Verjährungsfrist von drei Jahren nach § 195 BGB. Abweichungen durch vertragliche AGB-Regelungen sind häufig und müssen im Einzelfall auf ihre AGB-rechtliche Wirksamkeit geprüft werden. Im Zweifel sollte jede Softwareinstallation unmittelbar auf Mängel untersucht und diese unverzüglich gerügt werden.
Dieser Beitrag dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung im Einzelfall dar. Er ersetzt nicht die anwaltliche Prüfung Ihres konkreten Sachverhalts. Für eine auf Ihre Situation zugeschnittene Beratung wenden Sie sich an info@brandtfalk.com.
Dieser Beitrag ist eine allgemeine Information und stellt keine Rechtsberatung dar. Für eine Prüfung Ihres Falls kontaktieren Sie info@brandtfalk.com.