Jusletter IT

Der fortlaufende technische Wandel wirft bei der Entwicklung und beim Einsatz von Computerprogrammen aus urheberrechtlicher wie auch aus vertragsrechtlicher Perspektive verschiedene neue Fragestellungen auf. Im Zentrum der rechtlichen Einordnungen dieser Arbeit steht das Gebiet der Virtualisierung – ein IT-Trend, welcher spätestens seit anfangs des 21. Jahrhunderts nicht mehr zu bremsen ist und in dessen Zuge ständig neue Lösungen entwickelt werden. Um Ressourcen zu sparen und die Verfügbarkeit von Systemen zu steigern, werden Hardware- oder Softwarekomponenten abstrahiert und auf virtueller Ebene bereitgestellt. Während die herkömmlichen virtuellen Maschinen, welche einen kompletten Rechner virtualisieren, in der juristischen Lehre schon teilweise Eingang gefunden haben, ist die neuere «leichtgewichtigere» Virtualisierungslösung des Containers bis anhin noch weitgehend unbehandelt. Bei diesem Ansatz wird das Betriebssystem des Hosts genutzt und es werden lediglich die Anwendungen voneinander isoliert. Aus der informationstechnologischen Sicht unterscheiden sich beide Architekturen erheblich, doch rechtlich gesehen wird selten differenziert, weshalb bei der juristischen Betrachtung der Container-Virtualisierung stets auch die Situation bei virtuellen Maschinen berücksichtigt werden muss. Um eine technische Basis für die Arbeit zu schaffen, werden zuerst die Hintergründe und Grundlagen beider Technologien dargelegt (2.). Anschliessend stellt sich im Falle der Softwareüberlassung auf Dauer die Frage, wie der Einsatz eines Programms in solch virtualisierten Umgebungen urheberrechtlich (3.) zu beurteilen ist, falls kein oder kein gültiger Vertrag vorliegt. Sodann ist die vertragsrechtliche Ebene (4.) bei Vorliegen eines Softwarevertrages darzulegen: Welche Vereinbarungen werden im Kontext von (container-)virtualisierten Umgebungen getroffen und welcher rechtliche Rahmen ist dabei zu berücksichtigen? Zur Diskussion stehen hiernach die Modelle grosser Softwareanbieter auf dem Markt sowie die Probleme, die in der Praxis auftreten und die die Vorteile einer Virtualisierung nicht selten auch zunichtemachen können. Schliesslich soll die Wechselwirkung zwischen der urheberrechtlichen und der vertragsrechtlichen Ebene (5.) genauer betrachtet werden, da Lizenzvereinbarungen durchaus verschiedene Wirkungen zukommen können, was zu unterschiedlichen Rechtsfolgen führt. Auf dieser Basis ist zu untersuchen, welche Rechtsnatur die spezifischen Vereinbarungen im Bereich virtualisierter bzw. containerisierter Umgebungen haben und inwiefern sie auch unwirksam sein können.

Die Virtualisierung ist als zentraler Innovationsmotor aus dem heutigen Geschäftsleben nicht mehr wegzudenken. Die Virtualisierungswelle hat bereits Mitte der 60er-Jahren begonnen, als IBM Versuchssysteme zur virtuellen Speicherverwaltung entwickelte und somit die Grundlagen für ein hardwareunabhängigeres Design von Rechnersystemen legte. Es gibt keine allgemeingültige Definition des Virtualisierungsbegriffs.¹ In der Informatik ist mit Virtualisierung prinzipiell die Abstraktion einer (physikalischen) Ressource (z.B. Prozessoren, Speicher, etc.) mithilfe eines Stückes Software gemeint.² Neben physikalischen Einheiten können auch Softwareobjekte abstrahiert werden.³ Für die unterschiedlichen Anwendungsszenarien wurden fortlaufend viele verschiedene Technologien, Produkte und Geschäftsmodelle entwickelt.⁴ Es braucht dabei immer ein Hostsystem, welches als Basis für die virtuellen Komponenten dient und sodann mit Guests, also mit virtuellen Gastsystemen bestückt wird.⁵ Im allgemeinen Sprachgebrauch wird mit der Virtualisierung meist die herkömmliche Hardware-Virtualisierung gemeint, bei welcher physikalische Computer zu virtuellen Maschinen (sog. VM), abstrahiert werden.⁶

Abbildung 1: System ohne Virtualisierung⁷

Abbildung 2: System mit Virtualisierung (Hardwarevirtualisierung)⁸

Die Mehrheit der virtuellen Systemumgebungen haben den gleichen Zweck: vorhandene Systemressourcen effizient und sicher nutzen.⁹ Ursprüngliche Serversysteme verbrauchten viel Strom und Platz, waren aber alles andere als ausgelastet und zudem auch nicht kostengünstig in der Anschaffung. Dank hocheffizienter Virtualisierungstechnologie kann heutzutage über nahezu 100 % der Ressourcen leistungsfähiger Hardware verfügt werden. Als Teil von Green IT trägt die Virtualisierung dank Stromeinsparung zur Verbesserung der Energieffizienz bei und reduziert die weltweite Hardwareproduktion.¹⁰ Von Vorteil ist auch die Steigerung der Verfügbarkeit von Systemen durch deren einfache Wiederherstellung oder Verschiebung.¹¹

Generell wird zwischen den Gebieten der Hard- und Software-Virtualisierung unterschieden. Erstere stellt virtuelle Hardware-Ressourcen (z.B. CPU oder Speicher) bereit, zweite hingegen Anwendungen oder Betriebssysteme.¹² Die Hardware-Virtualisierung findet hauptsächlich im Serverbereich Einsatz. Zugleich ist dieses Konzept auch auf den Gebieten der Speicher- und der Netzwerkvirtualisierung verbreitet, welche in dieser Arbeit nicht weiter berücksichtigt werden.¹³ Die Hardware-Virtualisierung ermöglicht auf einem «echten Rechner» das gleichzeitige Betreiben mehrerer virtuellen Maschinen, die sich die Ressourcen teilen.¹⁴ Die dabei angewendete Technologie und logische Schicht zwischen Host- und virtuellem Gastsystem nennt sich Hypervisor bzw. Virtual Machine Monitor.¹⁵ Dabei wird zwischen zwei Typen unterschieden: solchen, die direkt auf der Hardware – also bare metal – laufen und solchen, die als Applikation innerhalb eines Betriebssystem agieren.¹⁶ Dem virtuellen System wird durch den Hypervisor vorgetäuscht, es sei der alleinige Nutzer der Hardware-Ressourcen.¹⁷

Klassische Einsatzfelder der Software-Virtualisierung sind die Desktop- (auch Präsentations-) sowie die Anwendungsvirtualisierung. Bei der erstgenannten wird üblicherweise mittels thin clients auf den Desktop oder auf Anwendungen eines entfernten Servers zugegriffen (auch Terminal Computing genannt).¹⁸ Für die folgende Darstellung zentral ist jedoch vor allem die Anwendungsvirtualisierung. Deren Ziel ist die Vermeidung von Konflikten zwischen Anwendungen untereinander oder zwischen Anwendung und Betriebssystem.¹⁹ Während dies traditionell u.a. durch Techniken wie Streaming erreicht wurde, erfolgt die Umsetzung heutzutage auch mittels virtueller Isolation durch die folglich relevante Containerisierung von Applikationen (dazu Kap. 2.2.). Zudem ist es auch möglich, beide Ansätze zu kombinieren.²⁰

Gängige Hypervisor-Technologien wurden in den letzten Jahren fortlaufend durch neue Virtualisierungsansätze auf Betriebssystemebene verdrängt bzw. ergänzt. Im Vordergrund steht dabei die leichtgewichtigere Container-Virtualisierung.²¹ Man spricht in diesem Zusammenhang nicht mehr von virtuellen Maschinen, sondern von Containern oder Jails. Bei Containern handelt es sich um voneinander abgetrennte Laufzeitumgebungen, die sich den gleichen Betriebssystemkern (Kernel) teilen. Die darauf laufenden einzelnen Applikationen wissen nichts von den anderen Containern oder deren Ressourcen.²²

Abbildung 3: Container-basierte Virtualisierung²³

Durch die Mitbenutzung des Betriebssystemkernels des Hosts können Systemressouren wie Prozessor, Netzwerk oder Speicher effizient genutzt werden und Applikationen über Systeme hinweg verschoben werden, ohne dabei das komplette Betriebssystem mit zu migrieren.²⁴ Verbreitete Containertechnologien sind z.B. Linux Containers (LXC), Docker, Rocket (rkt) oder OpenVZ, wobei Docker am meisten verbreitet ist. Insbesondere der Cloud-Computing-Markt wurde durch das Aufkommen der Container-Virtualisierung stark geprägt.²⁵ Aufgrund der unterschiedlichen Ausgestaltung und Anwendung können die Containerprodukte weiter in application containers und system containers unterteilt werden. Applikations-Container (z.B. Docker und rkt) erwirken die Abkapselung einer einzigen Anwendung oder eines Prozesses in einem container image.²⁶ Mit Docker kann man Applikationen und all deren Abhängigkeiten (Bibliotheken, Hilfsprogramme und Konfigurationsdateien) in einen Container packen.²⁷ Die extreme Simplifizierung einer Anwendung birgt vor allem bei Mikroservice-Architekturen grosse Vorteile. Systemcontainer (z.B. LXC oder OpenVZ) stellen dagegen ähnlich wie virtuelle Maschinen ein vollwertiges Betriebssystem bereit.²⁸ Innovative und cloudbasierte Anwendungen können durch Container auf eine agile und kosteneffiziente Weise umgesetzt, ausgeliefert und gewartet werden.²⁹

Der Hauptunterschied zwischen den beiden Virtualisierungslösungen liegt beim Betriebssystemkern.³⁰ Container nutzen alle denselben Kernel und das bestehende Betriebssystem wird lediglich modifiziert, um weitere Isolation bereitzustellen, während bei Hypervisor-Technologien ein oder mehrere vollständige Gast-Betriebssysteme betrieben werden.³¹ Abbildung 4 soll beide Architekturen illustrieren.

Abbildung 4: Vergleich der beiden Architekturen (virtuelle Maschine und Container)³²

Im Gegensatz zu Containern, die sich das Betriebssystem teilen, benutzen virtuelle Maschinen eine Ebene weiter unten dieselbe physische Hardware.³³ Ein Hypervisor betreibt oft verschiedene Host-Betriebssysteme und benötigt grosse Mengen an Hardware-Ressourcen.³⁴ Der Hypervisor fällt bei Containern weg, wodurch ein geringerer Management-Aufwand verursacht wird. Der reduzierte Overhead ermöglicht den Betrieb einer grösseren Anzahl von Anwendungen als dies bei virtuellen Maschinen möglich ist.³⁵ Ausserdem sind Container um Einiges performanter, denn sie brauchen weniger Speicherressourcen und lassen sich schneller starten als virtuelle Maschinen.³⁶ Als schwieriger erweist sich die zuverlässige Isolation der Container voneinander, was zu schwerwiegenden Sicherheitslücken führen kann.³⁷ Beide Virtualisierungsansätze bezwecken Portabilität und Isolation sowie Nutzungsoptimierung der Hardware-Ressourcen, sind aber für unterschiedliche Anwendungsfälle geeignet.³⁸ Ausserdem ist auch eine Kombination möglich, was insbesondere in Cloud-Umgebungen nicht selten vorkommt, aber letztendlich trotzdem wieder unnötigen Overhead generiert und redundant ist betreffend die Performanz.³⁹ Je nach Cloud-Typ eignen sich Container (v.a. bei Private Clouds) oder virtuelle Maschinen besser.⁴⁰

Auf urheberrechtlicher Ebene stellt sich die Frage, wie der Einsatz eines urheberrechtlich geschützten Computerprogramms in virtualisierten Umgebungen zu beurteilen ist. Wie weit gehen die Ausschliesslichkeitsrechte des Urhebers und in welchen Fällen schränken gesetzliche Gebrauchsrechte des Erwerbers diese ein?

Im Folgenden wird primär auf den urheberrechtlichen Schutz in der Schweiz Bezug genommen, dessen rechtliche Grundlagen vor allem das URG und die URV bilden. Weiteren Schutz bieten die Sonderbestimmungen über Computerprogramme in Art. 10 Ziff. 1 und Art. 11 des TRIPS-Abkommens sowie Art. 4 und 7 des WIPO-Urheberrechtsvertrags.⁴¹ Für die Auslegung des URG ist ausserdem die Softwareschutz-Richtlinie⁴² bedeutsam, da der schweizerische Gesetzgeber sich an dieser orientiert hatte.⁴³ Erwähnenswert ist, dass auch das Patent-, Design- und das Lauterkeitsrecht Computerprogrammen in gewissen Fällen Schutz bieten.⁴⁴

