IT-Recht. IP-Recht. 360°

Jetzt unverbindlich Kontakt aufnehmen:

OLG Hamburg: Zur komplexen Beweisführung der Bearbeiterurheberschaft an Open Source Software / Helwig vs. VM Ware Global Inc.

veröffentlicht am 21. Mai 2019

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!


Haben Sie ein rechtliches Problem mit Open Source Software?

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.



Hanseatisches Oberlandesgericht Hamburg

Urteil

In der Sache

Christoph Hellwig, Schidlachstraße 11, 6020 Innsbruck, Österreich

– Kläger und Berufungskläger –

gegen

VMware Global Inc., Zweigniederlassung Deutschland, Freisinger Straße 3, 85716 Unterschleißheim

– Beklagte und Berufungsbeklagte –

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.

II. Der Kläger hat die Kosten des Berufungsverfahrens zu tragen.

III. Das vorliegende Urteil und das angefochtene erstinstanzliche Urteil sind ohne Sicherheitsleistung vorläufig vollstreckbar. Der Kläger kann die Zwangsvollstreckung der Beklagten aus den Kostenentscheidungen erster und zweiter Instanz jeweils durch Sicherheitsleistung in Höhe von 110 % der auf Grund der Urteile vollstreckbaren Beträge abwenden, sofern nicht die Beklagte vor der Vollstreckung ihrerseits Sicherheit in Höhe von 110 % des jeweils zu vollstreckenden Betrages leistet.

IV. Die Revision wird nicht zugelassen.

Gründe

Der Kläger verfolgt einen urheberrechtlichen Unterlassungsanspruch. Daneben begehrt er die Zahlung von vorgerichtlich entstandenen Rechtsanwaltskosten. Aus der Sicht des Klägers geht es im Kern um die Frage, was als Bearbeitung eines Computerprogramms anzusehen ist, wenn Softwarekomponenten zu einem Softwareprodukte verschmolzen werden.

Der Kläger ist selbstständiger Softwareentwickler. Er arbeitet seit Jahren an einer Vielzahl von Open Source-Softwareprojekten mit, so auch seit dem Jahre 2000 an der Fortentwicklung des Linux-Betriebssystems. Welche Anteile er genau an Linux bearbeitet hat, ist streitig. Der Kläger macht geltend, am sog. Kernel des Linux-Betriebssystems mitgearbeitet und auf diese Weise Bearbeiterurheberrechte erworben zu haben. Er wirft der Beklagten vor, für ein von ihr angebotenes Softwareprodukt unrechtmäßig Teile seines Linux-Codes verwendet zu haben.

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.

Linux-Kernelmodule sind keine klassisch dynamisch ladbaren Treiber und andere Module, die anhand einer abstrakten Schnittstellendefinition entwickelt werden, sondern haben vollen Zugriff auf die Interna des Linux-Betriebssystems und werden allenfalls zur Reduzierung des Ressourcenverbrauchs ausgelagert. Anders als bei anderen Betriebssystemen sind bei Linux die Treiber und der Kern des Betriebssystems grundsätzlich untrennbar; bei Linux stammen die internen Schnittstellen und die Treiber regelmäßig aus der gleichen Hand und werden zusammen erstellt. Die Schnittstellen bei Linux sind nicht stabil, also weder gleichbleibend noch rückwärtskompatibel. Vielmehr werden Schnittstellen und Treiber ständig aneinander angepasst. Der Betriebssystemkern und die Treiber sind voneinander abhängig und entwickeln sich gemeinsam und gegenseitig.

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 Aufbau von ESXi weist eine Architektur auf, bei der der Betriebssystem-Kernel von sog. Kernelmodulen getrennt ist, wobei die Parteien darüber streiten, ob eine funktionale Einheit von „vmkernel“ und „vmklinux“ besteht:

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 Kläger hat vorgetragen, dass die Beklagte für ein eigenes, zum Download angebotenes Softwareprodukt Teile seines Linux-Codes verwendet habe. Sie könne sich dafür nicht auf die Open Source-Lizenz, unter der Linux veröffentlicht worden sei, berufen, da sie deren Lizenzbedingungen nicht eingehalten habe. Die auflösend bedingte Lizenzierung sei entfallen, weshalb für die Beklagte derzeit kein Nutzungsrecht mehr bezüglich der Linux-Code-Anteile bestehe und er, der Kläger, als Mitbearbeiter von Linux der Beklagten die Nutzung ihrer unter Verwendung von Linux entwickelten Software untersagen könne.

Er, der Kläger, habe erhebliche Teile des Linux-Kernels bearbeitet und insofern Bearbeiter-Urheberrechte erworben. Der von ihm entwickelte Source Code sei in dem sog. Git-Repository unter der URL <https://git.kernel.org/cgit/linux/kernel/> für jedermann öffentlich einsehbar. Es könne in den Repositories des Mainline-Kernels (d.h. der offiziellen Kernelversion) jeder Entwicklungsbeitrag seiner Person detailliert nachvollzogen und belegt werden. Ergänzend hat der Kläger auf der CD-Rom Anlage K 12 (Ordner history.tgz) den nach seinen Angaben vollständigen Source Code des letzten Standes der Entwicklung des Linux-Programms mit dem Source Code-Verwaltungssystem Bitkeeper (Linux Version 2.6.12-rc2) als Archiv (history.tgz) und die gesamte Versionsgeschichte bis dahin im Git-Format vorgelegt. Ferner verweist der Kläger für die CD-Rom Anlage K 12 auf den dortigen Ordner „linux.tgz“ und erklärt, er lege damit das Archiv vor, das sowohl den Stand des Linux-Kernels in Version 2.6.18 enthalte als auch die gesamte Versionsgeschichte zwischen Linux 2.6.12-rc und Linux 2.6.18 im Git-Format. Die Version 2.6.18 des Linux-Kernels sei diejenige, die der von der Beklagten verwendeten Version am ähnlichsten sei. Mit der CD-Rom Anlage K 12 liege der Source Code vor, den er, der Kläger, zu Linux beigetragen habe und der sich in dem Modul „vmklinux“ der Beklagten wiederfinde. Die weiter mit der CD-Rom Anlage K 12 vorgelegten „.blame“-Dateien zeigten, welcher Code von ihm stamme und welche Änderungen die Beklagte vorgenommen habe.

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.

Der Kläger hat weiter vorgetragen, er habe vor allem am sog. SCSI-Subsystem des Linux-Kernels mitgearbeitet. Dieser Code sei seit 1992 (damals noch ohne seine Beteiligung) als Teil des Linux-Kernels entwickelt und immer zusammen mit dem Kernel als Teil eines einzigen Programms veröffentlicht worden. Es sei zwar möglich, das SCSI-Subsystem in ein separates Kernelmodul auszulagern, jedoch werde davon in der Praxis nur selten Gebrauch gemacht. Das SCSI-Subsystem interagiere direkt mit der Speicherverwaltung, den Dateisystemen und dem Scheduler (zur Steuerung von Prozessen des Betriebssystems) und werde nicht über abstrakte Schnittstellen angesprochen. Er, der Kläger, sei selbst 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. Andere Linux-Kernel-Entwickler könnten bezeugen, dass er, der Kläger, wesentliche und komplexe Beiträge zu der Entwicklung des SCSI-Subsystems geleistet habe. Er, der Kläger, habe zwar Anzeichen dafür, dass ein Teil der SCSI-Funktionalität sich auch im „vmkernel“ befinde, er müsse jedoch mangels anderer Anhaltspunkte davon ausgehen, dass es sich insoweit um Eigenentwicklungen der Beklagten handele.

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.

