Source: https://www.damm-it-recht.de/lg-hamburg-zum-nachweis-der-urheberrechte-bei-open-source-software/
Timestamp: 2020-02-27 14:29:11
Document Index: 68667611

Matched Legal Cases: ['§ 69', '§ 69', '§ 23', '§ 69', '§ 3', '§ 69', '§ 3', '§ 69', '§ 23', '§ 24', '§ 10', '§ 69', 'EuG', 'EuG', 'Art. 1', 'EuG', 'Art. 4']

Zum Nachweis der Urheberrechte bei Open Source Software › IT-Recht | Dr. Ole Damm - Rechtsanwalt & Fachanwalt
Der Kläger macht im vorliegenden Rechtsstreit Rechte am sog. Kernel des Linux-Betriebssystems auch und gerade im Zusammenhang mit dem System zur Ansprache externer Geräte über sog. 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 Darstellung der Parteien im vorliegenden Rechtsstreit den Kern eines Betriebssystems, wobei dieser Kern 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 ist (Kläger, Klageschrift S. 8 und 9) bzw. der Kernel neben anderen Aufsichtsfunktionen die Aufgabe hat, die Input/Output-Anfragen anderer Softwarekomponenten und Anwendungen zu verwalten, zu überprüfen, zu organisieren und zu priorisieren (Beklagte Ss 01.07.2015 S. 6 = Bl. 68 d.A.).
– Zur Kommunikation eines Betriebssystem-Kernels mit einem an den Computer angeschlossenen externen Gerät ist ein sog. Gerätetreiber erforderlich ist. Die Beklagte hat hierzu unbestritten vorgetragen, dass grundsätzlich ein Gerätetreiber eine Software ist, die einen besonderen Typ von Geräten, welche mit dem Computer verbunden sind, 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 (Ss 01.07.2015 S. 7 = Bl. 61 d.A.).
– Das Zusammenwirken zwischen Kernel und Gerätetreibern kann durch einen unterschiedlichen Aufbau des Betriebssystems erreicht werden. Der Kläger hat dazu unbestritten ausgeführt, dass beim Aufbau eines Betriebssystems die Gerätetreiber entweder mit dem übrigen Kernel des Betriebssystems zu einer einheitlichen Binärdatei verbunden werden können oder als sog. Kernel-Module ausgelagert werden können und dann vom System dynamisch nachgeladen werden müssen (Klageschrift S. 9).
– Als Schnittstelle bezeichnet man eine Komponente, die die Kommunikation anderer Komponenten ermöglicht; im Hardware-Bereich mag das eine bestimmte Steckverbindung sein, im Softwarebereich mögen dies bestimmte Programmierungsanforderungen sein. 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, und diese Schnittstellen bleiben über längere Zeit unverändert (Klageschrift S. 17). Unter dieser Voraussetzung werden üblicherweise die Hardeware-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 (vgl. Beklagten-Ss 01.07.2015 S. 7 = Bl. 61).
– 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 ein Quellcode 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 solche 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 v.a., um welche Codeteile es sich handelt und ob diese vom Kläger stammen). Den Quellcode dieses Moduls hat die Beklagte unstreitig auf ihrer Website offen gelegt und zum Download angeboten und insofern unter der GPL-2.0 lizenziert.
– Schließlich enthält ESXi weitere Module, in denen sich 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 Website 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 K 8). Die Beklagte antwortete und gab keine Unterlassungsverpflichtungserklärung ab (Schreiben 19.09.2014, Anlage K 9). Der Kläger übersandte eine E-mail vom 14.11.2014 (K 10). Anschließende Gespräche der Parteien führten nicht zu einer Einigung.
Der Kläger macht weiter geltend, dass er mit der – nach Existenz und Wortlaut unstreitigen – vorgerichtlichen e-mail K 10 der Beklagten gegenüber Beispiele dafür genannt, welche Teile von bestimmten Sourcecode-Dateien (scsi_error.c, scsi_lib.c, scsi_proc.c scsi.c und host.c) er entwickelt habe (Ss 25.09.2015 S. 2 = Bl. 146 d.A.).
Der Kläger wirft der Beklagten vor, 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 gesteht der Beklagten zwar zu, 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 betrachten zu müssen, ergebe sich aus folgenden, vom Kläger behaupteten Eigenschaften des Programms der Beklagten:
– Die diesbezügliche Architektur von 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 (Klageschrift S. 15 = Bl. 15 d.A.).
– 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 (Klageschrift S. 15-16 = Bl. 15-16 d.A.).
– Der „vmkernel“ sei ohne die Benutzung des „vmklinux“-Moduls mit dem bearbeiteten Linux-Code nicht lauffähig (Klageschrift S. 29). 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 Softwarebestanteile fänden sich in den aus dem Kernel ausgelagerten Kernel-Modulen, so insbesondere im Modul „vmklinux“. Der „vmkernel“ sei also ohne die in die Module ausgelagerte Software nicht lauffähig (Klageschrift S. 8).
– 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 hinaus gehende Integration in den Kernel von ESXi erforderlich gewesen, nämlich eine jeweils spezielle Anpassung und Einzelabstimmung (Klageschrift S. 13). 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 (Klageschrift S. 29) oder mit einem anderen Betriebssystem ausgeführt werden (Klageschrift S. 13).
– 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 werde, 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 werde;
– Durch Analyse der vom Kläger vorgelegten Informationen habe die Beklagte in etwa 798 Zeilen Code von „vmklinux“ identifizieren können, von denen der Kläger behauptete, 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) (Ss 05.02.2016 S. 4 = BL. 193 d.A.).
– Von den 798 Code-Zeilen seien jedoch 396 Zeilen in „vmklinux“ nicht verwendet, sondern „auskommentiert“ worden (d.h. sie erscheinen nur im menschenlesbaren Quellcode) (Ss 05.02.2016 S. 6 = Bl. 46 d.A.).
– 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 (Ss 05.02.2016 S. 6 = Bl. 46 d.A.).
– 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 (Ss 05.02.2016 S. 6 = Bl. 46 d.A.).
– Es verblieben damit letztlich nur noch 149 Zeilen, die möglicherweise von Kläger stammten und zum Endbenutzer gelangten (Ss 05.02.2016 S. 6 f. = Bl. 46 f. d.A., auch zum Folgenden). Allein die drei „vmklinux“-Dateien, auf die sich der Kläger beziehe, enthielten aber bereits 6895 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 haben 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.
Dass sich die Bearbeiterurheberstellung des Klägers nur auf einen Teil des Linux-Kernels beziehen mag, steht grundsätzlich der Annahme von eigenen jeweiligen Bearbeiterurheberrechten für solche Teile nicht entgegen. „Schutzfähig können dabei 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. Januar 2001 – 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.
Unter der hier 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. So heißt es z.B. bei Schicker/Loewenheim, UrhR, 4. Aufl. 2010, § 69c Rz. 20: „Schutzgegenstand des Bearbeiterurheberrechts ist nur die Umarbeitung als solche, am Originalprogramm erwirbt der Bearbeiter keinerlei Rechte.“ Das ist – soweit ersichtlich – in Rechtsprechung und Literatur nicht umstritten. Auch der Kläger persönlich ist letztlich davon ausgegangen, wenn er in dem von ihm zitierten Forumsbeitrag aus 2006 (Anlage K 19) davon spricht, er habe leider keine ausreichenden Urheberrechte an der damaligen Linux-Version, um gegen die Beklagte vorgehen zu können.
Gleichwohl kann der Bearbeiterurheber Unterlassung der Nutzung eines solchen anderen Computerprogramms verlangen, welches die für den Bearbeiterurheber geschützten Anteile in 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 erwerblich 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 erfüllt.
Wie bereits zur Zulässigkeit ausgeführt, kommen vorliegend als Grundlage der Rechtsposition des Klägers lediglich Bearbeiterurheberrechte in Betracht, da der Kläger geltend macht, sukzessiv eigenständige Beiträge zum Linux-Kernel beigetragen zu haben. Dass auch an einer Umarbeitung von Software ein Bearbeiterurheberrecht entstehen kann, folgt – wie gesagt – aus § 69c Nr. 2 S. 2 i.V.m. § 3 UrhG. Dies ist im Ausgangspunkt zwischen den Parteien des Rechtsstreits auch rechtlich nicht strittig.
Unter der Prämisse, der Kläger habe an Teilen des Linux-Kernels entsprechende Bearbeiterurheberrechte erworben, wäre die Rechtsstellung des Klägers jedoch – wie ebenfalls ausgeführt – eine begrenzte. Im Rahmen der Begründetheitsprüfung hat das Gericht daher zu prüfen, ob der Kläger hinreichend substantiiert dargelegt und ggf. bewiesen hat,
– welche Teile aus dem Linux-Programm von ihm in welcher Weise umgearbeitet worden sein sollen,
– inwiefern diese Umarbeitungen die Anforderungen an ein Bearbeiterurheberrecht nach § 69c Nr. 2 S. 2 i.V.m. § 3 UrhG erfüllen und
– inwiefern der Kläger darlegt und ggf. beweist, dass gerade die für ihn schutzbegründenden umgearbeiteten Programmteile ihrerseits von der Beklagten (ggf. weiter umgearbeitet) übernommen worden sind.
– Können „vmklinux“ und „vmkernel“ als ein einheitliches Werk angesehen werden (und nach welchen rechtlichen Kriterien ist diese Einheitlichkeit zu bestimmen)? Falls nämlich „vmklinux“ als ein von „vmkernel“ getrennt zu betrachtendes Werk sollte angesehen werden müssen, so besteht zwischen den Parteien Einigkeit, dass die Beklagte zur Einhaltung der Anforderungen der GPL-2.0 nur zur Offenlegung des „vmklinux“-Codes verpflichtet war und diese Bedingung eingehalten hat.
– Wenn „vmklinux“ und „vmkernel“ als ein einheitliches Werk angesehen werden könnten, so wäre schließlich zu prüfen, welche Bedeutung die in „vmklinux“ übernommenen Code-Teile des Klägers für die dann anzunehmende Einheit „vmkernel+vmklinux“ haben und ob unter dieser Perspektive diese Übernahme sich 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 (und nach welchen rechtlichen Kriterien dies zu bestimmen wäre). Dabei würde insbesondere zu beachten sein, dass die Rechtsposition des Klägers 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 völlig unzutreffend wären.
Ein solcher Vergleich findet sich stattdessen in den in der e-mail K 10 ebenfalls genannten html-Dateien. Zu ihnen heißt es in K 10, diese Dateien gäben das Ergebnis eines Vergleichs der „Linux-Datei (Version 2.6.18) mit der Datei ihrer Mandantin“ wieder; gemeint sind offenbar ein Vergleich des Programmes Linux mit dem Programm der Beklagten. Weiter heißt es in 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.“ Das ist insofern nachvollziehbar, als sich tatsächlich in den html-Dateien 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 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.
– In seinem unmittelbaren schriftsätzlichen Vortrag zu K 15 (Ss 25.09.2015 S. 11 = Bl. 155 d.A.) findet sich insofern kein Beweisantritt.
– K 15 selbst ist kein Ausdruck eines Code-Abschnitts und auch keine Veröffentlichung einer Bearbeitungshistorie, sondern eine vermutlich wohl vom Kläger persönlich zusammengestellte Übersicht über die einzelnen dort geltend gemachten acht Funktionen; daher kommt der Anlage K 15 selbst keinerlei Beweiswert bzgl. 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 nicht hinreichend spezifiziert bzgl. der Fragen, wo genau die Bearbeitungshistorie der acht spezifischen Funktionen veröffentlicht sei und welche Ergebnisse dort bezüglich der konkreten Anteile des Klägers an den acht Funktionen mitgeteilt werden.
– Das gilt entsprechend aber auch für die vom Kläger mit 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.
Daher kann sich – wie bereits ausgeführt – auch insofern die Prüfung auf die Frage der Übernahmen in „vmklinux“ beschränken.
Das Verständnis des Begriffs des Computerprogramms in § 69a UrhG ist richtlinienkonform auszulegen. Der EuGH hat zur Auslegung der Computerprogramm-Richtlinie 91/250 entschieden (EuGH, Urteil vom 02. Mai 2012 – C-406/10 – = GRUR 2012, 814 – SAS – zit. nach juris-Rz. 46), 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 (zit. nach juris-Rz. 42 und 43):
„42. 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.
43. 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 im Sinne des Art. 4 Buchst. a der Richtlinie 91/250 handeln.“
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) am sinnvollsten, effektivsten, Speicherplatz sparend, am schnellsten ausführbar o.ä. anzuordnen sind, so ginge es dann doch nur um ein generelles Gestaltungsprinzip für Computerprogramme, nicht aber um ein Programm als solches. Ein bloßes Gestaltungsprinzip, welches – wie der Kläger selbst geltend macht – in unterschiedlichsten Zusammenhängen anwendbar ist, ist als solches aber nicht urheberrechtlich schutzfähig.
Soweit es dazu in der Klageschrift auf S. 15 heißt, eine von ihm durchgeführte Analyse habe ergeben, dass im Quellcode der Beklagten – so wörtlich – „die ‚Radix-Tree‘-Funktionalität verwendet“ worden sei und dafür zum Beweis angeboten wird „Im Bestreitensfall Vorlage von Quellcode-Dateien“, so ist der Vortrag zum einen nicht nachvollziehbar, dass überhaupt konkrete Codezeilen übernommen worden sein sollen („Funktionalität“), zum anderen welche Code-Zeilen dies sein sollen und schließlich ist das Beweisangebot nicht nur auf Ausforschung gerichtet, sondern auch selbst völlig unbestimmt.