Zu den Schutzgegenständen des URG gehören grundsätzlich Werke der Literatur und Kunst gemäss Art. 2 Abs. 1 URG, die sodann in Abs. 2 beispielhaft aufgeführt werden (literarische, musikalische Werke etc.). Der nachfolgende Abs. 3 gewährt auch Computerprogrammen urheberrechtlichen Schutz, indem diese im Sinne des Gesetzes als Werke angesehen werden. Im Gesetz finden sich zahlreiche weitere Sonderbestimmungen zu Computerprogrammen, da die generell geltenden Regeln, welche ursprünglich auf Schriftsteller, Künstler etc. zugeschnitten worden waren, sich vielfach als ungeeignet erwiesen.⁴⁵

Computerprogramme umfassen alle in einer Programmiersprache verfassten vollständigen Verfahren zur Lösung einer bestimmten Aufgabe. Schutz geniessen der Quellcode und der Objektcode.⁴⁶ Die allgemeinen urheberrechtlichen Schutzvoraussetzungen sind gleichermassen auch beim Schutz von Computerprogrammen zu erfüllen. Es muss sich also gemäss Art. 2 Abs. 1 URG um eine geistige Schöpfung handeln, die über einen individuellen Charakter verfügt.⁴⁷ Der vorgegebene Zweck lässt bei der Programmierung je nach Aufgabenstellung oft nicht allzu grossen Gestaltungsspielraum zu, weshalb nach h.L. keine hohen Anforderungen an die Individualität zu stellen sind.⁴⁸ Das zweite Schutzkriterium, das Vorliegen einer geistigen Schöpfung, ist dann erfüllt, wenn es sich um ein von Menschen entwickeltes Computerprogramm handelt.⁴⁹ Nach dem Schöpferprinzip, dem das URG folgt, ist der Inhaber der Rechte gemäss Art. 6 URG grundsätzlich der Urheber, d.h. die natürliche Person, die das Werk geschaffen hat.⁵⁰ Der Schutzumfang ist gleichzustellen mit dem Umfang der Individualität. Bei einem Computerprogramm sind also alle Sequenzen einer oder mehreren Programmzeilen geschützt, die das Erfordernis der Individualität erfüllen.⁵¹

Was den Inhalt des Urheberrechts anbelangt, steht dem Rechtsinhaber ein umfassendes bzw. ausschliessliches Recht zu, über die Verwendung seines Werks zu entscheiden. Davon erfasst sind einerseits die nicht übertragbaren Urheberpersönlichkeitsrechte und die (in casu relevanten) frei übertragbaren Urhebervermögensrechte.⁵² Im Softwarebereich sind letztere in die folgenden selbständig verwertbaren ausschliesslichen Nutzungsrechte zu unterteilen: Vervielfältigungs-, Verbreitungs-, Vorführungs-, Bearbeitungs- und Vermietungsrechte.⁵³ Ebenfalls dazugezählt werden auch das Recht auf Dekompilation von Computerprogrammen und die Befugnis zur Nutzung innerhalb von Netzwerken, Software as a Service etc.⁵⁴ Die vorliegende Darstellung befasst sich vorwiegend mit dem Vervielfältigungsrecht nach Art. 10 Abs. 2 lit. a URG und daneben auch mit dem Änderungsrecht gemäss Art. 11 Abs. 1 URG.

Das Vervielfältigungsrecht (Recht zur Herstellung von Werkexemplaren) als wichtigste Einzelbefugnis erstreckt sich auf jede mögliche Art der Vervielfältigung, d.h. sowohl auf die Erstellung permanenter Kopien wie auch auf die Erstellung flüchtiger Kopien. Bei jeder Vervielfältigung, die nicht durch die bestimmungsgemässe Verwendung (dazu Kap. 3.2.2.) gedeckt wird, bedarf es der Zustimmung des Rechtsinhabers.⁵⁵

Weiter hat der Urheber auch das ausschliessliche Änderungs- bzw. Bearbeitungsrecht. Ihm steht zu, jegliche Änderungen seines Werks zu verbieten. Übliche Bearbeitungsarten bei Software sind die Übersetzung aus einer Programmiersprache in eine andere und die Wartung, welche in der Regel mit einer Änderung des Programms, insbesondere mit einer Fehlerkorrektur einhergeht.⁵⁶ Falls der Rechtsinhaber die notwendigen Programmänderungen zur Fehlerkorrektur nicht unter angemessenen Konditionen anbietet, ist der Erwerber dazu ggf. aus seinem Gebrauchsrecht berechtigt (dazu Kap. 3.2.2.).⁵⁷

Neben der im vorherigen Kapitel behandelten positiven Umschreibung der urheberrechtlichen Kontrollrechte enthält das Gesetz zwecks Ausgleich der vielfältigen Interessen der Softwarenutzer auch Schrankenregelungen, die die Kontrolle des Rechtsinhabers beschränken.⁵⁸ Die zentrale softwarerechtliche Schranke bildet das gesetzliche Gebrauchs- und Weiterveräusserungsrecht nach Art. 12 Abs. 2 URG.⁵⁹ Der rechtmässige Erwerber eines Computerprogramms hat demnach das Recht, das Werkexemplar zu gebrauchen und weiterzuveräussern. Die Tragweite dieses Artikels ist in der Lehre zum Teil umstritten.⁶⁰ In dieser Arbeit spielt Art. 12 Abs. 2 URG eine wichtige Rolle, da es u.a. vom Gebrauchsrecht abhängt, inwieweit der Erwerber die Software in virtualisierten Umgebungen einsetzen darf und in welchen Situationen der Urheber einschreiten darf. Weiter darf der Softwareerwerber zur Schaffung der Interoperabilität eines Programms gemäss Art. 21 URG i.V.m. Art. 17 Abs. 2 und 3 URV dessen Programmcode entschlüsseln und hat nach Art. 24 Abs. 2 URG das Recht, eine Sicherheitskopie herzustellen.⁶¹ Nach der weiteren Schrankenbestimmung in Art. 24a URG ist überdies die bloss flüchtige Kopie eines Werks erlaubt, wenn sie der rechtmässigen Nutzung dient und ihr keine eigenständige wirtschaftliche Bedeutung zukommt.⁶² Sonstige urheberrechtliche Schranken wie z.B. das Zitatrecht oder die Parodiefreiheit spielen im Softwarebereich eine untergeordnete Rolle.⁶³ Die im URG sonst geltenden Befugnisse des Erwerbers zum Eigengebrauch und zur Vermietung gelangen nach Art. 19 Abs. 4 URG und Art. 13 Abs. 4 URG bei Software nicht zu Anwendung.⁶⁴

Voraussetzung für die Anwendung von Art. 12 Abs. 2 URG ist die Erschöpfung.⁶⁵ Mit der Veräusserung des Werkexemplars oder der Zustimmung zu einer solchen verliert der Urheber das Verbreitungsrecht für das betreffende Exemplar, nicht aber das Urheberrecht. Es erschöpft sich also lediglich ein Element des Urheberrechts.⁶⁶ Dem Erwerber des Exemplars werden zwei Befugnisse zugestanden: einerseits das Recht auf Weiterveräusserung, welches vor allem beim Vertrieb von Gebrauchtsoftware wichtig ist, und anderseits das vorliegend entscheidende Gebrauchsrecht.⁶⁷ Es soll damit der Werkgenuss des Erwerbers abgesichert werden.⁶⁸ Anders als bei anderen Werkkategorien wird dem Softwareerwerber kein Recht auf Weitervermietung vermittelt.⁶⁹ Damit die Erschöpfung eines Programmexemplars eintritt, muss es mit der Zustimmung des Berechtigten veräussert werden.⁷⁰ Generell wird bejaht, dass die Regelung auch bei online übertragener Software greift.⁷¹ Nicht bei allen Software-Übertragungen ist das Merkmal der Veräusserung erfüllt (zum Softwareüberlassungsvertrag Kap. 4.1.1.). Der Veräusserungsbegriff von Art. 12 Abs. 2 URG ist mit demjenigen des Obligationen- oder Sachenrechts nicht deckungsgleich, sondern geht weiter.⁷² Ausschlaggebend ist das definitive Entlassen der Programmkopien aus dem Herrschaftsbereich des Rechtsinhabers zum zeitlich unlimitierten Gebrauch. Ferner ist die Kopie gegen Einmalentgelt, ggf. Ratenzahlungen oder gratis zu überlassen.⁷³ Demgemäss findet das Gebrauchs- und Weiterveräusserungsrecht auch auf Softwareüberlassungen auf Dauer (sog. unechte Lizenzen) Anwendung. Nicht anwendbar ist dies nach h.L. bei Softwareüberlassungen auf Zeit (sog. echte Lizenzen), bei welchen wiederkehrende Nutzungsgebühren die Norm sind und somit mangels Veräusserung keine Erschöpfung eintritt.⁷⁴ Eine andere Ansicht vertritt Rauber, welcher beim Gebrauchsrecht den Anwendungsbereich auch auf echte Lizenzen ausdehnen möchte, da in Art. 5 Abs. 1 der Softwareschutz-RL klar auch die zeitlich limitierte Überlassung als Anwendungsfall konstituiert wird und beim Gebrauchsrecht nicht an die Erschöpfung angeknüpft wird.⁷⁵ Diese Arbeit folgt jedoch der h.L. und konzentriert sich nur auf die Vereinbarungen zur Softwareüberlassung auf Dauer (Kap. 4.).

Um den Umfang der gesetzlichen Gebrauchsbefugnis zu eruieren, ist eine Interessenabwägung zwischen den Interessen des Erwerbers und denjenigen des Rechtsinhabers vorzunehmen.⁷⁶ Anders als bei der «Konsumierung» anderer Werke ist der Softwareerwerber auf gewisse zum Gebrauch notwendige Kopiervorgänge angewiesen.⁷⁷ Art. 12 Abs. 2 URG äussert sich nicht konkret zum sachlichen Umfang (bspw. wie viele virtuelle Kopien gleichzeitig im System genutzt werden dürfen).⁷⁸ Massgebend für dessen Bestimmung ist in erster Linie der Softwarelizenzvertrag zwischen Rechtsinhaber und Ersterwerber.⁷⁹ Zu berücksichtigende Faktoren sind der Vertragsinhalt und die Vertragsumstände, die Charakteristika und Beschreibung der Software wie auch Branchenusanzen und die in Art. 17 URV aufgezählten Nutzungshandlungen, die als Mindestinhalt dienen.⁸⁰ Fehlen spezifische Regelungen im Softwarevertrag, sind die Präzisierungen in Art. 17 Abs. 1 lit. a URV zu beachten, die die Umsetzung der Softwareschutz-RL⁸¹ bezwecken und das Laden, Anzeigen, Ablaufenlassen, Übertragen oder Speichern sowie die Herstellung dafür erforderlicher Kopien als bestimmungsgemässe Verwendung eines Programms bezeichnen.⁸² Dazu gehört insbesondere die zum Gebrauch notwendige Vervielfältigung im Arbeitsspeicher.⁸³ Vertragliche Nutzungsbeschränkungen müssen mit urheberrechtlicher Wirkung ausgestattet sein, um das Gebrauchsrecht zu definieren und damit auch für alle nachfolgenden Erwerber bindend zu sein.⁸⁴ Dem gesetzlichen Gebrauchs- und Weiterveräusserungsrecht wird zudem ein zwingender Kerngehalt zugeschrieben, welcher vertraglich nicht einschränkbar ist.⁸⁵ Neben Vervielfältigungen soll das Gebrauchsrecht, obwohl dies in Art. 17 Abs. 1 lit. a URV nicht explizit erwähnt wird, ebenfalls ein Recht auf Bearbeitung der Software im Rahmen des bestimmungsmässen Gebrauchs vermitteln, zumal auch Art. 5 Abs. 1 i.V.m. Art. 4 lit. b der Softwareschutz-RL ein solches vermittelt.⁸⁶ Das setzt voraus, dass die Änderungen zur bestimmungsgemässen Verwendung des Programms notwendig sind, was nicht der Fall ist, wenn der Rechtsinhaber die Fehlerbehebung zu angemessenen Konditionen anbietet.⁸⁷

Art. 12 Abs. 2 URG kommt vor allem dann zur Anwendung, wenn kein direkter Vertrag zwischen Rechtsinhaber und Programmerwerber vorliegt (bspw. bei nicht rechtsgültig akzeptierten AGB) oder einer vorliegt, dieser sich aber aus anderen Gründen nicht als wirksam herausstellt.⁸⁸ Ausserdem kommt es auch oft vor, dass in den wirksamen Verträgen konkrete Regelungen zur Virtualisierungsproblematik fehlen, was ebenfalls zu einer Anwendung von besagtem Artikel führt. Es ist konkret zu klären, ob und in welchem Umfang der Softwareerwerber bei fehlender oder fehlender zusätzlicher Vereinbarung zum Einsatz der Software in containerisierten bzw. virtualisierten Umgebungen berechtigt ist. Braucht es bei den Nutzungen im Zusammenhang mit dem typischen Betrieb von containerisierter Software eine Erlaubnis des Rechtsinhabers, womit eine gesonderte Lizenzpflicht bestünde oder kann sich der Erwerber auf die gesetzliche Gebrauchsbefugnis berufen? Wie weit der bestimmungsgemässe Gebrauch geht, ist immer anhand des konkreten Falls zu ermitteln.⁸⁹