Schließlich habe die Analyse ergeben, dass viele andere Teile des Linux-Betriebssystems von der Beklagten verwendet würden, zu denen er, der Kläger, kleinere Bearbeitungen des Quellcodes beigetragen 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.

Aus einerseits der Notwendigkeit, „vmkernel“ und „vmklinux“ als Einheit betrachten zu müssen, und andererseits dem Umstand, dass in „vmklinux“ Teile des Codes von „Radix-Trees“ und des SCSI-Subsystems übernommen worden seien, folge die Bewertung, dass die Software VMware ESXi als „combined work“ bzw. „derivative work“, also als Bearbeitung der Programmierleistung des Klägers angesehen werden müsse.

Der Kläger hat beantragt, die Beklagte zu verurteilen,

1. es bei Vermeidung eines vom Gericht für jeden Fall der Zuwiderhandlung festzusetzenden Ordnungsgeldes bis zu € 250.000,00 und für den Fall, dass dieses nicht beigetrieben werden kann, einer Ordnungshaft oder einer Ordnungshaft bis zu sechs Monaten, diese zu vollziehen am ihrem ständigen Vertreter, zu unterlassen,
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;

2. an den Kläger € 4.046,00 nebst Zinsen hieraus in Höhe von fünf Prozentpunkten über dem jeweiligen Basiszinssatz seit Rechtshängigkeit zu zahlen.

Die Beklagte hat beantragt, die Klage abzuweisen.

Die Beklagte hat geltend gemacht, der Kläger versuche es, sie, die Beklagte, zu zwingen, auf den Schutz ihres geistigen Eigentums an dem Produkt ESXi de facto zu verzichten, indem ESXi Gegenstand einer „open source“-Softwarelizenz werden solle, dies allein mit der Begründung, die zentrale Komponente von ESXi, der „vmkernel“, enthalte zwar selbst keinen Linux-Code, kommuniziere aber mit einem eigenständigen Modul, welches seinerseits Linux-Code verwende. Ein solcher Anspruch stehe dem Kläger nicht zu. Insbesondere habe der Kläger weder hinreichend dargelegt, dass und welche Anteile er am Linux-Code habe, die überhaupt in „vmklinux“ verwendet worden seien, noch sei die Argumentation des Klägers zur Einordnung des „vmkernel“ als eines aus Linux im Sinne der GPL-2.0 „abgeleiteten“ Werkes tatsächlich und rechtlich zutreffend.

Der Beklagte hat vorgetragen, dass die Klage schon unzulässig sei. Der Antrag sei zu unbestimmt und der Kläger habe kein Rechtsschutzbedürfnis daran. Die Klage sei aber auch unbegründet.
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.

Soweit der Kläger für seine Urheberschaft auf das SCSI-Subsystem verweise, sei der Vortrag unsubstantiiert, weil der Kläger nicht erläutere, welche bestimmten Dateien des Linux-Kernels seiner Ansicht nach das SCSI-Subsystem bilden sollen. Unklar sei auch, was genau der Kläger dazu beigetragen habe. Auch soweit sich der Kläger für seine Urheberschaft auf „Radix-Trees“ berufe, sei der Vortrag unsubstantiiert. „Radix-Trees“ seien Jahrzehnte alte Dateien-Strukturen, die dem schnellen Aufruf von Dateien dienten. Der Kläger habe nicht erläutert, welchen Code er geschrieben habe und dass dieser Code hinreichend kreativ für einen Urheberrechtsschutz sei. Darüber hinaus seien „Radix-Trees“ schon nach dem eigenen Vortrag des Klägers lediglich Strukturen; bloße Dateistrukturen seien aber nach der Rechtsprechung des EuGH gerade keine urheberrechtlich geschützten Computerprogramme.

Der Verweis des Klägers auf ein Repository zum Beleg seiner Urheberschaft an bestimmten Code sei ebenfalls nicht ausreichend; der Vortrag des Klägers, er habe zum Code „beigetragen“ bzw. sei daran „beteiligt“, stelle nicht genau genug dar, was der Kläger geschaffen haben wolle; vielmehr ergäben Analysen der Beklagten, dass tatsächlich andere Programmierer den gesamten oder zumindest Teile des Codes, für den der Kläger Urheberschaft beanspruche, geschrieben hätten.

Die Beklagte hat angebliche Beiträge des Klägers mit Nichtwissen bestritten. Sie hat ebenso die urheberrechtliche Schutzfähigkeit etwaiger Beiträge bestritten. Der Kläger habe kein einziges konkretes Beispiel für Code vorgelegt, der von ihm stamme, eine urheberrechtlich geschützte individuelle geistige Schöpfung darstelle und den sie, die Beklagte, in „vmklinux“ verwendet habe.
Selbst wenn aber der Kläger Teile des Linux-Kernel geschaffen haben sollte, so könne er insofern lediglich Bearbeiter-Urheberrechte erworben haben und diese seien dann auf die bearbeiteten Teile begrenzt. Der Kläger könne keine Rechte geltend machen, die über seine eigenen Beiträge hinausgingen.

Der Kläger liefere keinen ausreichenden Vortrag zu einer verletzenden Übernahme von Code, nämlich dazu, dass die Software der Beklagten tatsächlich originäre und/oder bearbeitete Werke/Werkteile enthalte, an denen dem Kläger Rechte zuständen, bzw. dass „vmkernel“ aus schutzfähigen Linux-Anteilen des Klägers abgeleitet sei. Ihr Produkt ESXi sei kein einheitliches ausführbares, sondern ein Softwareprodukt, welches viele Werke sowie Komponenten, Funktionen und Merkmale umfasse; der Kläger habe nicht dargetan, dass und wie sie, die Beklagte, ESXi zum Download über das Internet angeboten habe.

Soweit ihr der Kläger vorwerfe, sie habe Linux-Code überarbeitet, um ihn für eine enge Integration mit dem proprietären Bestandteil von „vmkernel“ benutzen zu können, so sei dieser Vortrag unsubstantiiert; zudem habe sie, die Beklagte, Linux-Kernel-Code verwendet, um eine Technologie zu entwickeln, die einen völlig anderen Zweck habe als der Linux-Kernel, nämlich um ein Interoperabilitätsmodul zu schaffen, was unter der GPL gestattet sein. Jeglicher SCSI-Code in „vmklinux“ diene etwa einem anderen Zweck als das SCSI-Subsystem innerhalb von Linux. Auch soweit der Kläger auf die „SCSI-Hotplug“-Funktionalität verweise, sei die Fähigkeit eines Systems, Komponenten auszutauschen, ohne das System herunterfahren zu müssen, weder eine Erfindung oder Schöpfung des Klägers noch ein Feature, das in einer einzigen Funktion implementiert werde. Die vom Kläger hierzu in Bezug genommenen „Patches“ seien nicht aussagekräftig, denn sie bezögen sich auf den Linux-Kernel, nicht aber auf „vmklinux“ und könnten daher keine Aussage darüber treffen, ob von demjenigen Code, den der Kläger geschrieben haben wolle, überhaupt etwas schutzfähig und von der Beklagten verwendet worden sei. Tatsächlich enthielten die Funktionen in „vmklinux“, die sich auf die Hotplug-Funktionalität bezögen, keinen wesentlichen vom Kläger stammenden Code.

Es sei im Übrigen insgesamt davon auszugehen, dass etwaige Linux-Code-Beiträge des Klägers, soweit sie innerhalb von „vmklinux“ und damit von ESXi verwendet worden sein sollten, dem Umfange nach so gering seien, dass sie im Verhältnis zur Gesamtheit von „vmklinux“, „vmkernel“ und „ESXi“ so sehr zurücktreten, dass keine Umarbeitung oder Bearbeitung, sondern allenfalls eine freie Benutzung vorliege. Sie, die Beklagte, habe erhebliche Änderungen am Linux-Code vorgenommen:

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.

