Aktuelle Entwicklungen im IT-Recht

Alesch Staehelin

Inhaltsverzeichnis

I. Google LLC v. Oracle America, Inc. – wie wäre das in der Schweiz?

1. Worum ging es in dem Rechtsstreit zwischen Oracle und Google?

2. Der Supreme Court und die «Fair Use Doctrine»

3. Der 4-Faktoren-Test der Fair-Use-Doktrin

4. Supreme Court: «Fair Use» vorliegend gegeben

5. Die Kernfrage liess der Supreme Court leider offen

6. Interessanter Nebenfakt

7. Wie ist die Rechtslage in der Schweiz?

8. Die Rechtslage in Deutschland und gemäss der Rechtsprechung des EuGH

II. Judikatur: Softwareschutz & Urheberrecht

1. «Schüttgefässwaage 1 II» (BGer vom 2. Dezember 2019)

2. «Schüttgefässwaage 2 I» (HGer SG vom 24. Januar 2020)

3. «Schüttgefässwaage 2 II» (BGer vom 22. September 2020)

Kommen wir gleich zum wohl spektakulärsten und wichtigsten IT-Gerichtsfall der letzten 15 bis 20 Jahre: Darf man eigentlich Softwareschnittstellen (Application Programming Interfaces, APIs) kopieren?

Im Bereich der Softwaretechnik und -entwicklung ist es weit verbreitet, von anderen geschriebene Softwareschnittstellen zu verwenden. In der Schweiz, in Deutschland, in vielen anderen europäischen Ländern und in den USA ist – auch durch eine gefestigte Rechtsprechung – allgemein anerkannt, dass Software-Quellcode als Ganzes meist urheberrechtlich geschützt ist.

Die Frage, inwieweit Softwareschnittstellen bzw. API-Code kopiert werden dürfen, blieb aber bisher von den Gerichten unbeantwortet.

Der Oberste Gerichtshof der USA, der US Supreme Court, hat in seiner Entscheidung «Google LLC v. Oracle America, Inc.» vom 5. April 2021 ein wenig Klarheit darüber geschaffen, in welchem Umfang der zur Erstellung einer Softwareschnittstelle verwendete Deklarationscode kopiert werden kann.

Java ist eine von Oracle entwickelte Computerprogrammiersprache, die als Teil der Java SE-Plattform verwendet wird. Oracle ist die Inhaberin des Urheberrechts an Java SE.

2005 erwarb Google Android und kopierte, um Programmierern die Arbeit mit Java zu ermöglichen, 37 Java-API-Codestellen (d. h. rund 11’500 Zeilen Code). Die Java-API von Oracle wird indes nicht nur von Google, sondern weltweit verbreitet von Programmierern genutzt. Oracle warf Google vor, dass dieses Kopieren von Computer-Code unberechtigt erfolge und das Verwenden der urheberrechtlich geschützten Java-SE-Computerplattform entsprechend unzulässig sei.

Oracle verklagte daraufhin Google wegen des Kopierens dieses API-Codes mit dem Argument, dass Google damit das Urheberrecht von Oracle verletze. Google wiederum argumentierte, dass ein solches Kopieren eine faire Nutzung (sog. «Fair Use») darstelle und es somit von der Beachtung des Urheberrechts befreit sei.

|Nach einer Reihe gerichtlicher Auseinandersetzungen befand die untere Instanz, dass sowohl der API-Code als auch die Struktur von Oracle urheberrechtlich geschützt werden könnten und dass die Verwendung des API-Codes durch Google keine faire Nutzung darstelle.

Schliesslich hatte das höchste US-amerikanische Gericht, der Supreme Court, zu beurteilen, ob die Nutzung von Oracles Java-API-Codes durch Google eine Urheberrechtsverletzung darstellt und ob allenfalls die «Fair Use Doctrine» die Nutzung rechtfertigt.

Der Oberste Gerichtshof der USA hob am Ende das Urteil der unteren Instanz auf. Bei den von Google kopierten API-Codezeilen handle es sich um Teile von Benutzerschnittstellen. Durch diese APIs können Programmierer vorgefertigte Rechenaufgaben zur Verwendung in ihren eigenen Programmen aufrufen. Da Computerprogramme also primär eine Funktion erfüllten, sei es schwierig, traditionelle Urheberrechtskonzepte für diese Technologien anzuwenden. Justice Stephen Gerald Breyer, der für den Gerichtshof schrieb, wies darauf hin, dass die Fair-Use-Doktrin insbesondere bei der Computerprogrammierung die Funktionalität des fraglichen Werks berücksichtigen müsse. «Fair Use» biete also ein Korrektiv gegen die potenzielle Übermonopolisierung durch die Gewährung von Urheberrechten für Computerprogramme. Aus prozessökonomischen Gründen ging der Supreme Court hypothetisch von einem Szenario aus, in dem der fragliche API-Code urheberrechtlich geschützt ist, und widmete sich sodann eingehend dem 4-Faktoren-Test der Fair-Use-Doktrin:

Beim Prüfen des ersten der vier Fair-Use-Faktoren, geht es um die Art des Werks. Gemäss dem Supreme Court ist ein API zwar ein Code, aber kein Computerprogramm, da ein API keine Aufgabe ausführt. Als Teil einer Schnittstelle sind die von Google kopierten Zeilen naturgemäss mit Ideen betreffend die Gesamtorganisation bzw. Struktur der API verbunden. Dies, so das Gericht, spreche für eine faire Nutzung. Ideen seien urheberrechtlich nicht geschützt – erst die Konkretisierung der Idee, also deren Ausdruck, sei urheberrechtlich schützbar.

Beim zweiten Faktor befasste sich der Supreme Court mit dem Zweck und Charakter bzw. der Art der Nutzung. Das Gericht befand, dass das Kopieren vorliegend keinen Selbstzweck darstelle. Die APIs sollten lediglich genutzt werden, um einen neuen kreativen Ausdruck, nämlich den von Google unabhängig geschriebenen, für die Entwicklung der Android-Plattform benötigten Code, zu schaffen. Der Supreme Court stufte somit den Zweck des Werks als umgestaltend ein.