Zuerst zu beurteilen ist das blosse Ablaufenlassen einer Anwendung in einem Container. Container stellen eine stabile Laufzeitumgebung für eine Software bereit, da wie gesagt das Programm samt benötigter Abhängigkeiten zur Laufzeit integriert werden kann. Die reine Installation einer Anwendung in einem Container oder in einer virtuellen Maschine unterscheidet sich nicht im Wesentlichen von der direkten Installation auf einem physischen Rechner. Physikalische und virtuelle Server sind aus wirtschaftlich funktionaler Sicht äquivalent.⁹⁰ Wenn im Lizenzierungsumfeld von einer «Instanz» gesprochen wird, ist dieser Begriff gleichzustellen mit der virtuellen Maschine selbst (bzw. deren Betriebssystem) oder mit dem Container.⁹¹ Die Ausführung der Anwendung in Docker und seinen Pendants deckt sich mit dem in Art. 17 Abs. 1 lit. a URV definierten Ablaufenlassen eines Programms. Vorliegend geht es um den Betrieb einer einzigen Programmkopie im Container (analog in einer virtuellen Maschine), bei welchem es zu einer urheberrechtlichen Vervielfältigung im Arbeitsspeicher kommt, die aber für den Gebrauch notwendig ist und somit von Art. 12 Abs. 2 URG umfasst wird.⁹² Es fehlt an einer wirtschaftlich eigenständigen Bedeutung der Nutzung in virtualisierten Systemen, die eine gesonderte Lizenzierung dafür rechtfertigen würde.⁹³ Es wird schliesslich nach wie vor nur eine Kopie genutzt und darüber hinaus werden auch keine neuen Nutzerkreise erschlossen. Allein der Umstand, dass auch nicht speziell dafür konzipierte Programme in einer virtuellen Umgebung betrieben werden, deutet auf eine fehlende eigenständige Nutzungsart hin.⁹⁴ Straub und auch Fröhlich-Bleuler gehen davon aus, dass im Zweifel von einer Erlaubnis dazu auszugehen ist, sofern keine Beschränkungen auf bestimmte Technologien vorliegen.⁹⁵ Ob das allgemeine Ablaufenlassen einer Kopie in virtualisierten Umgebungen dem Kerngehalt des Gebrauchsrechts zuzuordnen ist, ist in der Lehre umstritten (dazu Kap. 5.3.1.).⁹⁶

Oftmals stellen Anbieter ihre Software ihrerseits gleichzeitig auch als Container bereit in Form einer Downloadversion auf Plattformen wie z.B. Docker Hub. Docker Hub ist ein Onlinedienst, welcher eine Registry für Docker-Images und Repositories zur Verfügung stellt. Nutzer können dort selbst erstellte Images hochladen, öffentlich und auch nicht-öffentlich, d.h. nur für einen bestimmten Adressatenkreis.⁹⁷ Die Bereitstellung deutet darauf hin, dass die Containerisierung einer Anwendung bereits durch die Beschreibung und die Charakteristika der Software vorgesehen und somit als bestimmungsgemässe Verwendung zu qualifizieren ist. Dabei handelt es sich um weitere Vertragsumstände, die auf den bestimmungsgemässen Gebrauch hinweisen. Das blosse Ablaufenlassen einer einzigen Programmkopie im Container und allgemein in virtualisierten Umgebungen braucht also keine explizite Erlaubnis und ist nicht gesondert lizenzpflichtig.

In der Praxis kommt es selten vor, dass nur eine einzige Containerinstanz mit der betreffenden Programmkopie im Einsatz ist, gehören doch gerade die Skalierung und die Hochverfügbarkeit zu den grössten Vorteilen der Container-Technologie und der Virtualisierung. Meist betreibt man ein Set-Up mit zahlreichen Containern und Hosts, ein sog. «Container-Cluster». Skalierbarkeit und Redundanz sind im Bereich der Container nur im Zusammenspiel mit Orchestrierungswerkzeugen wie Kubernetes, Docker Swarm etc. erreichbar. Bei Problemen mit einem Server oder Container übernimmt ein anderer Node (virtuelle oder physische Ressource für Container) blitzschnell die notleidenden Workloads.⁹⁸ Container sind vergleichsweise noch skalierbarer als virtuelle Maschinen. Es ist einfacher, sie zu installieren und zu starten.⁹⁹ Bei Kubernetes bspw. sollen immer hinreichend viele Container für den durchgängigen und reibungslosen Betrieb zur Verfügung stehen, dies auch auf verschiedenen Servern, um die Ausfallsicherheit zu gewährleisten. Es ist möglich und sogar oft der Fall, dass Container in Private oder Public Clouds betrieben werden.¹⁰⁰ Auf die Einzelheiten der Clouds wird aufgrund des ausufernden Themenbereichs nicht weiter eingegangen. Betreffend die urheberrechtlich relevanten Vervielfältigungen vertritt die h.L. die Ansicht, dass bereits eine Parallelinstallation urheberrechtlich unzulässig sei.¹⁰¹ Dafür spricht die enge Umschreibung des gesetzlichen Gebrauchsrechts. Folglich müsste eine parallele Installation, wie sie in redundanten Systemen üblich ist, ausdrücklich vereinbart werden, auch wenn keine zeitgleiche Nutzung erfolgt.¹⁰² Fröhlich-Bleuler ist der Meinung, dass wenn die Mehrfachinstallation des Programms für den bestimmungsgemässen Gebrauch aus technischen Gründen erfolgt, wie es bei der Spiegelung des EDV-Systems zur Erhöhung der Verfügbarkeit zutrifft, dies zum gesetzlich erlaubten Gebrauch zähle.¹⁰³ Eine andere Lehrmeinung geht davon aus, dass die mehrfache Installation auf dem Computer allein noch keine Parallelnutzung darstelle, sondern erst das Ausführen des Programms wirtschaftlich relevant sei. Gemäss dem Prinzip der «sequentiellen Singulärnutzung» dürfe die Programmkopie auf unterschiedlichen Maschinen im Einsatz sein, jedoch nur sequentiell, d.h. nicht gleichzeitig.¹⁰⁴ Einigkeit besteht darin, dass beim parallelen Einsatz mehrerer Programmkopien auf einer oder unterschiedlichen Maschinen die Zustimmung des Rechtsinhabers erforderlich ist.¹⁰⁵ Die Nutzung in mehreren Instanzen führt dazu, dass die Software zumindest teilweise mehrfach im Arbeitsspeicher vorhanden ist.¹⁰⁶ Nur der Rechtsinhaber ist dazu berechtigt, die zeitgleiche Mehrfachnutzung des Computerprogramms in Containern wie auch in virtuellen Maschinen zu erlauben und vorzugeben, bis zu welcher Anzahl von Instanzen seine Software lizenziert werden soll, wobei bei Fehlen einer weitergehenden Erlaubnis die Instanzenanzahl auf diese vorgegebene Anzahl beschränkt ist.¹⁰⁷ Das mehrfache Betreiben einer Software in einer virtuellen Umgebung gehört ohne weitere Vereinbarung nicht mehr zum bestimmungsgemässen Gebrauch nach Art. 12 Abs. 2 URG. Dem Rechtsinhaber könnten sonst potenziell Einnahmemöglichkeiten verloren gehen.¹⁰⁸ Berücksichtigt man das Prinzip der sequentiellen Singulärnutzung, könnten mehrere Container mit der gleichen Konfiguration (inkl. Programmkopie) parallel erstellt werden, aber nur einer dürfte ohne weitere Vereinbarung tatsächlich in Betrieb sein. In der Praxis spielt es eine untergeordnete Rolle, welcher Ansicht gefolgt wird, da bei Container-Umgebungen die Gefahr einer Übernutzung erheblich ist, weshalb die mehrfache Installation oft vertraglich eingeschränkt oder zusätzlich vergütet wird. Die genannten Orchestrierungslösungen können helfen, unerlaubte Mehrfachnutzungen ausfindig zu machen und sie zu verhindern, denn sie koordinieren den Containerbetrieb. Parallele Nutzungen erfolgen in der Praxis oft unabsichtlich.

Es ist fraglich, wie es sich mit virtuellen Umgebungen verhält, die als Sicherungskopie gespeichert werden, um sie bei Nutzungsverlusten abzurufen. Art. 24 Abs. 2 URG statuiert grundsätzlich die zwingende Erlaubnis zur Herstellung einer Sicherungskopie des Computerprogramms. Gemäss h.L. handelt es sich hier um einen Anwendungsfall des gesetzlichen Gebrauchsrechts, welcher zwar bei Software-Überlassungen auf Dauer gelten soll, nicht aber bei echten Lizenzen.¹⁰⁹ Dem Anwender sollte das Recht zustehen, seine Sicherheitsarchitektur selbst zu definieren und zu implementieren.¹¹⁰ Das kann je nachdem bedeuten, dass auch mehrere Sicherungskopien hergestellt werden dürfen, was entweder durch eine weite Auslegung von Art. 24 Abs. 2 URG oder durch den bestimmungsgemässen Gebrauch gedeckt ist.¹¹¹ Der Anwender muss jedoch aufpassen, dass die überlassene Software durch die Sicherheitsarchitektur nicht übernutzt wird.¹¹² Zu berücksichtigen sind Partizipations-, Kontroll- und Geheimhaltungsinteressen des Urhebers.¹¹³ Erlaubt ist das Sichern der gesamten Installation einer virtuellen Maschine als Backup, bei welchem nicht zwischen Daten und Software unterschieden wird, d.h. Softwarekomponenten automatisch mitgesichert werden.¹¹⁴ Bei echten Backups, die erst später zur Nutzung zurückgespielt werden, stellt das kein Problem dar, denn die Gefahr einer parallelen Nutzung besteht nicht.¹¹⁵ Derartige Backups sind vorwiegend bei virtuellen Maschinen relevant, deren gesamte Konfiguration gesichert wird. Container können zwar auch Sicherungszwecken dienen, doch wäre hier eher von einer warm oder hot-Standby-Situation auszugehen. Dabei installiert der Anwender die Sicherungskopie je Software bereits auf einem Ausweich-Rechner (oder in diesem Fall Container) und fährt sie im Notfall hoch (warmes Backup) oder behält sie dauernd in paralleler, synchroner Bereitschafts-Verfügung bereit (heisses Backup).¹¹⁶ Sicherungskopien auf solchen Standby-Systemen sind nicht mehr vom gesetzlichen Privileg gedeckt, da es in diesem Fall nicht bloss um die Sicherung der Daten geht, sondern auch um eine Leistungsverbesserung.¹¹⁷ Der Hersteller wird auch kaum dazu fähig sein, zu prüfen, ob die Software wirklich als Backup oder eher parallel genutzt wird. Dasselbe gilt für Kopien, die im Netzwerk gespeichert werden und jederzeit zum Gebrauch bereitstehen, denn sie bringen eine hohe Gefahr der operativen Nutzung mit sich.¹¹⁸ Eine Version liegt auch «heiss» vor, wenn sie virtuell an einem anderen Ort vorfindbar ist, beim Backup in der Cloud etwa.¹¹⁹ Für solche vom Gebrauchsrecht nicht gedeckte Situationen wären gesonderte Lizenzen erforderlich. Handelt es sich jedoch um eine technische Modalität und müssen die Anwendungen notwendigerweise ständig verfügbar sein (bspw. bei einer Handelssoftware bei Banken) kann das aktive, permanente Vorhalten im Rahmen von Hochverfügbarkeits-Clustern durchaus als bestimmungsgemäss gelten.¹²⁰

Eine weitere relevante Nutzungshandlung im Zusammenhang mit der Container-Virtualisierung ist die Modifikation bzw. Bearbeitung von Software. Je nach Technologie beinhaltet ein Container mehrere Layer. Dateien auf einem Layer lassen sich ausblenden, ergänzen oder überlagern, was als Bearbeitung im lizenzrechtlichen Kontext zu verstehen ist.¹²¹ Um die Grösse und den Ressourcenbedarf eines Containers noch mehr zu reduzieren, werden nicht betriebsrelevante Informationen der containerisierten Software gelegentlich bewusst entfernt, z.B. Logos, Dokumentation oder gar Programmteile wie nicht verwendete Treiber/Module. Dieses «Entschlacken», welches in der Praxis vorkommt, gilt auch als Modifikation und stellt eine ggf. unerlaubte Nutzungshandlung dar. Obwohl in Art. 17 Abs. 1 lit. a URV nicht erwähnt, gehört auch ein Bearbeitungs- und Fehlerbehebungsrecht zum bestimmungsgemässen Gebrauch, insofern dazu Notwendigkeit vorliegt.¹²² Dazu gehören bspw. die Behebung blockierender Fehler oder die Anpassung von Installationsskripten.¹²³ Somit bleibt dem Softwareerwerber mangels anderer vertraglicher Absprache lediglich das Recht, die Software bei entsprechender Notwendigkeit für die Installation in einem Container zu «modifizieren». Nicht vom Gebrauchsrecht umfasst sind Anpassungen des Programms an individuelle Bedürfnisse, Programmerweiterungen- oder verbesserungen.¹²⁴ Auf diese Punkte ist bei Modifikationen im Kontext des Containereinsatzes acht zu geben.

