Rechte des Entwicklers einer Programmiersprache

Ein recht interessantes – wenn auch in Rechtsprechung und Literatur bisher nicht diskutiertes - juristisches Problem ist die Frage, ob der Entwickler einer Programmiersprache an den in dieser Sprache erstellten Quellprogrammen der Anwender Rechte geltend machen und diesen die Übersetzung ihrer Quellprogramme in eine andere Programmiersprache verbieten kann.

Gerade diese Frage ist für die gesamte Software- und IT-Dienstleistungsbranche, die nach Angaben des Bundesverbandes Informations-Technologien in Deutschland 1996 einen Umsatz von DM 32,3 Mrd. (weltweit DM 1.791 Mrd.) erwirtschaftete, von elementarer Bedeutung. Da jedes Anwendungsprogramm in einer Computersprache geschrieben worden ist - niemand ist in der Lage, ein komplexes Programm unmittelbar im Objektcode in den Computer einzugeben - steht hier die Frage zur Diskussion, ob die jeweiligen Entwickler der Programmiersprachen nun den gesamten Softwaremarkt lahm legen dürfen, indem sie Migrationen (Übersetzungen) der Quellprogramme der Anwender in eine andere Programmiersprache untersagen. Dies würde bereits gegen den eindeutigen Wortlaut des § 69c Nr.2 UrhG verstoßen, der das Recht zur Übersetzung ausdrücklich dem Urheber der Quellprogramme einräumt, nicht dem Entwickler der Programmiersprache, in welcher die Quellprogramme geschrieben sind!
Seit einigen Jahren wird der Forschungs- und Technologiepolitik in der Europäischen Union ein besonderer Stellenwert eingeräumt: Aufgrund der Einsicht, gegenüber den Vereinigten Staaten und Japan auf den Gebieten der "Zukunftsindustrien" - Computerbau, Robotertechnik, Telekommunikation - in einen erheblichen Rückstand geraten zu sein und angesichts der forschungs- und technologiepolitischen „Wiederaufrüstungsbemühungen" der USA, stellt die Europäische Union das Erfordernis einer "europäischen Technologiegemeinschaft" immer wieder in den Vordergrund (Roth, Schnittstellenkooperation und europäisches Kartellrecht, CR 1988, 195).
Ausgangspunkt jeder anzustellenden Interessenbewertung ist die Freiheit des Wettbewerbs, jedes Unternehmen soll sich möglichst ungehindert, im Rahmen der geltenden Gesetze, wettbewerbsfördernd am Markt betätigen können (Lehmann, Portierung und Migration von Anwendersoftware, CR 1990, 700[702]). In der EDV-Branche ist die Kompatibilität zu anderen EDV-Produkten sowohl im Bereich der Vereinbarkeit von Hardwarekomponenten miteinander, wie auch im Bereich der Software sehr häufig anzutreffen. Selbst, wenn durch ein kompatibles Produkt die entsprechende Software des Lizenzgebers ersetzt werden kann, begründet dies alleine noch keinen Unterlassungsanspruch, weil die Ersetzung eines Produktes durch ein anderes Produkt gerade den Wesensbereich der freien Marktwirtschaft ausmacht (LG Nürnberg-Fürth, CR 1993, 145 [147]).
Dies gewinnt zunehmend an Bedeutung, da die Computerinstallationen immer komplexer werden und, da die Benutzer unterschiedliche Software und Hardware von einer Vielzahl von Anbietern kombinieren wollen, um ihre Bedürfnisse am besten zu befriedigen. Folglich ist der Wettbewerb hart, und die Möglichkeit, Rechte des geistigen Eigentums zur Behinderung des Wettbewerbs einzusetzen, mag mitunter verlockend erscheinen (Vinje, Softwarelizenzen im Lichte von Art. 85 des EWG-Vertrages, CR 1993, 401[406]).
Wenn man eine solche Übersetzung untersagte, würde dies eine Vielzahl heutiger Produkte auf den Boden der Illegalität stellen. Ein Textverarbeitungssystem dürfte keine Möglichkeit mehr anbieten, Dokumente anderer Hersteller zu laden, ein Drucker dürfte keinen Befehlssatz eines anderen Herstellers emulieren (z.B. "HP kompatibel") und selbst Microsofts Internet Explorer wäre ungesetzlich, weil doch eigentlich die Firma Netscape das Produkt "Internet-Browser", welches die Sprache HTMIL versteht, auf dem Markt platzierte. Hierdurch würden Monopolstellungen geschaffen, die mit der freien Marktwirtschaft nicht vereinbar sind!
Offenbar ist die oben gestellte Frage, ob der Entwickler einer Programmiersprache an den in dieser Sprache erstellten Quellprogrammen der Anwender Rechte geltend machen und diesen die Übersetzung ihrer Quellprogramme in eine andere Programmiersprache verbieten kann, bisher weder von den deutschen noch von den US-amerikanischen Gerichten entschieden worden. Es ergibt sich jedoch aus einer Betrachtung ähnlicher - wenn auch nicht identischer - Rechtsprobleme, daß dem Entwickler einer Programmiersprache ein solches monopolisierendes Recht nicht zustehen darf