Zum dritten Faktor, mit dem die Menge und der Umfang sowie die Wesentlichkeit des verwendeten Teils im Verhältnis zum urheberrechtlich geschützten Werk beurteilt werden, hielt der Supreme Court fest, dass die 11’500 kopierten Zeilen bloss 0.4 % des API ausmachen. Die Menge des kopierten Codes ist folglich bloss ein kleiner Teil eines wesentlich grösseren Ganzen – weniger als 3 % der Gesamtmenge des Codes in der Java-API, die sich auf 2,86 Mio. Zeilen belief.

Der vierte und letzte Fair-Use-Faktor analysiert die Auswirkungen der Nutzung auf dem potenziellen Markt. Die neue Android-Smartphone-Plattform von Google stelle gemäss dem Supreme Court keinen Marktersatz für Java SE dar. Oracle würde sogar von der Neuimplementierung ihrer Schnittstelle profitieren.

Das Gericht verneinte also das Vorliegen einer Urheberrechtsverletzung auf der Basis der Fair-Use-Doktrin und fügte an, dass ein Durchsetzen des Urheberrechts auf der Grundlage dieser Tatsachen die Gefahr bergen würde, dass der Öffentlichkeit «kreativitätsbezogene Schäden» entstünden.

Aus der Kombination der vier Fair-Use-Faktoren ergab sich für das Gericht, dass Google sich mit dem Kopieren des API-Codes durchaus im Rahmen der Fair-Use-Doktrin – und damit in zulässiger Weise – bewegte. Der Oberste Gerichtshof der USA wies darauf hin, dass diese Entscheidung keine Änderung gegenüber seinen anderen Urteilen zur Fair-Use-Lehre darstelle. Vielmehr biete diese einen Rahmen und eine Analyseanleitung für die besonderen und einzigartigen Fragen und Umstände, die sich ergeben, wenn ein urheberrechtlich geschützter Computercode von anderen Entwicklern und Unternehmen verwendet wird.

Wichtig ist, dass das Gericht nicht entschieden hat, ob der deklarierende Code für sich allein urheberrechtsfähig ist. Diese Frage wurde offengelassen. Entschieden wurde bloss, dass im Zusammenhang mit Google das Verwenden eines kleinen Prozentsatzes des Codes zur Erstellung der Android-API zulässig war. Das Gerichts fällte den Entscheid mit einer Quote von 6 : 2.

Ein Durchsetzen von Oracles Urheberrechten hätte sicherlich Konsequenzen auf globaler Ebene gehabt, denn es wird vermutet, dass rund 70 % der Smartphones davon be|troffen gewesen wären: Dies hätte unweigerlich zu enormen Schadenersatzklagen geführt.

Die «Dissenting Opinion» stammt von Justice Clarence Thomas, dem erzkonservativen Abtreibungsgegner (der auch im April 2023 wieder in die Schlagzeilen geriet). Justice Thomas war der Meinung, dass Oracles API-Code urheberrechtlich geschützt sei und drei der vier Fair-Use-Faktoren gegen Google sprächen, insbesondere seien sowohl qualitativ wie auch quantitativ in erheblichem Mass Code-Teile kopiert worden. Ihn dürfte wohl das Prinzip «Thou shalt not steal» aus den zehn Geboten beeinflusst haben.

Das Thema ist aktuell, APIs sind in unserer digitalisierten Welt überall anzutreffen. Ein eigentliches Pendant zur Fair-Use-Doktrin gibt es in der Schweiz nicht. Ein Gericht könnte sich also nicht (wie der US Supreme Court) um die Beantwortung der Kernfrage, ob APIs urheberrechtlich schützbar sind, drücken, um dann sogleich die kopierende Partei zu entlasten, indem dieser faire Nutzung («Fair Use») attestiert wird.

Software-Schnittstellen können in der Schweiz grundsätzlich selbständig urheberrechtlich schützbar sein, soweit man den Programmierern einen gewissen Gestaltungsspielraum bei deren Schaffung zugesteht. Für den Urheberrechtsschutz braucht es also auch bei einer Schnittstelle eine gewisse Individualität in der Kreation und die nötige Schöpfungshöhe.

In diesem Zusammenhang lohnt sich ein Blick auf die Anforderungen für den Urheberrechtsschutz bei Computerprogrammen: Ungeachtet eines bestehenden Gestaltungsspielraums fehlt einem Computerprogramm dann die notwendige Individualität, wenn es als banal bzw. trivial zu qualifizieren ist, weil sein Inhalt eine blosse Aneinanderreihung von bekanntem, zum Gemeingut gehörendem Material darstellt, oder wenn es vollständig auf rein alltäglicher, standardisierter Programmierarbeit beruht.

Was bereits bei einem Computerprogramm gilt, muss daher umso mehr für eine Schnittstelle gelten: Massgebend für die Feststellung der Werkqualität einer Schnittstelle ist folglich allein, ob sie eine ausreichende schöpferische Individualität aufweist oder nicht. Prinzipiell wird diese Voraussetzung bei Schnittstellen in geringerem Masse als bei Computerprogrammen gegeben sein, weil der Gestaltungsspielraum eines Programmierers aufgrund der Vorgaben zur jeweiligen Datenübermittlung der einzelnen Computerprogramm-Komponenten noch enger ist. Zudem werden für den Datentransfer vielfach bestimmte Standards durch Regulierungsorganisationen, Branchenverbände oder die in diesem Bereich tätigen Unternehmen festgelegt, wodurch das Geltendmachen eines Urheberrechts durch einen einzelnen Hersteller einer Computerprogrammkomponente ausscheidet.

Was bräuchte es denn, damit eine Softwareschnittstelle in der Schweiz überhaupt urheberrechtlich geschützt sein könnte? Die notwendige Voraussetzung für einen urheberrechtlichen Schutz von Schnittstellen besteht in jedem Fall erstmal darin, dass die jeweilige Schnittstelle gemäss Art. 2 URG auch als geschütztes Werk zu qualifizieren ist.

Um diese Möglichkeit auszuloten, bietet sich zunächst einmal ein Blick darauf an, wann denn ein Computerprogramm Urheberrechtsschutz geniesst und wann nicht:

Voraussetzung für die Anerkennung von Computerprogrammen als urheberrechtliches Werk bildet gemäss Art. 2 Abs. 1 URG das Vorhandensein einer geistigen Schöpfung mit individuellem Charakter.