Nachdem soeben der Umfang des gesetzlichen Gebrauchsrechts erläutert und die Situation bei fehlenden vertraglichen Regelungen bezüglich des Softwareeinsatzes in containerisierten bzw. generell virtualisierten Umgebungen untersucht worden ist, soll es nun um die Situation bei Vorliegen vertraglicher Bestimmungen gehen. Vorab sind einige Ausführungen zur strittigen Qualifikation des Softwareüberlassungsvertrags und dessen rechtlichen Rahmen vorzunehmen. Danach werden Lizenzformen und spezifische Lizenzklauseln, die sich auf den Softwareeinsatz in (container-)virtualisierten Systeme beziehen anhand der Regelwerke bestimmter Softwareanbieter thematisiert. Durch diese beispielhaften Vereinbarungen sollen auch deren Probleme in der IT-Praxis, insb. im Lizenzmanagement verdeutlicht werden.

Das Gebiet der Softwareüberlassung zeichnet sich durch eine Vielfalt möglicher Rechtsgeschäfte aus.¹²⁵ Dem Vertragspartner wird hierbei durch den Berechtigten das Recht zur Nutzung der Software eingeräumt, wobei die Qualifikation derartiger Verträge umstritten ist. Umgangssprachlich ist meist von einem «Softwarelizenzvertrag» die Rede, dessen Ausgestaltung unterschiedlich sein kann, was Auswirkungen auf die rechtliche Qualifikation hat.¹²⁶ Davon zu unterscheiden ist der Übergang absoluter Rechte am Immaterialgut, welcher beim Softwarelizenzvertrag als rein schuldrechtliche Konzeption nicht zutrifft.¹²⁷ Gemäss h.L. und Rechtsprechung handelt es sich beim (Software-)Lizenzvertrag um einen Innominatvertrag, welcher je nach Ausgestaltung miet- und pachtrechtliche, teilweise aber auch teilweise kauf- oder gesellschaftsrechtliche Elemente beinhalten kann.¹²⁸ Der Eingrenzung des Themas halber soll Gegenstand folgender Erläuterungen vor allem Standardsoftware sein, die auf Dauer überlassen wird. Beim Vertragsgegenstand handelt es sich demnach um Programme, die nicht speziell für den Anwender hergestellt werden.¹²⁹ Die Berücksichtigung der Überlassung von Individualsoftware, welche spezifisch auf die Bedürfnisse des Erwerbers zugeschnitten wird, würde den Rahmen dieser Arbeit sprengen, da es sich in diesem Falle i.d.R. um einen Werkvertrag handelt.¹³⁰ Eine weitere zentrale Weichenstellung liegt darin, dass zeitlich begrenzte Nutzungsrechte im Sinne der – bereits in Kap. 3.2.1. behandelten – «echten» Lizenz (vorherrschend bei Individualsoftware) im weiteren Verlauf ebenfalls nicht Thema sein werden. Bei solchen Konstellationen wird meist ein periodisches Entgelt entrichtet und das Element der Gebrauchsüberlassung überwiegt.¹³¹ Hierbei wären ggf. die Regeln der Miete oder diejenigen der Pacht anzuwenden.¹³² Nicht jeder Vertrag mit dem Titel «Softwarelizenz» bezieht sich aber auf die Gewährung einer «echten» Lizenz.¹³³ In der Lehre herrschen unterschiedliche Meinungen über die Rechtsnatur des vorliegend relevanten Vertrags zur Überlassung von Standardsoftware auf Dauer (auch: definitive Softwareüberlassung), bei welchem die Nutzungsbefugnis zeitlich unbeschränkt übertragen wird und der Vertragsgegenstand meist Standardsoftware darstellt.¹³⁴ Einige Autoren möchten darauf direkt oder zumindest analog Kaufvertragsrecht anwenden¹³⁵, andere beabsichtigen Kaufrecht anzuwenden, da das Rechtsgeschäft über das Werkexemplar einen Kaufvertrag darstelle¹³⁶ und wiederum eine dritte Meinung besagt, dass es sich um einen Lizenzvertrag¹³⁷ bzw. Innominatkontrakt handle, auf welchen die allgemeinen Bestimmungen des OR anzuwenden sind.¹³⁸ Nach der Ansicht der Autoren Straub und Fröhlich-Bleuler, welcher ich mich anschliesse, ist auf das Vertragsverhältnis Kaufrecht analog anzuwenden, wenn es sich beim Vertragsgegenstand um Standardsoftware handelt, die Nutzungsbefugnis auf Dauer erteilt wird und der Anwender für die Nutzung nur eine Einmal-Lizenzgebühr schuldet.¹³⁹ Straub braucht bei solchen Situationen den – bereits im Zusammenhang mit dem Anwendungsbereich des Gebrauchsrechts behandelten – Begriff des «unechten Lizenzvertrags».¹⁴⁰ Aufgrund dessen wird weiterhin von «Lizenzklauseln» oder «Lizenzbedingungen» die Rede sein, obwohl es sich aufgrund des fehlenden Dauerschuldverhältnisses eher um einen atypischen Lizenzvertrag handelt.¹⁴¹ Es ist letztendlich festzuhalten, dass bei dieser Konstellation nach Rechtsprechung und h.L. primär Kaufvertragsrecht angewendet wird, ungeachtet deren Qualifikation.¹⁴²

Softwarevertragliche Nutzungsvereinbarungen sind nur bei gültiger Vereinbarung wirksam, weshalb der rechtliche Rahmen zu berücksichtigen ist. Wenn AGB Vertragsbestandteil sein sollen, stellen sich bereits Konsensfragen. Weiter können der bisher nur angetönte zwingende Kern von Art. 12 Abs. 2 URG sowie kartell- und lauterkeitsrechtliche Schranken zu einer Unwirksamkeit oder Nichtigkeit führen. Auf die übrigen urheberrechtlichen Schranken bei Software wurde bereits eingegangen (Kap. 3.2.). Im weiteren Verlauf dieser Arbeit werden die kartellrechtlichen Bestimmungen nur am Rande behandelt.

Die h.L. in der Schweiz ordnet dem Gebrauchsrecht einen zwingenden Kern gemäss Art. 12 Abs. 2 URG i.V.m. Art. 17 Abs. 1 lit. a URV zu, welcher in Abweichung vom Grundsatz der Vertragsautonomie vertraglich nicht eingeschränkt werden kann.¹⁴³ Zwar hält Art. 12 Abs. 2 URG diesen nicht explizit fest, doch bei der Gesetzesauslegung ist die Softwareschutz-RL mitzuberücksichtigen, und diese enthält einen solchen Kerngehalt.¹⁴⁴ Dieser beinhaltet die mit der Installation verbundenen notwendigen Vervielfältigungen und Speicherungen sowie den operativen Lauf des Programms. Dasselbe gilt für Fehlerbehebungen, die die bestimmungsgemässe Nutzung des Programms sicherstellen, insofern der Rechtsinhaber selbst keine solche anbietet.¹⁴⁵ Der zwingende Kern von Art. 12 Abs. 2 URG stellt auf gebrauchsrechtlicher Ebene den minimalen Sockel dar, von welchem die Parteien auch auf vertraglicher Ebene nicht abweichen dürfen.¹⁴⁶ Vertragliche Einschränkungen, die gegen den zwingenden Kern verstossen, gelten als unwirksam.¹⁴⁷

Bei Vorliegen allgemeiner Lizenzbedingungen (oder: AGB), muss stets geprüft werden, ob diese überhaupt Vertragsbestandteil geworden sind. Vorausgesetzt ist ein Konsens zwischen den Vertragsparteien betreffend den Nutzungseinschränkungen.¹⁴⁸ Um ein direktes Vertragsverhältnis zum Endabnehmer, welcher die Software über Zwischenhändler erwirbt, herzustellen, bedienen sich Hersteller oft vorformulierter Allgemeiner Vertragsbedingungen (End User License Agreements, EULA). Das Ziel ist die Einschränkung des Umfangs des Gebrauchsrechts und der Haftungsansprüche.¹⁴⁹ Entsprechende Bedingungen müssen aber, um vom Konsens umfasst und damit Vertragsbestandteil zu werden, vor dem Vertragsschluss zur Kenntnis genommen werden können. Dies trifft z.B. bei den sog. Shrink Wrap Licenses nicht zu, denn die Nutzungsbedingungen können erst nach Softwarekauf durch das Öffnen der Schutzhülle (mittels Hinweis auf der Verpackung) zur Kenntnis genommen werden.¹⁵⁰ Konstellationen, bei welchen die EULA vor dem Eigentumserwerb (bspw. vor dem Download) akzeptiert werden, führen zu einer gültigen Vereinbarung.¹⁵¹ Containerspezifisch ist hierbei anzufügen, dass in der Praxis den EULA bereits durch integrierte Parameter im Ausführungsbefehl, den Container zu starten, zugestimmt wird. Inwieweit Vertragsbedingungen so tatsächlich gültig vereinbart werden ist fraglich und wird in casu offengelassen. Sind die vorformulierten Nutzungsbedingungen einmal gültig vereinbart worden, kann ggf. immer noch ein Anwendungsfall der Ungewöhnlichkeitsregel vorliegen. Demnach ist ein Erwerber nach Treu und Glauben nicht an global übernommene vorformulierte Vertragsbedingungen gebunden, bei welchen er zu seinen Ungunsten auf das verzichtet, worauf er sich vernünftigerweise verlassen darf.¹⁵² Davon ist bei Klauseln mit ungewöhnlichem Inhalt oder intransparenter Form auszugehen. Derartige Bestimmungen sind als nichtig zu qualifizieren.¹⁵³ Unter Umständen liegen in diesem Zusammenhang auch lauterkeitsrechtliche Verletzungen vor, dies einerseits bei irreführenden Inhalten in AGB nach der Generalklausel in Art. 2 UWG (praktisch von geringer Bedeutung) und bei missbräuchlichen Konditionen in Konsumentenverträgen nach Art. 8 UWG, welcher auch eine Inhaltskontrolle beinhaltet.¹⁵⁴ Im Gegensatz zur Schweiz, bildete sich in Deutschland eine detaillierte Lehre und Rechtsprechung zu AGB-rechtlich unwirksamen Nutzungsbeschränkungen und anderen Bestimmungen in Softwareüberlassungsverträgen. Hierzulande muss der Hinweis auf das Korrektiv bei ungewöhnlichen Nutzungsbeschränkungen genügen.¹⁵⁵

Das Gebiet der Container-Virtualisierung ist verhältnismässig jung und in der juristischen Lehre noch wenig behandelt. In der Praxis sind Lizenzmodelle häufig obsolet und noch auf physische Rechner ausgerichtet, m.a.W. noch nicht an dynamische virtualisierte Umgebungen angepasst.¹⁵⁶ Diese Problematik trifft bei Containern wie auch bei virtuellen Maschinen zu. Je nach Hersteller kann die Ausgestaltung der Lizenzen und v.a. deren Metrik, also die dazugehörigen Vergütungssysteme, stark variieren. Eine Systematisierung ist angesichts der stetigen technischen Entwicklung komplex.¹⁵⁷ In der Praxis erweisen sich Lizenzmodelle vielfach als extrem umfangreich und geradezu unübersichtlich.

Es gibt zahlreiche Lizenzformen mit unterschiedlichen – bspw. räumlichen, zeitlichen und inhaltlichen – Beschränkungsmöglichkeiten. Im Folgenden stehen inhaltliche Beschränkungen der Nutzungsrechte und Lizenzmetriken im Vordergrund.

Softwareüberlassungsverträge beinhalten oft Klauseln, die den Umfang der Nutzung klar festlegen. Nutzungsrechte an Software werden üblicherweise als Einfach- oder als Mehrfachlizenz eingeräumt. Bei ersterer erhält der Anwender das Recht, das Programm auf einem einzigen Computer zu nutzen, wohingegen bei der Mehrfachlizenz das Recht auf die gleichzeitige Nutzung auf mehreren Geräten eingeräumt wird.¹⁵⁸ Sie kann sich anstatt auf die Anzahl der Rechner auch auf die Anzahl der Anwender beziehen, die die Software gleichzeitig nutzen (Concurrent User).¹⁵⁹ Um allfällig komplexe hardwarebasierte Lizenzmetriken zu umgehen, entscheiden sich Anwender in der Praxis gelegentlich für das Named User Modell. Dabei wird die maximale Anzahl der Nutzer festgelegt und mit einem registrierten, namentlich eingetragenen Zugang auf das Programm ausgestattet.¹⁶⁰ Eine bekannte Zwischenform der Einfach- und Mehrfachlizenz ist die sog. Volumenlizenz, bei welcher mehrere Einfachlizenzen im Paket mit einem Volumenrabatt veräussert werden.¹⁶¹ Im Hinblick auf den Softwareeinsatz in virtualisierten Umgebungen stehen maschinenbezogene Einfach- und Mehrfachlizenzen im Vordergrund und es muss erörtert werden, wie Container (oder virtuelle Maschinen) einzuordnen sind. Einfach- und Mehrfachlizenzen gestatten mitunter den Einsatz des Programms auf einer bestimmten Höchstzahl von Rechnern. Virtuelle Maschinen sind indessen dazu fähig, komplette Rechner zu simulieren und somit hunderte von Betriebssystemen nebeneinander völlig unabhängig voneinander ablaufen zu lassen. Angesichts dieses technologischen Fortschritts stellt sich die Frage, wie eine solche Recheneinheit definiert werden soll, wobei die Qualifikation einer virtuellen Maschine als eigener Rechner oft vorherrschend ist.¹⁶² Bei den üblichen Applikationscontainern werden nicht mehrere Betriebssysteme nebeneinander betrieben, sondern es wird auf der Ebene des Betriebssystems für zusätzliche Isolation gesorgt. Besonders von Herstellern werden Containerinstanzen aber oft auch als eigene Rechner im Vertragssinne aufgefasst (Kap. 4.2.2.). In der Praxis erfolgt bei Containern – und analog auch bei virtuellen Maschinen – vielfach eine Lizenzierung nach der Zahl der Instanzen, auf denen die Applikation läuft. Die Instanzenanzahl definiert dann den Lizenzbedarf. Die Einzellizenz erfasst den Einsatz auf einer Instanz, während der Betrieb auf mehreren Instanzen gesondert lizenzpflichtig ist.¹⁶³

