Die Richtlinie der Europäischen Gemeinschaften zum Schutz von Computersoftware wurde am 13. Mai 1991 verabschiedet. Ziel der Richtlinie ist es, ein einheitliches Schutzniveau für EDV-Programme in ganz Europa zu schaffen.
Der daraus resultierende Schutz wird sehr viel effektiver sein, als der, den die gegenwärtige deutsche Rechtslage gewährt. Denn immer noch gilt hierzulande die unselige Feststellung des Bundesgerichtshofes (BGH), wonach Programme nur ausnahmsweise urheberrechtsfähig sind, wenn sie eine ganz außerordentliche Gestaltungshöhe aufweisen.
Das wichtigste Anliegen der Richtlinie war es, von diesen übertriebenen Schutzvoraussetzungen abzukommen und auch dem durchschnittlichen und herkömmlichen Programm den Urheberrechtsschutz zu gewähren. In den offiziellen Darlegungsgründen der Richtlinie, die mitveröffentlicht werden, heißt es dazu wörtlich:
"Qualitative oder ästhetische Vorzüge eines Computerprogrammes sollten nicht als Kriterium für die Beurteilung der Frage angewendet werden, ob ein Programm ein individuelles Werk ist oder nicht. "Die Bestimmung ist nicht eindeutig
Die Richtlinie selbst bestimmt in Artikel 1, Absatz 3:
"Computerprogramme werden geschützt, wenn sie individuelle Werke in dem Sinne darstellen, daß sie das Ergebnis einer eigenen geistigen Schöpfung ihres Urhebers sind. Zur Bestimmung ihrer Schutzfähigkeit sind keine anderen Kriterien anzuwenden. "
Leider ist diese Bestimmung keineswegs so eindeutig wie der Erwägungsgrund. Ein Blick in das geltende Urheberrechtsgesetz (UrhG) macht dies besonders deutlich. ° 2, Abs. 2 UrhG bestimmt:
"Werke im Sinne dieses Gesetzes sind nur persönliche geistige Schöpfungen. "
Auf diese Vorschrift stützt der BGH seine übertriebenen qualitativen Anforderungen an Computerprogramme. Es ist nun nach Erlaß der Richtlinie von namhaften deutschen Juristen bereits argumentiert worden, daß sich der eigentliche Richtlinientext - im Gegensatz zum Erwägungsgrund - kaum vom geltenden Urheberrechtsgesetz unterscheidet. Dies könnte der BGH zum Anlaß nehmen, seine verfehlte Rechtsprechung aufrechtzuerhalten und fortzuführen.
Ich halte das nicht für überzeugend. Richtig daran ist, daß die Richtlinie in dieser - wie auch in vielen anderen Fragen - wenig präzise und eher unglücklich formuliert ist. Aus der gesamten Entstehungsgeschichte ergibt sich jedoch eindeutig der Wille der Kommission, ein einheitliches Schutzniveau zu schaffen. Meines Erachtens wird daher der Europäische Gerichtshof einschreiten, wenn der BGH nach Implementierung der Richtlinie seine bisherige Rechtsprechung fortsetzt. Für eine gewisse Übergangsperiode besteht hier jedoch noch Unsicherheit. Die Schutzberechtigten:
Artikel 3 der Richtlinie bestimmt, daß natürliche und juristische Personen nach dem geltenden deutschen Urheberrecht schutzberechtigt sind. Eine frühere Bestimmung, wonach im Auftrag erstellte Software dem Arbeitgeber oder Auftragnehmer zusteht, wurde gestrichen. Das ist einerseits zu begrüßen. Denn die Verteilung der Rechte an dem im Auftrag erstellten Programm gehört zu den schwierigsten und wirtschaftlich wichtigsten Fragen des EDV - Rechts, die bislang noch keineswegs klar geregelt ist. Allzu forsche Festlegungen hätten sich daher später als Bumerang erweisen können.
Hingewiesen werden muß allerdings auf einen besonderen Effekt dieser Gesetzgebungsgeschichte.
Namhafte deutsche Juristen vertreten die Ansicht, daß auch die Frage der Rechte von Arbeitnehmern an im Arbeitsverhältnis erstellten Programmen von der Richtlinie ausdrücklich offengehalten werde und daß deshalb die Diskussion um eine eventuelle Arbeitnehmer-Erfindungsvergütung für Software-Erstellung wieder aufgenommen werden sollte. Das erscheint mit zum gegenwärtigen Zeitpunkt nicht vernünftig.
Es ist nach längeren Irrungen und Wirrungen gelungen, in den zentralen Fragen des Software-Arbeitsrechts Einigkeit zu erzielen.
Ein wesentlicher Bestandteil dieser Einigkeit besteht darin, daß im Normalfall alle Ansprüche des angestellten Software-Arbeitnehmers durch sein Gehalt abgegolten sind und dem Arbeitgeber alle Verwertungsrechte zustehen sollen.
Das erscheint bei solchen Arbeitnehmern als angemessen und fair, die ausdrücklich zum Zweck der Programmierung eingestellt werden. Denn hier trägt der Arbeitgeber ja auch das Risiko, daß er Vergütung zahlen muß, obwohl keine Programme erstellt werden.
Auch hier könnte die Richtlinie eher Unsicherheit und Unklarheit schaffen, als zur Verstetigung der Rechtsentwicklung beitragen Es ist zu hoffen, daß der Gesetzgeber sich dieses Problems nicht annehmen wird. Reverse Engineering und Schnittstellen:
Die Fragen der Dekompilierung und der Offenlegung von Schnittstellen waren bekanntlich heiß umkämpft. Wer geglaubt hat, diese Kämpfe seien durch den Erlaß der Richtlinie nun beendet, wird vermutlich schon bald eines Besseren belehrt werden: Unglücklicherweise enthält die Richtlinie gerade in dieser brisanten Frage eine Reihe von Auslegungsproblemen und Wertungswidersprüchen, die sie schwer handhabbar machen. Ein Beispiel:
Artikel 5, Absatz 1, lautet:
"In Ermangelung spezifischer vertraglicher Bestimmungen bedürfen die in Art. 4 a und b genannten Handlungen nicht der Zustimmung des Rechtsinhabers, wenn sie für eine bestimmungsgemäße Benutzung des Computerprogrammes einschließlich der Fehlerberichtigung durch den rechtmäßigen Erwerber notwendig sind. "
Das bedeutet, daß unter anderem die Dekompilierung zulässig sein soll, wenn sie zur Fehlerberichtigung "notwendig" ist - also dann, wenn der Programmautor die Fehlerberichtigung nicht zu zumutbaren Bedingungen selbst anbietet.
Natürlich ist es eine ungemein wichtige Frage, ob diese Bestimmung vertraglich abbedungen werden kann.
Die Verwendung der Worte "in Ermangelung spezifischer vertraglicher Bestimmungen" deutet eindeutig darauf hin, daß der Lizenzgeber dem Lizenznehmer in der Tat das Reverse Engineering auch zum Zwecke der Fehlerberichtigung verbieten kann. Das könnte man auch aus dem eigentlich eindeutigen Wortlaut von Artikel 9, Absatz 1, folgern. In den - ja ebenfalls offiziellen - Erwägungsgründen heißt es indes:
"Dies bedeutet, daß das Laden und Ablaufen, sofern es für die Benutzung einer Kopie eines rechtmäßig erworbenen Computerprogrammes erforderlich ist, sowie die Fehlerberichtigung nicht vertraglich untersagt werden dürfen. "
Auf diesen Widerspruch hingewiesen, erklärte ein maßgebliches Mitglied der zuständigen Generaldirektion bei der EG, daß "selbstverständlich" nicht der eigentliche Richtlinientext sondern die Erwägungsgründe ausschlaggebend seien - eine Behauptung, für die deutsche Richter wohl wenig Verständnis aufbringen werden. Konsequenzen für die Vertragsgestaltung:
Die Richtlinie bedarf noch der Umsetzung in ein deutsches Gesetz. Nach Artikel 9, Absatz 2, finden ihre Bestimmungen "unbeschadet etwaiger vor dem 1. Januar 1993 getroffener Vereinbarungen und erworbener Rechte auch auf vor diesem Zeitpunkt geschaffene Programme Anwendung". Es ist daher vernünftig, sich schon heute in der Vertragsgestaltung auf die Richtlinie einzustellen. Hierbei dürfte insbesondere der Bereich des Reverse Engineering eine große Rolle spielen. Aus den Regelungen (siehe CW Nr. 10, 22 und 27 vom 8. März, 31. Mai und 5 Juli 1991) lassen sich derzeit wohl folgende praktische Empfehlungen ableiten: - Soweit dies möglich ist, sollte in Software-Überlassungsverträgen immer der Zweck des Programms einigermaßen klar zwischen den beiden Parteien vereinbart werden. Denn Dekompilierung und andere Bearbeitungshandlungen sind nach Artikel 5, Absatz 1, immer dann erlaubt, wenn sie für die "bestimmungsgemäße Benutzung" des Programmes erforderlich sind. Das legt es nahe, der Definition dieser bestimmungsgemäßen Benutzung größere Aufmerksamkeit als in der bisherigen Vertragspraxis zu widmen. - In die Verträge sollte - trotz gewisser Zweifel an der Wirksamkeit - ein ausdrückliches Verbot der Dekompilierung aufgenommen werden. Allerdings wird nach dem deutschen Gesetz über allgemeine Geschäftsbedingungen ein solches Verbot wohl nur dann wirksam sein, wenn der Lizenzgeber gleichzeitig die Berichtigung auftretender Fehler zu vernünftigen wirtschaftlichen Konditionen ermöglicht und dies auch ausdrücklich im Vertrag anbietet. - Gewährleistungsklauseln sollten überdacht werden. Klauseln, welche die gesetzlichen Rechte der Anwender zu stark einengen, sind ohnehin meist wegen Verstoßes gegen die Vorschriften des AGB-Gesetzes unwirksam. In Zukunft könnten sie darüber hinaus auch ausgesprochen gefährlich werden. Denn Klauseln, mit denen jede Fehlerbeseitigungspflicht abgestritten wird, könnten ebenfalls als Legitimation für eine Dekompilierung betrachtet werden. - Alle Softwarehäuser werden verpflichtet sein, die Schnittstellenspezifikationen dritten Parteien gegenüber offenzulegen. Auf den Programmhandbüchern sollte daher immer ein Hinweis enthalten sein, wo diese Schnittstellenspezifikationen zu welchen Bedingungen zu beziehen sind.
Umstritten ist unter Juristen bereits heute, welche Rechtsnatur der Artikel 6 der Richtlinie hat. Dabei geht es um ein wirtschaftlich außerordentlich bedeutsames Problem. Zum einen wird nämlich vertreten, daß es sich um eine sogenannte gesetzliche Zwangslizenz handelt. In diesem Fall wären Drittunternehmen berechtigt, den eigentlichen Code der Schnittstelle zu kopieren und in ihr eigenes Programm aufzunehmen beziehungsweise die zur wechselseitigen Abstimmung der Programme erforderlichen Bearbeitungen des fremden Schnittstellencodes vorzunehmen. Dabei ist auch noch umstritten, ob in diesem Fall eine Lizenzgebühr an den Rechtsinhaber zu zahlen ist. Die Industrie vertritt - mit Hinsicht auf die Entstehungsgeschichte und den Sinn der Vorschrift wohl mit einigem Recht - den entgegengesetzten Standpunkt. Danach verpflichtet Artikel 6 nicht zur Veröffentlichung von Code und berechtigt schon gar nicht dazu, diesen zu kopieren. Artikel 6 verpflichtet vielmehr nur, Informationen (Spezifikationen) über die entsprechenden Programmteile zu veröffentlichen - so, wie sie beispielsweise in Entwicklerhandbüchern vorhanden sind.
Jedenfalls sollte der Hersteller von Programmen immer bekanntgeben, wo die erforderlichen Programminformationen bezogen und eingesehen werden können. Denn andernfalls riskiert er, daß Wettbewerber wiederum zur Dekompilierung berechtigt sind.
Darüber hinaus sollte auch immer ausdrücklich das Angebot bestehen, daß weitere Informationen zur Verfügung gestellt werden. Dem liegt folgende Überlegung zugrunde: - Zweck der Richtlinie ist es ja gerade, die Interoperabilität neu geschaffener Programme mit bereits vorhandenen Programmen zu erzwingen. Wenn aber ein Softwarehaus B nun ein Programm entwickelt, das Daten mit dem Programm des Softwarehauses A in einer Art und Weise und in einer bestimmten Programmfunktion austauscht, die von Softwarehaus A ursprünglich nicht vorgesehen war, so kann wohl nach dem Richtlinientext Softwarehaus B von Softwarehaus A dennoch die zum Datenaustausch erforderlichen Informationen verlangen. Wenn dies zutrifft, dann wird die Schnittstelle des Programmes in Zukunft nicht mehr alleine vom Ausgangsprogrammierer definiert, sondern vor allem von später darauf folgenden Programmherstellern.
Nicht zuletzt im Hinblick auf diesen Umstand sollte das Design von Programmen in Zukunft noch sorgfältiger geprüft werden. Es kann nämlich vernünftig sein, möglichst alle Informationen und Programmzeilen in einen bestimmten Abschnitt des Programmes zu konzentrieren, die von Drittprogrammen benötigt werden, um Daten austauschen zu können.
Wenn ausnahmsweise Reverse Engineering in Zukunft zulässig sein wird, dann werden sich wohl auch in der Bundesrepublik sogenannte clean room procedures durchsetzen, wie sie in den USA bereits gebräuchlich sind. Denn zulässig ist nach der Richtlinie nur die sogenannte reverse analysis, nicht aber ein darauf aufbauendes forward programming. Das Programm darf analysiert werden, doch die so gewonnenen Erkenntnisse sollen allein zur Sicherung der Interoperabilität dienen. Das wird man wohl nur dann sicherstellen können, wenn die Programmierer, die das Dekompilieren betrieben haben, nicht identisch sind mit denen, die später die gewonnenen Erkenntnisse in das neue Programm aufnehmen.
Ein letzter kurzer Hinweis: Nach dem jetzigen Text der Richtlinie sind Softwarehersteller zwar verpflichtet, die Schnittstellen spezifikationen zu veröffentlichen. Sie sind aber nicht verpflichtet, diese Schnittstellenspezifikationen bei späteren Programmversionen beizubehalten. Es ist zu hoffen, daß dies nicht zum Anlaß genommen wird, Schnittstellen ständig zu ändern, um auf diese Weise die Interoperabilität von Drittprogrammen zu unterbinden.