Geschützt ist ein Werk, wenn es sich als individuelle Schöpfung von den tatsächlichen oder natürlichen Vorbedingungen im Rahmen der Zweckbestimmung abhebt. Eine geistige Schöpfung liegt dann vor, wenn das Werk die Äusserung einer gedanklichen Tätigkeit eines Menschen darstellt und damit auf einer zumindest geringen geistigen Leistung beruht. Der individuelle Charakter eines Werks spiegelt sich darin wider, dass ein Dritter bei gleicher Aufgabenstellung nicht das gleiche oder im Wesentlichen das gleiche Werk schaffen wird, und grenzt sich gegenüber der Banalität oder einer routinemässigen Arbeit ab.

Die Schutzfähigkeit von Computerprogrammen hängt somit davon ab, ob dem Programmierer angesichts der Aufgabenstellung und der übrigen Rahmenbedingungen ein genügender Spielraum für eine persönliche Gestaltung in Auswahl, Sammlung, Anordnung und Einteilung der Informationen und Befehle zur Verfügung stand und ob er diesen Spielraum auch entsprechend genutzt hat.

Ungeachtet eines bestehenden Gestaltungsspielraums fehlt einem Computerprogramm allerdings dann die not|wendige Individualität, wenn es als banal bzw. trivial zu qualifizieren ist, weil sein Inhalt eine blosse Aneinanderreihung bekannten, zum Gemeingut gehörenden Materials darstellt, oder wenn es vollständig auf rein alltäglicher, standardisierter Programmierarbeit beruht.

Im Zusammenhang mit der Banalität bzw. der Trivialität ist darauf hinzuweisen, dass vieles, was sog. «statistisch einmalig» ist, dennoch trivial bzw. banal ist – und deswegen keinen Urheberechtsschutz geniesst. Hinsichtlich der statistischen Einmaligkeit gilt nämlich dort, wo die Natur des Werks nur wenig Platz für eine persönliche Auswahl zulässt, dass es schwieriger ist, sich von der Einmaligkeit des Werks zu überzeugen: Die Auswahl muss überraschend und ungewöhnlich erscheinen, um Urheberrechtsschutz zu erlangen, ansonsten verlässt das Werk den Bereich des Banalen nicht.

Eine triviale Kombination banaler Elemente könnte statistisch einmalig sein, wenn auch bloss, weil sie eine gewisse Anzahl Elemente kombiniert: Gemäss den Gesetzen der Wahrscheinlichkeit wird eine Kombination mit zahlreichen Elementen kaum noch einmal identisch kreiert. Eine strikte Anwendung dieses Kriteriums bei der Beurteilung des Urheberrechtsschutzes würde also darauf hinauslaufen, banale, triviale Schöpfungen zu schützen, soweit sie sich durch eine bestimmte Komplexität auszeichnen bzw. aus genügend vielen Elementen bestehen. Nicht nur die Lehre,, sondern auch das schweizerische Bundesgericht sind daher der Meinung, dass die reine statistische Einmaligkeit allein für den Urheberrechtsschutz nicht genügt.

Nun also zu den Schnittstellen und deren Spezifikationen bzw. Definitionen:

Unabhängig davon, ob Schnittstellen als selbständige Computerprogramme oder als Teil eines Computerprogramms ausgestaltet werden, kommt ihnen nur dann ein urheberrechtlicher Schutz zu, wenn sie auch selbst eine ausreichende schöpferische Individualität aufweisen. Als selbständige Computerprogramme ergibt sich dies unmittelbar aus Art. 2 Abs. 1 URG. Als Teile eines Computerprogramms weist ihnen Art. 2 Abs. 4 URG nur dann einen urheberrechtlichen Schutz zu, wenn sie selbst über eine ausreichende schöpferische Individualität verfügen.

Nach überwiegender Ansicht ist bei Schnittstellen jedoch eine ausreichende schöpferische Individualität im Regelfall nicht gegeben. Ganz allgemein ist anerkannt, dass Schnittstellenspezifikationen nicht schutzfähig sind, da es sich dabei bloss um Ideen und Grundsätze der Interoperabilität handelt, denen der Urheberrechtsschutz verwehrt ist. Zwar gehören die Schnittstellendefinitionen zum Computerprogramm, doch sind sie in der Regel wegen des fehlenden Gestaltungsspielraums bzw. mangels Schutzhöhe urheberrechtlich nicht geschützt.

Auch wird in der Literatur ausgeführt, dass Schnittstellendefinitionen schon daher grundsätzlich nicht als Computerprogramme geschützt sind, weil sie nicht direkt ausführbar sind. Es ist nämlich auch (bzw. insbesondere) im Bereich des Softwareschutzes zwischen dem Ausführbaren (hier: durch einen Computer ausführbare Software) und den statischen Daten zu differenzieren: Im Gegensatz zu Computerprogrammen haben Daten den Charakter isolierter Partikel (z. B. ja/nein, false/true, Zahlen), die erst vom Computerprogramm in einen Zusammenhang eingebettet werden. Die speziellen Bestimmungen über den Softwareschutz gelten daher nicht für statische elektronische Dokumente, weil diese nicht die für Computerprogramme typische unmittelbare Funktionalität aufweisen. Die Softwareschutzbestimmungen sind vielmehr auf direkt ausführbare Werke zugeschnitten. Mit anderen Worten: Auf der Ebene der statischen Daten greift noch kein rechtlicher Schutz – schon gar nicht ein urheberrechtlicher Schutz.

Wie aufgezeigt, gibt es im Zusammenhang mit Schnittstellenspezifikation kaum Gestaltungsspielraum, und wenn auch die eine oder andere Formulierung in der Schnittstel|lenspezifikation statistisch einmalig sein sollte, so würde der Urheberrechtsschutz an der Trivialität, Banalität bzw. Alltäglichkeit solcher Formulierungen scheitern. Dem «Beschrieb» einer Schnittstelle fehlt es somit in aller Regel an jeglicher schöpferischen Individualität – der Grundvoraussetzung für Urheberrechtsschutz nach Art. 2 Abs. 1 URG. Es handelt sich schlicht um eine standardisierte bzw. funktionsbestimmte – und damit nicht schutzfähige – Spezifikation. Eine Entwicklungsdokumentation ist in aller Regel standardisiert bzw. funktionsbestimmt – und damit nicht schutzfähig. Müssen Schnittstellen oder Teile davon aus technischen Gründen identisch oder praktisch identisch übernommen werden, damit sie überhaupt ihren Zweck erfüllen, dann ist dies zulässig.