Um eine Nutzungsbeschränkung (und damit gelegentlich auch Vergütungsansprüche) an der Leistungsfähigkeit der Hardware auszurichten, bedienen sich Softwareanbieter seit jeher sog. «CPU-Klauseln», heutzutage vermehrt aber auch Klauseln, die auf eine bestimmte Anzahl Kerne in einer Mehrkern-CPU abstellen.¹⁶⁴ Mitunter ist der Übergang von der Begrenzung der Mehrfachnutzung hin zu einer Beschränkung der Nutzungsintensität fliessend.¹⁶⁵ Manche CPU-Lizenzen sind in der Praxis mit der Vergütungsregelung gekoppelt.¹⁶⁶ Die urheberrechtliche und insb. die schuldrechtliche Wirkung solcher Klauseln ist hierzulande – noch mehr aber in Deutschland¹⁶⁷ – umstritten (Kap. 5.3.2.).

Unter dem Begriff «CPU-Klauseln» versteht man Klauseln, die die Software-Nutzung an eine bestimmte Zentraleinheit der Hardware (Hauptspeicher und Prozessor¹⁶⁸) oder an eine bestimmte Prozessorfamilie binden.¹⁶⁹ Der deutsche Autor Marly ist der Ansicht, diese Bezeichnung sei unglücklich, da die jüngeren Mehrprozessorsysteme oder Mehrkern-CPUs einer Anbindung an lediglich eine CPU entgegenstehen und weil virtuelle Systeme keinen eigenen Prozessor haben, aber dennoch mitumfasst werden. Aus diesem Grund bevorzugt er den Begriff «Systemvereinbarungen».¹⁷⁰ Die Beschränkungen können konkreter oder abstrakter Natur sowie mit oder ohne Upgrade-Recht ausgestattet sein.¹⁷¹ Ein solches wird bei einem Wechsel auf eine Hardware mit höherer Ablaufgeschwindigkeit ausgeübt, unter der Bedingung einer zusätzlichen Lizenzgebühr.¹⁷² Ebenfalls unter den Überbegriff der «CPU-Klausel» fallen Beschränkungen der Softwarenutzung auf Systeme mit einer bestimmten Anzahl an Prozessoren oder Prozessorenkernen.^173,174 Modelle, die auf den Prozessor bzw. die Zahl der Prozessoren, Cores o.Ä. abstellen, nennt man auch «Prozessor-Modelle». Es werden damit nutzungsintensitätsabhängige Vergütungen erzielt.¹⁷⁵

Im Laufe der Zeit haben technische Innovationen bei solchen Bestimmungen zu Unklarheiten geführt. Systeme verfügen heutzutage meist über mehrere Prozessoren. In einen Prozessorchip können ausserdem seit 2005 auch mehrere Prozessorkerne integriert werden (sog. Mehrkernprozessoren, englisch Multicoreprocessors), um eine erhöhte Rechenleistung zu erreichen. Die dadurch erwünschte Steigerung der Leistungsfähigkeit einer Software hängt dann aber vor allem von deren Parallelisierungsgrad ab.¹⁷⁶ Ältere Lizenzgebührenmodelle stellten im Gegensatz zu heute oft auf die Anzahl der Prozessoren ab, ohne die Anzahl der Prozessorenkerne zu berücksichtigen.¹⁷⁷ Ist heute von «Prozessoren» die Rede, sind darunter im Zweifel die Prozessorchips und nicht die Prozessorkerne zu verstehen.¹⁷⁸ Stellt der Vertrag auf eine bestimmte Anzahl CPU ab, ohne eine spezifische Regelung zum Einsatz in virtualisierten Umgebungen zu enthalten, darf dem entsprechenden Programm im virtualisierten System nur so viel Prozessorleistung zustehen, wie es der Anzahl vertraglich definierter CPU entspricht. Den massgebenden Nutzungsanteil zu eruieren gestaltet sich in der Praxis schwierig, da virtualisierte Umgebungen dynamisch über mehrere Hardwareeinheiten verteilt werden.¹⁷⁹ Bei virtualisierten Umgebungen sind zudem oft virtuelle Prozessorkerne im Einsatz, auf welchen weitere Programme betrieben werden können. Manche Softwareanbieter beschränken die Nutzung ihrer Programme sowohl auf eine bestimmte Anzahl physischer als auch virtueller Prozessoren.¹⁸⁰ Ausserdem wird in Lizenzmodellen inzwischen auch nach sog. Hardwarethreads lizenziert, die den Besonderheiten von virtuellen Maschinen oder Containern Rechnung tragen (dazu Kap. 4.2.2.2.). Grundsätzlich ist immer fraglich, wie gut sich solche Lizenzmetriken für virtuelle Systeme eignen, denn diese benutzen die Hardware-Ressourcen zeitlich nur partiell, teilen sie mit weiteren «Guests» und werden ggf. zwischen den Servern hin- und hergeschoben oder je nach Bedarf gestartet. Sie nehmen allesamt nur einen Teil der verfügbaren Gesamtprozessorleistung in Anspruch und es wird ihnen keine eigene Hardware zugewiesen, denn sie laufen dynamisch auf mehreren physischen Einheiten.¹⁸¹ Es kann überdies sinnvoll sein, gleich die Gesamtheit aller physikalischen oder virtuellen Computer (analog auch Containerinstanzen) zu lizenzieren, was durch einige Anbieter mittels Cluster-Lizenzen angeboten wird.¹⁸² Cluster können unterschiedliche Zwecke verfolgen und deren Ausgestaltung variiert nach Hersteller. Teils resultiert die Höhe der Vergütung aus dem Umfang der Nutzungsintensität.¹⁸³

Softwareanbieter, die ihre Software in Online-Verzeichnissen wie «Docker Hub» anbieten, geben im besten Fall die spezifischen Lizenzbedingungen der containerisierten Software an, wobei es oft keine grossen Unterschiede zu den herkömmlichen Lizenzmetriken für virtuelle Maschinen gibt. Ein einheitliches, auf die Virtualisierung abgestimmtes und aus Kostenperspektive faires Modell hat sich noch nicht durchgesetzt. In der Softwarebranche wird momentan mit dem SaaS-Ansatz der Abrechnung nach tatsächlicher Softwarenutzung «pay per use» (auch «on demand») experimentiert, wobei die Nutzung in der Cloud erfolgt.¹⁸⁴ Beim CaaS-Ansatz bietet der Cloud-Provider sogar ganze Container-Infrastrukturen zur Nutzung an.¹⁸⁵ Aufgrund der starken Abweichung von der klassischen Softwareüberlassung und des begrenzten Umfangs dieser Arbeit wird vorliegend nicht weiter darauf eingegangen.

Als prominentes Beispiel für die instanzenbasierte Lizenzierung können die Lizenzbestimmungen von SQL Server 2019, einer bekannten Datenplattform aus dem Hause Microsoft, genannt werden. Die Standard Edition kann über Server- und Zugriffslizenzen lizenziert werden (Server+CAL licensing model), wobei es sich um Volumenlizenzen handelt. Beim Client/Server Modell geht es typischerweise darum, ein Nutzungsrecht anhand der technischen Definition der beteiligten Server und der Clients, auf welchen die Nutzer die Software nutzen, einzuräumen.¹⁸⁶ In casu benötigt jede Betriebssysteminstanz, egal ob physisch oder virtuell, auf welcher die SQL 2019 Standard Software läuft, eine Server-Lizenz. So steht in den Licensing Terms: «For Products under the Server/CAL License Model, customer may use one Running Instance of server software in either a Physical OSE or Virtual OSE on a Licensed Server for each License it acquires.»¹⁸⁷ Um den Einsatz von Containerlösungen zu regeln, werden diese einer virtuellen Betriebssysteminstanz gleichgestellt: «For purposes of licensing use of SQL Server software running within a container on a container runtime such as docker, cri-o or containerd, (i) a container is considered to be a Virtual OSE, […]».¹⁸⁸ Folglich braucht auch jeder Container eine Server-Lizenz. Der zusätzliche Licensing Guide von Microsoft zeigt zwar ausführlich die strukturellen Unterschiede einer virtuellen Machine und eines Containers auf, hält dann aber fest: «[…] Containers and virtual machines are structured differently, but they are considered the same from a licensing perspective.».¹⁸⁹ Demnach werden Container gleich wie virtuelle Maschinen behandelt, auch wenn sie nicht ein komplettes Betriebssystem virtualisieren. Es sind dann aber noch Zugriffslizenzen (Nutzer oder Gerät) nötig.¹⁹⁰ Die Hardware und die virtuellen Ressourcen können sodann ohne zusätzliche Kosten im Rahmen der Lizenzbestimmungen frei skaliert werden.¹⁹¹

Ein Beispiel für eine Einfachlizenz ist in den Lizenzbestimmungen vom kleineren Softwareanbieter ColorLogic zu finden, der im Bereich von Farbmanagement-Technologien entsprechende Lösungen anbietet. Dort steht explizit: «[…] Sie sind berechtigt, die Software auf nur einem Computer gleichzeitig zu benutzen. Virtuelle Maschinen und Docker-Container werden hierbei als separate Computer gewertet. […]».¹⁹² Docker-Container und virtuelle Maschinen werden einander wieder explizit gleichgestellt und als eigener Rechner definiert. Das Betreiben der Software ist demgemäss nur auf einer Container-Instanz bzw. einer Instanz einer virtuellen Maschine von der Einzellizenz erfasst. Je nach Anzahl Container kann eine Lizenzierung nach Containerinstanzen aus der Sicht des Anwenders ein teures Szenario darstellen. Bei der Lizenzierung von Instanzen gibt es verschiedene Möglichkeiten. Lizenzen können die Anzahl der Instanzen beschränken bzw. sich an ihnen orientieren oder auch für den Softwareeinsatz auf einem Server eine unbeschränkte Zahl von virtuellen Lizenzen vorsehen.¹⁹³ Eine rechtliche Einordnung folgt in Kap. 5.3.1.

Traditionelle Lizenzmodelle orientieren sich oft an Hardwarekomponenten und stossen beim Softwareeinsatz in virtuellen Umgebungen, sei es in virtuellen Maschinen oder auch in Containern, an ihre Grenzen. Bei den virtuellen Maschinen hat sich die Frage schon etwas früher, vor dem grossen Aufkommen der Container, gestellt. Einsparungen, die das Unternehmen durch Virtualisierungstechnologien erzielt hatte, wurden wieder ausgeglichen durch hohe Softwarekosten, welche durch herkömmliche Lizenzmodelle, die für die Preisbestimmung v.a. auf die Anzahl Prozessoren im virtuellen System abstellten, verursacht.¹⁹⁴

Oracle, einer der grössten Softwareanbieter, stellt ein breit ausgearbeitetes und verschachteltes Vertragswerk mit vielen verschiedenen AGB und Anlagen bereit. Bei softwarebasierenden virtuellen Maschinen wird von einer «Soft-Partitionierung» ausgegangen, da Ressourcen flexibel verteilt werden.¹⁹⁵ Oracle und andere Softwareanbieter sehen für den Fall der Applikationsvirtualisierung vor, dass ihre Anwendung für den gesamten Serververbund lizenziert wird und nicht nur für die Prozessoren, denen die Applikation zugewiesen ist.¹⁹⁶ Gängige Containerprodukte wie Docker sind ebenfalls nicht bei der «Hard-Partitionierung» aufgeführt, was e contrario bedeutet, dass auf der Basis einer «Soft-Partitionierung» lizenziert wird.¹⁹⁷ In der Oracle Partitioning Policy, welche definiert, unter welchen Konditionen Lizenzen verlangt werden, wird aufgeführt: «Once a container image (e.g. a Docker image) containing Oracle Programs has been pulled to a host, or to a Kubernetes node in a Kubernetes cluster, (either a virtual machine or a physical machine), that host or Kubernetes node must be licensed for the Oracle Programs for the number of processors on that host or Kubernetes node.».¹⁹⁸ Alle im Server vorhandenen physischen Prozessoren und deren Kerne müssen also lizenziert werden, unabhängig davon, wie viele Ressourcen die virtuelle Maschine (oder der Container) tatsächlich adressiert und nutzt.¹⁹⁹ Bei der Standard Edition²⁰⁰ bspw. benötigt man bei einem Virtualisierungs-Cluster, welcher aus fünf Servern mit je zwei Prozessoren besteht, zehn Lizenzen. Die Diskrepanz zwischen genutzter und zu lizenzierender Leistung kann erheblich sein.²⁰¹ Einige wenige Ausnahmen sind von diesem «Hardine-Approach» ausgenommen. Sobald aber die gesamte Infrastruktur lizenziert ist, kann eine unbeschränkte Anzahl an Containern in Betrieb genommen werden. Da oft zahlreiche Container – üblicherweise mehr als virtuelle Maschinen – in Betrieb sind, birgt diese Reglung je nach Situation auch Vorteile.²⁰²