Es liege auch kein Verstoß gegen die Lizenzbedingungen der GPL-2.0 vor. Den Quellcode von „vmklinux“ als solchen habe sie, die Beklagte, wie unstreitig ist, im Einklang mit der GPL lizenziert. Der Quellcode von „vmkernel“ müsse nach diesen Bedingungen nicht offen gelegt werden. Zwar sähen die Bedingungen vor, dass der Quellcode eines sogenannten „derivative work’s“, also eines vom frei lizenzierten Werk abgeleiteten Werks, offen gelegt werden müsse. Jedoch sei „vmkernel“ kein von Linux abgeleitetes Werk. „Vmkernel“ sei ein unabhängig entwickeltes Werk, dessen Entwicklung sie, die Beklagte, vor über 15 Jahren begonnen und für die sie erhebliche Investitionen getätigt habe. Das Programm „vmkernel“ als solches sei von ihr, der Beklagten, (unbestritten) zeitlich entwickelt worden, bevor der Kläger sein angebliches Softwarewerk geschaffen habe. Dass „vmkernel“ nicht allein lauffähig sei, sondern zusätzliche Softwarebestandteile benötige, und dass diese aus dem Linux entnommen worden seien, hat die Beklagte bestritten. Im Übrigen könne kein Betriebssystem-Kernel ohne Gerätetreiber laufen oder habe irgendeinen praktischen Nutzen; aus der Tatsache, dass jeder Kernel also Gerätetreiber benötige, könne nicht gefolgert werden, dass es sich dann automatisch um ein abgeleitetes Werk i.S. der GPL handele.

„Vmklinux“ sei eine eigenständige, ebenfalls von ihr, der Beklagten, entwickelte Komponente; sie ermögliche die Kommunikation zwischen „vmkernel“ und Linux-kompatiblen Gerätetreibern, also dass dritte Hardwarehersteller die von ihnen für den Linux-Kernel entwickelten Gerätetreiber nun mit dem „vmkernel“ weiterverwenden könnten. Wie auch andere (Linux-kompatible und andere) Gerätetreiber, die mit dem „vmkernel“ kommunizierten, sei auch „vmklinux“ ein vom „vmkernel“ separates und eigenständiges Modul; es sei von ihr, der Beklagten, gezielt als Gerätetreiber-Interoperabilitätsmodul entwickelt worden. Dass „vmklinux“ nicht ohne „vmkernel“ lauffähig sei, sei unerheblich und irreführend. Ob eine Komponente selbstständig lauffähig sei, sei nicht entscheidend; so seien zum Beispiel Anwendungsprogramme auf Betriebssysteme angewiesen. Wenn der Kläger geltend mache, es gebe eine Verkehrsauffassung dahin, dass Kernel-Module als Teil des Kernel anzusehen seien, wenn sie nicht auch in unveränderter Form mit anderen unixartigen Betriebssystemen lauffähig seien, so sei dies eine nicht bindende nachträgliche Interpretation der GPL; ob sie auf den Linux-Kernel und Linux-Kernelmodule zutreffe, sei unerheblich, jedenfalls gelte sie nicht für „vmkernel“. Im Übrigen bildeten auch Linux-Kernelmodule kein einheitliches Werk mit dem Linux-Kernel.

Somit seien „vmkernel“ einerseits und „vmklinux“ andererseits kein einheitliches Programm. Vielmehr existierten beide (insofern unstreitig) als zwei getrennte Binärdateien. „Vmkernel“ sei die Kernkomponente von ESXi, „vmklinux“ dagegen ein wesentlich kleineres, getrenntes Modul, welches konzipiert sei, um Geräteherstellern die Wiederverwendung ihrer Linux-kompatiblen Gerätetreiber mit ESXi zu ermöglichen. Zwar kommuniziere „vmkernel“ mit dem Modul „vmklinux“. „Vmkernel“ weise jedoch eine vom Linux-Kernel grundverschiedene Architektur auf, da Gerätetreiber nicht (wie beim Linux-Kernel) in den Kernel integriert seien, sondern über eine stabile und dokumentierte Schnittstelle, die „VMK API“ angesprochen werden müssten. Der Umstand allein, dass „vmkernel“ mit dem selbstständigen „vmklinux“ kommuniziere und dieses Modul Linux-Code enthalte, führe nicht dazu, auch „vmkernel“ als aus Linux abgeleitet ansehen zu müssen. Die Kommunikation zwischen „vmkernel“ und „vmklinux“ erfolge nicht über instabile interne Kernel-Schnittstellen, sondern über die Schnittstelle „VMK API“, bei der es sich (anders, als vom Kläger behauptet) um eine stabile und dokumentierte Schnittstelle handele. „VMK API“ sei eine Schnittstelle, die von vielen Komponenten und Gerätetreibern genutzt werde; sie sei stabil und grundsätzlich rückwärtskompatibel; derzeit seien von 21 Unternehmen insgesamt ca. 122 Gerätetreiber und andere Module entwickelt worden, welche alle über „VMK API“ mit dem „vmkernel“ kommunizierten. So könne „vmkernel“ über „VMK API“ native Treiber ansprechen, ohne dass die Kommunikation über „vmklinux“ laufe (z.B. Hewlett Packard Drucker); „vmkernel“ sei insofern nicht von „vmklinux“ abhängig. „VMK API“ sei eine echte Schnittstelle, weil sie nicht nur für die Kommunikation zwischen „vmklinux“ und „vmkernel“, sondern auch von hunderten anderer Module verwendet werde, die von dritten Parteien als auch von der Beklagten entwickelt worden seien; zudem weise „VMK API“ die typischen Merkmale einer Software-Schnittstelle auf. Die Gerätetreiber, die mit „vmkernel“ kommunizierten, seien separate Bestandteile. „VMK API“ sei von der Beklagten schon in 2004 entwickelt und seit 2006 vertrieben worden, während die Version des Produkts der Beklagten, die nach Ansicht des Klägers das angebliche „SCSI-Subsystem“ enthalte, erst seit Mai 2009 vertrieben werde, ferner diejenige Version, die angeblich den „Radix-Tree“-Code enthalten solle, erst seit 2013. „VMK API“ sorge somit für eine klare Trennlinie zwischen der proprietären Software der „vmkernel“ und dem Modul „vmklinux“. Bei einer Verbindung über eine solche Schnittstelle sei gerade von getrennten Programmen und damit unabhängigen Werken auszugehen. Wollte man dies anders sehen, so würde dies zu der absurden Situation führen, dass alle Inhaber dritter Module, die mit „vmkernel“ über die Schnittstelle kommunizierten, ebenfalls in der Lage wären, Urheberrechte an „vmkernel“ geltend zu machen.

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.

Der weitere Umstand, dass „vmklinux“ im sog. Kernel-Space ausgeführt werde, führe nicht dazu, „vmklinux“ und „vmkernel“ als einheitliche Software ansehen zu müssen, denn andere Kernel-Erweiterungen und Gerätetreiber würden ebenfalls an dieser Stelle ausgeführt. Es gebe auch keine entsprechende Verkehrsauffassung. Ob zwei Softwarekomponenten in demselben Speicherraum oder in verschiedenen Speicherräumen ausgeführt würden, sei eine technische Gegebenheit, die ohne Bedeutung für die urheberrechtliche Beurteilung sei.

Die Beklagte hat ferner u.a. Verwirkung eingewandt. Der Kläger habe trotz anzunehmender Tatsachenkenntnis mit der Klageerhebung mehrere Jahre zugewartet.

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.