Gemäss der sog. «Merger Doctrine» liegt im Übrigen dann keine Rechtsverletzung vor, wenn die «Idee» und der «Ausdruck» derart ineinander verschmolzen sind, dass sich die Übernahme der Ausdrucksformen nicht vermeiden lässt. Ein Ausdruck ist nicht schutzfähig, wenn es nur sehr wenige Möglichkeiten gibt, um eine Idee auszudrücken. Idee und Ausdruck fallen in einem solchen Fall zusammen. Auch dies spricht gegen einen Urheberrechtsschutz für Schnittstellen.

Interessant sind folgende Ausführungen des Kantonsgerichts St. Gallen: «Für die Kommunikation unter Programmen ist die Kenntnis von sogenannten Schnittstelleninformationen von Bedeutung, da die Schnittstellen zur Herstellung von interoperablen Programmen benötigt werden. Schnittstellen sind Verbindungsstellen zwischen verschiedenen Systemen. Verbindungsstellen in diesem Sinne bestehen aus Informationen über die Art, wie an einer bestimmten Stelle Daten bereitgestellt werden müssen oder die Aufrufe für Programme zu erfolgen haben, damit die Zusammenarbeit zwischen verschiedenen Systemen möglich ist. In diesem Bereich wurde der Schutz des Urheberrechts bewusst gelockert. Unter dem Kapitel «Schranken des Urheberrechts» regelt Art. 21 URG die sogenannte Dekompilierung bzw. Entschlüsselung eines Computerprogramms mit Blick auf seine Schnittstellen und deren Ausnutzung für die Herstellung interoperabler Computerprogramme. Wer das Recht hat, ein Computerprogramm zu gebrauchen, darf sich die erforderlichen Informationen über Schnittstellen zu unabhängig entwickelten Programmen durch Entschlüsselung des Programmcodes beschaffen oder durch Drittpersonen beschaffen lassen (Art. 21 Abs. 1 URG). Es ist dabei auch erlaubt, die Schnittstelleninformationen für ein Konkurrenzprodukt auszunutzen.»

In der IT-Praxis lässt sich häufig beobachten, dass eine Schnittstelle und deren Beschreibung sich im Lauf der Zeit zu einem Standard oder zumindest zu einem Quasi-Standard bzw. faktischen Standard auf dem jeweiligen Markt etabliert. Werden für den Datentransfer bestimmte Standards durch Regulierungsorganisationen, Branchenverbände oder die in diesem Bereich tätigen Unternehmen festgelegt, scheidet das Geltendmachen eines Urheberrechts durch einen einzelnen Hersteller einer Computerprogrammkomponente aus.

Bei Schnittstellen bzw. deren Spezifikationen dürfte schliesslich in aller Regel auch ein Schutz als Sprachwerk gemäss Art. 2 Abs. 2 lit. a URG nur schon am fehlenden Gestaltungsspielraum scheitern. Keinen Urheberschutz geniessen nämlich Sprachwerke, denen es an der individuellen Gestaltung fehlt, also z. B. Gebrauchsanweisungen, Produkteinformationen, und dies immer auch dann, wenn der konkrete Text zwar statistisch einmalig ist, insgesamt aber doch als banale Zusammenstellung von Alltagsredewendungen oder als durch die Sachlogik vorgegeben erscheint. Vergleichbar ist die Schnittstellenspezifikation mit den Charakteristiken einer Nachricht. Nachrichten sind Tatsachen, übermittelt in einer alltäglichen, nüchternen und schnörkellosen Sprache. Sie sind urheberechtlich nicht schützbar.

Es finden sich also ganz viele Argumente, die im Zusammenhang mit der Rechtslage in der Schweiz gegen den Urheberrechtsschutz für eine Softwareschnittstelle bzw. deren |Beschreibung (Spezifikation) sprechen. Selbstverständlich kann die Frage nach der Schützbarkeit einer API jedoch nur jeweils im Einzelfall zuverlässig analysiert werden.

Nicht fehlen sollte schliesslich bei einer Betrachtung der Möglichkeiten des Urheberrechtsschutzes von Softwareschnittstellen auch die Perspektive des deutschen Rechts und gemäss der Rechtsprechung des EuGH:

Auch im deutschen Urheberrecht gilt, dass die «den Schnittstellen zugrundeliegenden Ideen und Grundsätze» nicht geschützt sind. Diese – nicht schutzfähigen – Elemente werden als «Schnittstellenspezifikation» (bzw. als «Schnittstellenbeschreibung») bezeichnet. Die überwiegende Mehrheit der Autoren in Deutschland fordert – wohl zu Recht – eine Trennung zwischen der Schnittstelle und ihrer «Spezifikation», also zwischen Ausdruck und Idee bzw. Form und Inhalt. Nicht urheberrechtlich geschützt bleibt damit stets die Schnittstellenspezifikation bzw. -beschreibung, also die blosse Idee. In Deutschland gehören Schnittstellenspezifikationen zu den nicht schutzfähigen Ideen und Grundsätzen eines Computerprogramms. Das schliesst logisch aus, dass sie zugleich selbst Schutz als Computerprogramm geniessen können. Schnittstellenspezifikationen erfüllen weder die Definition des Computerprogramms (denn es handelt sich bestenfalls um eine Sammlung, nicht aber eine Folge von Befehlen; und ohne richtige Umsetzung in Quellcode kann man einen Computer nicht zu einer Ausführung bewegen) noch die Anforderungen des EuGH an eine Ausdrucksform (denn es handelt sich nicht um Quellcode, Objektcode oder um einen vergleichbaren Code). Diverse deutsche Autoren gehen noch einen Schritt weiter und sprechen sogar den Schnittstellen selbst jeglichen Urheberrechtsschutz ab.