Bei der Lizenzierung des SQL Servers 2019 (bereits behandelt für die Standardausgabe in Kap. 4.2.2.1.) entschied sich Microsoft bei der Enterpriseversion, welche sich eher an grössere Organisationen richtet, nach Prozessorkernen zu lizenzieren (Per-Core-Modell).²⁰³ Container werden auch bei der Core-Lizenzierung wieder den virtuellen Maschinen aus Lizenzierungsperspektive gleichstellt.²⁰⁴ Das Core-Lizenzmodell von Microsoft ermöglicht einerseits die maximale Virtualisierung, bei welcher u.U. das Ausführen einer unbegrenzten Anzahl an virtuellen Maschinen oder Containern erlaubt ist, wenn alle physischen Prozessorkerne des Hostservers lizenziert werden.²⁰⁵ Um nicht das ganze physische Cluster zu lizenzieren, können anderseits auch die individuellen Container oder die einzelnen virtuellen Maschinen lizenziert werden, dies gemäss den ihnen zugewiesenen v-Cores (oder v-CPUs, virtuelle Threads).²⁰⁶ Diese virtuellen Einheiten stellen – vereinfacht gesagt – die Pendants der physischen Einheiten in der virtualisierten Umgebung dar und werden tatsächlich aus time slots über alle physischen Cores gebildet.²⁰⁷ Bei Containern wird nicht nach v-Cores lizenziert, sondern nach Hardwarethreads: «[…] (ii) the Physical or Virtual Cores available to that container are considered to be Hardware Threads.»²⁰⁸, sodann: « […] If hyperthreading is enabled and Customer is licensing use under the Per Core License Model, Customer must assign a Core License for each Hardware Thread mapped to a container, subject to a minimum of four Licenses.»²⁰⁹. Ein Hardwarethread eines Cores bildet (aus Lizenzierungsperspektive) einen v-Core ab.²¹⁰ Ein v-Core kann aber auch mehrere Hardwarethreads repräsentieren.²¹¹ Bei mehreren Hardwarethreads, die einen v-Core unterstützen, müssen alle Threads (aller v-Cores) lizenziert werden, die der virtuellen Maschine oder dem Container zugewiesen sind.²¹² Für die Zuweisung von v-Cores/Hardwarethreads an Container braucht es – anders als bei virtuellen Maschinen – eine spezielle Konfiguration, ansonsten werden standardmässig alle physischen Ressourcen in Anspruch genommen.²¹³ Insbesondere bei Containerlösungen ist eine Lizenzierung auf Basis der Anzahl Cores fragwürdig. Der Container benötigt tatsächlich oft nur einen Bruchteil eines (lizenzierten) Cores, was in casu bei Berücksichtigung der Mindestlizenzierung von vier Cores je nach Szenario zu einer teuren Angelegenheit werden kann. Durch die massiven Skalierungsmöglichkeiten von Containern ergeben sich völlig andere Nutzungsszenarien, für welche erst wenige Softwarehäuser angemessene Lizenzmodelle entwickelt haben. Bei einer Container-Orchestrierung arbeitet man mit Pods, kleinteiligen Plattformen, die eine Gruppe von Applikationscontainern beinhalten. Der tatsächliche Core wird dabei oft so segmentiert, dass bei OpenShift²¹⁴ z.B. 1000 Millicores (entsprechen zusammen einem Core) ressourcentechnisch auf die verschiedenen Pods verteilt werden können.²¹⁵ Dabei den ganzen Core oder sogar mehrere Cores zu lizenzieren, obwohl nur ein Tausendstel tatsächlich genutzt wird, ist fragwürdig und macht die Anwendung von Containern kostspielig.

Schliesslich ist noch auf die Lizenzbestimmungen von IBM, einem weiteren grossen Softwareanbieter, einzugehen, welcher wie seine Konkurrenten über ein vielschichtiges Regelwerk mit zahlreichen Anlagen verfügt. Es handelt sich um ein ähnliches Modell wie dasjenige von Oracle, jedoch wird bei der «Soft-Partitionierung» anhand des IBM License Metric Tools die maximale tatsächliche Prozessornutzung erörtert und nur diese lizenziert.²¹⁶ Mittels der spezifischen Lizenzmetrik des «Processor Value Units» (PVU) wird die Leistungsfähigkeit der Prozessoren gemessen.²¹⁷ Das Gesagte gilt primär für virtuelle Maschinen und es müssen bestimmte Sub-Capacity-Lizenzierungsbedingungen erfüllt sein.²¹⁸ In den Vertragsbestimmungen ist folgende Nutzungsbeschränkung ersichtlich: «Vor einer Erweiterung der Virtualisierungskapazität eines berechtigten Sub-Capacity-Produkts muss der Kunde zuerst ausreichende Lizenzen […] zur Abdeckung der Erweiterung erwerben.».²¹⁹ Anders als andere Anbieter unterscheidet IBM zwischen Containern und virtuellen Maschinen. Erst gerade kürzlich, im Oktober 2020, hat das Unternehmen neue Lizenzbestimmungen zum Einsatz von IBM Software in containerisierten Unternehmungen veröffentlicht, vor allem in Hinblick auf die zukunftsrelevanten (Hybrid-)Clouds und den damit einhergehenden grossen Container-Orchestrierungen. Den kleinteiligen Pods, worauf Container laufen, soll mit einer neuen, granulareren Zählweise bei der Messung der v-CPU Kapazität besser Rechnung getragen werden.²²⁰ Sind die spezifischen Bedingungen für die Containerlizenzierung²²¹ erfüllt, hält der «Anhang – Spezielles Angebot für Containerlizenzierung» fest, der Kunde müsse: «[…] die Berechtigungen für die Gesamtzahl der Kerne (Cores) erwerben, die zur Kapazität aller Container beitragen, die für das Berechtigte Containerprodukt verfügbar sind.»²²², ansonsten «[…] muss der Kunde die Gesamtzahl der physischen Prozessorkerne lizenzieren, die zur Nutzung auf allen Servern, auf denen das Berechtigte Produkt bereitgestellt wird, aktiviert und verfügbar sind (Volle Kapazität).»²²³. Es ist also nicht wie bei anderen Anbietern nötig, der ganze Container-Cluster zu lizenzieren, sondern gesamthaft gesehen nur die addierten v-CPU Kapazitäten der containerisierten Applikationen.²²⁴ Wenn es sich um Kapazitäten handelt, die weniger als einem v-Core entsprechen, ist der betreffende Bruchteil massgeblich.²²⁵ Alle diese Bruchteile werden dann addiert und auf die nächste ganze Zahl gerundet, die für die Lizenzierung relevant ist, und nicht die aufgerundete Kapazität jedes einzelnen Pods/Nodes. Im Fokus steht dabei der Einsatz auf Kubernetes-Orchestrierungen.²²⁶ Für die Kunden von IBM birgt diese granulare Zählweise beim Einsatz von Containern grosse Kostenvorteile, wenn nicht die ganzen v-CPUs lizenziert werden müssen.²²⁷ Eine zentrale Voraussetzung für die IBM-Containerlizenzierung ist der Besitz des Zählprogramms «IBM License Service».²²⁸ M.E. legt IBM mit der Einführung dieser Lizenzmetrik einen Meilenstein für die Lizenzierung von Containern, da deren ressourcenschonende, kleinteilige Struktur berücksichtigt wird, was bei grossen Container-Orchestrierungen zu einer angemessenen Vergütung führt.

Im Gespräch mit Praktikern hat sich herausgestellt, dass es sich zum Teil als schwierig erweist, in diesem Durcheinander von Lizenzbedingungen den Durchblick zu bewahren und die Lizenz-Compliance sicherzustellen. Fundierte Kenntnisse der Regelwerke sind notwendig, um einerseits Überlizenzierungen zu verhindern, anderseits auch Sanktionen als Folge einer Unterlizenzierung zu vermeiden. Auf dem Markt gibt es zahlreiche Programme, die hierbei Abhilfe verschaffen können. Gängige Vorteile der Container-Technologie wie das «Scale-Up»²²⁹ und das «Scale-Out»²³⁰ können in der Praxis durch die verbreiteten Lizenzmodelle schnell zum Kostenfaktor werden. Lizenzen, die sich auf fixe Hardwarekomponenten oder Instanzenanzahl beziehen, eignen sich aus der Kostenperspektive nicht für Container-Landschaften, bei welchen man fliessend Ressourcen anpassen und für eine bestimmte Zeit dazu- oder abschalten kann.

Im letzten Teil dieser Arbeit soll auf die Wechselwirkung zwischen dem Urheber- und dem Vertragsrecht eingegangen werden. Nach den generellen Grundlagen sollen kurz die Rechtsfolgen einer Vertragsverletzung sowie einer kumulativen Urheberrechtsverletzung skizziert werden, um danach die urheberrechtliche Tragweite bzw. die bloss schuldrechtliche Natur der spezifischen Lizenzvereinbarungen im Bereich der Virtualisierung zu erörtern.

Nutzungsbeschränkungen im Lizenzvertrag sind zunächst vertragliche Bestimmungen, doch es bestehen auch enge und vielschichtige Zusammenhänge zum Urheberrecht an der Software.²³¹ Es ist daran zu erinnern, dass am Bestand des Urheberrechts nichts geändert wird und dem Anwender lediglich ein obligatorisch wirkender Anspruch auf Nutzung der Software eingeräumt wird.²³² Das gesetzliche Gebrauchsrecht und der Überlassungsvertrag hängen insofern zusammen, als dass der Umfang des gesetzlichen Gebrauchsrechts oft vertraglich definiert wird, wobei aber bei Begrenzungen auf gebrauchsrechtlicher Ebene urheberrechtlich wirkende Nutzungsbeschränkungen vorausgesetzt werden. Solche urheberrechtlich wirkenden Klauseln sind dann auch gegenüber nachfolgenden Erwerbern bindend.²³³ Wichtig in der Praxis ist dies vor allem im Falle unwirksamer AGB des Herstellers beim Softwareerwerb über einen Zwischenhändler.²³⁴ Es gibt aber auch rein vertraglich (wirkende) Nutzungsbefugnisse, die das gesetzliche Gebrauchsrecht erweitern, einschränken oder konkretisieren können, wobei diese dann einzig zwischen den Parteien – also inter partes – wirken und bei einer Weiterveräusserung der Software entfallen.²³⁵ Bei solchen schuldrechtlichen Beschränkungen hängt die Durchsetzbarkeit lediglich davon ab, dass keine kartell- und lauterkeitsrechtlichen Unwirksamkeitsgründe vorliegen.²³⁶ Der zwingende Kerngehalt des Gebrauchsrechts nach Art. 12 Abs. 2 URG setzt der Vertragsfreiheit ebenfalls Grenzen.²³⁷

Auf Ebene des Gebrauchsrechts wird dem Programmerwerber erlaubt, sonst nur dem Rechtsinhaber vorbehaltene Nutzungshandlungen gemäss Art. 10 URG vorzunehmen, wobei je nach dem eine Begrenzung auf einzelne davon stattfindet.²³⁸ Für urheberrechtlich (oder auch absolut) wirkende Beschränkungen auf Ebene des Gebrauchsrechts wird vorausgesetzt, dass es sich um wirtschaftlich selbständige Verwertungs- und Vertriebsformen bzw. wirtschaftlich-technisch selbständige Nutzungsarten handelt.²³⁹ Andersartige Nutzungsbeschränkungen hätten nur vertragliche Wirkung. Aus Herstellersicht bezwecken urheberrechtliche Beschränkungen die Sicherung seiner Marktstellung sowie seiner Erträge aus dem Softwarevertrieb.²⁴⁰ Nach der – nach wie vor noch nicht ganz einheitlichen – Verkehrsauffassung deutet die Erschliessung eines neuen Verbraucher- oder Nutzerkreises auf eine selbständige Nutzungsart hin. Darunter fällt bspw. die Regelung, die die Softwarenutzung nur auf einer bestimmten Anzahl von Arbeitsplätzen erlaubt.²⁴¹ Von urheberrechtlicher Bedeutung sind ausserdem nur solche Vereinbarungen, die dem Partizipationsinteresse des Herstellers dienen, ansonsten wären sie rein schuldrechtlicher Natur.²⁴² Letztendlich muss das Programmexemplar im Sinne des zwingenden Kerns aber in jedem Fall gebraucht werden können, was die Installation und den Ablauf des installierten Programms sowie ggf. die Fehlerbehebung umfasst.²⁴³