Der Kläger trägt vor, dass die Klageabweisung trotz der scheinbar ausführlichen Begründung nur auf einem kurzen Absatz beruhe, wonach der Vortrag zur urheberrechtlichen Schutzfähigkeit des von ihm, dem Kläger, stammenden Linux-Codes nicht ausreichend sei, weil er nicht vorgetragen habe, dass dieser „ausreichende Komplexität aufweisen soll“, und der angebotene Sachverständigenbeweis „auf Ausforschung gerichtet“ sei. Das Landgericht habe die Beweislast für die Schutzfähigkeit der von der Beklagten übernommenen Software fehlerhaft ihm, dem Kläger, aufgebürdet und seine Beweisangebote, insbesondere ein Sachverständigengutachten über die Individualität der von ihm programmierten und von der Beklagten übernommenen Software, nicht oder fehlerhaft gewürdigt. Das Landgericht habe seine materielle Prozessleitungspflicht verletzt, da er, der Kläger, nicht darauf hingewiesen worden sei, welche Anforderungen das Gericht an den Nachweis der Rechtsinhaberschaft an der übernommenen Software und an die Schutzfähigkeit des programmierten Codes stelle.

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.

Das Landgericht Hamburg habe sich mit der zentralen Rechtsfrage nicht auseinandergesetzt. Der Klage hätte stattgegeben werden müssen.

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.

Unabhängig von der Frage, ob das von der Beklagten behauptete Ergebnis, wonach 0,07 % des Codes vom Kläger stammten, zutreffend sei, habe eine rein quantitative Analyse keine Relevanz für die urheberrechtliche Schutzfähigkeit des übernommenen Programmcodes. Eine urheberrechtlich schutzwürdige Leistung könne auch gerade darin bestehen, den Programmcode kurz zu halten, wenn damit der gewünschte technische Effekt erzielt werde. Die Ausführungen der Beklagten zu dem Beweisangebot in Anlage K 59 seien unsubstantiiert und reine Spekulation. Der Kläger ist der Auffassung, dass die Übernahmen signifikant und damit urheberrechtlich relevant seien.

Die Linux Foundation habe nach der mündlichen Verhandlung in der ersten Instanz dieses Verfahrens ein Software-Tool mit dem Namen „Cregit“ veröffentlicht, das die Änderungsschritte im Linux-Kernel seit der Verwendung der Versionskontrollsysteme „Bitkeeper“ und „Git“ nachvollziehbar mache. Ein Sachverständiger wäre damit in der Lage nachzuvollziehen, welche Code-Bestandteile ursprünglich von ihm, dem Kläger, stammten, wie diese in der Linux-Entwicklung über Jahre verändert worden seien und weiterhin relevant im Quellcode der Beklagten auffindbar seien.

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,

1. es bei Vermeidung eines vom Gericht für jeden Fall der Zuwiderhandlung festzusetzenden Ordnungsgeldes bis zu € 250.000,00 und für den Fall, dass dieses nicht beigetrieben werden kann, einer Ordnungshaft oder einer Ordnungshaft bis zu sechs Monaten, diese zu vollziehen an ihrem ständigen Vertreter, zu unterlassen,
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;

2. an den Kläger € 4.046,00 nebst Zinsen hieraus in Höhe von fünf Prozentpunkten über dem jeweiligen Basiszinssatz seit Rechtshängigkeit zu zahlen.

Die Beklagte beantragt,
die Berufung zurückzuweisen

Die Beklagte trägt unter Bezugnahme auf ihren erstinstanzlichen Vortrag vor, dass das Landgericht zutreffend entschieden habe. Wie in der ersten Instanz sei es dem Kläger auch in seiner Berufungsbegründung nicht gelungen, auch nur im Ansatz urheberrechtlich schutzfähigen Code zu benennen, der von ihm geschrieben und von ihr, der Beklagten, übernommen worden sei. Das Landgericht habe rechtsfehlerfrei bestehende und anerkannte Grundsätze angewandt, die in sämtlichen Urheberrechtsverletzungsfällen zur Anwendung kämen. Mit dem Schriftsatz vom 29.04.2016 habe der Kläger verspätet neue Tatsachen und Beweismittel vorgebracht. Dieser Vortrag sei nicht mehr zuzulassen.

Die Beklagte macht weiterhin geltend, dass die Funktion „scsi_remove_single_device“ in „vmklinux“ aus dem Quellcode „auskommentiert“ worden sei und daher in der endgültigen computerlesbaren Version, die mit ESXi Endnutzern zur Verfügung gestellt werde, nicht enthalten sei. Der entsprechende Vortrag des Klägers, der mit Schriftsatz vom 07.11.2018 nunmehr einräumt, dass die Beklagte die Funktion „scsi_remove_single_device“ in ihrem Produkt „VMware ESXi“ nicht verwendet, sei deshalb ohne Belang. Es sei Aufgabe des Klägers, seinen Anspruch zu substantiieren, und nicht Aufgabe der Beklagten oder des Gerichts, die Grundlage für den Anspruch des Klägers aus einer Menge von nicht näher konkretisiertem Vorbringen und Beweisen herauszusuchen. Soweit sie, die Beklagte, klägerischen Vortrag mit Nichtwissen bestritten habe, sei dies zulässig gewesen. Demgegenüber sei es unzulässig, wenn der Kläger die Ergebnisse der Analyse der Beklagten mit Nichtwissen bestreite. Er sei der einzige, der den Umfang seiner schutzfähigen Beiträge zu Linux kenne.

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.

Die Beklagte weist darauf hin, dass ein Verbot nach dem klägerischen Antrag trotz der in der mündlichen Verhandlung am 28.11.2018 seitens des Klägers erfolgten Klarstellung offen ließe, was ihr, der Beklagten, genau verboten sein solle.

Wegen des weiteren Vortrags der Parteien wird auf die eingereichten Schriftsätze nebst Anlagen sowie auf das Protokoll der Senatssitzung vom 28.11.2018 Bezug genommen. Der Kläger hat am 29.01.2019 einen nicht mehr nachgelassenen Schriftsatz vom selben Tag zur Akte gereicht.

II.
Die zulässige Berufung des Klägers ist unbegründet. Zu Recht hat das Landgericht Hamburg die Klage vollen Umfangs abgewiesen.

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.

aa. Der insofern erstinstanzlich erhobene Einwand der Beklagten, der Kläger müsse bereits im Antrag bezeichnen, welche konkreten Teile aus dem Programm der Beklagten von dieser nicht genutzt werden sollten, begründet nicht die Unzulässigkeit der Klage. Jedenfalls aus der Klagebegründung muss sich allerdings hinreichend sicher ergeben, auf welche Rechte und welche Programmteile der Kläger abstellen will. Ebenso müsste ein entsprechendes gerichtliches Verbot genau bezeichnen, worauf es sich bezieht.

