Man lernt ja sein leben lang und hier eine Blogserie darüber, wie man sich verhalten sollte, wenn man den Verdacht hat, dass die eigene Software durch Dritte missbraucht wird. Da solche Fälle häufiger vorkommen, haben wir hier mal den Prozess aufgeführt, den man als best Praxis aufführen sollte, wenn die eigene Software anscheinend rechtswidrig durch Dritte bearbeitet wird und man dadurch einen
Fünf typische Fallkonstellationen und der Weg vom Verdacht zum durchsetzbaren Anspruch
Teil 1
I. Das strukturelle Problem
Softwarehersteller stehen bei Verdacht auf unbefugte Bearbeitung ihrer Programme regelmäßig vor einem strukturellen Beweisproblem. Die Verdachtsmomente sind meist konkret genug für einen erheblichen Anfangsverdacht, aber nicht ausreichend, um einen Unterlassungsantrag nach § 97 UrhG substantiiert zu begründen. Für einen tragfähigen Bearbeitungsvorwurf nach § 69c Nr. 2 UrhG braucht es forensische Feststellungen – Zeitstempel, Autorenkürzel, Kommentare im Quellcode, Deployment-Pfade – , die der Anspruchsteller aus eigener Wahrnehmung nicht erlangen kann, weil sich der Quellcode auf Systemen befindet, zu denen er keinen unmittelbaren Zugriff hat.
Der Beitrag stellt den zweistufigen Rechtsschutz nach § 101a UrhG in Kombination mit dem selbstständigen Beweisverfahren nach §§ 485 ff. ZPO – die sogenannte Düsseldorfer Besichtigungspraxis – im Prozessablauf dar. Als roter Faden dienen fünf typische Fallkonstellationen aus der IT-rechtlichen Praxis.
II. Fünf typische Verdachtssituationen
Fall 1 – Der Ex-Mitarbeiter im komplementären Softwarehaus
Ein ehemaliger Mitarbeiter des Unternehmens A wechselt zu einem anderen Softwarehaus B, das Module entwickelt und vertreibt, die mit der Software von A zusammenwirken. Anlässlich von Supportleistungen wird bei Endkunden erkennbar, dass die Software von A bearbeitet wird – vermutlich durch den ehemaligen Mitarbeiter im Namen von B.
Fall 2 – Der Vertriebspartner ohne Zustimmung
Unternehmen A hat die Software Y entwickelt. Vertriebspartner dürfen Y bearbeiten, wenn die Integration durch reine Konfiguration nicht möglich ist, aber nur mit schriftlicher Zustimmung der A. Ein Mitarbeiter wechselt von einem Vertriebspartner zu A und berichtet, dass Anpassungen ständig auch ohne Zustimmung erfolgten. Das Motiv des Vertriebspartners sei, sich unabhängig von A zu machen.
Fall 3 – Der Kunde mit übergebener Websoftware
Unternehmen A hat seinem Kunden im Rahmen eines Web-Projekts sowohl Open-Source-Komponenten als auch eigene, urheberrechtlich geschützte Softwarebestandteile überlassen; für die Bearbeitung der „A-eigenen Bestandteile“ ist nach dem Vertragswerk eine Lizenz der A erforderlich. Nach Ende der Geschäftsbeziehung beobachten Mitarbeiter der A, dass die eingesetzte Websoftware inzwischen deutlich mehr Funktionen aufweist als seinerzeit ausgeliefert. Es entsteht der Verdacht, der Kunde habe die A-eigenen Bestandteile bearbeitet.
Fall 4 – KI-gestützte Weiterentwicklung durch den Kunden
Konstellation wie Fall 3, mit einer zusätzlichen Angabe: Mitarbeiter des Kunden bestätigen, die Software insgesamt – also auch die „A-eigenen Bestandteile“ – mit KI-Unterstützung weiterentwickelt zu haben. Damit stellen sich neben der Bearbeitungsfrage weitere Zurechnungsfragen, die noch nicht abschließend geklärt sind.
Fall 5 – Insolvenz und verdächtige Marktbewegung
Ein Kunde geht in die Insolvenz. Unternehmen A hatte dem Kunden Standardsoftware verkauft und ergänzend Individualsoftware als eigenständiges Modul erstellt. Der Kunde hatte nur ein einfaches Nutzungsrecht erhalten, beschränkt auf das eigene Unternehmen; die Rechte an der Standardsoftware waren nicht exklusiv übergegangen. Der Anwalt des Kunden hatte im Rahmen der Vertragsverhandlungen durchgesetzt, dass der Quellcode der Individualsoftware mit übergeben wird. Nach der Insolvenz beobachtet A, dass ein anderes Softwareunternehmen B ein Modul auf dem Markt anbietet, das der A-Individualsoftware verblüffend ähnelt. Der Quellcode von B ist A nicht bekannt.
III. Sofort die Unterlassung geltend zu machen funktioniert selten
In allen fünf Fällen scheitert der klassische Weg – sofortige Abmahnung und anschließende Unterlassungsklage oder einstweilige Verfügung nach § 97 UrhG – an der Beweisnot des Antragstellers. Die Bearbeitungshandlung nach § 69c Nr. 2 UrhG muss der Anspruchsteller nach den allgemeinen Beweislastregeln darlegen und in der einstweiligen Verfügung nach § 294 ZPO glaubhaft machen. Solange er nur äußere Beobachtungen hat – Support-Wahrnehmungen (Fall 1), Berichte eines Insiders (Fall 2), Funktionsunterschiede in der laufenden Software (Fall 3 und 4), Marktbeobachtung eines Konkurrenzprodukts (Fall 5) – , kann er die konkrete Bearbeitungshandlung im Quellcode nicht selbst nachweisen. Ein Antrag, der auf diese Verdachtsmomente allein gestützt wird, würde mangels ausreichender Glaubhaftmachung zurückgewiesen.
Damit wird die Konstellation für den Anspruchsteller doppelt problematisch. Er weiß oder ahnt, dass eine Rechtsverletzung stattfindet, kann aber prozessual nicht darauf reagieren. Und die Rechtsverletzung setzt sich in der Zwischenzeit fort, verstärkt sich möglicherweise sogar (Fall 2: Unabhängigkeitsstrategie des Vertriebspartners; Fall 5: aktive Vermarktung eines abgeleiteten Produkts durch B).