Source: https://www.damm-it-recht.de/olg-hamburg-zur-komplexen-beweisfuehrung-der-bearbeiterurheberschaft-an-open-source-software-helwig-vs-vm-ware-global-inc/
Timestamp: 2020-02-27 15:31:07+00:00

Document:
OLG Hamburg: Zur komplexen Beweisführung der Bearbeiterurheberschaft an Open Source Software / Helwig vs. VM Ware Global Inc. › IT-Recht | Dr. Ole Damm - Rechtsanwalt & Fachanwalt
OLG Hamburg, Urteil vom 28.02.2019, Az. 5 U 146/16
§ 3 UrhG, § 69c Nr. 2 S. 2 UrhG
Diese Entscheidung habe ich hier besprochen (OLG Hamburg: Zur komplexen Beweisführung der Bearbeiterurheberschaft an Open Source Software / Helwig vs. VM Ware Global Inc.). Zum Volltext der erstinstanzlichen Entscheidung des LG Hamburg (hier). Den Volltext der Senatsentscheidung finden Sie unten!
Wird Open Source Software, an der Sie mitgearbeitet haben, rechtswidrig verwendet? Oder haben Sie eine Abmahnung wegen Urheberrechtsverletzung an einer Open Source Software erhalten? Rufen Sie an: 04321 / 390 550 oder 040 / 35716-904. Schicken Sie uns Ihre Unterlagen per E-Mail (info@damm-legal.de) oder per Fax (Kontakt). Die Prüfung der Unterlagen und meine Ersteinschätzung ist für Sie kostenlos. Als Fachanwalt für IT-Recht bin ich mit dem Recht von Open Source Software bestens vertraut und helfe Ihnen gerne, eine Lösung zu finden.
Christoph Hellwig, Schidlachstraße 11, 6020 Innsbruck, Österreich
VMware Global Inc., Zweigniederlassung Deutschland, Freisinger Straße 3, 85716 Unterschleißheim
erkennt das Hanseatische Oberlandesgericht – 5. Zivilsenat – durch … auf Grund der mündlichen Verhandlung vom 28.11.2018 für Recht:
I. Die Berufung des Klägers gegen das Urteil des Landgerichts ‚Hamburg vom 08.07.2016 in der Fassung des Beschlusses vom 10.11.2016, Az. 310 0 89/15, wird zurückgewiesen.
Das Linux-Betriebssystem ist unstreitig lange vor dem Jahr 2000 in seiner Ursprungsversion von dem bekannten Programmierer Linus Torvalds initiiert und seither von einer Vielzahl von Programmierern unabhängig voneinander weiterentwickelt worden. Seit April 2005 wird das Versionskontrollsystem „git“ für das Linux-System eingesetzt, über welches nachvollziehbar ist, welche Beiträge von welchem Programmierer beigesteuert worden sind (vgl. Auszug Website Anlage K 1). Dabei ist die Linux-Software fortwährend als sog. Freie Software lizenziert worden und zwar unter den Bedingungen der GNU General Public License, Version 2, auch GPL-2.0 (Text Anlage K 6). Grundgedanke dieser Lizenzierung ist, dass jeder Softwareentwickler, der einen Beitrag zu Linux leistet, es generell jedermann gestattet, Linux einschließlich der jeweils beigesteuerten Beiträge nicht nur zu nutzen, sondern auch weiterzuentwickeln, jedoch unter der auflösenden Bedingung, dass auch die Weiterentwicklung wiederum unter der GPL lizenziert wird, d.h. jedermann zur freien Nutzung und Weiterentwicklung zur Verfügung gestellt wird. Die Nutzer sollen danach umfassende Nutzungsrechte dafür erhalten, dass sie im Gegenzug selbst auch allen anderen Nutzern wieder umfassende Nutzungsrechte einräumen, wenn sie die Software weitergeben. Dazu gehört u.a. die Offenlegung des Quellcodes der veränderten Version. Soweit der Kläger Bearbeitungen der Linux-Software vorgenommen hat, hat er diese nach dem vorstehenden Grundsatz unter der GPL-2.0 lizenziert.
Der Kläger macht Rechte am sog. Kernel des Linux-Betriebssystems auch und gerade im Zusammenhang mit dem System zur Ansprache insbesondere externer Geräte über sogenannte Gerätetreiber geltend. Zu den generellen Begrifflichkeiten „Betriebssystem‘, „Gerätetreiber“ und „Schnittstelle“ — unabhängig von den vorliegend streitgegenständlichen Programmen – ist dabei unstreitig:
Unter dem sog. Kernel eines Betriebssystems versteht man nach übereinstimmender Darstellung der Parteien im vorliegenden Rechtsstreit den Kern eines Betriebssystems. Dieser Kern ist für die Verwaltung und das Ansprechen von Geräten zur Datenspeicherung (Festplatte, optische Laufwerke, Flash-Speicher) sowie für die Verwaltung von Gerätetreibern zuständig. Der Kernel hat unter anderem die Aufgabe, die Input/Output-Anfragen anderer Softwarekomponenten und Anwendungen zu verwalten, zu überprüfen, zu organisieren und zu priorisieren.
Zur Kommunikation eines Betriebssystem-Kernels mit einem integrierten oder an den Computer angeschlossenen externen Gerät ist ein sog. Gerätetreiber erforderlich. Ein Gerätetreiber ist eine Software, die einen besonderen Typ von Geräten, welcher mit dem Computer verbunden ist, bedient oder kontrolliert, indem sie die Anfragen von Anwendungen und vom Betriebssystem für die besonderen Anforderungen des jeweiligen Typs, der Marke und des Modells des Gerätes übersetzt. Möchte eine Software mit einem Gerät kommunizieren, muss der Treiber einen Befehl oder eine Serie von Befehlen an das Gerät erteilen.
Das Zusammenwirken zwischen Kernel und Gerätetreibern kann durch einen unterschiedlichen Aufbau des Betriebssystems erreicht werden. Beim Aufbau eines Betriebssystems können die Gerätetreiber entweder mit dem übrigen Kernel des Betriebssystems zu einer einheitlichen Binärdatei verbunden oder als sog. Kernel-Module ausgelagert werden. Im letzten Fall können sie vom System dann dynamisch nachgeladen werden.
– Als Schnittstelle bezeichnet man Komponenten, die die Kommunikation anderer Komponenten ermöglichen; im Hardware-Bereich können dies bestimmte Steckverbindungen sein und im Softwarebereich bestimmte Programmierungsanforderungen. Als eine abstrakte oder stabile Schnittstelle kann dabei eine solche bezeichnet werden, deren Konfiguration bzw. Anforderungen sich auch bei einer Weiterentwicklung der kommunizierenden Komponenten nicht ändert; so stellt z.B. Microsoft für das Betriebssystem Windows spezielle öffentliche Schnittstellen für Gerätetreiber zur Verfügung. Diese Schnittstellen bleiben über längere Zeit unverändert. Unter dieser Voraussetzung werden üblicherweise die Hardware-Unternehmen, die die anzusprechenden externen Geräte herstellen, in Kenntnis der Spezifikation der abstrakten Schnittstelle den für ihr jeweiliges Gerät zu dieser Schnittstelle passenden Gerätetreiber entwickeln und zur Verfügung stellen. Weitere Einzelheiten zum Begriff der Schnittstelle und ihrer Qualifizierung sind streitig.
Die Beklagte ist Herstellerin des Softwareprodukts „Hypervisor vSphere VMware ESXi 5.5.0″ (im Folgenden: ESXi). Die Beklagte nennt die Software selbst eines ihrer wesentlichen Produkte. Bei ESXi handelt sich um eine sog. Virtualisierungssoftware, die es dem Nutzer erlaubt, einen Computer in mehrere virtuelle Maschinen aufzuteilen. ESXi besteht aus mehreren unterschiedlichen Programmen und Komponenten. Insbesondere enthält ESXi eine Komponente „Hypervisor“, die eine besondere Art eines Betriebssystems darstellt, welche es ermöglicht, dass mehrere unterschiedliche Betriebssysteme auf ein und demselben Computer parallel zueinander ablaufen können. Wie andere Betriebssysteme enthält auch ESXi einen Kernel. Dieser ist als „vmkernel“ bezeichnet (dabei steht die Abkürzung „vm“ für „virtual machine“). Ist auf einem Computer ESXi installiert, kann der Nutzer den „vmkernel“ anweisen, eine virtuelle Maschine zu starten und dann auf dieser virtuellen Maschine ein Betriebssystem installieren. Der Nutzer kann auch mehrere virtuelle Maschinen starten und auf diese Weise eine beliebige Anzahl von Betriebssystemen auf den von „vmkernel“ erstellten virtuellen Maschinen installieren. Auf diese Weise kann unter ESXi auch das Linux-Betriebssystem auf einer virtuellen Maschine installiert werden.
Der eigentliche Kernel des ESXi ist der sog. „vmkernel“. Dieser liegt nur im sog. Binär-oder Objektcode vor, d.h. er kann von einem Programmierer ohne Übersetzung nicht überarbeitet werden. Den Quellcode für den „vmkernel“ hat die Beklagte nicht offen gelegt; sie hat für den „vmkernel“ auch keine Lizenzierung, insbesondere keine unter der GPL-2.0 angeboten. Der Kläger macht nicht geltend, dass der „vmkernel“ als solcher auch selbst Linux-Code enthalte.
Daneben besteht ein Modul, welches die Beklagte als „vmklinux“ bezeichnet. Zwischen den Parteien ist unstreitig, dass dieses Modul Teile aus bearbeitetem Code des Linux-Betriebssystems enthält. Streitig ist unter anderem, um welche Codeteile es sich handelt und ob diese vom Kläger stammen. Den Quellcode dieses Moduls hat die Beklagte unstreitig auf ihrer VVebsite offen gelegt, zum Download angeboten und insofern unter der GPL-2.0 lizenziert.
Schließlich enthält ESXi weitere Module, in denen sich insbesondere Gerätetreiber finden, die zum Teil bearbeitete Gerätetreiber sind.
Die Beklagte bietet — nach dem klägerischen, von der Beklagten pauschal bestrittenen Vortrag – die Software ESXi in der im Klagantrag zu 1) bezeichneten Version als ausführbares Programm, d.h. im sog. Objektcode, über ihre VVebsite u.a. in Deutschland zum Download über das Internet an. Der Kläger sieht darin eine Verletzung seiner Rechte am verwendeten Linux-Code und mahnte die Beklagte mit Schreiben vom 20.08.2014 ab (Anlage K8). Die Beklagte antwortete mit Schreiben vom 19.09.2014 (Anlage K9). Sie gab keine Unterlassungsverpflichtungserklärung ab. Der Kläger übersandte eine E-Mail vom 14.11.2014 (Anlage K 10). Anschließende Gespräche der Parteien führten nicht zu einer Einigung.
Der Beklagten habe er mit der — nach Existenz und Wortlaut unstreitigen — vorgerichtlichen E-Mail Anlage K 10 Beispiele dafür genannt, welche Teile von bestimmten Source Code-Dateien („scsi_error.c“, „scsi_lib.c“, „scsi_proc.c“, „scsi.c“ und „hosts.c“) er entwickelt habe. Ergänzend hat der Kläger die dreiseitige Anlage K 15 vorgelegt und erklärt, aus den dortigen Ausführungen ergebe sich, welche Beiträge er geleistet habe, die durch die Beklagte übernommen worden seien. Dass sich der von ihm, dem Kläger, entwickelte Code in urheberrechtlich relevantem Umfang in ESXi befinde, könne anhand des in der Anlage K 15 beigefügten Source Code-Vergleichs beispielhaft nachvollzogen werden; diese Anlage beschreibe auch, wie der Vergleich nachvollzogen werden könne; ein vollständiger Source Code-Vergleich sei mit Hilfe des Linux-Codes in Anlage K 15 und dem Source Code von „vmklinux“, den die Beklagte anbiete, durchgeführt worden. In zwei Dateien, zu denen die Beklagte den Quellcode offen gelegt habe, fänden sich im Übrigen sog. Header mit Hinweisen auf Urheberrechte u.a. des Klägers. Der Kläger hat in diesem Zusammenhang des Weiteren auf Anlage K3 verwiesen.
Das „SCSI-Hotplug“ sei eine der Funktionen, die ESXi benutze. Innerhalb des SCSI-Subsystems sei die sog. „SCSI-Hotplug“-Funktionalität, also das dynamische Einbinden und Ausbinden von Hardware im laufenden Betrieb, eine der wichtigsten Funktionen. Die dieser Funktionalität zugrundeliegende Programmierung genieße für sich genommen urheberrechtlichen Schutz, denn sie sei ein Beispiel für eine komplexe Funktionalität und deren Implementierung, die zu einer tatsächlichen Vermutung für hinreichende Individualität führe. Der entsprechende Code sei dem Programm Linux über viele Schritte hinzugefügt worden und verteile sich über mehrere Einzelfunktionen. Er, der Kläger, habe dabei die im Schriftsatz vom 25.09.2015, dort S. 9 (BI. 153 d.A.), genannten 19 Einzelbeiträge (Patches), darunter den Patch „some scsi_scan.c restructuring for ieee1394 hotplugging“, beigesteuert. Der Kläger hat insoweit auch auf Kopien dieser „Patches“ auf der CD-Rom Anlage K 12 verwiesen. Dass es sich um eine komplexe Programmierung handele, könne durch einen Sachverständigen belegt werden. Soweit die Beklagte zu einzelnen Patches seine, des Klägers, Urheberschaft bestritten hat, trägt der Kläger weiter zu von ihm behaupteten Bearbeitungsteilen vor.
Der Kläger hat ergänzend vorgetragen, er habe am 21.02.2003 zum SCSI den Beitrag (Patch) „some scsi_scan.c restructuring for ieee1394 hotplugging“ beigesteuert, der am 23.03.2003 in Linux übernommen worden sei. Dass seine Funktionalität in „vmklinux“ übernommen worden sei, könne man an bestimmten Aufrufen der Funktionen „scsi_add_device“ und „scsi_remove_device“ in allen „vmklinux“ SAS-Treibern sowie in dem Libata-Modul erkennen. Der Kläger hat zu Teilen der SCSI-Funktionalität vorgetragen, die sich in „vmklinux“ befinden sollen und die für mehrere Hardwaretreiber benötigt würden (sog. „Midlayer-Code“) und quasi vor die Klammer gezogen worden seien; das gelte z.B. für die „Error Handling“-Funktion; ein weiterer Teil der SCSI-Funktionalität finde sich in den Hardwaretreibern, die an „vmklinux“-angebunden seien. Seitens der Beklagten sei eine Funktion „scsi_remove_single_device“ identisch übernommen worden; sie finde sich im Linux Kernel 2.5.64 in der Datei „drivers/scsi/scsi_proc.c“ in den Zeilen 423 ff. (Anlage K 25) und bei VMware ESXi 5.5 Update 2 in der Datei „vmkdrivers/src_92/vmklinux_92/linux/scsi/scsi_proc.c“ in den Zeilen 250 ff. (Anlage K 26); es bestehe eine Übereinstimmung von 991Y0 (Anlage K 27).
Der Kläger hat außerdem geltend gemacht, dass er auch bei der Entwicklung der sog. „Radix-Trees“ wesentlich mitgearbeitet habe. Bei den „Radix-Trees“ handele es sich um eine skalierbare Implementierung einer speziellen Baumstruktur, die insbesondere in der Verwaltung von Dateisystemen-Puffern (Caches), aber auch in vielen anderen Anwendungsbereichen benutzt werde. Als zentraler Teil des Linux-Betriebssystemkerns sei diese Funktionalität nie zur Auslagerung in Modulen vorgesehen gewesen und werde durch andere Nutzer als die Beklagte auch nicht in Kernelmodule ausgelagert. Zuletzt hat der Kläger vorgetragen, Linux „Radix-Tree“ sei eine effiziente Implementation einer Datenstruktur zum Finden von Objekten mittels eines Indexes. Die Datenstruktur sei von dem Programmierer Momchil Velikov erfunden worden. Die Implementation sei eine gemeinsame Arbeit von Velikov und ihm, dem Kläger. Er habe am 09.04.2002 die Implementation zur Aufnahme in Linux eingereicht. Die Beklagte habe eine neuere Version des Codes von 2012 übernommen und minimal bearbeitet. Andere Linux-Kernel-Entwickler könnten bezeugen, dass er, der Kläger, wesentliche und komplexe Beiträge zu der Entwicklung der „Radix-Trees“ geleistet habe.
Der Kläger hat der Beklagten vorgeworfen, die Übernahme des Linux-Code in „vmklinux“ sei rechtswidrig, weil die Lizenzierungs-Bedingungen der GPL-2.0 nicht eingehalten worden seien. Die GPL-2.0 verlange nach ihrer Ziffer 2.b) — insofern unstreitig — dass der Nutzer „must cause any work […], that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole […] under the terms of this License“. Der Kläger hat der Beklagten zwar zugestanden, den Quellcode des Moduls „vmklinux“ offengelegt und unter GPL-2.0 lizenziert zu haben. Damit allein seien die Anforderungen der GPL-2.0 zur Nutzung des Linux-Codes jedoch noch nicht erfüllt und daher eine etwaige Lizenzierung nach Ziffer 4 der GPL-2.0 entfallen. Denn die oben zitierte Klausel müsse auf den vorliegenden Fall dahin angewandt werden, dass „vmklinux“ und „vmkernel“ als ein einheitliches „work“ betrachtet werden müssten und daher auch insgesamt unter der GPL-2.0 lizensiert werden müssten, d.h. auch der Quellcode zu „vmkernel“ müsse von der Beklagten offen gelegt werden, um den Anforderungen der GPL-2.0 zu genügen. Die Notwendigkeit, „vmklinux“ und „vmkernel“ als Einheit zu betrachten, ergebe sich aus den folgenden, vom Kläger behaupteten Eigenschaften des Programms der Beklagten:
Die diesbezügliche Architektur der Software der Beklagten ergebe sich aus Anlage K 2.
Der Linux-Code werde dynamisch in den Bestandteil „vmkernel“ nachgeladen. Das gelte insbesondere auch für das SCSI-Subsystem, das den Code des Klägers enthalte. Dabei werde der Code im sog. Kernel-Space ausgeführt, d.h. nicht in dem Bereich für selbstständige Anwendungen (User-Space), sondern als Teil des Betriebssystems.
Sowohl „vmkernel“ als auch „vmklinux“ würden in demselben Adressraum ausgeführt, d.h. Funktionen in „vmkernel“ riefen Funktionen in „vmklinux“ auf, welche dann wieder Funktionen in „vmkernel‘ benutzten. Nach der Verkehrsauffassung sei dies ein typisches Merkmal für ein einheitliches Programm, denn selbstständige Programme würden typischerweise in getrennten Adressräumen ausgeführt und implementierten eigenständige Funktionalität, die keine tiefgreifende Interaktion der Komponenten beinhalte.
Der „vmkernel“ sei ohne die Benutzung des „vmklinux“-Moduls mit dem bearbeiteten Linux-Code nicht lauffähig. Im ESXi-Programm der Beklagten sei der Bereich „vmkernel“ nicht alleine lauffähig und benötige zwingend zusätzliche Softwarebestandteile, um eine Hardware ansprechen zu können. Diese Softwarebestandteile fänden sich in den aus dem Kernel ausgelagerten Kernet-Modulen, so insbesondere im Modul „vmklinux“. Der „vmkernel“ sei also ohne die in die Module ausgelagerte Software nicht lauffähig.
Auch „vmklinux“ sei ohne „vmkernel“ nicht lauffähig. Ziel der Beklagten sei es gewesen, den stark bearbeiteten Linux-Code in enger Integration mit „vmkernel“ benutzen zu können. Dafür habe es der Beklagten nicht genügt, die übernommenen Linux-Module im Objektcode zu verwenden und bloß über eine Schnittstelle anzubinden; vielmehr sei eine darüber hinausgehende Integration in den Kernel von ESXi erforderlich gewesen, nämlich eine jeweils spezielle Anpassung und Einzelabstimmung. Das Ergebnis sei, dass „vmklinux“ nicht als Teil von Linux ausgeführt werden könne. Insbesondere könne „vmklinux“ der Beklagten nicht in den Linux-Kernel nachgeladen werden oder mit einem anderen Betriebssystem ausgeführt werden.
den Kernel (also einschließlich der Komponenten „vmkernel“, „vmklinux“ und „VIVIK API“) der Software Hypervisor vSphere VMware ESXi 5.5.0 (einschließlich Update 1 und Update 2) öffentlich zugänglich zu machen, ohne dass zugleich entsprechend den Lizenzbedingungen der GNU General Public License, Version 2,
-der vollständige korrespondierende Quellcode des Kernels der Software Hypervisor vSphere VMware ESXi 5.5.0 (einschließlich Update 1 und Update 2) lizenzgebührenfrei zugänglich gemacht wird, und
-der Kernel der Software Hypervisor vSphere VMware ESXi 5.5.0 (einschließlich Update 1 und Update 2) unter den Lizenzbedingungen der GNU General Public Licence, Version 2, angeboten wird;
Der Kläger habe ein schutzfähiges Softwarewerk schon nicht dargestellt, geschweige denn, dass er darlegt habe, dass ein solches – und welches genau – von ihm geschaffen worden sei. Auch der Verweis auf „linux.tgz-Archivs“ und „Git-Repository“ sei nicht ausreichend; der Kläger versuche nicht einmal, einzelnen Code zu identifizieren, sodass nur geraten werden könne, welche Code-Zeilen der Kläger zur Begründung seines Anspruch heranziehen wolle.
Durch die – vom Kläger mit Nichtwissen bestrittene – Analyse der vom Kläger vorgelegten Informationen habe sie, die Beklagte, in etwa 798 Zeilen, die in den Dateien „scsi_proc.c“, „scsi_error.c“ und „linux_scsi_Ild_if.c“ enthalten seien, Code von „vmklinux“ identifizieren können, von denen der Kläger behaupte, dass er sie geschrieben habe. Bereits „vmklinux“ selbst umfasse aber 214.000 Code-Zeilen (also das 269-fache); „vmkernel“ umfasse 1,3 Mio. Code-Zeilen (das 1.654-fache).
Von den 798 Code-Zeilen seien jedoch 396 Zeilen in „vmklinux“ nicht verwendet, sondern „auskommentiert“ worden, d.h. sie erschienen nur im menschenlesbaren Quellcode.
Von den verbleibenden 402 Zeilen Code stellten wiederum knapp die Hälfte, nämlich 185 Zeilen, solchen Code dar, der nicht vom Kläger stamme, sondern von ihm nur geringfügig geändert oder an eine andere Stelle bewegt worden sei.
-Von den verbleibenden 217 Code-Zeilen seien ferner 68 bloße „Kommentare“ (zum Beispiel Erklärungen zur Funktionalität des Codes), die auch nicht in den endgültigen maschinenlesbaren, ausführbaren Code kompiliert seien.
-Es verblieben damit letztlich nur noch 149 Zeilen, die möglicherweise von Kläger stammten und zum Endbenutzer gelangten. Allein die drei „vmklinux“-Dateien, auf die sich der Kläger beziehe, enthielten aber bereits 6.895 Codezeile, zu denen der Kläger dann also vom Umfang her betrachtet weniger als 2,2 % beigetragen habe. Zu „vmklinux“ insgesamt mit seinen 214.000 Codezeilen habe der Kläger dann also lediglich 0,07% beigetragen. Zu „vmkernel“ mit seinen 1,3 Mio. Zeilen hätte der Kläger, wenn man, wie von der Beklagten verneint, „vmkernel“ und „vmklinux“ als Einheit betrachten würde, weniger als 0,012 % beigetragen.
Soweit der Kläger argumentierte, die Schnittstelle teile „ymkernel“ und „vmklinux“ künstlich auf, so verfange diese Argumentation nicht, denn „vmklinux“ habe eine von „vmkernel“ getrennte bestimmte Funktionalität, nämlich es Linux-kompatiblen Gerätetreibern zu ermöglichen, mit „vmkernel“ zu kommunizieren. Der Kläger verwechsele auch die Schnittstellen, über die er spreche: Richtig sei vielmehr, dass es neben der „VMK API“ (über die „vmkernel“ und „vmklinux“ kommunizierten) eine weitere Schnittstelle gebe; dieses sei aber diejenige, über die „vmklinux“ mit den Gerätetreibern kommuniziere, und auch diese Schnittstelle sei nicht in dem Sinne instabil, wie vom Kläger behauptet.
Das Landgericht Hamburg hat die Klage durch Urteil vom 08.07.2016 abgewiesen. Wegen der Einzelheiten wird auf das genannte Urteil (BI. 386 ff. d.A.) Bezug genommen. Durch Beschluss vom 10.11.2016 (BI. 495 ff. d.A.), auf den gleichfalls Bezug genommen wird, ist dieses Urteil in einzelnen Punkten berichtigt worden. Mit der vorliegenden Berufung verfolgt der Kläger sein erstinstanzliches Begehren vollen Umfangs weiter.
Die klägerischen Beweisangebote im Schriftsatz vom 29.04.2016 (Seiten 13 und 15) betreffend den klägerischen Code für die Funktionalität „SCSI Device Hotplug“ und den für die „Radix-Trees“ übernommenen Code seien nicht auf Ausforschung gerichtet. Beiden Beweisangeboten gehe eine dataillierte Darstellung des Inhalts der Programmierung voraus sowie die Vorlage des entsprechenden Sourcecodes. Der Kläger meint, dass das Landgericht von Amts wegen gemäß § 144 Abs. 1 ZPO einen Sachverständigen hätte beauftragen, jedenfalls aber dem Beweisantrag hätte nachkommen müssen. Wäre das Landgericht dem Beweisangebot nachgegangen, hätte der Sachverständige anhand der vorgelegten Sourcecodes und unter Nachvollziehung der in Anlage K 27 beschriebenen Vorgehensweise bestätigt, dass die Beklagte individuelle Programmierleistungen des Klägers in „vmklinux“ übernommen habe. Der Klage hätte dann stattgegeben werden müssen. Nach der Rechtsprechung des BGH bestehe zudem eine tatsächliche Vermutung für die Schutzfähigkeit bei komplexen Programmen (BGH CR 2005, 854, 855 — Fash 2000). Daher habe hier der Beklagten die Darlegungs- und Beweislast dafür oblegen, dass von ihr keine individuelle Programmierung übernommen worden sei, zumal er, der Kläger, in dem von der Beklagten selbst angebotenen Sourcecode von „vmklinux“ als Urheber genannt werde. Unabhängig von der Beweislast habe das Landgericht auch schon rechtsfehlerhaft das Bestreiten der Beklagten mit Nichtwissen hinsichtlich der Rechtsinhaberschaft und Schutzfähigkeit der übernommenen Programmierungen zugelassen.
Der Kläger trägt weiter vor, dass die in den Anlagen K 26 und K 31 vorgelegten Sourcecodes der Beklagten Sourcecode des Klägers mit hinreichender Individualität enthielten. Die Beklagte habe Funktionalitäten im Wesentlichen übernommen, so zum Beispiel die Funktionalität in der Funktion „_scsi_iterate_devices“ und dem darauf basierenden Makro „shost_for_each_device“, welche bei der Beklagten nur trivial verändert worden seien. Ebenso seien andere Funktionen inklusive der Kommentare übernommen worden, wie z.B. „scsi_device_lookup and scsi_device_lookup“, welche allesamt auf der funktionsübergreifenden Logik einer von den Benutzern versteckten Liste und einem sogenannten „Reference-Counting“ basierten. Daneben habe die Beklagte die Dateien „radix-tree.c“ und „radix-tree.h“ aus einer neueren Linux-Version übernommen, aber — wie im Code-Vergleich ersichtlich sei — auch einen Großteil der jetzt „radix_tree_insert“ genannten Funktion von der ursprünglich als „radix_tree_reserve“ benannten Funktion des Klägers. Der Kläger legt nunmehr die Vergleichsdateien mit den übernommenen Funktionen für „SCSI Device Hotplug“ und „Radix-Trees“ vor (Anlage K 59). Er macht weitere Ausführungen zur Nachverfolgbarkeit der behaupteten Übernahmen.
Mit Schriftsatz vom 07.11.2018 trägt der Kläger ergänzend vor, dass „vmklinux“ stets benötigt werde, weil „vmkernel“ in der streitgegenständlichen Version niemals ohne „vmklinux“ für irgendeine gängige Hardware verwendet werden könne. Deshalb werde die Software von der Beklagten, wie insoweit unstreitig ist, auch ausschließlich zusammen vertrieben. Die Anlagen K 29 bis K 31 belegten die Übernahmen der „Radix-Tree“-Funktionalität. Die Anlage K 31 enthalte den von der Beklagten verwendeten Quellcode, der auch Programmierungen des Klägers enthalte, die wiederum als Anlage K 30 vorgelegt worden seien. Damit sei für einen Sachverständigen nachvollziehbar, dass die Beklagte Programmierungen des Klägers verwendet habe. Die Ursprungsprogrammierung sei vom Entwickler Momchil Velikov und ihm, dem Kläger, gemeinsam und damit in Miturheberschaft geleistet worden. Urheberrechtlich relevante Programmierung geschehe nicht nur auf der Ebene von Zeilen, sondern auch auf der Basis einzelner „Wörter“ oder „Token“. Seit der ursprünglichen Version der Datei „lib/radix-tree.c“ habe es 75 weitere Beiträge („Commits“) bis zu der Version aus Linux 3.3 gegeben, welche die Beklagte 10 Jahre später mit minimalsten Anpassungen übernommen habe.
Der Kläger hat in der mündlichen Verhandlung am 28.11.2018 auf gerichtlichen Hinweis klargestellt, dass er seine Ansprüche ableitet aus seinen Codebeiträgen für die Radix-Trees und das SCSI-Subsystem, wie in den Anlagen K 12 i.V.m. K 13, K 14, K 15, K 26, K 30, K 31 und K 59 dargestellt wird. Insoweit weist er besonders auf die Anlage K 12, dort den Ordner „E-Mail vom 14.11.2014″ und die im Ordner in farbiger Ausgestaltung enthaltenen HTML-Dokumente, hin.
Der Kläger beantragt unter Berücksichtigung der vorstehenden Klarstellung, das Urteil des Landgerichts Hamburg vom 08.07.2016, Az. 310 0 89/15, abzuändern und die Beklagte zu verurteilen,
den Kernel (also einschließlich der Komponenten „vnnkernel“, „vmklinux und „VMK API“) der Software Hypervisor vSphere VMware ESXi 5.5.0 (einschließlich Update 1 und Update 2) öffentlich zugänglich zu machen, ohne dass zugleich entsprechend den Lizenzbedingungen der GNU General Public License, Version 2, der vollständige korrespondierende Quellcode des Kernels der Software Hypervisor vSphere VMware ESXi 5.5.0 (einschließlich Update 1 und Update 2) lizenzgebührenfrei zugänglich gemacht wird, und der Kernel der Software Hypervisor vSphere VMware ESXi 5.5.0 (einschließlich Update 1 und Update 2) unter den Lizenzbedingungen der GNU General Public Licence, Version 2, angeboten wird;
In der Anlage K 59 lege der Kläger den Quellcodevergleich der angeblich übernommenen Funktionen für „SCSI Hotplug“ und den „Radix-Tree“ vor. Dabei lege der Kläger nicht dar, warum die Vorlage weiterer Beweismittel in der Berufungsinstanz zulässig sein solle. Er setze sich über § 531 Abs. 2 ZPO hinweg. Diese Anlage enthalte Dateien, die als Teil der Anlage K 15 benannt würden, in dieser jedoch nicht enthalten gewesen seien. Die Anlage K 59 enthalte vor allem in Bezug auf die Dateien im „Radix-Tree“-Ordner völlig neue Beweise. Unabhängig davon erfülle die Anlage K 59 immer noch nicht die Voraussetzungen an ein substantiiertes Vorbringen. Zum einen identifiziere dieser Ordner nicht den Teil des Codes, der vom Kläger und nicht vom Entwickler Velikov stammen solle. Zudem lasse die Analyse der Anlage K 59 zusätzliche Zweifel aufkommen, ob der Kläger zu dem in „vmklinux“ verwendeten „Radix-Tree“-Code überhaupt irgendeinen nennenswerten Beitrag geleistet habe.
Die Beklagte erwidert auf den klägerischen Schriftsatz vom 29.04.2016 und trägt insoweit unter anderem vor, dass der tatsächliche Code in „vmklinux“, der vom Kläger für die Funktionen „scsi_add_device“ und „scsi_remove_device“ erwähnt werde, sich von dem in Anlage K 24 vorgelegten Code unterscheide und keinen klägerischen Code enthalte. In der Anlage K 27 fänden sich unter 27 Funktionen, von denen der Kläger behaupte, dass sie Beiträge von ihm enthielten, 22 Funktionen in Linux-kompatiblem Treiber-Code. Linux-kompatible Treiber seien jedoch nicht „vmklinux“. Sie seien auch nicht Gegenstand der Klage. Hinsichtlich der verbleibenden fünf Funktionen sei sie, die Beklagte, zu dem Schluss gekommen, dass von den Codezeilen, deren Urheberschaft der Kläger beanspruche, nur 3 von 72 nicht-leeren Zeilen im „vmklinux“-Code enthalten seien. Es ergebe sich — ungeachtet der Frage der Urheberschaft — allenfalls ein Ähnlichkeitsverhältnis von 2,12 %. Die mit der Anlage K 59 vorgelegte Fassung des Codes zum „Radix-Tree“ unterscheide sich deutlich von der Fassung, die in Anlage K 30 vorgelegt worden sei. Insoweit sei die Anlage K 59 für die vom Kläger geltend gemachten Ansprüche ohne Bedeutung. Der angeblich vom Kläger beigetragene „Radix-Tree“-Code unterscheide sich komplett von der Version des „Radix-Tree“-Codes, der von ihr, der Beklagten, verwendet werde. „Vmkernel“ sei kein „derivative work“ des gesamten „vmklinux“ und keine Bearbeitung eines „Software-Werks“, an dem der Kläger Urheberrechte habe.
Die Beklagte rügt hinsichtlich des klägerischen Schriftsatzes vom 07.11.2018 Verspätung. Sie trägt weiter vor, dass der Kläger kein Bearbeiterurheberrecht dargelegt habe, geschweige denn eine Verletzung eines solchen. Die Voraussetzungen einer Miturheberschaft habe der Kläger in der ersten Instanz nicht dargelegt, ein Versuch in der zweiten Instanz sei präkludiert, da die Voraussetzungen der §§ 529 Abs. 1 Nr. 2, 531 Abs. 2 ZPO nicht vorlägen. Zusätzlich sei die Einführung von Tatsachen auch nach § 530 i.V.m. § 296 Abs. 1 ZPO verspätet. Die neue „Miturheber“-Argumentation des Klägers sei zudem unzutreffend. Die Voraussetzungen einer Miturheberschaft seien nicht dargelegt worden. Der Entwickler Velikov habe, wie unbestritten geblieben ist, an dem Code der Anlage K 61 bereits gearbeitet und diesen eingereicht, ohne den Kläger in irgendeiner Form zu erwähnen. Er habe Teile des schwarzen Codes in Anlage K 61, wie ebenfalls unstreitig ist, bereits im Dezember 2001 beigetragen. Die Behauptung des Klägers, „sämtliche schwarz markierten Codebestandteile“ stammten aus der „gemeinsamen Ursprungsprogrammierung“, stimme nicht. Soweit der Kläger vorschlage, dass ein Sachverständiger das Tool „Cregit“ verwenden solle, blende er aus, dass er seiner Darlegungslast nicht genügt habe. Zudem weise der Autor von „Cregit“ selbst darauf hin, dass dieses Tool nicht nachvollziehen könne, welche Bestandteile von Autoren beigetragen worden seien. Der Anteil der vom Kläger in Bezug genommenen schwarzen Zeilen sei so gering, dass nicht nachvollziehbar sei, wie sie einen hinreichend schöpferischen Beitrag ergeben sollten.
1. Die Klage ist allerdings zulässig, insbesondere auch mit dem Klageantrag zu 1. hinreichend bestimmt gemäß § 253 Abs. 2 Nr, 2 ZPO.
a. Die internationale Zuständigkeit der deutschen Gerichte ist, wie vom Landgericht im angegriffenen Urteil festgestellt, gemäß §§ 21, 32 ZPO gegeben. Der Kläger macht Ansprüche aus einer angeblich in Deutschland begangenen unerlaubten Handlung — dem öffentlichen Zugänglichmachen des Kernels (also einschließlich der Komponenten „vmkernel“, „vmklinux“ und „VMK API“) der Software „Hypervisor vSphere VMware ESXi 5.5.0″ (einschließlich Update 1 und Update 2) — geltend. Die Beklagte handelt in Deutschland von ihrer hiesigen Niederlassung aus. Da die internationale Zuständigkeit hier nicht im Streit steht, greift letztlich auch § 39 S. 1 ZPO.
b. Der auf Unterlassung gerichtete Klageantrag zu 1. ist weit gefasst. Er richtet sich, wie ausgeführt, auf Unterlassung der öffentlichen Zugänglichmachung des Kernels (einschließlich der Komponenten „vmkernel“, „vmklinux“ und „VMK API“) der Software „Hypervisor vSphere VMware ESXi 5.5.0″ (einschließlich Update 1 und Update 2), mithin eines erheblichen Teils der bezeichneten Software. Gleichwohl ist der Antrag hinreichend bestimmt.
(1) Wie bereits im angefochtenen Urteil im Einzelnen ausgeführt worden ist, kommen nach dem erstinstanzlichen Vortrag als Schutzrechte, aus denen der Kläger einen Unterlassungsanspruch ableiten kann, lediglich Bearbeiterurheberrechte in Betracht, da der Kläger geltend macht, sukzessiv eigenständige Beiträge zum Linux-Kernel beigetragen zu haben. Diese Bewertung greift auch der Kläger mit seiner Berufung nicht an. Soweit der Kläger jetzt im weiteren Verlaufe des Berufungsverfahrens mit Schriftsatz vom 07.11.2018 erstmals auch ein angebliches Miturheberrecht — zusammen mit dem Entwickler Momchil Velikov — an der Ursprungsprogrammierung bemüht, ist eine gesonderte Betrachtung veranlasst, auf die zurückzukommen ist.
Dass auch an einer Umarbeitung von Software ein Bearbeiterurheberrecht entstehen kann, folgt aus § 69c Nr. 2 S. 2 § 3 UrhG. Ob dabei einzelne dieser Beiträge im Zusammenwirken mit anderen geschaffen worden sein mögen, ändert daran nichts, denn insofern würde auch der etwaigen Miturhebergemeinschaft nur ein Bearbeitungsrecht zustehen, dem Kläger also nur ein — wie es bereits das Landgericht ausgedrückt hat — „Mit-Bearbeiterurheberrecht“.
(3) Gleichwohl kann der Bearbeiterurheber, wie vom Landgericht Hamburg in der angefochtenen Entscheidung zugrunde gelegt, Unterlassung der Nutzung eines solchen anderen Computerprogramms verlangen, welches die für den Bearbeiterurheber geschützten Anteile i.S.v. § 69c Nr. 2 UrhG (Umarbeitung) i.V.m. § 23 UrhG (Bearbeitung) in unfreier Weise nutzt. Der dazu prozessual zu formulierende Unterlassungsantrag ist bereits dann hinreichend bestimmt, wenn diejenige Programmversion, die die Rechtsverletzung enthält, hinreichend präzise bezeichnet ist. Dies gibt oftmals bei individuell entwickelten Programmen, die nicht frei gehandelt, sondern nur von einem einzelnen Auftraggeber genutzt und laufend angepasst werden, Formulierungsschwierigkeiten auf, die es erforderlich machen können, das Verletzungsmuster schon im Rahmen der Antragsfassung genauer zu spezifizieren. Dieses Problem stellt sich vorliegend aber nicht, da das Programm der Beklagten — insofern von ihr nicht bestritten — grundsätzlich käuflich zu erwerben ist. Der Kläger hat die Version, die die Rechtsverletzung enthalten soll, hinreichend genau bezeichnet, so dass in einem etwaigen Vollstreckungsverfahren geprüft werden könnte, ob die benannte Version (oder eine als kerngleich zu beurteilende Version) trotz Verbots weiter vertrieben worden ist. Damit sind die Anforderungen an eine hinreichende Bestimmtheit insoweit erfüllt. Das Verletzungsprodukt wird identifiziert (vgl. dazu Czychowski GRUR-RR 2018, 1, 3).
Das Risiko eines Klägers, der den materiellen Kern des verfolgten Unterlassungsanspruchs nicht hinreichend spezifiziert vorträgt, mag sein, dass das Gericht anhand des nicht ausreichend substantiierten Vortrags eine Verletzungshandlung nicht feststellen kann (dann ist die Klage zulässig, aber unbegründet) oder von möglicherweise mehreren Verletzungshandlungen nur eine feststellen kann (dann ist die Klage zulässig und begründet, der Kern des Verbots ist aber eng, denn er orientiert sich allein an der einen feststellbaren Verletzungshandlung). Ob der Kläger zusätzlich den Unterlassungsantrag von vornherein auf einen bereits im Antrag spezifizierten rechtsverletzenden Aspekt begrenzt und damit den Streitgegenstand möglicherweise gegenüber einer weiter reichenden Begründung beschränkt, bleibt seiner Parteidisposition überlassen. Ob aus Gründen der Klarheit des Urteilsausspruches auch dann, wenn eine solche Beschränkung nicht in den Antrag aufgenommen ist, sie doch im Tenor der Entscheidung zur genaueren Umschreibung des Verbot aufgenommen werden sollte, ist im Einzelfall vom Gericht zu prüfen. Dies alles ändert aber nichts daran, dass vorliegend das verlangte Verbot vom Kläger durch Bezeichnung des Programms der Beklagten hinreichend bestimmt worden ist. Eine andere Frage ist, ob dieser — weitgehende — Antrag (jedenfalls teilweise) unbegründet ist, weil ein solcher Unterlassungsanspruch nicht besteht.
bb. Im Hinblick auf die gebotene genaue Bestimmung des Streitgegenstandes hat der Kläger im Rahmen der mündlichen Verhandlung am 28.11.2018 eine Klarstellung vorgenommen. Prozessual geboten ist, wie sich auch aus dem Vorstehenden ergibt, eine Identifikation des Ausgangswerkes und des Anteils des Klägers daran, um einerseits den Streitgegenstand zu identifizieren und andererseits im Folgenden zu bestimmen, ob etwa ein Bearbeiterurheberrecht oder eine Miturheberschaft vorliegen (so auch Czychowski GRUR-RR 2018, 1, 2). So ist der Senat nach dem schriftsätzlichen Vortrag des Klägers davon ausgegangen, dass es hier um Rechte am SCSI-Subsystem des Linux-Kernels, konkret die sog. „SCSI-Hotplug“-Funktionalität mit 19 Einzelbeiträgen (Patches) des Klägers, vor allem aber den Beitrag mit dem Titel [PATCH] „some scsi_scan.c restructuring for ieee1394 hotplugging“, und die sog. „Radix-Trees“ geht. Weitere Beiträge des Klägers zum Linux-Kernel sind nach seinem -schriftsätzlichen Vortrag unklar geblieben. In der mündlichen Verhandlung am 28.11.2018 hat der Kläger auf gerichtlichen Hinweis klargestellt, dass er seine Ansprüche ableitet aus seinen Codebeiträgen für die Radix-Trees und das SCSI-Subsystem, wie in den Anlagen K 12 (CD-Rom insbesondere mit Ordner „E-Mail vom 14.11.2014″ und Sourcecode-Dateien) i.V.m. K 13 ([PATCH] „allow registering individual HBAs“), K 14 („scsi: Fix wrong additional sense length in descriptor format“), K 15 (Sourcecode-Vergleich), K 26 („scsi/scsi_proc.c“), K 30 ([PATCH] „radix-tree pagecache for 2.5″), K 31 („radix-tree.c“) und K 59 („Vergleichsdateien SCSI Device Hotplug und Radix Trees“), letztgenannte Anlage K 59 vorgelegt mit der Berufungsbegründung, dargestellt wird.
Hieraus ist gegebenenfalls ein konkretes Verbot abzuleiten.
aa. Der Kläger hat seine Aktivlegitimation weiterhin nicht hinreichend dargetan. Wie vorstehend bereits ausgeführt, kommen im vorliegenden Fall als Grundlage der Rechtsposition des Klägers aufgrund des erstinstanzlichen Vortrags lediglich Bearbeiterurheberrechte in Betracht, da der Kläger selbst lediglich geltend gemacht hat, sukzessiv eigenständige Beiträge zum Linux-Kernel beigetragen zu haben. Nach § 3 UrhG werden Bearbeitungen eines Werkes, die persönliche geistige Schöpfungen des Bearbeiters sind, unbeschadet des Urheberrechts am bearbeiteten Werk wie selbstständige Werke geschützt. Dass auch an einer Umarbeitung von Software ein Bearbeiterurheberrecht entstehen kann, folgt — wie ebenfalls bereits ausgeführt — aus § 69c Nr. 2 S. 2 i.V.m. § 3 UrhG. Entscheidend ist, dass die Umarbeitung selbst ein eigenschöpferisches Niveau erreicht (ebenso LG Köln GRUR-RR 2018, 11, 13 Rn. 65 — Linux-Kernel). Dabei ist auch die kleine Münze des Programmschaffens geschützt. Dies ist im Ausgangspunkt zwischen den Parteien des Rechtsstreits auch rechtlich nicht strittig.
Der Rechtsinhaber hat nach § 69c Nr. 1 UrhG das ausschließliche Recht, die dauerhafte oder vorübergehende Vervielfältigung, ganz oder teilweise, eines Computerprogramms mit jedem Mittel und in jeder Form vorzunehmen oder zu gestatten. Nach § 69c Nr. 2 UrhG hat der Rechtsinhaber das ausschließliche Recht, die Umarbeitung eines Computerprogramms sowie die Vervielfältigung der erzielten Ergebnisse vorzunehmen oder zu gestatten. Nach § 69c Nr. 4 ‚UrhG hat der Rechtsinhaber schließlich das ausschließliche Recht unter anderem der öffentlichen Zugänglichmachung. Geschützt sind dabei auch Teile von Computerprogrammen, sofern sie für sich betrachtet Werkqualität besitzen (Czychowski in Fromm/Nordemann, Urheberrecht, 12. Aufl., § 69a UrhG Rn. 22, m.w.N.). Für den Schutz von Teilen von Computerprogrammen gelten die allgemeinen Regeln (Czychowski in Fromm/Nordemann, Urheberrecht, 12. Aufl., § 69a UrhG Rn. 32a).
-welche Teile aus dem Linux-Programm von ihm in welcher Weise umgearbeitet worden sind,
-dass gerade die für ihn schutzbegründenden umgearbeiteten Programmteile ihrerseits von der Beklagten (gegebenenfalls weiter umgearbeitet) übernommen und genutzt worden sind.
Handelt es sich um ein einheitliches Werk, welches sich nicht als freie Benutzung darstellt, bliebe schließlich zu prüfen, ob auch der konkrete Ausspruch — als Minus zu einem schlichten Verbot — beansprucht werden kann. Wie bereits ausgeführt, will der Kläger sich insoweit an die GPL-2.0 halten und Nutzungsrechte unter deren Bedingungen einräumen. Insoweit bleibt festzuhalten, dass die Zugänglichmachung von unter der GPL-2.0-Lizenz stehender Software ohne Einhaltung der Lizenzbedingungen, ihre Wirksamkeit vorausgesetzt (vgl. dazu Dreier in Dreier/Schulze, UrhG, 6. Aufl., § 69c Rn. 38, 41; Czychowski GRUR-RR 2018, 1, 4 f.), eine Verletzung der ausschließlichen Nutzungsrechte der konkret als Bearbeiterurheber oder Miturheber mitwirkenden Programmierer darstellt (ebenso LG Köln GRUR-RR 2018, 11, 13 f. Rn. 55 ff. — Linux-Kernel).
Ausgehend von diesen Fragestellungen gibt es keinen Grund, hier von dem Grundsatz (vgl. auch OLG München GRUR-RR 2016, 495, 497 Rn. 32 — Die Realität III) abzuweichen, dass derjenige, der einen Anspruch geltend macht, die Darlegungs-und Beweislast für alle Tatsachen trägt, aus denen sich sein Anspruch herleitet; der Anspruchsgegner hat demgegenüber die rechtsvernichtenden, rechtshindernden und rechtshemmenden Tatsachen darzulegen und zu beweisen (vgl. Winnnners in Schricker/Loewenheim, Urheberrecht, 5. Aufl., § 97 Rn. 349). Dementsprechend trägt der Verletzte die Beweislast für das Vorliegen der tatsächlichen Voraussetzungen der Rechtsverletzung. Macht ein Software-Entwickler an Teilen eines Software-Betriebssystems (hier: Linux-Kernel) Bearbeiterurheberrechte geltend, so muss er substantiiert darlegen und gegebenenfalls beweisen, welche schutzfähigen Werke bzw. Werkteile er geschaffen hat (Czychowski GRUR-RR 2018, 1, 3), mithin welche Teile aus dem Programm von ihm in welcher Weise umgearbeitet worden sind und inwiefern diese Umarbeitungen die Anforderungen an ein Bearbeiterurheberrecht nach § 69c Nr. 2 S. 2 i.V.m. § 3 UrhG erfüllen, und inwiefern gerade die für ihn Schutz begründenden, umgearbeiteten Programmteile ihrerseits von dem vorgeblichen Verletzer übernommen worden sind (ebenso LG Köln GRUR-RR 2018, 11, 13 Rn. 59 — Linux-Kernel). Insoweit hat das Landgericht die Darlegungs- und Beweislast zweifelsfrei nicht verkannt (für strenge Anforderungen an die Darlegungslast von Open Source-Programmierern, um den Anknüpfungspunkt für die geltend gemachte Urheberrechtsverletzung zu identifizieren, auch Czychowski GRUR-RR 2018, 1, 2).
(a)Wie bereits vom Landgericht in der angegriffenen Entscheidung ausgeführt, genügen die allgemeinen Ausführungen des Klägers zu seiner Mitarbeit am Linux-Kernel und der Möglichkeit, diese auch in öffentlich zugänglichen Quellen zu recherchieren, den prozessualen Anforderungen an seine Darlegungslast nicht.
(b)Ebenso genügt die Vorlage des angeblich vollständigen Linux-Sourcecodes der Version 2.6.12-rc2 mit Versionsgeschichte gemäß Schriftsatz vom 25.09.2015 den Anforderungen an einen prozessual nachvollziehbaren Vortrag zu den vorliegend relevanten Bearbeiterurheber-Anteilen des Klägers nicht; denn es ist, wie bereits vom Landgericht Hamburg in der angegriffenen Entscheidung ausgeführt, nicht Aufgabe des Gerichts oder des Gegners, sich aus einem Gesamtsourcecode etwa vom Kläger stammende Code-Teile herauszusuchen und selbst zu beurteilen, inwieweit der Kläger für welche Teile und Zusammenhänge Urheberrechtsschutz begehren könnte. Insoweit bleibt auch der Verweis des Klägers, auf dem Datenträger Anlage K 12 seien diejenigen Teile seines Codes enthalten, die sich in „vmklinux“ wiederfänden, pauschal und genügt nicht zur Darlegung der Rechtsverletzung. Der Kläger müsste die Übernahmen konkret benennen. Dies wäre ihm auch möglich, denn unstreitig ist der Sourcecode zum Modul „vmklinux“ von der Beklagten öffentlich gemacht worden.
Auf der CD-Rom Anlage K 12 sind im dortigen Ordner „E-Mail vom 14.11.2014″ allerdings mehrere PDF-Dateien enthalten, die laut E-Mail Anlage K 10 den ebenfalls beigefügten „.blame“-Dateien entsprechen sollen. In den „.blame“-Dateien sei, so der Kläger, angegeben, welche Linux-Code-Teile von ihm stammten; letzteres scheint, wie bereits vom Landgericht Hamburg in der angegriffenen Entscheidung zugrunde gelegt, zu stimmen, denn wenn man die PDFs öffnet, sind dort Listen mit Code-Zeilen aufgeführt, in denen zu jeder Code-Zeile der jeweilige Autor genannt wird. Dies kann aber, wie bereits vom Landgericht im angefochtenen Urteil ausgeführt, nur so verstanden werden, dass es sich um die Bearbeiter-Urheberschaft der verschiedenen Autoren (einschließlich des mit aufgeführten Klägers) innerhalb von Linux selbst handelt. Schon die „.blame“-Dateien beziehen sich lediglich auf die Linux-Programmierung. Ein Vergleich mit dem „vmklinux“-Code aus dem Programm der Beklagten wird in diesen Listen jedenfalls nicht vorgenommen.
Ein solcher Vergleich findet sich stattdessen in den in der E-Mail Anlage K 10 ebenfalls genannten html-Dateien. Zu ihnen heißt es in Anlage K 10, diese Dateien gäben das Ergebnis eines Vergleichs der „Linux-Datei (Version 2.6.18) mit der Datei ihrer Mandantin“ wieder; gemeint ist damit offensichtlich ein Vergleich des Programmes Linux mit dem Programm der Beklagten. Weiter heißt es in der E-Mail Anlage K 10 wörtlich: „Die verglichenen Dateien ergeben sich aus dem Dateinamen. Sie finden in den Dateien schwarz, grün und rot markierten Code. Der schwarze Code ist solcher, der völlig unmodifiziert sowohl in der ursprünglichen Linux-Version, als auch der modifizierten Version Ihrer Mandantin enthalten ist. Der von Ihrer Mandantin hinzugefügte Code ist grün markiert, während der rot markierte Code solcher Linux Code ist, der in der Version Ihrer Mandantin nicht mehr vorhanden ist. ,scsi_error.c` und ,scsi_proc.c zeigen erhebliche Übereinstimmungen. Sie erscheinen in den anderen Dateien geringer, da Code aus mehreren Linux-Dateien in eine Datei gemergt wurde.“
-In seinem unmittelbaren schriftsätzlichen Vortrag zu Anlage K 15 (Schriftsatz vom 25.09.2015) findet sich insofern kein Beweisantritt.
-Die Anlage K 15 selbst ist kein Ausdruck eines Code-Abschnitts und auch keine Veröffentlichung einer Bearbeitungshistorie, sondern eine -klägerseitig zusammengestellte Übersicht über die einzelnen dort geltend gemachten acht Funktionen des „SCSI Device Hotplug“ („ scsi_get_command“;
„scsi_put_command“; „scsi_setup_command_freelist“;
„scsi_destroy_command_freelist“; „_scsi_iterate_devices“;
„ scsi_device_lookup“; „scsi_device_lookup“; „scsi_remove_single_device“); daher kommt der Anlage K 15 selbst keinerlei Beweiswert bezüglich der Urheberschaft des Klägers zu.
Soweit der Kläger auf die generelle Möglichkeit verwiesen hat, die Bearbeitungshistorie von Linux im Internet nachvollziehen zu können, ist dieser Vortrag, wie vorstehend bereits ausgeführt, nicht hinreichend spezifiziert bezüglich der Fragen, wo genau die Bearbeitungshistorie der acht spezifischen Funktionen veröffentlicht worden ist und welche Ergebnisse dort bezüglich der konkreten Anteile des Klägers an den acht Funktionen mitgeteilt werden.
Dies gilt, wie ebenfalls vom Landgericht Hamburg bereits ausgeführt worden ist, entsprechend auch für die vom Kläger mit der Anlage K 12 vorgelegten Dateien, die Versionshistorien enthalten sollen (history.tgz; linux.tgz). Da der Kläger somit nicht in ausreichend nachvollziehbarer Form konkrete Aussagen dieser Dateien über die spezifischen acht Funktionen geltend macht, kann deren Indizwert für eine Urheberschaft des Klägers schon nicht beurteilt werden.
Selbst wenn in den Versionsgeschichten jedoch der Kläger als letzter Bearbeiter benannt werden würde, hat die Beklagte zutreffend geltend gemacht, dass Versionshistorien keine Vervielfältigungsstücke des betreffenden Computerprogramms sind, so dass von ihnen keine Vermutungswirkungen nach § 10 UrhG ausgehen können. Der dann allenfalls noch anzunehmende Indizwert müsste aber vom Kläger konkretisiert und auf die jeweiligen Funktionen bezogen dargelegt werden. Das hat der Kläger nicht getan.
Aber selbst wenn die Anlage K 59 zu berücksichtigen wäre, würde sie immer noch nicht die Voraussetzungen an ein substantiiertes Vorbringen insbesondere in Bezug auf die Urheberschaft des Klägers erfüllen. Betreffend das „SCSI Device Hotplug“ finden sich, soweit erkennbar, in der Anlage K 59 überhaupt keine Urhebernennungen, bezüglich der „Radix-Trees“ wird der Kläger als eine unter mehreren Personen genannt. Es bleibt danach, wie von der Beklagten geltend gemacht, jedenfalls zweifelhaft, ob der Kläger insbesondere zu dem in „vmklinux“ verwendeten „Radix-Tree-Code“ überhaupt irgendeinen nennenswerten Beitrag geleistet hat. Jedenfalls identifiziert etwa der in der Anlage K 59 enthaltene Ordner „orig-to-newest“ nicht die Teile des Codes, der vom Kläger (und nicht vom Entwickler Momchil Velikov) stammen soll. Die Beauftragung eines Sachverständigen gemäß § 144 Abs. 1 ZPO kommt danach nicht in Betracht.
(a) Soweit der Kläger vorgetragen hat, er habe Anzeichen dafür, dass ein Teil der SCSI-Funktionalität sich auch im „vmkernel“ befinde, so hat er zugleich eingeräumt, er müsse jedoch mangels anderer Anhaltspunkte davon ausgehen, dass es sich insoweit um Eigenentwicklungen der Beklagten handele; damit hat der Kläger hier nach seinem eigenen Vortrag ausdrücklich keine Übernahme eigenen Linux-Codes geltend gemacht. Damit muss sich — wie bereits ausgeführt — auch insofern die Prüfung auf die Frage der Übernahmen in „vmklinux“ beschränken.
(b)Soweit der Kläger des Weiteren im Schriftsatz vom 25.09.2015 zunächst allgemein behauptet hat, er sei in der Zeit von 2000-2004 einer der aktivsten Entwickler am SCSI-Subsystem des Linux-Kernels gewesen, das sicherlich eine komplexe und damit schutzfähige Programmierung darstelle, so genügt diese generelle Behauptung nicht, urheberrechtlich schutzfähige Leistungen des Klägers darzulegen. Der Kläger kann sich für die Schutzfähigkeit seiner Beiträge nicht auf die Komplexität des SCSI-Subsystems insgesamt berufen, denn der Kläger räumt ein, auch dieses nur (mit-) überarbeitet zu haben; da er also auch hier nur ein Bearbeiterurheberrecht geltend macht, muss er diejenigen Programmierleistungen, für die er Schutz beansprucht, konkret benennen.
Das Angebot des Klägers, andere Kernel-Entwickler zu seinen Beiträgen zum Linux-Kernel zu hören, stellt keinen nachvollziehbaren Vortrag zu diesen Anteilen dar, ist als Beweismittel auf Ermittlung dieser als Voraussetzung einer Beweisaufnahme bereits spezifiziert vorzutragenden Tatsachen gerichtet und damit letztlich unbeachtlich. Ein „Ausforschungsbeweis“ liegt nicht nur vor, wenn der Beweisantrag darauf abzielt, bei Gelegenheit der erstrebten Beweisaufnahme Tatsachen in Erfahrung zu bringen, die genaueres Vorbringen oder die Benennung weiterer Beweismittel erst ermöglichen (vgl. Foerste in MusielakNoit, ZPO, 15. Aufl., § 284 Rn. 17). In diese Kategorie unzulässiger Beweisanträge fällt auch ein nicht auf substantiiertes Vorbringen gestützter Beweisantrag, der darauf abzielt, den an sich gebotenen Parteivortrag durch ein Beweisergebnis zu ersetzen. Auch ein solcher Beweisantrag berechtigt zur Ablehnung (vgl. Foerste in Musielak/Voit, ZPO, 15. Aufl., § 284 Rn. 15). Beweisangebote dienen dazu, Vortrag zu belegen und ihn nicht als solchen zu ersetzen. Das bloße Angebot von Beweismitteln kann ein substantiiertes Vorbringen nicht ersetzen.
(c)Soweit der Kläger im Schriftsatz vom 25.09.2015 geltend macht, das „SCSI-Hotplug“ sei eine der wichtigsten Funktionen, die ESXi benutze, so kann, wie vom Landgericht Hamburg in der angegriffenen Entscheidung ausgeführt, offen bleiben, ob der Kläger mit den PDFs zu 19 sog. Patches auf der CD-Rom Anlage K 12 ausreichend zu einer Bearbeiter-Urheberleistung vorgetragen hat. Nicht ausreichend ist insoweit jedenfalls sein Vortrag zu einer etwaigen Übernahme seiner Code-Anteile in „vmklinux“. Die Beklagte hat eine Übernahme relevanten Codes des Klägers im Zusammenhang mit der Hotplug-Funktionalität ausdrücklich bestritten.
Im klägerischen Schriftsatz vom 25.09.2015 heißt es dazu lediglich, das ESXi der Beklagten benutze die „Funktion“ der „Unterstützung für das SCSI-Hotplug“. Das ist nur die Behauptung einer entsprechenden Funktionalität, nicht aber die Behauptung, dass dieser Funktionalität auch identischer Programmcode zugrunde liege. Erst recht lässt sich diesem Vortrag nicht entnehmen, dass in ESXi, insbesondere in „vmklinux“, solcher Programmcode enthalten ist, der gerade die aus. der CD-Rom Anlage K 12, Ordner „Patches“, ersichtlichen 19 Beiträge des Klägers enthält, für die der Kläger Bearbeiter-Urheberrechtsschutz ‚beansprucht, insbesondere nicht in einer gerade bezüglich dieser Beiträge unveränderten Form. Eine solche Behauptung wäre aber zur schlüssigen Darlegung einer Verletzung gerade des Bearbeiter-Urheberrechts des Klägers erforderlich gewesen. Dass auch insofern die Vorlage der Anlage K 15 nicht genügt, ergibt sich aus den vorstehenden Erwägungen entsprechend. Eine Verbindung etwa zur Anlage K 59 stellt der Kläger nicht nachvollziehbar her.
Auch der Vortrag des Klägers gemäß Schriftsatz vom 29.04.2016 zum Patch „some scsi_scan.c restructuring for ieee1394 hotplugging“ (= Patch Nr. 11 auf S. 9 des Schriftsatzes vom 25.09.2015) genügt nicht. Zum einen wird nicht klar, inwiefern es sich bei diesem einzelnen Patch um eine komplexe, für eine Individualität sprechende Programmierung handelt. Jedenfalls aber wird auch hier nicht dargelegt, dass gerade die Programmierung des Klägers in „vmklinux“ übernommen worden ist; vielmehr wird zum Aufruf zweier einzelner Funktionen „scsi_add_device“ und „scsi_remove_device“ vorgetragen, an denen die Übernahme solle erkannt werden können. Das genügt nicht. Die Beklagte hat ausdrücklich vorgetragen, die „scsi_add_device“- und „scsi_remove_device“-Funktionen enthielten, so wie sie in „vmklinux“ existierten, keinen Code des Klägers. Der Kläger hätte konkret darlegen müssen, welcher Code in „vmklinux“ von ihm stammen soll. Die Funktion „scsi_remove_single_device“ ist jedenfalls inzwischen unbestritten im „vmklinux“-Code — klassisch oder nicht klassisch — „auskommentiert“ worden und wird daher nicht verwendet.
(g) Soweit der Kläger schließlich zu einer SCSI-Funktion „scsi_remove_single_device“ vorgetragen hat, unterscheidet sich dieser Vortrag von den bisher erörterten Darlegungen des Klägers zum SCSI-Subsystem zwar, wie vom Landgericht Hamburg in der angefochtenen Entscheidung zutreffend ausgeführt worden ist, dadurch, dass der Kläger hier die Herkunft konkreten Codes und dessen Übernahme in „vmklinux“ grundsätzlich nachvollziehbar behauptet, nämlich durch Angabe konkreter Dateifundstellen (im Linux Kernel 2.5.64 in der Datei „drivers/scsi/scsi_proc.c“ in den Zeilen 423 ff., wobei die ausdrücklich in Bezug genommene Anlage K 25 zwar Beiträge des Klägers ausweist, nicht aber eine Datei „drivers/scsi/scsi_proc.c“ benennt, bei VMware ESXi 5.5 Update 2 in der Datei „vmkdrivers/src_92/vmk1inux_92/1inux/scsi/scsi_proc.c“ in den Zeilen 250 ff. (Anlage K 26). Dies belegt, dass dem Kläger ein solcher Vortrag möglich ist. Damit vermag auch das Argument des Klägers, das Landgericht habe die Darlegungslast in einer Weise gesteigert, dass ein derartiges Verfahren gar nicht mehr möglich sei, nicht zu überzeugen.
Auch soweit der Kläger geltend macht, er habe bei der Entwicklung der sog. „Radix-Trees“ mitgearbeitet, so ist schon, wie vom Landgericht Hamburg zutreffend ausgeführt worden ist, ursprünglich nicht schlüssig vorgetragen worden, dass es sich insofern überhaupt um ein Computerprogramm i.S.v. § 69a Abs. 1 UrhG handelt. Erst mit der Berufungsbegründung hat der Kläger verdeutlicht, dass er von einer „Implementierung einer speziellen Baumstruktur“ und „Code“ gesprochen habe, woraus sich ohne weiteres ergebe, dass es hier um konkreten Sourcecode und nicht nur um eine abstrakte Funktion gehe. Diese Klarstellung ändert indes nichts daran, dass weiterhin jedenfalls zu für den Kläger schutzfähigen und von der Beklagten übernommenen etwaigen „Radix-Tree“-Code-Teilen nicht nachvollziehbar vorgetragen worden ist. Insoweit ist auch der bloße Hinweis auf die vorgelegten Anlagen K 30 und K 31 allein unzureichend.
(a) Das Verständnis des Begriffs des Computerprogramms in § 69a UrhG ist richtlinienkonform auszulegen. Der EuGH hat zur Richtlinie 91/250/EWG des Rates vom 14.05.1991 über den Rechtsschutz von Computerprogrammen entschieden (EuGH GRUR 2012, 814, 815 Rn. 46 — SAS Institute Inc. / VVorld Programming Ltd.), dass ihr Art. 1 Abs. 2 dahin auszulegen ist, dass weder die Funktionalität eines Computerprogramms noch die Programmiersprache oder das Dateiformat, die im Rahmen eines Computerprogramms verwendet werden, um bestimmte Funktionen des Programms zu nutzen, eine Ausdrucksform dieses Programms sind und daher nicht unter den Schutz des Urheberrechts an Computerprogrammen im Sinne dieser Richtlinie fallen. Diesem Ausspruch vorausgehend findet sich folgende Differenzierung des EuGH (EuGH GRUR 2012, 814, 815 Rn. 42 f. — SAS Institute Inc. / VVorld Programming Ltd.):
„Was die Programmiersprache und das Dateiformat anbelangt, die im Rahmen eines Computerprogramms verwendet werden, um die von den Nutzern geschriebenen Anwendungsprogramme zu interpretieren und auszuführen bzw. um Daten in einem besonderen Dateiformat zu lesen und zu schreiben, so handelt es sich um Elemente dieses Programms, mittels deren die Nutzer bestimmte Funktionen des Programms nutzen.
Würde sich ein Dritter den Teil des Quell- oder Objektcodes beschaffen, der sich auf die Programmiersprache oder das Dateiformat bezieht, die im Rahmen eines Computerprogramms verwendet werden, und würde er mit Hilfe dieses Codes in seinem eigenen Computerprogramm ähnliche Komponenten erstellen, könnte es sich bei diesem Verhalten möglicherweise um eine teilweise Vervielfältigung i.S. des Art. 4 lit. a der Richtlinie 91/250 handeln.“
In der Klageschrift spricht der Kläger zudem nur davon, es handele sich bei „Radix-Trees“ um „eine skalierbare Implementierung einer speziellen Baumstruktur, die insbesondere in der Verwaltung von Dateisystemen-Puffern (Caches), aber auch in vielen anderen Anwendungsbereichen benutzt werde“. Daraus wird nicht ersichtlich, dass es sich um einen konkreten Programm-Code handelt, der selbst ausführbar ist, oder einen urheberrechtsschutzfähiger Teil eines ausführbaren Programmcodes darstellt. Vielmehr lässt sich der Vortrag des Klägers nur dahin verstehen, es gehe um eine „Struktur“, also die Art und Weise einer Anordnungsmöglichkeit. Selbst wenn sich diese Struktur darauf beziehen sollte, in welcher Weise (Reihenfolge) bestimmter Programmcode (als bestimmte Befehle) zum Beispiel am sinnvollsten, effektivsten, Speicherplatz sparend oder am schnellsten ausführbar anzuordnen ist, so ginge es dann doch nur um ein generelles Gestaltungsprinzip für Computerprogramme, nicht aber um ein Programm als solches. Ein bloßes Gestaltungsprinzip, welches — wie der Kläger selbst geltend macht — in unterschiedlichsten Zusammenhängen anwendbar ist, ist als solches aber nicht urheberrechtlich schutzfähig.
Soweit es dazu bereits in der Klageschrift heißt, eine von ihm durchgeführte Analyse habe ergeben, dass im Quellcode der Beklagten — so wörtlich — „die ,Radix-Tre&-Funktionalität verwendet“ worden sei und dafür zum Beweis angeboten wird „Im Bestreitensfall Vorlage von Quellcode-Dateien“, so ist aus dem Vortrag zum einen schon nicht zu entnehmen, dass überhaupt konkrete Codezeilen übernommen worden sein sollen („Funktionalität“), zum anderen nicht nachzuvollziehen, welche Code-Zeilen dies gegebenenfalls sein sollten. Schließlich ist das Beweisangebot, wie bereits das Landgericht Hamburg in der angefochtenen Entscheidung angenommen hat, nicht nur mangels unzureichenden Tatsachenvortrags unzulässig, sondern auch selbst völlig unbestimmt.
Soweit der Kläger sodann im Schriftsatz vom 29.04.2016 Ausführungen zu „Radix-Trees“ macht, spricht zwar, wie bereits vom Landgericht Hamburg in der angefochtenen Entscheidung ausgeführt, die Vorlage der Anlage K 31 mit Code aus „vmklinux“ der Beklagten dafür, dass es sich bei „Radix-Trees“ nicht allein um eine Struktur, sondern um konkrete Programmzeilen handeln mag. Der Kläger legt aber nicht dar, welche Teile der Anlage K 31 (dem Verletzungsmuster) denn aus Linux übernommen und welche davon wiederum von ihm geschaffen worden seien (Klagemuster). Noch im Schriftsatz vom 07.11.2018 führt er wiederum lediglich allgemein aus, die Anlage K 31 enthalte den von der Beklagten verwendeten Quellcode, der auch Programmierungen des Klägers enthalte, die wiederum als Anlage K 30 vorgelegt worden seien. Darüber hinaus räumt der Kläger ein, die Struktur nicht „erfunden“ zu haben; lediglich an der „Implementation“ habe er neben dem Erfinder Momchil Velikov mitgewirkt. Damit ist aber derjenige Anteil des Codes, den der Kläger selbst geschaffen haben will, aus dem Vortrag des Klägers nicht zu entnehmen. Auch die Anlage K 30 gibt insofern keinen Aufschluss. Soweit deren Seite 1 darauf hinzudeuten scheint, dass Teile des Codes vom Kläger stammen könnten, so bleibt unklar, auf welche konkreten Zeilen sich das bezieht und inwiefern gerade diese Zeilen auch in „vmklinux“ verwendet worden sein sollen. Das gilt umso mehr, als der Kläger selbst vorträgt, die Beklagt habe gar nicht die aus Anlage K 30 ersichtliche Version von 2002, sondern eine spätere Version von 2012 zur Grundlage von „vmklinux“ genommen; welche Teile der „Radix-Trees“-Version aus 2012 aber vom Kläger stammen sollen, lässt sich dem Vortrag des Klägers ebenfalls nicht entnehmen. Insofern ist der vom Kläger angebotene Sachverständigenbeweis darauf gerichtet, vom Kläger als Voraussetzung einer Beweisaufnahme substantiiert vorzutragende Tatsachen erst zu erbringen und damit zu ersetzen, mithin unzulässig und abzulehnen.
Soweit der Kläger nunmehr vorträgt, dass es unschädlich sei, dass auch der Entwickler Momchil Velikov an der Ursprungsprogrammierung beteiligt gewesen sei, ist dies einerseits neuer Vortrag, wenn der Kläger sich damit jetzt auf eine Miturheberschaft berufen will, und andererseits so nicht zutreffend. Der pauschale Vortrag des Klägers, die Programmierung sei tatsächlich gemeinsam und damit in Miturheberschaft gemacht worden, ist gemäß § 531 Abs. 2 ZPO schon nicht zuzulassen, in jedem Fall aber auch unzureichend. Eine Miturheberschaft setzt nach § 8 Abs. 1 UrhG eine gemeinsame Schöpfung voraus. Ein Werk wird gemeinsam geschaffen, wenn mehrere Schöpfer zum Zwecke seiner Entstehung zusammenarbeiten, wobei jeder einzelne Schöpfer seinen eigenen schutzfähigen Beitrag zur Schöpfung leistet (VVirtz in Fromm/Nordemann, Urheberrecht, 12. Aufl., § 8 UrhG Rn. 2, m.w.N.). Voraussetzung für eine Miturheberschaft ist eine einheitliche Schöpfung, die einen entsprechenden natürlichen Handlungswillen der beteiligten Urheber voraussetzt; bei zeitlich gestaffelten Beiträgen ist eine Miturheberschaft zwar nicht ausgeschlossen, sie setzt jedoch voraus, dass jeder Beteiligte seinen schöpferischen Beitrag in Unterordnung unter die gemeinsame Gesamtidee erbracht hat (BGH GRUR 2005, 860, 862 f. — Fash 2000). Mithin setzt (auch) die Annahme einer Miturheberschaft substantiierten Vortrag dazu voraus, wie die Zusammenarbeit der Urheber und ihr Handlungswillen genau ausgestaltet waren und welchen Beitrag der Kläger genau in Abstimmung mit dem anderen Urheber geleistet hat. Dieser Vortrag fehlt hier aber gerade. Er kann nicht durch die bloße Behauptung des Rechtsbegriffs einer „Miturheberschaft“ ersetzt werden. Im Gegenteil spricht hier alles gegen eine Miturheberschaft: Der Beitrag des Klägers wird in der Anlage K 59 („Radix-Trees“: „radix-tree.c“ und „radix-tree.h“) lediglich mit „Portions Copyright 0 2001, mithin als „Teil“-Copyright, bezeichnet, ohne dass eine genaue Zuordnung erfolgt. Eine Miturheberschaft unterscheidet sich hiervon deutlich.
Der Kläger bezieht sich insoweit erneut auf die Anlage K 24, die eine „Patch-Datei“ enthält, in welcher der Code des Linux-Kernel bearbeitet worden ist, indem zwei Funktionen eingefügt worden sind, die genau ein Gerät hinzufügen bzw. löschen: „scsi_add_device“ und „scsi_remove_device“. Die Funktionalitäten seien, so der Kläger, von der Beklagten im Wesentlichen übernommen worden, so zum Beispiel die Funktionalität in der Funktion „ scsi_iterate_devices“ und dem darauf basierenden Makro „shost_for_each_device“, welche bei der Beklagten nur trivial verändert worden seien. Ebenso seien andere Funktionen inklusive der Kommentare übernommen worden, zum Beispiel „scsi_device_lookup and _scsi_device_lookup“.
Auch hierzu ist festzuhalten, dass die Anlage K 30 nur die vom Kläger behaupteten Beiträge zu Linux zeigt, nicht aber die vom Kläger behaupteten Beiträge zu Linux, die in „vmklinux“ verwendet worden sein sollen. Zudem zeigt die Anlage K 30 nicht auf, was der Kläger genau beigetragen haben will, da die Beiträge, wie auch die Anlage K 59 zu „radix-tree.c“ und „radix-tree.h“ ausweist, maßgeblich auch und gerade auf den Entwickler Momchil Velikov zurückgehen. So erlaubt die Anlage K 30 keine genaue Identifizierung des Bearbeiters. Auch die Komplexität der übernommenen Programmierung ergibt sich nicht. Die mit der Berufungsbegründung vorgelegte Anlage K 59 weist zudem aus, wie auch die Beklagte geltend macht, dass die von der Beklagten angeblich verwendete neuere Version durch spätere Veränderungen, nämlich Streichungen und Hinzufügungen, völlig anders als der ursprüngliche Code ist, den angeblich der Kläger und der Entwickler Velikow beigetragen haben.
(8)Soweit die Klägerin in der Klageschrift weiter behauptet hat, seine Analyse habe ergeben, dass viele andere Teile des Linux-Betriebssystems von der Beklagten verwendet würden, zu denen er kleinere Bearbeitungen des Quellcodes beigetragen habe, und auch hier „Vorlage von Quellcode-Dateien“ als Beweis angeboten wird, so ist auch dieser Vortrag in mehrfacher Hinsicht nicht ausreichend, denn weder wird deutlich, um welche „Teile“ aus Linux es gehen soll, welche Bearbeitungsleistung der Kläger insofern geleistet haben will und welche gerade von ihm stammenden Code-Teile in „vmklinux“ übernommen worden sein sollen.
(9)Soweit der Kläger in seiner Klarstellung im Verhandlungstermin am 28.11.2018 speziell auf die Anlage K 14 („scsi: Fix wrong additional sense length in descriptor format“) Bezug genommen hat, ist dies von vornherein nicht geeignet, seine Aktivlegitimation in irgendeiner Weise zu stützen. Mit dem Schriftsatz vom 25.09.2015 ist die Anlage K 14 als Beispiel für einen Fall vorgelegt worden, in dem der Kläger den Entwicklungsbeitrag eines Dritten (als sog. „reviewer“) überprüft hat. Dabei hat der Kläger ausdrücklich ausgeführt, vorliegend nur Urheberrechte aus Codebeiträgen geltend zu machen, die er selbst geschrieben hat. Der Code gemäß Anlage K 14 fällt von vornherein nicht in diese Kategorie. Ausgewiesener Autor ist vielmehr eine andere Person („author Sagi Grimberg“).
Entsprechendes gilt, soweit der Kläger in seiner Klarstellung im Verhandlungstermin am 28.11.2018 speziell auf die Anlagen K 26 („scsi/scsi_proc.c“) und K 31 („radix-tree.c“) Bezug genommen hat. Ausweislich seines Vortrags im Schriftsatz vom 29.04.2016 handelt es sich sowohl bei der Anlage K 26 als auch bei der Anlage K 31 um den Ausdruck von Quellcode der Beklagten. Dies wird auch durch die vom Kläger in Bezug auf die Anlage K 26 mitgeteilte vollständige Dateibezeichnung („vmkdrivers/src_92/vmklinux_92/1inux/scsi/scsi_proc.c“) und den Copyright-Vermerk eingangs der Anlage K 26 („Portions Copyright 2008, 2010-2011 VMware, Inc.“) belegt. Ebenso weist die Anlage K 31 den Copyright-Vermerk der Beklagten aus („Portions Copyright 2012 VMware, Inc.“). Dementsprechend können auch diese zur Klarstellung herangezogenen Anlagen die klägerische Position in der Sache nicht stützen.
(10) Soweit sich der Kläger schließlich darauf beruft, dass bei komplexen Computerprogrammen eine tatsächliche Vermutung für eine hinreichende Individualität der Programmgestaltung spreche (vgl. BGH GRUR 2005, 860, 861 — Fash 2000), ist dies im Ausgangspunkt zwar zutreffend, rechtfertigt im vorliegenden Fall indes keine von den landgerichtlichen und den vorstehenden Ausführungen abweichende Bewertung.
Die vom Kläger angeführte tatsächliche Vermutung knüpft, wie der BGH in der „Fash 2000″-Entscheidung (BGH GRUR 2005, 860, 861 — Fash 2000) zum Ausdruck gebracht hat, an das Vorliegen eines komplexen Computerprogramms an. Zudem erging die „Fash 2000″-Entscheidung des BGH in Bezug auf ein Programm, das aufgrund jahrelanger Programmierarbeit von einem einzelnen Programmierer geschaffen worden war (vgl. auch Czychowski GRUR-RR 2018, 1, 3). Im vorliegenden Fall geht es jedoch, wie vorstehend ausgeführt, lediglich um ein Bearbeiterurheberrecht des Klägers. Dieser hat indes gerade nicht dargelegt, dass seine angeblichen Beiträge zum Linux-Code, die nach dem Vortrag der Beklagten allenfalls geringfügige Änderungen einer bestehenden Computerprogrammdatei waren, mit komplexen Programmen vergleichbar sind und deshalb die Vermutung der „Fash 2000″-Entscheidung im vorliegenden Fall zur Anwendung kommen kann. Stattdessen bezieht sich der Kläger lediglich auf zwei angeblich komplexe „Funktionen“ („SCSI Device Hotplug“ und „Radix-Trees“) und verweist insbesondere auf die Anlagen K 26, K 27 und K 31 als Beweismittel für die Übernahme von derartigen komplexen Funktionen durch die Beklagte. Dies ist nicht ausreichend, zumal die Analyseergebnisse gemäß Anlage K 27 nicht einmal einen Bezug zum „Radix-Tree“ haben. Dies räumt der Kläger jetzt auch ausdrücklich ein.
Die „Fash 2000″-Entscheidung des BGH sieht nicht vor, dass ein Bearbeiter, der lediglich ein bereits existierendes Werk bearbeitet hat, sich auf die Vermutung einer geschützten Urhebereigenschaft stützen kann, nur weil das bereits existierende Werk Aspekte aufweist, die komplex sind. Die Vermutung gilt nur in den Fällen, in denen die Bearbeitung selbst ein komplexes Computerprogramm darstellt. Dies ist hier nicht zu erkennen.
Unterstellt es gäbe hier konkret übernommene, schutzfähige Elemente des Originalwerks, handelte es sich nach dem Vorstehenden allenfalls um einzelne Programmbefehle, die nach dem derzeitigen Stand im Kontext des Gesamtbildes der neuen schöpferischen Gestaltung des Programms der Beklagten so sehr „verblassen“, dass eine urheberrechtliche Bearbeitung zu verneinen ist. Legt man den klägerischen Vortrag zur „SCSI-Hotplug“-Funktionalität („SCSI Device Hotplug“) zugrunde, der allenfalls den — wie hier unterstellt werden soll — Vorwurf einer unzulässigen Umarbeitung rechtfertigen könnte, so ist nach den Gesamtumständen von einer freien Benutzung auszugehen. Das Programm „vmkernel“ als solches ist von der Beklagten, wie unstreitig ist, in zeitlicher Hinsicht entwickelt worden, bevor der Kläger sein angebliches Softwarewerk schuf. Bei dem Anteil des Klägers handelt es sich um einen kleinen Anteil eines einzelnen Moduls, das die Beklagte bereits unter der GPL-2.0 „opensourced“ hat. Wie die Beklagte weiter vorträgt, macht der behauptete Beitrag des Klägers insgesamt höchstens 0,07 % des Codes in „vmklinux“ und 0,012 % des Codes in „vmkernel“ und „vmklinux“ als Einheit betrachtet aus, ohne dass der Kläger aufgezeigt hat, dass diese Größenordnung unzutreffend sein könnte. Da der Kläger sowohl den eigenen Code, nämlich seine schutzfähigen Beiträge zu Linux, als auch den angegriffenen Code kennt, ist sein Bestreiten mit Nichtwissen an dieser Stelle unzulässig. Zu qualitativ herausgehobenen Programmierungen trägt auch der Kläger nichts vor. Insoweit ist es ohne weiteres veranlasst, von einer freien Benutzung i.S.d. § 24 UrhG auszugehen, selbst wenn der Vortrag der Beklagten, dieser Beitrag bestehe größtenteils aus substanzlosen Änderungen von bereits bestehendem und von Dritten geschriebenem Code, so unzutreffend sein sollte.
Dass sich die Übernahmen nach dem insoweit durchaus übereinstimmenden Vortrag der Parteien in ganz engen Grenzen halten, wird auch durch den weiteren Vortrag des Klägers bestätigt. Der Kläger trägt selbst beispielhaft ausdrücklich vor, es sei zu berücksichtigen, dass der Quellcode des Linux-Kernels bei der Weiterentwicklung ständig geändert werde, wobei die Änderungen meist in kleinen Schritten erfolgten. Seit der ursprünglichen Version der Datei „lib/radix-tree.c“ habe es 75 weitere Beiträge („Commits“) bis zu der Version aus Linux 3.3, die die Beklagte 10 Jahre später mit minimalsten Anpassungen übernommen habe. Dies lässt zum einen darauf schließen, dass der Beitrag des Klägers an übernommener Programmierung schon sehr überschaubar ist, und zum anderen und vor allem ebenfalls deutlich werden, dass sein Beitrag zu „vmklinux“ jedenfalls vom Umfang her zu vernachlässigen ist. Wenngleich der Kläger Recht hat, wenn er darauf hinweist, dass eine rein quantitative Analyse zu kurz greift, bietet sie jedoch durchaus einen Anhaltspunkt, gerade wenn — wie hier — zur Qualität bzw. Schöpfungshöhe einzelner Programmierleistungen auch kein Vortrag erfolgt, so dass jedenfalls von einer gesteigerten Schöpfungshöhe nicht im Ansatz ausgegangen werden kann.
Bestätigt wird dies alles durch die vom Kläger vorgelegte Anlage K 61: Der Anteil der Datei „lib/radix-tree.c“, der überhaupt vom Kläger stammen könnte („schwarze Schrift“), macht nur einen Bruchteil der Programmierung aus. Zudem geht dieser Anteil, wie ausgeführt, jedenfalls auch auf den Entwickler Momchil Velikov zurück, ohne dass eine Miturheberschaft tatsächlich dargetan ist. Der Beitrag des Klägers wird lediglich mit „Portions Copyright © 2001″, mithin als „Teil“-Copyright, bezeichnet, ohne dass eine genaue Zuordnung erfolgt. Auch der Vortrag, die Übernahmen stammten aus verschiedenen Linux-Versionen, stützt die Position des Klägers in keiner Weise. Zudem haben die Programme unterschiedliche Zielrichtungen und stehen, soweit erkennbar, wirtschaftlich nicht in Konkurrenz zueinander.
b. Wie sich bereits aus dem Vorstehenden ergibt, ist damit auch der mit dem Klageantrag zu 2. geltend gemachte Anspruch auf Erstattung von Abmahnkosten zzgl. Zinsen nach § 97a Abs. 3 S. 1 UrhG i.V.m. §§ 31, 69c UrhG, §§ 288, 291 ZPO schon dem Grunde nach nicht gegeben. Es gilt hier — anders als vom Kläger geltend gemacht — bereits die Neuregelung des § 97a Abs. 3 UrhG, da die Abmahnung nach dem 09.10.2013 erfolgte (vgl. Specht in Dreier/Schulze, UrhG, 6. Aufl., § 97a Rn. 2). Auf die Anspruchshöhe kommt es nicht mehr an.
4. Der nicht mehr nachgelassene Schriftsatz des Klägers vom 29.01.2019 hat keine Veranlassung zur Wiedereröffnung der mündlichen Verhandlung gegeben, §§ 296a, 156 ZPO. Mit dem Inhalt des Schriftsatzes hat sich der Senat — soweit geboten — in den vorstehenden Ausführungen bereits auseinandergesetzt.
6. Die Voraussetzungen für eine Zulassung der Revision nach § 543 Abs. 2 ZPO- liegen nicht vor. Die Rechtssache hat weder grundsätzliche Bedeutung noch erfordern die Fortbildung des Rechts oder die Sicherung einer einheitlichen Rechtsprechung eine Entscheidung des Revisionsgerichts. Es handelt sich vorliegend um eine Einzelfallentscheidung, die auf der Anwendung bereits bestehender höchstrichterlicher Rechtsprechung beruht. Etwas Abweichendes trägt auch der Kläger nicht vor.

References: § 3
 § 69
 § 144
 BGH 
 § 531
 § 530
 § 296
 § 253
 § 39
 § 69
 § 3
 § 69
 § 23
 § 3
 § 69
 § 3
 § 69
 § 69
 § 69
 § 69
 § 69
 § 69
 § 97
 § 69
 § 3
 § 10
 § 144
 § 284
 § 284
 § 69
 § 69
 EuGH 
 Art. 1
 EuGH 
 Art. 4
 § 531
 § 8
 § 8
 BGH 
 BGH 
 BGH 
 BGH 
 § 24
 § 97
 § 97
 § 97
 § 543