(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“.

Dass sich die Bearbeiterurheberstellung des Klägers auch nach seinem Vortrag nur auf einen Teil des Linux-Kernels beziehen kann, steht grundsätzlich der Annahme von eigenen jeweiligen Bearbeiterurheberrechten für solche Teile nicht entgegen. Schutzfähig können auch Teile von Computerprogrammen sein, wenn diese ihrerseits die Voraussetzungen für einen urheberrechtlichen Schutz erfüllen, was dann der Fall sein kann, wenn sie jedenfalls für den Programmablauf von nicht nur untergeordneter Bedeutung sind und eine eigene Befehlsstruktur haben, die innerhalb eines vorhandenen Gestaltungsspielraumes Ausdruck individuellen Schaffens ist (Hanseatisches Oberlandesgericht Hamburg, Urteil vom 11.01.2001, Az. 3 U 120/00, Rn. 37, juris). Damit können sich auch Bearbeiterurheberrechte auf Teile von Software beziehen, wenn die Umarbeitungsleistung des Programmierers ihrerseits die vorgenannten Anforderungen erfüllt.

(2) Unter der auch bereits vom Landgericht Hamburg in der angefochtenen Entscheidung zunächst unterstellten Prämisse, der Kläger habe an Teilen des Linux-Kernels entsprechende Bearbeiterurheberrechte erworben, wäre die Rechtsstellung des Klägers jedoch eine begrenzte. Der Schutzgegenstand des Bearbeiterurheberrechts ist nur die Umarbeitung als solche, am Originalprogramm erwirbt der Bearbeiter keinerlei Rechte (Loewenheim/Spindler in Schicker/Loewenheim, Urheberrecht, 5. Aufl., § 69c Rn. 20; Czychowski in Fromm/Nordemann, Urheberrecht, 12. Aufl., § 69c Rn. 23). Ein Bearbeiterurheberrecht entsteht nur an der Bearbeitung selbst, d.h. an dem eigentlichen Beitrag des Bearbeiters, und erfasst nicht das gesamte bearbeitete Werk (Axel Nordemann in Fromm/Nordemann, UrhG, 12. Aufl., § 3 UrhG Rn. 34; Koch CR 2000, 273, 277). Davon geht letztlich auch der Kläger aus, der bereits in einem von ihm zitierten Forumsbeitrag aus 2006 (Anlage K 19) davon spricht, er habe leider keine ausreichenden Urheberrechte an der damaligen Linux-Version, um (schon damals) gegen die Beklagte vorgehen zu können.

(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).

(4) Der weitere Umstand, dass der materiell-rechtlich überhaupt in Betracht kommende Unterlassungsanspruch des Klägers ebenfalls nur ein begrenzter sein kann, steht der ausreichenden Bestimmtheit des Unterlassungstenors, wie bereits vom Landgericht Hamburg ausgeführt, nicht entgegen. Zwar ist denkbar, dass nach dem Erlass eines Verbots die Beklagte ihr Programm ändern und sodann geltend machen könnte, die neue Programmversion falle nicht mehr unter das titulierte Verbot. Dies ist jedoch keine Frage der Bestimmtheit des Verbotstenors, sondern eine Frage der Reichweite nach der Kerntheorie. Diese besagt, dass von dem titulierten Verbot auch solche Verletzungshandlungen erfasst werden, die das charakteristisch rechtsverletzende Moment derjenigen Verletzungshandlung aufweisen, die im Erkenntnisverfahren vor dem Erlass des Verbots geprüft worden ist und Grundlage des Erlasses war. Welches das insofern charakteristische Moment ist, kann und muss gegebenenfalls durch Auslegung ermittelt werden; hierzu kann und muss gegebenenfalls auf die Ausführungen in den Entscheidungsgründen zurückgegriffen werden. Dementsprechend muss sich aus den Gründen der Entscheidung zweifelsfrei ergeben, worauf das ausgesprochene Verbot gründet.

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.

c. Soweit der Verbotsausspruch an die Lizenzbedingungen der GNU General Public License, Version 2 (GPL-2.0), anknüpft, handelt es sich der Sache nach gegenüber dem vollständigen Verbot der öffentlichen Zugänglichmachung um ein sog. Minus. Der Kläger will sich insoweit an die GPL-2.0 halten und Nutzungsrechte unter deren Bedingungen einräumen. Insoweit ist die Bestimmtheit des Klageantrags zu 1. nicht beeinträchtigt. Ob ein solcher Unterlassungsanspruch besteht, stellt sich als Frage der Begründetheit des Antrags dar.

2. In der Sache hat das Landgericht Hamburg indes zutreffend entschieden. Es ergibt sich nicht, dass dem Kläger die geltend gemachten Ansprüche zustehen.

a. Dem Kläger steht der mit dem Klageantrag zu 1. geltend gemachte Unterlassungsanspruch gemäß § 97 Abs. 1 i.V.m. § 69c Nr. 2 und Nr. 4 UrhG nicht zu.

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.

(1) Gemäß § 69a Abs. 3 UrhG werden Computerprogramme geschützt, wenn sie individuelle Werke in dem Sinne darstellen, dass sie das Ergebnis der eigenen geistigen Schöpfung ihres Urhebers sind. Gemäß § 69a Abs. 4 UrhG finden auf Computerprogramme die für Sprachwerke geltenden Bestimmungen Anwendung, soweit in diesem Abschnitt nichts anderes bestimmt ist.

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).

(2) Für die Annahme eines vom Kläger tatsächlich erworbenen Bearbeiterurheberrechts wäre es danach, wie bereits vom Landgericht in der angegriffenen Entscheidung ausgeführt, erforderlich, dass der Kläger hinreichend substantiiert darlegt und gegebenenfalls beweist,
-welche Teile aus dem Linux-Programm von ihm in welcher Weise umgearbeitet worden sind,
inwiefern diese Umarbeitungen die Anforderungen an ein Bearbeiterurheberrecht nach § 69c Nr. 2 S. 2 i.V.m. § 3 UrhG erfüllen und
-dass gerade die für ihn schutzbegründenden umgearbeiteten Programmteile ihrerseits von der Beklagten (gegebenenfalls weiter umgearbeitet) übernommen und genutzt worden sind.
Nur wenn sich eine solche Übernahme und Nutzung von für den Kläger geschützten Code-Teilen feststellen ließe, wäre auf der Grundlage des Vortrags der Parteien weiter zu prüfen, ob „vmklinux“ und „vmkernel“ als ein einheitliches Werk angesehen werden können. Falls „vmklinux“ nämlich als ein von „vmkernel“ getrennt zu betrachtendes Werk sollte angesehen werden müssen, so bestünde zwischen den Parteien Einigkeit darüber, dass die Beklagte zur Einhaltung der Anforderungen der GPL-2.0 nur zur Offenlegung und Lizensierung des „vmklinux“-Codes verpflichtet war und diese Bedingungen eingehalten hat. Wenn „vmklinux“ und „vmkernel“ als ein einheitliches Werk angesehen werden könnten, würde sich des Weiteren die Frage stellen, welche Bedeutung die gegebenenfalls in „vmklinux“ übernommenen Code-Teile des Klägers für die damit anzunehmende Einheit „vmkernel+vmklinux“ haben und ob diese Übernahme sich dann noch als Umarbeitung bzw. Bearbeitung i.S.v. § 69 Nr. 2 i.V.m. § 23 UrhG darstellt oder bereits als freie Benutzung i.S.v. § 24 UrhG.

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).

Entgegen der Meinung des Klägers ist auch das Bestreiten der Rechtsinhaberschaft des Klägers und der Schutzfähigkeit von ihm übernommener Programmierungen seitens der Beklagten mit Nichtwissen nicht unzulässig. Soweit die Beklagte hier Vortrag des Klägers konkret mit Nichtwissen bestritten hat, geht es jeweils um Tatsachen, die sie nicht kennt und auch nicht kennen muss. Die Beklagte kann keine Kenntnis davon haben, welche etwaigen Beiträge der Kläger tatsächlich als urheberrechtsfähige Beiträge und damit als Grundlage für seine geltend gemachten Ansprüche ansieht, da es sich dabei weder um eigene Handlungen der Beklagten noch um Tatsachen handelt, die Gegenstand ihrer eigenen Wahrnehmung gewesen sind (§ 138 Abs. 4 ZPO). Der genaue Umfang der klägerischen Umarbeitungen und die daraus folgende urheberrechtliche Schutzfähigkeit seiner Bearbeitungen sind ihr vielmehr nachvollziehbar unbekannt. Insoweit geht es auch nicht darum, einer Informationspflicht über Tatsachen im eigenen Geschäfts- und Wahrnehmungsbereich zu genügen. In dem vom Landgericht bezeichneten Umfang hat der Kläger zunächst einmal den Sachverhalt darzulegen, bevor von der Beklagten gegebenenfalls eine Überprüfung vorzunehmen und weitergehende Einlassung abzugeben ist.