1.

Erster zum Vergleich heranzuziehender Fall ist die Frage der Kompatibilität. Kompatibilität ist in der EDV-Branche eines der wichtigsten Verkaufsargumente (Zahrnt, Einsatz von Standardanwendungsprogrammen auf "fremden" DV-Anlagen, CR 1989, 965). Wollte man den Herstellern von Personalcomputern untersagen, ihr Produkt als "IBM-kompatibel" zu bezeichnen, dürfte man ein ganzes Marktsegment lahm legen. Dabei bedeutet Kompatibilität nicht nur die Möglichkeit, verschiedene Systembestandteile gemeinsam einsetzen zu können. Es kann vielmehr auch die Möglichkeit beinhalten, einen Systembestandteil durch einen kompatiblen zu ersetzen (Jersch, Anmerkung zu LG Nürnberg-Fürth, CR 1993, 148[149]). Bei Software kann Kompatibilität somit beinhalten, daß die von dem einen Programm gespeicherten Daten auch von dem anderen Programm verarbeitet werden können. Solche Fähigkeiten sind für den Anwender von überragender Bedeutung, da ein Programmwechsel ausscheiden müßte, wenn damit zwangsläufig die in jahrelanger mühsamer Arbeit gesammelten Daten unbrauchbar würden. Hierdurch könnten faktische Monopole entstehen (Jersch, Anmerkung zu LG Nürnberg-Fürth, CR 1993, 148[149 f ]). Kompatibilität ist also ein von unserem Wettbewerbssystem grundsätzlich erwünschter Faktor.

2.