Aus den vorgängigen Erläuterungen ist zu folgern, dass eine Nutzung über den vertraglich vereinbarten Umfang des gesetzlichen Gebrauchsrechts hinaus nicht nur eine Vertragsverletzung, sondern zugleich eine Urheberrechtsverletzung darstellt.²⁴⁴ Die Verletzung einer rein schuldrechtlich wirkenden Vereinbarung stellt lediglich eine Vertragsverletzung dar.²⁴⁵

Die schweizerischen Gerichte mussten sich dazu bisher nicht konkret äussern. Dem EuGH wurden dagegen in jüngster Zeit vom Cour d’appel de Paris einige Fragen zum Verhältnis des Vertragsrechts zum Urheberrecht vorgelegt.²⁴⁶ Hintergrund bildet ein Rechtsstreit in Frankreich, bei welchem es darum ging, dass der Lizenznehmer «Free Mobile» die vom Lizenzgeber «IT Development» lizenzierte Software angeblich unrechtmässig bearbeitet und somit gegen das entsprechende vertragliche Verbot verstossen hat. Ob tatsächlich eine Vertrags- oder Urheberrechtsverletzung (in casu Verletzung der aus Art. 4 Software-RL vermittelten Rechte) vorliegt, ist fraglich²⁴⁷, stand aber auch nicht zur Debatte, vielmehr ging es darum, ob aus einer Vertragsverletzung auch eine Urheberrechtsverletzung erwachsen kann. Laut dem deutschen Autor Grützmacher ist diese Fragestellung unglücklich, «denn die Frage, ob eine Urheberrechtsverletzung vorliegt oder nicht, richtet sich nicht danach, ob gegen eine vertragliche Regelung verstossen wird oder nicht, sondern danach, ob in urheberrechtsrelevanter Weise in das Urheberrecht am Computerprogramm eingegriffen wird.».²⁴⁸ Der EuGH hält summa summarum fest, dass die Verletzung einer Klausel eines Lizenzvertrags, insofern sie die Urheberrechte des Inhabers betrifft, auch eine Urheberrechtsverletzung darstellt.²⁴⁹ Das bekannte CPU-Urteil des BGH²⁵⁰ ist in diesem Bereich ebenfalls wegweisend. Aus den Ausführungen des Gerichts lässt sich schliessen, dass bei Lizenzbegrenzungen, die sich mit eigenständigen Nutzungsarten decken, auch urheberrechtliche Beschränkungen vorliegen.²⁵¹ In der deutschen Lehre wird diese urheberrechtliche Wirkung bestimmter Lizenzklauseln bzw. -beschränkungen vielfach auch als (urheberrechtlich)-dinglicher Charakter bezeichnet.²⁵² Dieses Attribut sollte zurückhaltend angewendet werden, denn aufgrund der gegenwärtigen Konzeption des schweizerischen Rechts erweisen sich die Rechtsregeln zum dinglichen Eigentum beim Urheberrecht, welches das geistige Eigentum betrifft, nicht immer als passend. Bei immateriellen Gütern fehlt es erstens am Besitz, welcher nicht mit dem Besitz an einem Werkexemplar verwechselt werden darf, und zweitens ist auch kein Register (wie z.B. das Grundbuch) vorhanden, das als Besitzessubstitut dienen könnte. Während beim Urheberrecht gar kein solches existiert, werden andere Immaterialgüterrechte (Marken-, Patent- und Designrechte) zwar in einem Register eingetragen, doch kommt diesem nicht eine vergleichbare Bedeutung des öffentlichen Glaubens wie etwa beim Grundbuch zu.²⁵³ Beim geistigen Eigentum ist mitunter auch von «quasi-dinglichen» Rechten die Rede²⁵⁴, was m.E. besser passt.

Wird eine Verletzung des Softwareüberlassungsvertrags z.B. im Rahmen eines Software-Audits festgestellt, kann der Anbieter je nach urheberrechtlicher Tragweite der verletzten Vereinbarung ggf. gesetzliche sowie vertragliche Sanktionen herbeiführen.²⁵⁵ Betreffend den Schadenersatz im Besonderen ist dieser zwar bei einer Anspruchskonkurrenz wirtschaftlich nur einmal geschuldet, dennoch bestehen die Ansprüche aus vertraglicher und ausservertraglicher Haftung selbständig. Die Folge des Normkonkurrenzverhältnisses zwischen Art. 97 und Art. 41 OR ist dementsprechend nicht die Alternativität, sondern die Kumulation.²⁵⁶ Bei einer Urheberrechtsverletzung käme zudem auch der durch Art. 67 ff. URG vermittelte strafrechtliche Rechtsschutz in Frage, der vorliegend nicht weiter thematisiert wird.

Bei einem Verstoss gegen eine Klausel mit urheberrechtlicher Wirkung stehen dem Rechtsinhaber aufgrund seiner absolut geschützten Rechtsposition von Gesetzes wegen verschiedene Rechtsbehelfe zur Verfügung. Er kann sie nicht nur gegenüber dem betreffenden Vertragspartner geltend machen, sondern gegenüber jedermann (erga omnes), der derartige Handlungen begeht.²⁵⁷ Im Bereich des Softwareschutzes relevant sind dabei die Ansprüche auf Verbot einer drohenden Verletzung und Beseitigung einer bestehenden Verletzung nach Art. 62 Abs. 1 lit. a und b URG sowie nach Art. 62 Abs. 2 URG Ansprüche auf Schadenersatz (Art. 41 ff. OR) und Gewinnherausgabe (aus einer GoA gemäss Art. 423 Abs. 1 OR oder aus ungerechtfertigter Bereicherung gemäss Art. 62 OR).²⁵⁸ Bei widerrechtlich hergestellter Software gibt es zudem Auskunftsansprüche gemäss Art. 62 Abs. 1 lit. c URG. Es käme grundsätzlich auch eine Genugtuung bei Verletzungen des Urheberpersönlichkeitsrechts nach Art. 62 Abs. 2 URG i.V.m. Art. 49 OR in Frage, doch diese ist im Bereich des Softwareschutzes von untergeordneter Bedeutung.²⁵⁹

Daneben kann der Rechtsinhaber aufgrund der Verletzung des Vertrages Ansprüche auf Schadenersatz gemäss Art. 97 Abs. 1 OR und auf Schadensbeseitigung gemäss Art. 98 Abs. 3 OR geltend machen. Vertraglich werden meistens weitere Sanktionen an eine Urheberrechtsverletzung geknüpft, bspw. die Nachzahlung im Umfang der Übernutzung, der Verfall einer Konventionalstrafe sowie der Entzug der Nutzungsberechtigung, wobei sich letztere bei einer Veräusserung der Software wohl nicht mit dem zwingenden Kern von Art. 12 Abs. 2 URG vereinbaren lässt.²⁶⁰

Bei der folgenden Analyse wird die Konsensbildung zwischen den Parteien vorangestellt. Es wird davon ausgegangen, dass allfällige AGB gültig Vertragsbestandteil geworden sind, gemäss der Darlegung in Kap. 4.1.2.2.

Vertragliche Vereinbarungen, die den Einsatz auf einen Rechner und analog auf eine Instanz (virtuelle Maschine bzw. Container) beschränken, wie sie in den Lizenzbedingungen der ColorLogic vorliegen, wären nicht notwendig. Dennoch sind solche Klauseln aus der Sicht des Anbieters empfehlenswert, um Diskussionen mit den Anwendern zu vermeiden.²⁶¹ Die Beschränkung auf eine Instanz ist technisch-wirtschaftlich klar abgrenzbar. Es geht darum, dass dem Anbieter potenzielle Einnahmen weiterer Einzelplatzlizenzen nicht verloren gehen. Bei der Installation mehrerer Instanzen führt das bei der Nutzung pro Container oder pro virtueller Maschine zu einer urheberrechtlichen Vervielfältigung im Arbeitsspeicher.²⁶² Zwar ist eine solche Vervielfältigung beim Betreiben einer Programmkopie von Art. 12 Abs. 2 URG erfasst, doch kann bei einem mehrfachen Vorhandensein im Arbeitsspeicher (ggf. Storage) nicht mehr von einer bestimmungsgemässen Nutzung ausgegangen werden.²⁶³ Die Beschränkung auf eine bestimmte Anzahl Instanzen bzw. die Lizenzierung nach Instanzenanzahl knüpft direkt an die zusätzlichen Vervielfältigungsstücke an. Es handelt sich hierbei um eine selbständige Nutzungsart und Verwertungsform. Zusätzliche Installationen auf mehreren Instanzen erweitern den Verbraucherkreis. Der Rechtsinhaber ist wie erwähnt berechtigt dazu, die zeitgleiche Mehrfachnutzung seiner Software zu verbieten bzw. zu kontrollieren.²⁶⁴ Es kann gefolgert werden, dass die Regelungen zur Instanzenanzahl nicht nur rein schuldrechtlicher Natur sind, sondern auch urheberrechtlich wirken. Für die gesetzliche Gebrauchsbefugnis sind solche Regelungen also konstitutiv.²⁶⁵

Urheberrechtlich unzulässig im Sinne eines Verstosses gegen den Kerngehalt der Gebrauchsbefugnis nach Art. 12 Abs. 2 URG i.V.m. Art. 17 Abs. 1 lit. a URV wäre in diesem Zusammenhang – in der Lehre nicht unumstritten – vor allem ein generelles Verbot der Nutzung in einer virtuellen Umgebung.²⁶⁶ Da sich die Installation einer Software in einer virtuellen Instanz nicht entscheidend von derjenigen auf einem physikalischen Rechner unterscheidet und die Installation einer Anwendung in jedem Falle gewährleistet sein muss, schliesse ich mich der oben erwähnten Lehrmeinung an und sehe das allgemeine Verbot des Softwareeinsatzes in einem Container oder einer virtuellen Maschine als Verstoss gegen den zwingenden Kern der Gebrauchsbefugnis an. Demnach entfaltet es weder urheberrechtliche noch vertragliche Wirkungen. Beschränkungen auf bestimmte Technologien sind jedoch denkbar.²⁶⁷

Aus kartellrechtlicher Perspektive könnte ein missbräuchliches Verhalten etwa die zusätzlichen Gebühren oder den Erwerb weiterer Lizenzen z.B. bei der Erhöhung der Anzahl User (oder in diesem Kontext auch die Erhöhung der Anzahl Instanzen) betreffen.²⁶⁸ Bei unangemessen hohen Preisen solcher Nachlizenzierungen, die durch marktbeherrschende Unternehmen festgesetzt werden, ist eine Korrektur nach Art. 7 Abs. 2 lit. c KG i.V.m. Art. 13 lit. b KG möglich.

Es ist zu prüfen, ob vertragliche Beschränkungen durch Lizenzmetriken oder übrige hardwarebezogene Beschränkungen für die Softwarenutzung in containerisierten oder virtualisierten Umgebungen auch urheberrechtliche Wirkung entfalten. Bei CPU-Klauseln ist je nach Typ zu differenzieren. Bei Beschränkungen auf eine bestimmte einzelne Zentraleinheit oder einen bestimmten Prozessortypen, ist der generelle Konsens dahingehend, dass von einer rein vertraglichen Wirkung ausgegangen wird.²⁶⁹ Begründet wird dies damit, dass der Urheber kein Partizipationsinteresse am Einsatz auf einer anderen Hardwareeinheit hat, da keine zusätzlichen Verbraucherkreise erschlossen werden.²⁷⁰ Es fehlt an einer eigenständigen Nutzungsart, da nur die Art der Ausübung des Nutzungsrechts betroffen ist.²⁷¹ Die Zahl der Vervielfältigungen ist nicht tangiert.²⁷²

Umstrittener ist die Thematik bei Klauseln, die den Gebrauch des Programms auf eine bestimmte Anzahl Prozessoren(kerne) oder auf andere nutzungsintensitätsabhängige Lizenzmetriken beschränken, die im Bereich der Virtualisierung oft anzutreffen sind (vgl. Kap. 4.2.2.2.). Erstens ist das Partizipationsinteresse zweifelhaft. Das Nutzungsrecht des Anwenders darf nämlich nicht auf eine bestimmte Ausübungsart beschränkt werden, wenn keine neuen Verbraucherkreise daraus erfolgen, da dies nicht mehr dem Urheberrecht entspricht.²⁷³ Im vorliegenden Fall hat der Einsatz von Software in Containern oder virtuellen Maschinen auf Systemen mit unterschiedlich starker Leistungsfähigkeit m.E. keinen Einfluss auf die Erfassung möglicher Verbraucherkreise. Dennoch bringen die Softwareanbieter oft das Argument, dass durch leistungsfähigere Systeme, die Software auch intensiver genutzt werden könne, was eine Entgelterhöhung rechtfertige.²⁷⁴ Das hat m.E. nichts mit dem Partizipationsinteresse zu tun, denn die Programmnutzung in Containern oder virtuellen Maschinen wurde schon zu Beginn mit der Lizenzgebühr vergütet und es ergeben sich nach wie vor keine neuen Verbraucherkreise durch die intensivere Nutzung auf leistungsstärkeren virtuellen oder physischen Ressourcen. Die Hersteller möchten finanziell von der Mehrnutzung des Programms aufgrund der höheren Prozessorenleistung profitieren. Es soll jedoch gesagt sein, dass eine solche u.a. davon abhängt, ob eine Software auch für den Parallelbetrieb entwickelt wurde.²⁷⁵ Technisch gesehen ist hierbei anzumerken, dass eine Prozessoraufrüstung insb. bei virtualisierten Systemen nicht unbedingt zu einer intensiveren Nutzung führt. Es werden zwar absichtlich leistungsfähige Prozessoren genutzt, um eine Virtualisierung zu betreiben, doch letztlich teilt sich die Software, die in einer virtuellen Maschine oder einem Container läuft, die Ressourcen mit den anderen Gästen (und deren Applikationen).²⁷⁶