Ebenso ist nicht zu erkennen, dass das Landgericht hier gegen seine Hinweispflichten verstoßen hätte. Die Probleme lagen von Anfang an klar zutage. Auch die Beklagte hat deutlich gemacht, wo die entscheidenden Punkte liegen. Sodann hat das Landgericht im Termin einen Schriftsatz nachgelassen und diesen, nämlich den Schriftsatz vom 29.04.2016, bei seiner Entscheidung auch berücksichtigt. Hiergegen ist nichts zu erinnern.

(4) Wie vom Landgericht in der angefochtenen Entscheidung zutreffend ausgeführt worden ist, lässt sich bereits nicht feststellen, dass für den Kläger als Bearbeiterurheber geschützter Code in das Produkt der Beklagten übernommen worden ist. Dies gilt auch unter Berücksichtigung des nachgelassenen Schriftsatzes des Klägers vom 29.04.2016, mit dem er (unter Fristverlängerung) nochmals Gelegenheit hatte, zu den vom Landgericht bereits in der dortigen mündlichen Verhandlung geäußerten diesbezüglichen Bedenken vorzutragen. Das Landgericht hat diesen Vortrag noch zugelassen. Hieran ist der Senat nach §§ 529 Abs. 1, 531 ZPO gebunden (vgl. Zöller/Heßler, ZPO, 32. Aufl., § 531 Rn. 7, m.w.N.).

(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.

Der Hinweis des Klägers gemäß Schriftsatz vom 25.09.2015, in einem sog. Git-Repository sei für jedermann öffentlich einsehbar, welche Teile des Linux-Codes von ihm, dem Kläger, stammten, und der weitere Vortrag bereits in der Klageschrift, in den Repositories des Mainline-Kernels (d.h. der offiziellen Kernelversion) könne jeder Entwicklungsbeitrag des Klägers detailliert nachvollzogen und belegt werden, sind ersichtlich unzureichend. Ein solcher pauschaler Verweis auf eine Ermittlungsmöglichkeit von Tatsachenvortrag im Internet ist kein zulässiger prozessualer Vortrag.

Hiergegen wendet sich auch der Kläger mit seiner Berufung so nicht. Er macht nunmehr geltend, der Hinweis auf das Git-Repository habe zum Nachweis der Nachvollziehbarkeit jeder einzelnen Code-Änderung im Linux-Kernel und der Informationsmöglichkeit der Beklagten gedient. In der Sache ändert dies allerdings nichts daran, dass insoweit eine urheberrechtlich geschützte Position des Klägers nicht hinreichend dargetan ist.

(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.

An dieser Bewertung ändern auch die Ausführungen in der Berufungsbegründung nichts. Weder hat die Beklagte die Verpflichtung, unzureichenden prozessualen Vortrag des Klägers selbstständig für sich zu ergänzen, noch genügt es, wenn ein Sachverständiger ohne hinreichenden Vortrag durch eigene Ermittlungen zu einem bestimmten Ergebnis kommen kann. Bereits der erst noch zu beweisende Vortrag muss nachvollziehbar sein.

Nicht ausreichend ist in diesem Zusammenhang auch die Vorlage der Datei „linux.tgz“ auf der CD-Rom Anlage K 12 mit einem „Archiv“; denn auch hier müssten Gericht und Gegner wiederum selbst ermitteln, welche Anteile vom Kläger stammen sollen. Soweit der Kläger in diesem Zusammenhang mit Schriftsatz vom 25.09.2015 geltend macht, die Linux-Kernel-Version 2.6.18 sei diejenige, die „der von der Beklagten verwendeten Version am ähnlichsten“ sei, so ist auch dies kein schlüssiger Vortrag zu einer Übernahme von Code-Bestandteilen des Klägers, denn weder wird individualisiert, welche Bestandteile es sein sollen, noch wird dargelegt, wo im Code der Beklagten solche Teile auftauchen; als von der Beklagten „verwendete“ Version ist hier ersichtlich eine Linux-Version gemeint, nicht eine Version von „vmklinux“. Der Vortrag wird auch nicht im Schriftsatz vom 29.04.2016, wo sich der Kläger auf die Ausführungen in der Klageschrift bezieht, konkretisiert.

Wenn der Kläger zusammenfassend geltend macht, er habe mit der Anlage K 12 den von ihm zu Linux beigetragenen Code vorgelegt, der sich in „vmklinux“ wiederfinde, so genügt es, wie vom Landgericht Hamburg zutreffend ausgeführt, nicht zur Darlegung seines Bearbeiter-Urheberrechts an Linux, den Code dieses Programms insgesamt vorzulegen und lediglich geltend zu machen, darin seien die Bearbeitungsanteile mit enthalten, die von ihm, dem Kläger, stammten; dies ist kein für Gericht und Gegner nachvollziehbarer Vortrag, an welchen Bestandteilen gerade Bearbeiter-Rechte des Klägers geltend gemacht werden sollen.

(c) Soweit der Kläger geltend macht, die mit CD-Rom Anlage K 12 vorgelegten „.blame“-Dateien (bzw. die dazu inhaltsgleichen PDFs) zeigten, welcher Code von ihm, dem Kläger, stamme und welche Änderungen die Beklagte in „vmklinux“ vorgenommen habe, so ist das so weder nachvollziehbar noch im Ergebnis zutreffend, wie sich bereits aus der vorgerichtlichen klägerischen E-Mail Anlage K 10 selbst erschließt.

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.“

Diese Ausführungen sind insofern nachvollziehbar, als sich tatsächlich in den html-Dateien der Anlage K 12 schwarz, grün und rot markierte Code-Zeilen finden. Als übernommen macht die Klägerin schwarzen und (mit Veränderungen) grünen Code geltend. Die html-Dateien weisen aber nicht aus, von welchem Linux-Bearbeiter der angezeigte schwarze bzw. grün markierte Code in Linux stammt. Insbesondere wird nicht angezeigt, welche Teile des in den hmtl-Dateien schwarz und grün markierten Codes vom Kläger stammen sollen. Dies müsste sich der Leser also durch einen Vergleich der schwarzen und grünen Teile der html-Dateien mit den PDFs der „.blame-Dateien“ erst selbst erschließen. Jedenfalls dies ist, wie bereits das Landgericht in der angefochtenen Entscheidung ausgeführt hat, kein prozessual nachvollziehbarer Vortrag mehr, zumal sich aus dieser Art der Darstellung nicht einmal eine schlüssige Behauptung ergibt, es seien überhaupt bestimmte Code-Zeilen des Klägers in „vmklinux“ enthalten.

(d) Soweit der Kläger im Schriftsatz vom 25.09.2015 weiter behauptet, es sei ein vollständiger, beispielhaft aus der Anlage K 15 nachvollziehbarer Sourcecode-Vergleich durchgeführt worden, so kann das Gericht lediglich die mit K 15 vorgelegten Beispiele beurteilen; darüber hinaus bleibt der Vortrag zu Übernahmen schon deshalb unsubstantiiert, weil der Kläger das Ergebnis des angeblichen Vergleichs nicht vorlegt und dazu nichts vorträgt.

Hinsichtlich der mit der Anlage K 15 „beispielhaft“ geltend gemachten Code-Anteile hat der Kläger kein verletztes Bearbeiterurheberrecht zu belegen vermocht. Die Beklagte hat überzeugend eingewandt, aus der Anlage K 15 ließen sich letztlich nur acht spezifische und abtrennbare Funktionen des SCSI-Subsystems erkennen; dem ist der Kläger nicht entgegengetreten. Die Beklagte hat weiter eingewandt, eine dieser acht Funktionen sei innerhalb von „vmklinux“ „auskommentiert“ worden, d.h. sie werde in „vmklinux“ nicht verwendet; und bei den verbleibenden sieben Funktionen sei über die Hälfte der Codezeilen entweder von einem anderen Autor geschrieben (ohne jeglichen Beitrag des Klägers) oder vom Kläger höchstens einfach überarbeitet oder verschoben worden. Hinzu kommt, dass der Kläger in der Anlage K 15 auch nicht mit der von ihm ansonsten als Klagemuster angeführten Version 2.6.18 des Linux-Kernels argumentiert, sondern mit anderen Versionen, grundsätzlich der Version 2.6.0-test10 (Anlage K 15 Ziff. 1).

Wie vom Landgericht Hamburg in der angefochtenen Entscheidung ausgeführt, hätte der Kläger seine Anteile an den mit der Anlage K 15 geltend gemachten Funktionen genauer spezifizieren und für seine Bearbeiterurheberschaft Beweis antreten müssen. Das hat der Kläger, wie vom Landgericht zutreffend ausgeführt, nicht in ausreichender Weise getan:

-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.

(e) Vergleichsdateien mit angeblich übernommenen Funktionen für „SCSI Device Hotplug“ und „Radix-Trees“ hat der Kläger nunmehr mit der Berufungsbegründung vorgelegt (Anlage K 59).

Mit der Anlage K 59 legt der Kläger den Quellcodevergleich der angeblich übernommenen Funktionen für „SCSI Device Hotplug“ und die „Radix-Trees“ vor. Jedoch legt der Kläger schon nicht dar, warum dieser Vortrag nebst Beweisantrag in der Berufungsinstanz nach § 531 Abs. 2 ZPO noch zulässig sein sollte. Die Anlage K 59 enthält Dateien, die als Teil der Anlage K 15 benannt worden sind, in dieser tatsächlich jedoch noch nicht enthalten waren. Die Anlage enthält zudem, wie die Beklagte zu Recht geltend macht, vor allem in Bezug auf die Dateien im „Radix-Tree“-Ordner völlig neue Nachweise. Die Vorschrift des § 531 Abs. 2 ZPO ist danach nicht gewahrt worden, der Vortrag mithin nicht zuzulassen.

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.

(f) Soweit der Kläger in der Klage geltend macht, in zwei Dateien aus „vmklinux“, zu denen die Beklagte den Quellcode offengelegt habe, fänden sich sog. Header mit Hinweisen auf Urheberrechte u.a. des Klägers, so ist diesem Vortrag allein nicht zu entnehmen, dass (bearbeiter-)urheberrechtlich gesondert schutzfähige Teile aus dem Code des Klägers übernommen worden sein sollen. Dies kann schon allein deswegen nicht angenommen werden, weil die Beklagte ohne sachliche Einordnung verschiedene Angaben zu Urhebern chronologisch aufgelistet vermerkt hat. Der konkrete Beitrag des Klägers erschließt sich danach nicht. Es genügt nicht, dass die Beklagte den Kläger in dieser Art und Weise als einen möglichen Bearbeiter von Linux genannt hat, sondern muss spezifiziert vom Kläger dargelegt werden.

(5) Die Ausführungen des Klägers speziell zu seiner behaupteten Mitarbeit am sog. SCSI-Subsystem erlauben, wie vom Landgericht Hamburg in der angegriffenen Entscheidung ausgeführt, ebenfalls nicht die Feststellung einer Verletzung von Bearbeiterurheberrechten des Klägers.

(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.

Soweit der Kläger im Schriftsatz vom 25.09.2015 unter Ziffer II.4.a)-c) Ausführungen dazu macht, dass einzelne dort erörterte weitere Code-Zeilen zwar von anderen Bearbeitern stammten, jedoch an seiner urheberrechtlich geschützten Leistung nichts änderten, bleibt der Vortrag zur eigenen Leistung des Klägers nicht nachvollziehbar. Im genannten Schriftsatz unter a) macht er geltend, den Beitrag (Patch) „fixes and cleanups for the new command allocation code“ (= Patch Nr. 10 auf S. 9 des Schriftsatzes) geschaffen zu haben, ohne diesen Beitrag näher dazulegen. Im Schriftsatz unter b) räumt der Kläger ein, an der betreffenden Stelle lediglich fremden Code bearbeitet zu haben, um eine andere Schnittstelle benutzen zu können, was urheberrechtlich relevant sei; weder wird der von ihm bearbeitete Code vorgelegt, noch wird erläutert, inwiefern die Anpassung an eine Schnittstelle über eine Durchschnittsprogrammierleistung hinaus gehe. Unter c) macht der Kläger geltend, den Beitrag (Patch) „scsi_device refcounting and list lockdowndes“ (= Patch Nr. 19 auf S. 9 des Schriftsatzes) geschaffen zu haben; auch zu dessen urheberrechtlicher Schutzfähigkeit finden sich keine Erläuterungen. Nur vorsorglich ist mit dem Landgericht Hamburg zudem darauf hinzuweisen, dass der Kläger weder an dieser Stelle noch später ausdrücklich geltend macht, dass gerade die hier erörterten Code-Teile auch in „vmklinux“ der Beklagten enthalten sind.