Das LG Frankfurt hat in einem interessanten Fall entschieden, dass einer XML-Datei die urheberrechtliche Schutzfähigkeit fehlt: Dabei wurde insbesondere befunden, dass es sich bei der fraglichen XML-Datei und den darin enthaltenen Regelsätzen nicht um ein Sprachwerk handelt, da vorliegend wenig bis gar kein geistiger Inhalt durch das Mittel der Sprache zum Ausdruck komme. Die Leistung müsse aus dem Werk erkennbar sein. Schriftgut, das Gebrauchszwecken dient und von ihnen weitgehend vorgegeben ist, müsse vergleichbare alltägliche Schriften deutlich übersteigen. Die Frage des Eigentümlichkeitsgrads bemesse sich dabei nach dem geistig-schöpferischen Gesamteindruck, und zwar im Gesamtvergleich gegenüber vorbestehenden Gestaltungen.

Weiter hat das LG Frankfurt festgestellt, dass die Gesamtheit der Regelsätze, die in der XML-Datei enthalten sind, die Voraussetzungen eines urheberrechtlich geschützten Werks nicht erfüllt, dass weder die XML-Datei, noch die darin enthaltenen Regelsätze ein Computerprogramm darstellen und dass es sich bei der XML-Datei und den darin enthaltenen Regelsätzen um eine Schrift handle, die Gebrauchszwecken dient, nämlich dem Import in eine Datenbankanwendung, wodurch diese Datenbankanwendung auf die jeweiligen Bedürfnisse des Anwenders zugeschnitten wird. Dem Gericht erschliesse sich kein geistiger Inhalt der Regelsätze. Diese seien vielmehr bloss eine Aneinanderreihung von Zeichen, und selbst wenn ein geistiger Gehalt der Regelsätze erkennbar wäre, so sei nicht erstellt, dass diese Regelsätze bzw. der in ihnen verkörperte geistige Inhalt, also die geistige Schöpfung, sich deutlich vom Alltäglichen abheben.

Der EuGH hat die Trennung zwischen Implementation und Schnittstellenspezifikation für die mit den Kommunikationsprotokollen verwandten Dateiformate (es geht in beiden Fällen um Datenaustausch) bereits bestätigt: Es ist nur konsequent, diesen Gedanken auch auf Kommunikationsprotokolle zu erstrecken.

|Anfang Mai 2012 hat der EuGH erstmals entschieden, dass Programmiersprachen keinen urheberrechtlichen Schutz geniessen, denn sie sind in rechtlicher Hinsicht nicht mit Software-, Sprach- oder auch Musikwerken zu vergleichen.

Die Entscheidung verträgt sich gut mit der bisherigen schweizerischen Rechtsprechung zu schutzfähigen Werken.

Gleichzeitig regt sie dazu an, sich mit ähnlich gelagerten Fragen näher zu befassen, nämlich nach der urheberrechtlichen Einordnung von Dateiformaten, Protokollen und Benutzeroberflächen:

Das Urheberrecht ist im Kern der Schutz des Schöpferischen, d. h. dort wo es am Schöpferischen, an der Individualität bzw. der Originalität fehlt, da kann kein urheberrechtlicher Schutz geltend gemacht werden. Nicht geschützt sind – wie bereits erwähnt – Ideen, Konzepte und Grundsätze. Eine blosse Funktion, wie z. B. die Funktion, eine bestimmte Skriptsprache interpretieren zu können, ist keine Ausdrucksform. Diese Funktion – und damit letztendlich die Programmiersprache als solche – unterliegt daher nicht dem urheberrechtlichen Schutz. Wenn man bereits die Funktion (eines Computerprogramms) schützen wolle, so der EuGH in seiner letztlich wohlfahrtsökonomisch geprägten Argumentation, würde dies dem technischen Fortschritt und der industriellen Entwicklung schaden. Zudem würde es die Möglichkeit eröffnen, blosse Ideen zu monopolisieren. Der Generalanwalt hatte in seiner Urteilsempfehlung an den EuGH treffend angemerkt, dass eine Programmiersprache mit der Sprache eines Romanautors vergleichbar sei: Beide sind blosse Mittel zum Ausdruck, aber keine – urheberrechtlich schützbare – konkrete Ausdrucksform. Eine Programmiersprache könnte zwar theoretisch nach den allgemeinen Regeln als Sprachwerk urheberrechtlich geschützt sein. Das würde jedoch voraussetzen, dass die Auswahl der Schlüsselwörter und Operatoren sowie die Syntax, die von einer Programmiersprache vorgegeben werden, an eine geistige Schöpfung heranreichen. Das ist jedoch reine Theorie, denn die Programmiersprache wurde mit dem Ziel konzipiert, gemessen an ihrem Zweck möglichst effizient und leicht erlernbar zu sein. Die Gestaltungskriterien sind somit vorrangig funktional. Was seine Gestaltung aber nur einer rein technischen Zweckbestimmung verdankt, stellt eben nicht das Ergebnis eines schöpferischen Prozesses dar und ist damit einem urheberrechtlichen Schutz nach den allgemeinen Grundsätzen nicht zugänglich.

Diese vom EuGH entwickelten Grundsätze lassen sich nun auch im Hinblick auf Dateiformate, Protokolle, Benutzeroberflächen und Schnittstellenbeschreibungen anwenden:

Bei der Interpretation eines bestimmten Dateiformats handelt es sich nur um eine andere Art des Inputs als bei der Verarbeitung bestimmter Skripte. Hinzu kommt die Frage, ob die Output-seitige Verwendung eines Dateiformats (also die Fähigkeit, Dateien in einem bestimmten Format schreiben zu können) eine andere rechtliche Beurteilung erfordert. Tatsächlich musste der EuGH im Rahmen seiner Entscheidung auch genau diese Frage im Zusammenhang mit dem Dateiformat beantworten. Konsequenterweise stellte er fest, dass die Funktion, Dateien in einem bestimmten Format schreiben zu können, ebenso wenig geschützt ist, wie die des Einlesens. Im Ergebnis sind also Dateiformate wie Programmiersprachen zu beurteilen und daher grundsätzlich keinem urheberrechtlichen Schutz zugänglich.