Auch die Frage von Schnittstellen ist zur Beurteilung der vorliegenden Frage heranzuziehen. Um ein Programm zu einem anderen kompatibel zu machen, muß eine Schnittstelle zwischen den beiden geschaffen werden, damit das eine Programm die Befehle und/oder Daten des anderen Programms verarbeiten kann. Schnittstellen sind somit unabdingbar, um Programme zu entwickeln, die mit anderen Programmen in Verbindung treten können, d.h. die interoperabel sind (Dreier, Rechtsschutz von Computerprogrammen, CR 1991, 577[581]). Wer Hardware oder Software zur Ergänzung eines DV-Systems eines anderen Herstellers anbietet, nutzt Schnittstellen, die möglicherweise vom anderen Hersteller entwickelt worden sind. Der Konkurrent kann sogar unter Nutzung der Schnittstellen auch Produkte anbieten, welche die des Herstellers ersetzen (Dreier, Rechtsschutz von Computerprogrammen, CR 1991, 577[582]). Es handelt sich dabei grundsätzlich nicht um unberechtigte unmittelbare Leistungsübernahme (Zahrnt, Wettbewerbsverletzungen durch Werbung für Computer, CR 1995, 262). Denn dieser Konkurrent erspart sich nur einen geringen Aufwand, der Aufwand zum Herstellen der Kompatibilität kann sogar deutlich höher sein.Die EU-Kommission hat den Versuch, Computerprogrammen patentartige Monopolrechte zukommen zu lassen, im Hinblick auf die schädlichen Auswirkungen auf den Wettbewerb zurückgewiesen. In diesem Zusammenhang setzt sie sich auch mit der Frage auseinander, ob nicht auch das Urheberrecht ein in bestimmter Hinsicht wettbewerbspolitisch unerwünschtes Maß an Schutz gewährt (Sucker, Kommission der Europäischen Gemeinschaften verabschiedet Grünbuch zum Urheberrecht, CR 1988, 707[708]). Die Kommission weist hier insbesondere auf das Problem der Schnittstellen hin, die "wörtlich" übernommen werden müssen, wenn neue Software oder Hardware mit bereits auf dem Markt vorhandener Software oder Hardware kompatibel sein soll. Urheberrechtsschutz für solche Schnittstellen könne gegebenenfalls für ein ganzes Marktsegment eine Monopolsituation begründen. Gleichermaßen würde die aus Wettbewerbsgründen erwünschte Entwicklung kompatibler Programme behindert, wenn es Konkurrenten untersagt werden könnte, in ihr Produkt Schnittstellen zu integrieren (Sucker, Kommission der Europäischen Gemeinschaften verabschiedet Grünbuch zum Urheberrecht, CR 1988, 707[7081). Die EU-Kommission hat mit IBM sogar eine Vereinbarung mit der Verpflichtung für IBM geschlossen, Schnittstellenspezifikationen früher als bisher üblich der Konkurrenz bekanntzugeben, damit diese besser in der Lage ist, solche Konkurrenzprodukte zu entwickeln.
Das neue Urheberrecht erlaubt sogar ausdrücklich das Dekompilieren zur Ermittlung von Schnittstellen, um das Entwickeln konkurrierender Produkte zu fördern (Zahrnt, Wettbewerbsverletzungen durch Werbung für Computer, CR 1995, 262[263]), wie sich aus §69e UrhG ergibt. Macht der Entwickler eines Fremdprogrammes nur von den Ideen, Regeln oder Grundsätzen Gebrauch, die der übernommenen Schnittstelle zugrunde liegen, liegt eine Urheberrechtsverletzung nicht vor (Haberstumpf, Die Zulässigkeit des Reverse Engineering, CR 1991, 129[138]), dies ergibt sich bereits aus § 69a Abs. 2 Satz 2 UrhG, wonach diese ausdrücklich vom Urheberrechtsschutz ausgenommen sind.

3.

Ebenfalls heranzuziehen ist die Frage der Portierung/Migration. Viele Softwareanwender möchten z.B. unter Beibehaltung ihrer Programme von einem "älteren" Betriebssystem auf ein anderes überwechseln bzw. die Programme auf eine moderne Hardware übertragen (portieren). So können heute viele Programme, die ursprünglich z.B. für MS-DOS, MS-Windows oder andere Systeme entwickelt worden sind, auch unter anderen Betriebssystemen eingesetzt werden. Dabei werden auch sogenannte Emulatoren zum Einsatz gebracht, welche die notwendigen Anpassungs- und Übersetzungsarbeiten leisten (Lehmann, Portierung und Migration von Anwendersoftware, CR 1990, 625). Auch, wenn hierzu eine Veränderung des lizenzierten Programms erforderlich ist, darf der Urheber weder über die Verweigerung von Informationen über Schnittstellenspezifikationen noch durch das Verbot von angemessenen Umgestaltungen den Versuch unternehmen, als Lizenzgeber den Markt für Computerprogramme zu monopolisieren (Lehmann, Portierung und Migration von Anwendersoftware, CR 1990, 625 [628]). Denn gerade im Software-Bereich kann der Urheber besonders häufig seine Einwilligung gern. § 39 Abs. 2 UrhG in eine Adaption des Programms nach Treu und Glauben nicht versagen. Dies entspricht dem Grundgedanken der auch bei § 39 Abs. 2 UrhG vorzunehmenden Interessenbewertung, wobei die Int
ressen des Lizenzgebers auf ungehinderte, kommerzielle Verwertung seines Werkes mit den Interessen der Lizenznehmer an einer möglichst abnehmerfreundlichen Nutzungsmöglichkeit der Computerprogramme miteinander in Einklang zu bringen sind (Lehmann, Portierung und Migration von Anwendersoftware, CR 1990, 625[630]). Festgeschrieben werden soll damit eine Art computerprogrammbezogene Zweckübertragungstheorie, die offenbar werden läßt, daß der Lizenznehmer alle für seine vertragsgemäße Verwendung des Computerprogrammes notwendigen Umgestaltungen vornehmen kann, ohne einer Zustimmung des Lizenzgebers zu bedürfen. Erst, wenn er das Programm für andere Zwecke als jene, die im Lizenzvertrag explizit oder stillschweigend von den Parteien zugrunde gelegt worden sind, verwenden will, bedarf er einer weiteren Zustimmung des Rechtsinhabers (Lehmann, Portierung und Migration von Anwendersoftware, CR 1990, 625[629]).

Der für die Portierung entwickelte Compiler schafft die erforderliche Schnittstelle zur neuen DV-Anlage. Das ursprüngliche Programm wird nicht geändert, es wird aber ein weiteres Vervielfältigungsstück hergestellt. Dieser Vervielfältigungsakt liegt urheberrechtlich innerhalb des bestimmungsgemäßen Gebrauchs (Nutzung des Programms auf einer Anlage) (Zahrnt, Einsatz von Standardanwendungsprogrammen auf "fremden" DV-Anlagen, CR 1989, 965[968]). Dementsprechend hat das OLG München dem Anwender zu Recht erlaubt, Programme zwecks Portierung zu ändern; die evtl. urheberrechtliche Zustimmung könne nicht verweigert werden (OLG München CR 1988, 378). Bereits das LG München hatte erstinstanzlich ausgeführt, daß der Softwareanwender, soweit nicht etwas anderes ausdrücklich vertraglich vereinbart ist, zur Anpassung des Computerprogramms an seine betrieblichen Belange berechtigt ist, ähnlich, wie es der Eigentümer eines Hauses bei Anpassung des Gebäudes an seine geänderten Bedürfnisse gegenüber dem Architekten als Urheber ist (LG München, CR 1988, 379[380]). Wird im Lizenzvertrag nichts anderes vereinbart, darf der Anwender somit das Programm ändern, weil der Lizenzgeber die Zustimmung zur Portierung typischerweise nach Treu und Glauben erteilen muß (Zahrnt, Einsatz von Standardanwendungsprogrammen auf "fremden" DV-Anlagen, CR 1989, 965 [969]).In der hier zu beurteilenden Frage ist hervorzuheben, daß es aber noch nicht einmal darum geht, das Programm des Sprachurhebers zu migrieren, sondern nur die von den Anwendern erstellten Quellcodes. Wenn der Sprachurheber also sogar einer Portierung seines eigenen Systems zustimmen müßte, dann erst recht, wenn nur die von den Anwendern erstellten Programme migriert werden sollen.Wollte man eine Übersetzung untersagen, müßte sich ein Softwarehersteller, der heute ein Programm in einer Programmiersprache entwickelt, darüber im klaren sein, daß er sein Programm ausschließlich mit einem Compiler des Sprachurhebers nutzen und es nicht in eine andere Sprache übersetzen darf Würde ein Sprachurheber dieses Verbot in seine Lizenzverträge aufnehmen, würde kein Softwarehaus eine Entwicklung in dieser Sprache beginnen, da die "Übersetzbarkeit" in eine andere Sprache ein ganz wesentlicher - und selbstverständlicher Aspekt bei der Softwareentwicklung ist. Würde die Rechtsprechung eine solche Migration in eine neue Umgebung oder Sprache untersagen, hätte dies weitreichende Folgen, wie an folgendem Beispiel sichtbar wird: Ein Anwender kauft ein Textverarbeitungsprogramm und schreibt mit diesem einen Roman. Er verkauft das Manuskript an einen Verlag, der das Buch drucken will und übergibt ihm eine Diskette mit der Textdatei. Die Herstellerfirma der Textverarbeitung könnte nun dem Verlag untersagen, den Text im Verlag mit einem anderen Drucksystem auszudrucken, da auch das ursprüngliche Textverarbeitungssystem eine Druckoption enthält. Der Anwender wäre auf Ewig an diese Textverarbeitung gebunden, wenn es ihm untersagt wäre, seinen Text in das Format einer anderen Textverarbeitung zu konvertieren.

4.

Der vorliegende Fall läßt sich auch nicht unter die sog. "Dongle-Rechtsprechung" subsumieren, denn diese untersagt lediglich den Vertrieb eines Softwareprogrammes, welches ausschließlich dazu bestimmt ist, einen Hardware-Kopierschutz eines bestimmten Softwareprogrammes eines anderen Herstellers zu beseitigen, damit dieses Programm vom Erwerber entgegen den allgemeinen Geschäftsbedingungen des Verkäufers gleichzeitig auf mehreren Computern verwendet werden kann, was eine Wettbewerbsverletzung i.S.d. § 1 UWG darstellen würde (OLG Stuttgart, NJW 1989, 2633 f).
Der Compiler des Sprachurhebers übersetzt in seiner Sprache geschriebene Quellcodes in eine für den Computer besser interpretierbare Zwischenform, den Zwischen-Code. Die Ausführbarkeit dieser Zwischenform ist direkt an das Sprach-Laufzeitsystem (Runtime) gekoppelt. Wenn das Sprach-Laufzeitsystem eine Art Dongle für die Sprache darstellen sollte, dann wird durch diesen Dongle ausschließlich der vom Compiler erzeugte Zwischen-Code geschützt, nicht etwa die vom Anwender geschriebenen Quellcodes. Dieser Zwischen-Code wird jedoch nicht übersetzt, sondern ausschließlich der ursprüngliche Quellcode des Anwenders.

Unabhängig davon ist das Sprach-Runtimesystem jedoch gar kein Dongle. Die Technologie, eine plattformunabhängige Zwischenform zu erzeugen und diese durch ein spezielles Laufzeitsystem ausführen zu lassen, ist ein weit verbreitetes Mittel zur Umgehung eventueller Inkompatibilitäten zwischen verschiedenen Systemen , und z.B. bei den Programmiersprachen Forth, Smalltalk, Java und verschiedenen Basic Dialekten zu finden. Mit einem Dongle-Schutz hat dies nichts zu tun.Außerdem ist der Schutz von Zwischen-Code mit Hilfe eines Dongles ein für die Branche völlig unübliches Verfahren. Durch einen Dongle wird nämlich normalerweise ein Produkt geschützt und nicht die mit dem Produkt erstellten Dokumente. So wird z.B. bei dem CAD (Computer-Aided Design) Programm "Autocad" das Produkt selbst vor unerlaubter Vervielfältigung geschützt, nicht die Zeichnungen, die mit dem Produkt erstellt wurden. Ganz im Gegenteil sind Autocad-Dokumente mit einer Vielzahl von anderen Programmen lesbar, ohne, daß hierdurch bisher jemand seine Rechte verletzt sah. Auch Autocad-Dokumente werden, in eine durch den Computer besser interpretierbare Form überführt und abgelegt. Wenn also dort das Auslesen der durch das Produkt erzeugten Zwischenform keine Rechtsverletzung darstellt ist fraglich, warum dies hier anders sein sollte. Es sei allerdings nochmals darauf hingewiesen, daß hier der Fremd-Compiler noch nicht einmal auf den vom SprachCompiler erzeugten Zwischen-Code zugreift, sondern unmittelbar auf die vom Anwender geschriebenen Quelltexte.
Abschließend sei erwähnt, daß es erheblich einfacher - und kostengünstiger - ist, einfach ein Programm zu entwickeln, welches den "Dongle" des Sprachurhebers knackt, als die Anwendungsprogramme der Kunden komplett in eine andere Programmiersprache zu übersetzen.

5.

Etwas weiter entfernt, aber trotzdem hier nicht uninteressant, ist das kartellrechtliche Koppelungsverbot.Als kartellrechtlicher Grundsatz ist dabei hervorzuheben, daß Koppelungsbedingungen prinzipiell als ein Fremdkörper in unserem geltenden System der Wettbewerbsordnung anzusehen sind. Koppelungsgeschäfte sind daher, sowohl aus kartell- als auch aus wettbewerbsrechtlicher Sicht, grundsätzlich kritisch zu beurteilen. Dies gilt besonders für Koppelungsgeschäfte, die wichtige technische Schlüsselindustrieprodukte bzw. Dienstleitungen betreffen (Lehmann, Portierung und Migration von Anwendersoftware, CR 1990, 700[702]).Eine derartige Koppelung, daß vom Anwender in einer Sprache erstellte Quellprogramme nur mit dem Sprach-Compiler in Zwischen-Code übersetzt werden dürfen, aber nicht mit einem anderen Compiler in andere Sprache, scheint somit auch aus dieser Sicht zumindest bedenklich.

6.

Demgegenüber erfassen die klassischen Verbotstatbestände des Wettbewerbsrechts den Fremd-Compiler nicht.
So liegt z.B. eine unmittelbare Leistungsübernahme i.S.d. § 1 UWG nicht vor, denn die Sittenwidrigkeit folgt bei Datenverarbeitungsprogrammen allein aus der Tatsache, daß der Wettbewerber ein Programm kopiert und somit ohne nennenswerte eigene Anstrengung einen Wettbewerbsvorsprung verschafft (OLG Frankfurt, NJW 2631 f). Ein "Schmarotzen an fremder Leistung" setzt im Software-Bereich das unmittelbare Kopieren eines Programmes voraus (LG München, MarlyRC 1983 Nr. 15). Eine solche Kopie, also die identische Übernahme des Quellcodes liegt aber wie bereits oben ausgeführt nicht vor.

Auch die Rechtsprechung zur Pflicht zur Vermeidung einer Herkunftstäuschung bei Kompatibilität mit der Produktserie des Wettbewerbers (OLG Köln, ZIP 1997, 2095 ff) greift vorliegend nicht. Dort hat das Gericht nämlich seine Entscheidung davon abhängig gemacht, ob die konkrete Ausgestaltung technisch bedingt und eine weitere Abweichung insofern nicht ohne Verlust der durch das andere System gewährleisteten technischen Vorteile möglich ist (OLG Köln, ZEP 1997, 2095[2097]), wobei der Kompatibilität im dort zur Entscheidung anstehenden Fall eines Baugerüstes kein schützenswerter Gesichtspunkt eingeräumt wurde. Im Softwarebereich stellt der Verlust von Kompatibilität mit anderen Produkten jedoch einen wesentlichen technischen Nachteil dar (LG München, MarlyRC 1983 Nr. 15). Auch die weitere Einschränkung des Gerichts, daß selbst bei Zulässigkeit des Vertriebs eines kompatiblen Geräts keine Herkunftstäuschung bewirkt werden dürfe, die ohne die Umstände, welche die Kompatibilität bewirken, vermeidbar wären (OLG Köln, ZIP 1997, 2095[2099]), ist vorliegend nicht erfüllt, denn die Anwender werden bei Erwerb des Fremd-Compilers nicht davon ausgehen, daß dieser von dem Sprach-Urheber stamme. Im Gegenteil ist es gerade ihre Absicht, den Kontakt zum Sprach-Urheber abzubrechen, warum die Kunden das Produkt des Fremdanbieters kaufen.Es ist auch nicht zutreffend, daß sich der Fremdanbieter nur an Kunden des Sprachurhebers wenden könnte, die bereits das Sprach-Entwicklungssystem erworben hätten. Es ist in der Regel nämlich nicht erforderlich, das Sprach-Entwicklungssystem zu nutzen, um in der Sprache zu programmieren. Vielmehr ist es bei professionellen Programmierern üblich, die Quellcodes für neue Anwendungen in einem normalen Texteditor einzugeben.

© 1998 Jens Barkemeyer