Nach all dem Gesagten, stellt sich höchstens die Frage, ob allfällige urheberrechtlich relevante Vervielfältigungen auf eine «quasi-dingliche» Tragweite der Klauseln hinweisen könnte. Generell wird jedoch angenommen, dass eine Anknüpfung an CPU sich nicht an der Anzahl der Vervielfältigungen orientiert.²⁷⁷ Bezüglich den Mehrkernprozessoren sollten aber einige Besonderheiten in Betracht gezogen werden. Vorab kommt es bei Programmen, die nicht für den Parallelbetrieb geschrieben wurden, zu keinen zusätzlichen urheberrechtlichen Vervielfältigungen.²⁷⁸ Ist die Software aber parallelisierbar, wird ihre Abarbeitung mittels Multi-Threading auf die verschiedenen mehrfädigen Cores aufgeteilt, was zu einer erhöhten Geschwindigkeit führen kann, aber nicht muss (je nach Programmierung der Applikation oder Unterstützung des Betriebssystems). Gegebenenfalls werden die Daten hier in den verschiedenen Puffer-Speicher (Prozessorcaches) der Cores zwischengespeichert, was auf eine Vervielfältigung hindeuten könnte, die aber gemäss Grützmacher fraglich ist, denn die Programmteile werden bereits vorab auf die Cores aufgeteilt und parallel abgearbeitet.²⁷⁹ Geht man aber von einer Vervielfältigung aus, wäre diese m.E. sowieso, wenn nicht von Art. 12 Abs. 2 URG, sicherlich von Art. 24a URG gedeckt, da es sich bloss um eine der rechtmässigen Nutzung dienende, flüchtige Kopie ohne eigenständige wirtschaftliche Bedeutung handeln würde. Die Anzahl der urheberrechtlich relevanten Kopien erhöht sich aus meiner Sicht auch nicht durch die Anzahl mehrerer virtueller Prozessoren oder die Anzahl Hardwarethreads, die zu einem Container führen. Es geht immer noch um die Abarbeitung einer Programmkopie, die auf verschiedene Teile aufgeteilt wird. Ausserdem werden durch die Zusammenarbeit von v-CPU, v-Cores und Hardwarethreads auch keine neuen Verbraucherkreise erschlossen. Eine technisch-wirtschaftlich klar abgrenzbare Nutzungsform ist nicht ersichtlich.

Beschränkungen durch CPU-, Core- und sonstiger nutzungsabhängiger Lizenzmetriken, ungeachtet der Anknüpfung an physikalische oder virtuelle Einheiten, kommt lediglich eine schuldrechtliche Wirkung zu und sie sind nicht urheberrechtlich durchsetzbar. Um von der gegebenenfalls höheren Leistungsfähigkeit zu profitieren, bleibt dem Hersteller also nur die Möglichkeit, die Höhe der Vergütung von der Anzahl der Prozessoren mit vertraglicher Wirkung abhängig zu machen.²⁸⁰ Weiter könnte man lizenzrechtliche Beschränkungen von blossen Vergütungsregelungen unterscheiden.²⁸¹ Im vorliegenden Fall ändert sich ungeachtet dieser Unterscheidung nichts an der bloss vertraglichen Rechtsnatur.

Fraglich ist, ob bei CPU-Klauseln neben der urheberrechtlichen Unwirksamkeit auch ein Verstoss gegen den zwingenden Kerngehalt des gesetzlichen Gebrauchsrechts vorliegt, wonach entsprechende Bestimmungen nicht nur urheberrechtlich, sondern auch vertraglich nicht durchsetzbar wären. Klauseln, die auf Dauer den Wechsel der Software auf eine andere Hardwareeinheit verbieten, stellen ein Verbot der Installation zum bestimmungsgemässen Gebrauch dar. Schliessen solche Klauseln den Hardwarewechsel völlig aus oder machen ihn von der willkürlichen Zustimmung des Anbieters abhängig, greifen sie in den zwingenden Kern von Art. 12 Abs. 2 URG ein.²⁸² Die Ersetzung der Hardwareeinheit muss im Einzelfall erlaubt sein.²⁸³ Den Hardwarewechsel von einer zusätzlichen Vergütung abhängig zu machen, ist zulässig.²⁸⁴ Beschränkungen auf genau bestimmte Zentraleinheiten oder Prozessortypen sind im Zusammenhang mit container- oder VM-spezifischen Lizenzmetriken selten. Im Rahmen der Recherche wurden in casu keine Verstösse gegen den zwingenden Kerngehalt ausfindig gemacht. Der Wechsel auf leistungsfähigere Hardwareeinheiten ist in diesem Bereich kaum verboten, wird jedoch oft mit einer zusätzlichen Vergütung gekoppelt, was nicht gegen den zwingenden Kern verstösst.

In Ausnahmefällen können AGB- oder kartellrechtliche Nichtigkeitsgründe vorliegen.²⁸⁵ Individualvertraglich bereiten hardwarebezogene Lizenzbeschränkungen normalerweise keine Probleme.²⁸⁶ Es kann aber bei einer allfälligen Regelung der Beschränkungen in AGB zur Korrektur ungewöhnlicher Nutzungsbeschränkungen kommen (Kap. 4.1.2.2.) kommen. Die schweizerischen Gerichte mussten bis anhin noch keine solchen Fälle im Bereich der Nutzungsbeschränkungen in Softwareüberlassungsverträgen beurteilen. Es fehlt an einer systematischen Aufarbeitung dieser Thematik. Hingegen hat sich im deutschen Recht eine detaillierte Lehre und Rechtsprechung zu AGB-rechtlich unwirksamen Nutzungsbeschränkungen herausgebildet.²⁸⁷ Gemäss dieser AGB-Rechtsprechung werden CPU-Klauseln in Softwareveräusserungsverträgen oft als unwirksam qualifiziert.²⁸⁸

Hardware-bindende Nutzungsbeschränkungen können ausserdem gegen das Wettbewerbsrecht verstossen, wenn unangemessene Bedingungen bei Konfigurationsänderungen durch einen marktmächtigen Partner erzwungen werden.²⁸⁹ Missbräuchliches Verhalten kann bspw. bei der Bündelung von Leistungen und Produkten aus dem Angebot marktbeherrschender Hardware- oder Softwareanbieter vorliegen, da dadurch u.U. der Wettbewerb mit Drittanbietern beschränkt wird.²⁹⁰ Ebenfalls unzulässig können durch marktbeherrschende Unternehmen festgesetzte unangemessen hohe Upgrade-Gebühren sein, die in keinem Verhältnis zur wirtschaftlichen Gegenleistung stehen.²⁹¹ Mögliche Folgen von missbräuchlichen Bestimmungen sind die Unwirksamkeit gemäss Art. 20 OR²⁹² sowie die Korrektur missbräuchlicher Konditionen nach Art. 7 Abs. 2 lit. c i.V.m. Art. 13 lit. b KG und kartellrechtliche Bussen nach Art. 49a ff. KG.²⁹³

Die Container-Technologie hat in den letzten Jahren herkömmliche Virtualisierungsansätze ergänzt oder teilweise sogar abgelöst. Aufgrund der zahlreichen Vorteile interessieren sich immer mehr Unternehmen für die «leichtgewichtige» und vermeintlich kostengünstige Virtualisierungslösung. Werden urheberrechtlich geschützte Programme in Containern betrieben, muss der Softwareerwerber deren Schutz weiter beachten. Auch ohne explizite Nutzungseinräumung darf er aber aufgrund des gesetzlichen Gebrauchsrechts nach Art. 12 Abs. 2 URG bei Software-Überlassungen auf Dauer ein Programmexemplar in einem Container (oder in einer virtuellen Maschine) betreiben, denn die hierfür vorgenommene gesetzlich garantierte Installation unterscheidet sich nicht entscheidend von derjenigen auf einem physischen Rechner. Der Betrieb auf mehreren Instanzen, der in einer Mehrfachnutzung resultiert, sowie nicht für den Gebrauch notwendige Modifikationen sind nicht mehr von Art. 12 Abs. 2 URG erfasst. Der mehrfache Containerbetrieb als Teil der Sicherheitsarchitektur ist zwar von Art. 24 Abs. 2 URG gedeckt, aber nur solange nicht mehrere Programmkopien produktiv im Einsatz sind, um tatsächlich eine Leistungssteigerung zu erreichen. In der Praxis beinhalten die Regelwerke der Softwareanbieter meistens vertragliche Bestimmungen bzw. Beschränkungen zu den entsprechenden Sachverhalten, dies oft in AGB oder EULA, bei welchen jeweils geprüft werden muss, ob sie überhaupt gültiger Vertragsbestandteil werden. Um die Mehrfachnutzung abzugelten, werden Container sowie virtuelle Maschinen vielfach einem physischen Rechner gleichgestellt und es wird nach der Anzahl der Instanzen lizenziert. Zudem knüpfen Softwareanbieter bei Nutzungsbeschränkungen oder Vergütungsansprüchen mittels CPU- oder Coreklauseln an die Leistungsfähigkeit der Hardware an. Umgesetzt wird dies mittels umfangreicher und teilweise verwirrender Regelwerke sowie schwer deutbarer Lizenzmetriken, die mitunter auf die Anzahl Prozessoren oder Cores des physischen Hosts abstellen. Container (oder auch virtuelle Maschinen) werden aber meist zwischen Servern hin- und hergeschoben, nur nach Bedarf gestartet und teilen sich untereinander die Ressourcen. Pro Instanz alle Prozessoren/Cores zu lizenzieren, stellt eine fragwürdige Anknüpfung dar. Insbesondere bei Containern, die nur einen Bruchteil der Ressourcen benötigen und von denen oft eine Vielzahl in Betrieb ist, führt dies zur Lizenzierung von tatsächlich nicht gebrauchten Ressourcen. Manche Softwareanbieter haben inzwischen eine granularere Lizenzierung auf kleinteiliger Ebene eingeführt, was zu begrüssen ist. Letztlich muss immer zwischen Bestimmungen mit rein vertraglicher Wirkung und Beschränkungen mit urheberrechtlicher Tragweite, die auch gegenüber Zweiterwerbern durchsetzbar sind, differenziert werden. Je nachdem ob absolute oder relative Rechte verletzt werden, unterscheiden sich auch die Rechtsfolgen. Bei der Orientierung an der Anzahl Instanzen handelt es sich um urheberrechtlich wirkende Regelungen, denn sie knüpfen in wirtschaftlich-technisch abgrenzbarer Weise an die Anzahl Vervielfältigungen an. Ein allgemeines Verbot der Nutzung in virtualisierten Systemen würde jedoch gegen den zwingenden Kern von Art. 12 Abs. 2 URG verstossen. Wird an die Leistungsfähigkeit der Hardware angeknüpft, handelt es sich nicht um eine wirtschaftlich-technisch eigenständige Nutzungsform. Durch die Zusammenarbeit der Prozessoren oder Cores im Verbund kommt es zu keinen zusätzlichen urheberrechtlich relevanten Vervielfältigungen, und zwar ungeachtet, ob es sich um virtuelle oder physische Einheiten handelt oder ob es sich um parallelisierbare oder nicht-parallelisierbare Software handelt. Vertragsbestimmungen, die in einem Verbot des Hardwarewechsels resultieren und allenfalls gegen den zwingenden Kerngehalt von Art. 12 Abs. 2 URG verstossen, sind im Zusammenhang mit der Container-Virtualisierung im Rahmen dieser Recherche keine aufgefunden und dementsprechend untersucht worden. Immerhin müssen solche vertraglichen Bestimmungen, sofern sie bei allfälligen AGB überhaupt Vertragsbestandteil geworden sind, dann auch noch den kartell- und lauterkeitsrechtlichen Rahmen einhalten.

Nina Locher, MLaw, Legal Trainee bei Scout24.

Vorliegender Beitrag basiert auf der im Herbstsemester 2020 verfassten Masterarbeit der Autorin. Ein besonderer Dank gebührt dem Betreuer dieser Masterarbeit, Herrn Dr. iur. Wolfgang Straub, für die immer gewährte Unterstützung und seinen fachlichen Rat.