Ein verwandter Bereich betrifft Netzwerkprotokolle: Die für Skripte und Dateiformate geltenden Grundsätze lassen sich auch auf solche technischen Definitionen anwenden. Ähnlich wie Dateiformate geben sie lediglich vor, welches Format die über eine Schnittstelle einzulesenden oder auszugebenden Daten haben müssen. Die Funktion, ein bestimmtes Protokoll verstehen und ausgeben zu können, geniesst daher ebenso wenig urheberrechtlichen Schutz. Wie Programmiersprachen bieten auch Benutzerschnittstellen die Möglichkeit, mit einer Software zu kommunizieren. Das kann über Oberflächen unterschiedlicher Art geschehen: Die Interaktion kann grafisch, akustisch oder textorientiert erfolgen, Nutzer-Input kann eingetippt, eingesprochen, per Klick oder per Geste vermittelt werden. Auf textorientierte Benutzerschnittstellen, die etwa mit einer Befehlszeile oder einfachen Menüs arbeiten, lässt sich das zu Protokollen und Dateiformaten Geschriebene ebenfalls anwenden.

Auch nach deutschem Recht und im Licht der einschlägigen Rechtsprechung des EuGH dürften somit Softwareschnittstellen bzw. deren Beschreibungen (Spezifikationen) urheberrechtlich nicht schützbar sein.

Kommen wir nun zu den «Schüttgefässwaagen-Fällen», wo die Klägerin sich der Hauptherausforderung zu stellen hatte, wie sich substantiieren und beweisen lässt, dass sie überhaupt über die Urheberrechte an der durch die Beklagte übernommenen Software oder an den übernommenen Softwarekomponenten verfügt.

Schüttgefässwaagen bestehen aus interoperierenden Hard- und Softwarekomponenten. In allen vier Gerichtsfällen geht es insbesondere um Software zur elektronischen Steuerung von Waagen und Umwandlung analoger Messdaten in digitale Messwerte. Diese Software war von einem Mitarbeiter der Klägerin und von einem externen Softwareentwickler geschaffen worden. Die Klägerin beanspruchte, Eigentümerin der Urheberrechte an der Software zu sein. Der von der Klägerin beauftragte Drittentwickler hatte die Software ehemaligen Mitarbeitenden der Klägerin für die |Entwicklung eines Konkurrenzprodukts zur Verfügung gestellt.

In allen vier Gerichtsfällen ging es im Kern stets um die drei Fragen, was für Elemente denn konkret übernommen worden waren, ob die übernommenen Elemente urheberrechtlich geschützt seien und ob die Urheberrechte an diesen Elementen der Klägerin zustehen.

Die Klägerin legte jeweils ein Gutachten vor, um aufzuzeigen, dass acht Funktionalitäten der Originalsoftware praktisch unverändert bzw. bloss geringfügig angepasst im Konkurrenzprodukt integriert waren. Dieses Gutachten wurde anhand einer Analyse der kompilierten Maschinencodes (Original und Übernahme) erstellt.

Gerichtlich nicht entschieden wurde, ob die allenfalls bestehenden Urheberrechte der Klägerin zustehen. Die entsprechenden Massnahmengesuche gegen die Konkurrentin und den Drittentwickler wurden abgewiesen, da die Klägerin nicht substantiiert hatte, worin die angeblich übernommenen Funktionalitäten bestehen. Auch hatte sie nicht aufgezeigt, und dass die übernommenen Funktionalitäten angesichts der Vorgaben aus dem Stand der Technik überhaupt Individualität aufweisen.

Aus den Entscheiden lässt sich folgern, dass die Individualität übernommener Software(-Komponenten) in der Rechtsschrift selbst substantiiert und im Bestreitungsfall bewiesen werden muss – idealerweise mit den Quellcodes. Privatgutachten können zwar nützlich sein, sie sind aber als reine Parteibehauptungen zu werten und daher für sich nie ausreichend.

Das Schweizerische Bundesgericht in Lausanne befasste sich in seinem Entscheid «Schüttgefässwaage 1 II» vom 2. Dezember 2019 mit dem Fall der von der X. AG neu auf den Markt gebrachten, mit Druckluft betriebenen Schüttgefässwaagen. Die Y. AG, ein Technologieunternehmen, hatte ihrerseits bereits 2013 – 2017 solche Schüttgefässwaagen entwickelt und ging davon aus, dass ihre acht ehemaligen Mitarbeitenden, die inzwischen alle bei der X. AG tätig waren, das Konkurrenzprodukt durch unrechtmässige Verwendung von Arbeits- und Geschäftsgeheimnissen hergestellt hatten. Das Bundesgericht hiess die Beschwerde der Y. AG gegen den offensichtlich mangelhaften Entscheid der Vorinstanz, des Kantonsgerichts Appenzell Innerrhoden, gut und wies den Fall zur nochmaligen Beurteilung an die Vorinstanz zurück. Diese müsse nicht nur beurteilen, ob den angeblich rechtswidrig verwendeten Konstruktionsplänen, Leiterplatten und Dateien Geheimnischarakter zukomme, sondern v. a. auch, ob sie als Arbeitsergebnisse oder als urheberrechtlich geschützte Werke zu qualifizieren seien. Auch ohne Konkurrenzverbotsklausel i. S. v. Art. 340 des Schweizerischen Obligationenrechts (OR) bestehe gemäss der arbeitsrechtlichen Bestimmung von Art. 321a OR eine allgemeine Treuepflicht des Arbeitnehmers, aus der eine über die Beendigung des Arbeitsvertrags andauernde Geheimhaltungspflicht folge. Das Kantonsgericht Appenzell Innerrhoden hatte daher fälschlicherweise befunden, dass hier die während eines Arbeitsverhältnisses erworbenen spezifischen Branchenkenntnisse frei verwendbar sind und nicht unter Art. 6 des Bundesgesetzes gegen den unlauteren Wettbewerb (UWG) fielen.