(d) Ebenso wenig vermag der Vortrag des Klägers im Schriftsatz vom 29.04.2016 zu sog. Midlayer-Code innerhalb der SCSI-Funktionalität Rechte seiner Person darzulegen. Denn der Kläger behauptet nicht, dass dieser sog. Midlayer-Code von ihm stamme. Entsprechendes gilt zu seinen dortigen Ausführungen zur SCSI-Funktionalität in an „vmklinux“ angebundenen Hardwaretreibern. Hierzu stellt der Kläger mit seiner Berufungsbegründung jetzt auch klar, dass der Vortrag zum „Midlayer-Code“ nicht als Vortrag zur Rechtsinhaberschaft habe gewertet werden sollen.

(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.

Nicht ausreichend ist jedoch, wie ebenfalls bereits vom Landgericht Hamburg in der angefochtenen Entscheidung ausgeführt, der Vortrag des Klägers zur urheberrechtlichen Schutzfähigkeit des als von ihm stammend behaupteten Linux-SCSI-Codes. Der Kläger trägt bereits zur Funktion weder als solcher noch innerhalb des SCSI-Subsystems oder gar innerhalb von Linux vor und ebenso wenig zu der Funktion innerhalb von „vmklinux“. Inwiefern sich die konkrete Programmierung oder Überarbeitung von einer rein handwerklichen Programmierung abheben oder auch nur für sich genommen eine ausreichende Komplexität aufweisen soll, wird vom Kläger nicht vorgetragen und ist auch sonst nicht erkennbar. Der von ihm angebotene Sachverständigenbeweis ist mangels ausreichenden Tatsachenvortrags unzulässig und abzulehnen. Ein Antrag, der, wie hier, darauf gerichtet ist, etwaige Beiträge des Klägers durch einen Sachverständigen erst identifizieren und erstmals bewerten zu lassen, ist zurückzuweisen.

Letztlich können diese Gesichtspunkte, die das Landgericht maßgeblich herausgearbeitet hat, allerdings auch dahinstehen. Denn entscheidend ist, dass die Funktion „scsi_remove_single_device“ im „vmklinux“-Code, wie ausgeführt, „auskommentiert“ worden ist und damit von der Beklagten gar nicht verwendet worden ist. Insoweit geht auch der Vortrag des Klägers in der Berufungsbegründung, in dem er ausdrücklich auf seine Darlegungen zur Funktion „scsi_remove_single_device“ Bezug nimmt, an der Sache vorbei. Eine von der Beklagten gar nicht genutzte Funktion vermag keine Rechtsverletzung zu belegen.

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.“

Diese Differenzierung lässt sich, wie vom Landgericht Hamburg in der angefochtenen Entscheidung ausgeführt, insofern auf die Frage des Schutzes von Datei-Baum-Strukturen übertragen, als diese Strukturen als solche ebenfalls nur Funktionen des Programmes sind, jedoch keine Ausdrucksform des Programmes. Insofern genügt der bloße Verweis des Klägers auf Baumstrukturen nicht, um ein eigenes Bearbeiterurheberrecht oder dessen Verletzung zu begründen.

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.

(b) Zu einer Übernahme etwaigen Codes im Zusammenhang mit „Radix-Trees“ ist vom Kläger auch im Übrigen nicht schlüssig vorgetragen worden.

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.

(c) Das Angebot des Klägers, andere Kernel-Entwickler zu seinen Beiträgen zu den „Radix-Trees“ zu hören, stellt keinen nachvollziehbaren Vortrag zu diesen Beiträgen und zur Frage der Schutzfähigkeit der „Radix-Trees“ dar und ist gleichfalls auf eine unzulässige Beweisaufnahme gerichtet.

(7) Der weitere Vortrag des Klägers in der Berufungsbegründung, die in den Anlagen K 26 und K 31 vorgelegten Sourcecodes der Beklagten enthielten Sourcecode des Klägers mit hinreichender Individualität, begründet gleichfalls keinen Unterlassungsanspruch.

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“.

Hierzu ist festzuhalten, dass die Versionen der beiden Funktionen, die von der Beklagten verwendet werden, sich, wie von der Beklagten geltend gemacht, stark von denen unterscheiden, die vom Kläger zur Begründung seines Anspruchs angeführt werden. Die Beklagte behauptet hierzu, dass der tatsächliche Code in „vmklinux“, der vom Kläger für die Funktionen „scsi_add_device“ und „scsi_remove_device“ benannt wird, keinen klägerischen Code enthalte. Dies ist mit dem klägerischen Vortrag nicht zu widerlegen. Die Anlage K 24 zeigt nur die vom Kläger behaupteten Beiträge zu Linux, nicht die vom Kläger behaupteten Beiträge zu Linux, die in „vmklinux“ verwendet worden sein sollen. Die Komplexität der übernommenen klägerischen Programmierung ergibt sich ebenso wenig.

Weiter macht der Kläger geltend, in der als Anlage K 30 vorgelegten Datei würden zwei Änderungen des Linux-Kernel-Codes beschrieben. Zum einen sei neuer Code hinzugefügt worden, mit dem Datenstrukturen effizient gefunden werden könnten („Radix-Trees“), zum anderen sei die Speicherverwaltung so umgeschrieben worden, dass sie mit Hilfe dieser „Radix-Trees“ auf Computern mit vielen Prozessoren und viel Speicher um Größenordnungen effizienter funktioniere als vorher. Die Beklagte habe die Dateien „radix-tree.c“ und „radix-tree.h“ aus einer neueren Linux-Version übernommen, aber einen Großteil der jetzt „radix_tree_insert“ genannten Funktion von der ursprünglich als „radix_tree_reserve“ benannten klägerischen Funktion übernommen.

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.

(11) Bis zum Schluss vermochte der Kläger sein prozessuales Problem nicht zu lösen: Noch im Schriftsatz vom 07.11.2018 trägt er (weiterhin) vor, dass ein Sachverständiger in der Lage wäre nachzuvollziehen, welche Code-Bestandteile ursprünglich von ihm, dem Kläger, stammten, wie diese in der Linux-Entwicklung über Jahre verändert worden und weiterhin relevant in dem Quellcode der Beklagten auffindbar seien. Wie vorstehend ausgeführt, muss zunächst einmal jedoch substantiierter Vortrag des Klägers erfolgen, bevor ein gerichtlicher Sachverständiger tatsächlich streitigen Vortrag auf seine Richtigkeit hin überprüft. Auch § 144 Abs. 1 ZPO rechtfertigt hier nicht die Beauftragung eines Sachverständigen. Das gerichtliche Sachverständigengutachten ist nicht dafür da, den spezifizierten Tatsachenvortrag erstmals zu liefern und damit zu ersetzen.

bb. Festzuhalten bleibt des Weiteren, dass die Rechtsposition des Klägers, wie vorstehend ausgeführt, in jedem Fall nur diejenige eines Bearbeiterurhebers wäre und dass die Beklagte in erheblicher Weise geltend gemacht hat, dass der mengenmäßige Umfang des allenfalls übernommenen Codes des Klägers in Relation zum Gesamtumfang „vmkernel+vmklinux“ äußerst gering ist, ohne dass sich dem klägerischen Vortrag entnehmen lässt, dass die von der Beklagten geltend gemachten Größenordnungen unzutreffend wären. Angesichts des unter Beachtung des Vorstehenden allenfalls marginalen Umfangs durch die Beklagte vom Kläger übernommener Programmierungen wäre insoweit eine freie Benutzung im Sinne des § 24 Abs. 1 UrhG anzunehmen.

Nach § 24 Abs. 1 UrhG darf ein selbstständiges Werk, das in freier Benutzung des Werkes eines anderen geschaffen worden ist, ohne Zustimmung des Urhebers des benutzten Werkes veröffentlicht und verwertet werden. Die schöpferische Eigentümlichkeit des benutzten Werkes muss gegenüber der Eigenart des neu geschaffenen Werkes verblassen, wobei kein zu milder Maßstab anzulegen ist (Axel Nordemann in Fromm/Nordemann, Urheberrecht, 12. Aufl., § 24 UrhG Rn. 43, m.w.N.). Von einem Verblassen ist auszugehen, wenn das fremde Werk nur noch als Anregung für das neue Werkschaffen dient oder wenn im neuen Werk das ältere nicht mehr in relevantem Umfang benutzt wird, wenn das ältere Werk in dem neuen nur noch schwach und in urheberrechtlich nicht mehr relevanter Weise durchschimmert (Axel Nordemann in Fromm/Nordemann, Urheberrecht, 12. Aufl., § 24 UrhG Rn. 43 f., m.w.N.; Czychowski in Fromm/Nordemann, Urheberrecht, 12. Aufl., § 69c UrhG Rn. 22, m.w.N.). Hierbei ist der Grad der jeweiligen Individualität ebenso zu berücksichtigen wie der Umfang der Übereinstimmungen (Axel Nordemann in Fromm/Nordemann, Urheberrecht, 12. Aufl., § 24 UrhG Rn. 46 f., m.w.N.). Je individueller das vorbestehende Werk ist, desto weniger wird es in der Regel gegenüber bloßen Hinzufügungen verblassen; bewegt sich das vorbestehende Werk jedoch ohnehin am unteren Rand individueller, gerade noch schutzfähiger Werke, ist auch umso eher von einem Verblassen auszugehen.

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.

3. In der Sache hat die Berufung des Klägers danach keinen Erfolg.

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.

5. Die Kostenentscheidung beruht auf § 97 Abs. 1 ZPO. Der Ausspruch zur vorläufigen Vollstreckbarkeit folgt aus §§ 708 Nr. 10, 711 ZPO.

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.