Im Massnahmeentscheid «Schüttgefässwaage 2 I» des Handelsgerichts St. Gallen vom 24. Januar 2020 hatte sich das Gericht im Zusammenhang mit vorsorglichen Massnahmen (einstweilige Verfügung) mit den Substantiierungsanforderungen beim Geltendmachen einer Urheberverletzung an einem Softwareprogramm für die Steuerung einer Waage für Mehl und Futtermittel zu befassen. Der Gerichtspräsident hielt zunächst fest, dass Computerprogramme mit gewisser Komplexität i. d. R. urheberrechtlich geschützt seien. Werde die unerlaubte Übernahme von Programmteilen behauptet, so sei die Rechtsinhaberschaft am originären Code und die Übernahme konkreter Codeteile glaubhaft zu machen. Der Gerichtspräsident wies in der Folge die von der Gesuchstellerin (wiederum der Y. AG) geltend gemachten Ansprüche ab, da die Y AG nicht dargelegt habe, «welche Funktionen die angeblich übereinstimmenden Dateien konkret beinhalten. Nachdem die Gesuchstellerin […] weder darlegt, welchen Inhalt die einzelnen angeblich übereinstimmenden Programmfunktionen aufweisen, noch Ausführungen darüber macht, welche schöpferischen Eigenleistung XY bei der Programmierung dieser Programmfunktionen erbracht haben soll, kann nicht geprüft werden, ob sich diese Programmfunktionen von bereits vorbestehenden Programmfunktionen unterscheiden, einen individuellen Charakter aufweisen und somit urheberrechtlich geschützt sind. Eine Verletzung eines Urheberrechts ist damit nicht glaubhaft gemacht.»

Das Schweizerische Bundesgericht wies die gegen den Massnahmeentscheid «Schüttgefässwaage 2 I» des Handelsgerichts St. Gallen vom 24. Januar 2020 erhobene Beschwerde der Y. AG in seinem Entscheid «Schüttgefässwaage 2 II» vom 22. September 2020 ab, soweit darauf eingetreten wurde. Wird in einem Massnahmeverfahren das unerlaubte Verwenden und die Weitergabe neu entwickelter Software geltend gemacht, so sei davon auszugehen, dass ein nicht wieder gutzumachender Nachteil gemäss Art. 93 Abs. 1 lit. a des Bundesgesetzes über das Bundesgericht (BGG) glaubhaft ist, «zumal es sich bei den angeblich vom Beschwerdegegner verwendeten Programmfunktionen der strittigen Software |um Bestandteile einer Neuentwicklung handelt, für die Umsatz- und Gewinnzahlen fehlen». Zudem sei «mit der Beschwerdeführerin davon auszugehen, dass das Motiv der Kundschaft für die Wahl von Konkurrenzprodukten, die unter Verwendung geschützter Softwarebestandteile hergestellt&cbr; wurden, nicht nachweisbar sein dürfte». Unter diesen Umständen sei «entgegen der Ansicht des Beschwerdegegners nicht zu erwarten, dass der drohende Nachteil durch Schadenersatz, Genugtuung oder Gewinnherausgabe zu beseitigen ist.»

Zusammenfassung

Im Bereich der Softwaretechnik und -entwicklung ist es weit verbreitet, von anderen geschriebene Softwareschnittstellen zu verwenden. In der Schweiz, in Deutschland, in vielen anderen europäischen Ländern und in den USA ist – auch durch eine gefestigte Rechtsprechung – allgemein anerkannt, dass Software-Quellcode als Ganzes meist urheberrechtlich geschützt ist. Die Frage, inwieweit Softwareschnittstellen bzw. API-Code kopiert werden dürfen, blieb aber bisher von den Gerichten unbeantwortet.

Der Oberste Gerichtshof der USA, der US Supreme Court, hat in seiner Entscheidung «Google LLC v. Oracle America, Inc.» vom 5. April 2021 ein wenig Klarheit darüber geschaffen, in welchem Umfang der zur Erstellung einer Softwareschnittstelle verwendete Deklarationscode kopiert werden kann. Das Gericht verneinte das Vorliegen einer Urheberrechtsverletzung auf der Basis der sog. Fair-Use-Doktrin und fügte an, dass ein Durchsetzen des Urheberrechts auf der Grundlage dieser Tatsachen die Gefahr bergen würde, dass der Öffentlichkeit «kreativitätsbezogene Schäden» entstünden. Aus der Kombination der vier Fair-Use-Faktoren ergab sich für das Gericht, dass Google sich mit dem Kopieren des API-Codes durchaus im Rahmen der Fair-Use-Doktrin – und damit in zulässiger Weise – bewegte. Der Oberste Gerichtshof der USA wies darauf hin, dass seine Entscheidung keine Änderung gegenüber seinen anderen Urteilen zur Fair-Use-Lehre darstelle. Vielmehr biete diese einen Rahmen und eine Analyseanleitung für die besonderen und einzigartigen Fragen und Umstände, die sich ergeben, wenn ein urheberrechtlich geschützter Computercode von anderen Entwicklern und Unternehmen verwendet wird. Wichtig ist, dass das Gericht nicht entschieden hat, ob der deklarierende Code für sich allein urheberrechtsfähig ist. Diese Frage wurde offengelassen. Entschieden wurde bloss, dass im Zusammenhang mit Google das Verwenden eines kleinen Prozentsatzes des Codes zur Erstellung der Android-API zulässig war. Ein Durchsetzen von Oracles Urheberrechten hätte sicherlich Konsequenzen auf globaler Ebene gehabt, denn es wird vermutet, dass rund 70 % der Smartphones davon betroffen gewesen wären: Dies hätte unweigerlich zu enormen Schadenersatzklagen geführt.&cbr;

|Nach überwiegender Ansicht ist in der Schweiz bei Schnittstellen eine ausreichende schöpferische Individualität im Regelfall nicht gegeben. Es ist anerkannt, dass Schnittstellenspezifikationen nicht schutzfähig sind, da es sich dabei bloss um Ideen und Grundsätze der Interoperabilität handelt, denen der Urheberrechtsschutz verwehrt ist. Zwar gehören die Schnittstellendefinitionen zum Computerprogramm, doch sind sie in der Regel wegen des fehlenden Gestaltungsspielraums bzw. mangels Schutzhöhe urheberrechtlich nicht geschützt. Wenn auch die eine oder andere Formulierung in der Schnittstellenspezifikation statistisch einmalig sein sollte, so würde der Urheberrechtsschutz an der Trivialität, Banalität bzw. Alltäglichkeit solcher Formulierungen scheitern. Dem «Beschrieb» einer Schnittstelle fehlt es somit in aller Regel an jeglicher schöpferischen Individualität – der Grundvoraussetzung für Urheberrechtsschutz nach Art. 2 Abs. 1 URG. Es handelt sich schlicht um eine standardisierte bzw. funktionsbestimmte – und damit nicht schutzfähige – Spezifikation. Eine Entwicklungsdokumentation ist in aller Regel standardisiert bzw. funktionsbestimmt – und damit nicht schutzfähig. Auch wird in der Literatur ausgeführt, dass Schnittstellendefinitionen schon daher grundsätzlich nicht als Computerprogramme geschützt sind, weil sie nicht direkt ausführbar sind. Es ist nämlich auch (bzw. insbesondere) im Bereich des Softwareschutzes zwischen dem Ausführbaren (hier: durch einen Computer ausführbare Software) und den statischen Daten zu differenzieren: Im Gegensatz zu Computerprogrammen haben Daten den Charakter isolierter Partikel (z. B. ja/nein, false/true, Zahlen), die erst vom Computerprogramm in einen Zusammenhang eingebettet werden. Die speziellen Bestimmungen über den Softwareschutz gelten daher nicht für statische elektronische Dokumente, weil diese nicht die für Computerprogramme typische unmittelbare Funktionalität aufweisen. Die Softwareschutzbestimmungen sind vielmehr auf direkt ausführbare Werke zugeschnitten. Mit anderen Worten: Auf der Ebene der statischen Daten greift noch kein rechtlicher Schutz – schon gar nicht ein urheberrechtlicher Schutz. Müssen schliesslich Schnittstellen oder Teile davon aus technischen Gründen identisch oder praktisch identisch übernommen werden, damit sie überhaupt ihren Zweck erfüllen, dann ist dies zulässig.&cbr;

Résumé

Dans le domaine de la technique et du développement de logiciels, il est très répandu d’utiliser des interfaces logicielles écrites par des tiers. En Suisse, en Allemagne, dans de nombreux autres pays européens et aux États-Unis, il est communément admis, notamment par une jurisprudence bien établie, que le code source d’un logiciel dans son ensemble est généralement protégé par le droit d’auteur. Cependant, la question de savoir dans quelle mesure les interfaces logicielles ou le code API peuvent être copiés est restée jusqu’à présent sans réponse de la part des tribunaux.

Dans sa décision «Google LLC v. Oracle America, Inc.» du 5 avril 2021, la Cour suprême des États-Unis a apporté un peu de clarté quant à la mesure dans laquelle le code de déclaration utilisé pour créer une interface logicielle pouvait être copié. Le Tribunal a nié l’existence d’une violation du droit d’auteur sur la base du principe de l’usage loyal (fair use doctrine) et a ajouté que l’application du droit d’auteur à ces faits risquerait de causer au public des «dommages en matière de créativité». La combinaison des quatre facteurs déterminant l’usage loyal a permis à la Cour de conclure que Google, en copiant le code API, se situait bien dans le cadre du principe de l’usage loyal – et avait donc agi de manière licite. La Cour suprême des États-Unis a souligné que sa décision ne constituait pas un changement par rapport à ses autres jugements concernés par le principe de l’usage loyal. Au contraire, elle a estimé qu’elle fournissait ainsi un cadre et un modèle d’analyse pour les questions qui se posent et les circonstances particulières et uniques qui surviennent lorsqu’un code informatique protégé par des droits d’auteur est utilisé par d’autres développeurs et entreprises. Il est important de noter que le Tribunal n’a pas déterminé si le code dont il était question était en soi soumis au droit d’auteur; cette question a été laissée en suspens. Il a seulement été stipulé que, dans le contexte de Google, l’utilisation d’un petit pourcentage du code pour la création de l’API Android était licite. L’application des droits d’auteur d’Oracle aurait certainement entraîné des conséquences au niveau mondial, car on estime qu’environ 70 % des smartphones auraient été concernés: cela aurait inévitablement conduit à d’énormes actions en dommages et intérêts.

Selon l’opinion dominante en Suisse, les conditions suffisantes pour définir un caractère individuel créatif ne sont généralement pas réunies en ce qui concerne les interfaces. Il est admis que les spécifications d’interface ne peuvent pas être protégées, car il s’agit uniquement d’idées et de principes d’interopérabilité qui ne sont pas protégés par le droit d’auteur. Les définitions d’interface font certes partie d’un programme informatique, mais elles ne sont généralement pas protégées par le droit d’auteur en raison du manque de liberté de conception, et donc du champ de protection. Même si l’une ou l’autre formulation dans la spécification d’une interface devait être statistiquement unique, la protection par le droit d’auteur échouerait en raison de l’aspect trivial, banal ou commun de telles formulations. La «description» d’une interface est donc généralement dépourvue de tout caractère individuel créatif, condition de base pour jouir de la protection du droit d’auteur selon l’art. 2 al. 1 LDA. Il s’agit simplement d’une spécification standardisée et déterminée par la fonction – et donc non protégeable –, comme c’est en général le cas de la documentation de développement. La littérature explique également que les définitions d’interface ne sont en principe pas protégées en tant que programmes informatiques parce qu’elles ne sont pas directement exécutables. En effet, dans le domaine de la protection des logiciels, il convient également (voire surtout) de faire la distinction entre ce qui est exécutable (en l’espèce: un logiciel exécutable par un ordinateur) et les données statiques: contrairement aux programmes informatiques, les données ont le caractère de particules isolées (p. ex. oui/non, faux/vrai, chiffres) qui ne sont intégrées dans un contexte que par le biais du programme informatique. Les dispositions spécifiques relatives à la protection des logiciels ne s’appliquent donc pas aux documents électroniques statiques, car ceux-ci ne présentent pas la fonctionnalité immédiate caractéristique des programmes informatiques. Les dispositions relatives à la protection des logiciels sont plutôt conçues pour les œuvres directement exécutables. En d’autres termes, aucune protection juridique n’intervient encore au niveau des données statiques – et en tout cas pas une protection par le droit d’auteur. Enfin, la reprise à l’identique ou pratiquement à l’identique d’interfaces ou de parties d’interfaces est licite si elle est nécessaire pour des raisons techniques, afin que celles-ci puissent remplir leur fonction.