235
Vervielfältigung und Verbreitung im Hinblick auf die Erschöpfung führt – wie im
Fall Parfumflakon und der Problematik gebrauchter Software – zu Ergebnissen, die
der Realität des Wirtschaftsverkehrs nicht angemessen sind.
II. Softwareschutz und Interoperabilität
Softwareentwickler sind darauf angewiesen, dass ihre Programme mit den Programmen anderer Hersteller kommunizieren können, d.h. dass die Programme interoperabel sind.1484 Um Interoperabilität herzustellen, können bestimmte Formen des
„reverse engineering“ notwendig sein, im Softwarebereich vor allem die Dekompilierung.1485 Weil der reine Objektcode von Computerprogrammen für Menschen
nicht lesbar ist, wird der Code hierbei in eine höhere Programmsprache übersetzt.1486
Das Ziel ist dabei, die relevanten Programmschnittstellen zu identifizieren.1487 Solche Übersetzungshandlungen können mit den Interessen des Softwareherstellers in
Konflikt treten. Andererseits kann der Zugang zu nachgelagerten Märkten verschlossen sein, wenn bestehende Immaterialgüterrechte die Herstellung von Interoperabilität verhindern. Daher beeinflussen die softwareschutzrechtlichen Regelungen
in Bezug auf Handlungen zur Herstellung von Interoperabilität die vertikale Kontrolle durch Immaterialgüterrechte. Nach einer Einordnung dieser Problematik in
den Kontext der Arbeit und einer Erörterung der Interessenlage soll im Folgenden
dargestellt werden, wie das Urheber- und das Patentrecht diesen Konflikt lösen. Ort
der Konfliktlösung sind dabei die Schutzschranken.
1. Vertikale Kontrolle und Interoperabilität
Das „reverse engineering“ von Software ist ungeeignet für die Herstellung von direkten Konkurrenzprodukten zu dieser Software. Einerseits ist es technisch nicht
möglich alle „Geheimnisse“ einer Software offenzulegen, weil diese sich oftmals
nur auf höheren Abstraktionsstufen und nicht aus dem Sourcecode selbst erschließen
1484 S. hierzu ausführlich Pohlmann/Müglich, S. 3 ff.
1485 Vgl. zum Überbegriff des „reverse engineering“ von Computersoftware Marly, S. 269 ff. u.
Pohlmann/Müglich, S. 81 f. Darüber hinaus zum gesamten Bereich von Interoperabilität bei
Software: Pohlmann/Müglich, S. 9 ff. „reverse engineering“ hat auch in anderen Industriebereichen eine große Bedeutung, s. etwa zum „reverse engineering“ in der Halbleiterindustrie
Samuelson/Scotchmer, 111 Yale L.J. 1575, 1595 ff. (2002).
1486 Grützmacher in: Wandtke/Bullinger, § 69e Rdnr. 1; Haberstumpf in: Mestmäcker/Schulze, §
69e Rdnr. 2; Loewenheim in: Schricker (Hrsg.), § 69e Rdnr. 4; Marly, S. 268; Vinje, GRUR
Int. 1992, 250, 254.
1487 Schnittstellen eines Betriebssystems, die für die Programmierung von Anwendungssoftware
notwendig sind, werden als „application programming interfaces“ (APIs) bezeichnet, s. Europäische Kommission, (s. Fn. 188), Tz. 38 – Microsoft; Samuelson/Scotchmer, 111 Yale L.J.
1575, 1615 f. (2002).
236
lassen.1488 Andererseits sind die Kosten eines solchen Vorgehens sehr hoch.1489 „Reverse engineering“ dient daher in erster Linie der Herstellung von Interoperabilität.1490 Das heißt aber auch das Handlungen des „reverse engineering“, und dabei vor
allem die für die Herstellung von Interoperabilität erforderliche Dekompilierung,
nicht die direkten Investitionsanreize für Software beeinträchtigen. Während die
direkte Imitation der Software durch reines Kopieren unstreitig unter den Urheberrechtsschutz fällt, sind damit subtilere Formen der Nachschaffung faktisch nahezu
ausgeschlossen, zumindest aber unüblich.1491
Trotzdem hat die Herstellung von Interoperabilität Bedeutung in Wettbewerbsverhältnissen. Eine genaue Abgrenzung von Horizontal- und Vertikalverhältnis ist
jedoch in den betroffenen „neuen Märkten“, die durch eine enorme Dynamik gekennzeichnet sind, extrem schwierig. Exemplarisch kann hier das europäische Microsoft-Verfahren angeführt werden.1492 Microsofts Weigerung, Schnittstelleninformationen an Sun Microsystems herauszugeben hatte horizontale Wirkung, weil beide
Unternehmen auf dem Markt für Arbeitsgruppenserver-Betriebssysteme tätig waren.1493 Gleichzeitig war Hauptgegenstand der Entscheidung aber die Übertragung
von Marktmacht vom Markt für Client-Betriebssysteme auf den Markt für Arbeitsgruppenserver-Betriebssysteme, also eine Konstellation, die einer vertikalen Logik
folgt.1494 Die konkrete Marktabgrenzung fällt in diesen Fällen deshalb schwer, weil
die betroffenen Produkte ständig ihr Anwendungsfeld ändern können. Produkte, die
eigentlich nicht mit dem Produkt auf einem anderen Markt konkurrieren, können
sich weiterentwickeln und so doch zum Substitut werden.1495 Zum Beispiel kann ein
„Media Player“ heute noch als eigenes Produkt von Betriebssystemen abgegrenzt
werden. Es ist jedoch nicht auszuschließen, dass ein „Media Player“, dessen Schnittstellen offen liegen, bei einer entsprechenden Entwicklung in Zukunft selbst zu einer
relevanten Plattform wird und mit Betriebssystemen konkurriert.1496
1488 Samuelson/Scotchmer, 111 Yale L.J. 1575, 1613 f. (2002); Hoeren in: Möhring/Nicolini, §
69d Rdnr. 1.
1489 Samuelson/Scotchmer, 111 Yale L.J. 1575, 1613 f. (2002).
1490 Samuelson/Scotchmer, 111 Yale L.J. 1575, 1614 f. (2002).
1491 Gegenbeispiele, die allerdings die Ausnahme bilden, nennt Samuelson/Scotchmer, 111 Yale
L.J. 1575, 1613 Fn. 182 (2002).
1492 Europäische Kommission, (s. Fn. 188), – Microsoft; in den wesentlichen Punkten bestätigt
durch EuG, WuW/E EU-R 1307 ff. – Microsoft/Kommission. Ein weiteres Beispiel findet
sich in der US-amerikanischen Rechtsprechung: Die Firma Connectix dekompilierte Programme der Firma Sony um die Emulation von Sony Playstation Spielen auf Apple Computern
zu ermöglichen. Damit war das Ziel des „reverse engineering“ hier ein konkurrierendes Produkt herzustellen, s. 203 F.3d 596 (9th Cir. 2000); Samuelson/Scotchmer, 111 Yale L.J. 1575,
1611 (2002).
1493 Europäische Kommission, (s. Fn. 188), Tz. 343 ff. – Microsoft.
1494 Zimmerlich, WRP 2004, 1260, 1266 f.
1495 Zimmerlich, WRP 2004, 1260, 1266.
1496 Europäische Kommission, (s. Fn. 188), Tz. 972 – Microsoft. Ein anderes Beispiel das die
Kommission hier nennt ist Java, eine sogenannte „middleware“, die im US-amerikanischen
237
Ihren Schwerpunkt haben Probleme der Interoperabilität allerdings im Vertikalverhältnis, weil es regelmäßig um das Versperren nachgelagerter Märkte geht. Das
zeigt die Diskussion der ökonomischen Wirkungsweisen, die dem „reverse engineering“ zugrunde liegen. Ein Anbieter der sich gegen solche Handlungen wehrt, bietet
regelmäßig ein geschlossenes System an, für dessen Funktionsfähigkeit er mehrere
Märkte kontrollieren muss. Ein Beispiel für ein geschlossenes System, dessen
Schnittstellen nicht offengelegt wurden, ist eine frühere Praxis der Spielkonsolenhersteller Nintendo und Sega. Diese weigerten sich eine Zeit lang, Schnittstelleninformationen für die Herstellung von Spielen für ihre Konsolen preiszugeben und
verklagten Firmen wegen des Anbietens von Spielen, die zu ihren Konsolen kompatibel waren.1497 Ein solches Vorgehen kann durchaus profitabel sein.1498 Es gilt weitgehend dasselbe, wie für die dargestellten Möglichkeiten der Ausübung von Marktmacht in einem Vertikalverhältnis.1499 Wenn der Spielkonsolenhersteller nicht nur
seine Konsole verkauft, sondern auch den Spielmarkt komplett kontrolliert, kann er
beide Tätigkeiten selbst ausführen (Integration) oder die Lizenzierung steuern.
Wenn er es schafft, eine große Zahl von Nutzern in sein System zu ziehen, wird er
profitabler als mit einem offenen System arbeiten. Das kann er zum Beispiel erreichen, wenn er die Konsole – also den Zugang zum System – billig verkauft und
seinen Profit aus dem Verkauf der Spiele zieht.1500 Gleichzeitig kann er Konkurrenten behindern, indem er von lizenzierten Spielherstellern verlangt, gleichzeitig keine
Spiele für konkurrierende Systeme herzustellen (Exklusivbindung).1501 Da all diese
Möglichkeiten bei entsprechenden Marktverhältnissen den Profit des Anbieters
erhöhen, schaden Regelungen, die eine Herstellung von Interoperabilität erzwingen,
den Innovationsanreizen des Systemanbieters.1502
Die dargestellte Strategie eines Schutzrechtsinhabers, seine Schnittstellen nicht
offenzulegen, begegnet jedoch einem entscheidenden Problem.1503 Sie wird nur
profitabel sein, wenn eine entsprechende Zahl von Konsumenten sein System nutzt.
In diesem Fall verstärken Netzwerkeffekte die Marktmachtwirkungen.1504 Wenn die
Schließung des Systems jedoch dazu führt, dass nur eine geringe Zahl von kompatiblen Anwendungen entsteht, kann es für die Konsumenten attraktiver sein, ein
offenes System zu nutzen, für das viele kompatible Anwendungen bestehen. Der
Microsoft-Verfahren eine größere Rolle gespielt hat, s. hierzu Hovenkamp/Janis/Lemley, §
21.8, S. 21-134 ff.
1497 Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992); Atari Games Corp. v.
Nintendo of Am., Inc., 975 F.2d 832 (Fed. Cir. 1992); Samuelson/Scotchmer, 111 Yale L.J.
1575, 1617 (2002).
1498 Zum Folgenden Samuelson/Scotchmer, 111 Yale L.J. 1575, 1617 f. (2002). S. auch Zimmerlich, WRP 2004, 1260, 1262.
1499 S. oben Teil 2 B.
1500 S. oben Teil 2 B. V.
1501 S. oben Teil 2 B. III.
1502 Samuelson/Scotchmer, 111 Yale L.J. 1575, 1621 f. (2002).
1503 Zum Folgenden: Samuelson/Scotchmer, 111 Yale L.J. 1575, 1618 f. (2002).
1504 Hierzu s. oben Teil 2 B. II. 4. b).
238
Computerhersteller IBM verfolgte daher in den 80er Jahren eine Strategie der Öffnung. Dabei verlangte er von Microsoft, das das Betriebssystem für IBM-PCs lieferte, die Schnittstellen für dieses Betriebssystem offenzulegen, um eine große Zahl an
Anwendungen für den IBM-PC zu ermöglichen.1505 Im Ergebnis ist also eine Kombination der Strategien optimal: Die Offenlegung von Schnittstellen ist optimal bis
eine entsprechende Marktstellung erreicht ist, die Schließung des Systems bietet sich
an, wenn eine solche Stellung erreicht worden ist. Ein solcher Strategie-Mix könnte
man hinter dem Vorgehen des Unternehmens Microsoft vermuten, dessen Schnittstellenpolitik mit zunehmender Marktmacht restriktiver wurde.1506
Auch aus Sicht der Konsumenten und der gesamtgesellschaftlichen Wohlfahrt
kann die Schnittstellenproblematik nicht eindeutig bewertet werden. Offene Systeme
lassen eine größere Produktvielfalt erwarten. Soweit dies einen stärkeren Wettbewerb, zum Beispiel zwischen verschiedenen Anwendungsprogrammen für ein Betriebssystem oder verschiedenen Spielen für eine Spielkonsole, bewirkt, wird sich
dies auch in niedrigeren Endverkaufspreisen zeigen.1507 Aber auch ein geschlossenes
System kann dem Konsumenten nutzen, etwa wenn der Anbieter eines solchen Systems mehr in dessen Qualität investiert. Eindeutig negativ wirkt sich ein geschlossenes System wohl nur aus, wenn der Marktzugang auf beiden Marktstufen, also der
Eintritt eines konkurrierenden Systems, verhindert wird.1508 Genau das kann aber
wiederum durch Regelungen, die die Herstellung von Interoperabilität erlauben,
verhindert werden.1509 Zudem muss ein weiteres Problem berücksichtigt werden:
„Reverse engineering“ verursacht nicht nur selbst erhebliche soziale Kosten, sondern führt auch zu höheren Aufwendungen der Hersteller, die schon im Vorfeld
versuchen werden, dies technisch zu verhindern.1510 Eine Regelung, die „reverse
engineering“ erlaubt, könnte diese Kosten auf beiden Seiten schon von Anfang an
nutzlos werden lassen, und so einen effizienteren Mitteleinsatz bewirken.1511
Zuletzt sind weitere dynamische Aspekte zu beachten. Kann sich ein Schutzrechtsinhaber gegen die Herstellung von Interoperabilität wehren, behält er sich
bestimmte Entwicklungsmöglichkeiten des Programms vor. Hier kann das „prospect“ Argument für diese Kontrolle fruchtbar gemacht werden, wobei auch dessen
Schwächen berücksichtigt werden müssen.1512 Soweit die Schutzwirkung Lizenzie-
1505 Samuelson/Scotchmer, 111 Yale L.J. 1575, 1616 (2002).
1506 Europäische Kommission, (s. Fn. 188), Tz. 587 f. – Microsoft; Samuelson/Scotchmer, 111
Yale L.J. 1575, 1619 (2002); Zimmerlich, WRP 2004, 1260, 1265.
1507 Samuelson/Scotchmer, 111 Yale L.J. 1575, 1623 ff. (2002). Auch Zimmerlich, WRP 2004,
1260, 1262 geht von wohlfahrtsvermehrenden Effekten aus.
1508 Samuelson/Scotchmer, 111 Yale L.J. 1575, 1618 (2002); Zimmerlich, WRP 2004, 1260,
1268; s. oben Teil 2 B. V. 4. cc).
1509 Samuelson/Scotchmer, 111 Yale L.J. 1575, 1624 f. (2002).
1510 Samuelson/Scotchmer, 111 Yale L.J. 1575, 1625 (2002).
1511 Samuelson/Scotchmer, 111 Yale L.J. 1575, 1625 (2002)
1512 S. oben Teil 2 C. I. 2. a).
239
rungen nach sich zieht, sind die Probleme der Funktionsfähigkeit des Lizenzmarktes
zu berücksichtigen.1513 Zudem können Informationen zur Herstellung von Interoperabilität eine Infrastrukturressource darstellen und ihr Schutz damit den von Frischmann beschriebenen Problemen begegnen.1514 Schließlich sind hier vor allem die
Rückwirkungen auf den Informationsproduktionsprozess im Ganzen zu berücksichtigen: Schafft es ein Schutzrechtsinhaber die technische Abschottung seines Programms auch rechtlich durchzusetzen, kann dies die Quelle für wertvolle Inputs verschließen, aus denen sich vielfältige Ansätze zur Hervorbringung neuer Informationsprodukte speisen.1515 Im Folgenden soll gezeigt werden, wie das Recht auf die
den dargestellten Problembereich der Interoperabilität reagiert.
2. Urheberrecht
Software kann zunächst urheberrechtsschutzfähig sein. Dazu müssen die Voraussetzungen der §§ 69a ff. UrhG erfüllt sein. Gem. § 2 Abs. 1 UrhG ist ein Computerprogramm ein Unterfall des Sprachwerks. Soll Interoperabilität zwischen verschiedenen Computerprogrammen hergestellt werden, stellt sich zunächst ein faktisches
Problem: Der reine Objektcode von Computerprogrammen ist für Menschen nicht
lesbar.1516 Deshalb ist es notwendig, den Code eines Programms in eine höhere
Programmsprache zurück zu übersetzen (Dekompilierung).1517 Zur Herstellung von
Interoperabilität mit anderen Programmen erlaubt § 69e UrhG Vervielfältigungsund Übersetzungshandlungen, die dem Urheber eigentlich nach §§ 69c Nr. 1 und
Nr. 2 UrhG vorbehalten sind.1518 Diese Regelung trägt den Besonderheiten des
Computerprogramms als urheberrechtlichem Schutzobjekt Rechnung. Wie allgemein im Urheberrecht, gilt auch hier, dass Ideen und Grundsätze dem Schutz durch
das Ausschließlichkeitsrecht nicht zugänglich sind. § 69a Abs. 2 S. 2 UrhG stellt
dies für die den Schnittstellen zu Grunde liegenden Ideen und Grundsätze klar.
1513 S. oben Teil 2 C. I. 3. u. Teil 2 C. II. 3.
1514 S. oben Teil 2 C. II. 4.
1515 S. oben Teil 2 C. II. 5.
1516 Grützmacher in: Wandtke/Bullinger, § 69e Rdnr. 1; Loewenheim in: Schricker (Hrsg.), § 69e
Rdnr. 4; Marly, S. 268.
1517 Grützmacher in: Wandtke/Bullinger, § 69e Rdnr. 1; Haberstumpf in: Mestmäcker/Schulze, §
69e Rdnr. 2; Loewenheim in: Schricker (Hrsg.), § 69e Rdnr. 4; Vinje, GRUR Int. 1992, 250,
254. Neben der Dekompilierung, erfasst § 69e UrhG auch die Disassemblierung, eine andere
Form der Aufwärtsübersetzung, und die Rekompilierung für den Vergleich mit dem Originalcode, Grützmacher in: Wandtke/Bullinger, § 69e Rdnr. 5.
1518 § 69e UrhG beruht auf Art. 6 der Software-RL (vgl. oben Fn. 31). Die Regelung erfasst nicht
die Dekompilierung zu Zwecken der Programmwartung, Fehlerberichtigung oder wissenschaftlichen Forschung, Loewenheim in: Schricker (Hrsg.), § 69e Rdnr. 10. Vgl. zur Kontrolle
von (nachgelagerten) Märkten für Wartungsleistungen durch das Software-Urheberrecht
Bechtold, Die Kontrolle von Sekundärmärkten, S. 88 ff. u. Dreier in: Schricker/Dreier/Kur
(Hrsg.), S. 51, 53 f.
240
Bei Computerprogrammen kann dieser Grundsatz jedoch nicht vollständig zur
Geltung kommen. Ideen und Grundsätze von traditionellen Sprachwerken erschlie-
ßen sich schon durch Lesen, Hören oder Anschauen.1519 Weil der geschützte Programmcode von Software jedoch nicht ohne weiteres lesbar ist, erlauben die Ausschlussbefugnisse des Softwareurheberrechts dem Urheber eigentlich, den Zugang
zu diesen Ideen zu versperren.1520 Im Ergebnis bewirkt dies einen Know-how-Schutz
für den Softwarehersteller, der als Anzeichen einer systemwidrigen Einordnung von
Computerprogrammen in das urheberrechtliche Schutzsystem gewertet wird.1521
Dessen Auswirkungen korrigiert § 69e UrhG, indem er die mittelbare Monopolisierung der Schnittstelleninformationen verhindern will.1522 Soweit Abgrenzungsschwierigkeiten zwischen den als Ideen und Grundsätzen nicht geschützten Schnittstellenspezifikationen und dessen geschützter konkreter Implementierung bestehen,
ist im Zweifel auch die Übernahme der geschützten Merkmale zulässig.1523 Damit
dient die Vorschrift dem Wettbewerb auf dem Computermarkt und im Endeffekt
dem technischen Fortschritt.1524 Rechtssystematisch ist die Regelung eine Zwangslizenz1525 und trotz ihrer Verortung im Urheberrecht auch kartellrechtlicher Natur.1526
Sie erfordert aber im Gegensatz zur Möglichkeit einer Offenlegung von Schnittstellen durch das allgemeine Kartellrecht, etwa durch § 19 GWB oder Art. 82 EG, nicht,
dass das betroffene Unternehmen marktbeherrschend ist.1527 Zudem muss der Urheber bei Anwendung von § 69e UrhG die Dekompilierung nur dulden und nicht selbst
tätig werden. Demgegenüber hat die Kommission dem Unternehmen Microsoft in
1519 Marly, S. 272.
1520 Begr. d. RegE eines zweiten Gesetzes zur Änderung des Urheberrechtsgesetzes, BT-Drs.
12/4022, S. 13; Lehmann, GRUR Int. 1991, 327, 333; Loewenheim in: Schricker (Hrsg.), §
69e Rdnr. 1.
1521 Begr. d. RegE eines zweiten Gesetzes zur Änderung des Urheberrechtsgesetzes, BT-Drs.
12/4022, S. 13; Marly 1995, S. 273; Loewenheim in: Schricker (Hrsg.), § 69e Rdnr. 1.
1522 Begr. d. RegE eines zweiten Gesetzes zur Änderung des Urheberrechtsgesetzes, BT-Drs.
12/4022, S. 13; Grützmacher in: Wandtke/Bullinger, § 69e Rdnr. 1.
1523 Loewenheim in: Schricker (Hrsg.), § 69e Rdnr. 18; Haberstumpf in: Mestmäcker/Schulze, §
69e Rdnr.5; Funk/Zeifang in: Ullrich/Lejeune (Hrsg.), Teil I Rdnr. 54; a.A. Grützmacher in:
Wandtke/Bullinger, § 69e Rdnr. 11 mit Hinweis auf die Möglichkeit einer Clean-Room-
Programmierung.
1524 Begr. d. RegE eines zweiten Gesetzes zur Änderung des Urheberrechtsgesetzes, BT-Drs.
12/4022, S. 13; Grützmacher in: Wandtke/Bullinger, § 69e Rdnr. 1.
1525 Mestmäcker in: Becker/Lerche/Mestmäcker (Hrsg.), S. 419, 427 f.
1526 Marly, S. 280; Haberstumpf in: Mestmäcker/Schulze, § 69e Rdnr. 2. Ursprünglich sollte die
Schnittstellenproblematik nicht im Urheberrecht geregelt, sondern dem allgemeinen Kartellrecht vorbehalten werden, vgl. Lehmann, GRUR Int. 1991, 327, 333 m.w.N.
1527 Vgl. zum europäischen Kartellrecht: Europäische Kommission, (s. Fn. 188), – Microsoft; in
den wesentlichen Punkten bestätigt durch EuG, WuW/E EU-R 1307 ff. – Microsoft/Kommission. Zum deutschen Kartellrecht (allerdings in Anwendung des Diskriminierungs- und Behinderungsverbotes aus § 26 Abs. 2 GWB a.F., jetzt § 20 Abs. 1, Abs. 2 GWB
n.F.): OLG München, NJW-WettbR 1999, 142.
241
Anwendung des Art. 82 EG auferlegt, aktiv Schnittstelleninformationen herauszugeben.1528
Die Regelung des § 69e UrhG berücksichtigt neben den Wettbewerbsinteressen
jedoch auch die Interessen der Rechtsinhaber. Diese sind hauptsächlich darauf gerichtet, der Konkurrenz durch die Preisgabe des Quellcodes keine über die reine
Herstellung von Interoperabilität hinausgehenden Wettbewerbsvorteile zu ermöglichen.1529 § 69e Abs. 1 UrhG lässt die entsprechenden Handlungen nur zu, wenn
diese für die Herstellung der Interoperabilität unerlässlich sind, wenn die erforderlichen Informationen nicht schon ohne weiteres zugänglich gemacht sind (Nr. 2) und
wenn die Handlungen sich auf die für die Interoperabilität notwendigen Teile des
Programms beschränken (Nr. 3). § 69e Abs. 1 Nr. 1 UrhG beschränkt den personellen Anwendungsbereich zudem auf den Lizenznehmer und die nach § 69d UrhG
Nutzungsberechtigten. § 69e Abs. 2 UrhG sichert die Interessen des Urhebers darüber hinaus durch bestimmte Weiterverwendungsverbote ab, während § 69e Abs. 3
UrhG eine weitere Interessenabwägung entsprechend der Regelung des Art. 9 Abs. 2
RBÜ (Dreistufentest) enthält.1530
§ 69e UrhG ist insoweit eine Beschränkung des Ausschließlichkeitsrechts in vertikaler Hinsicht, als die Vorschrift sicherstellt, dass Programme entwickelt werden
können, die einen anderen Bedarf als das Ursprungsprogramm bedienen, mit diesem
aber kommunizieren müssen. Wichtigstes Beispiel hierfür ist die Entwicklung von
Anwendungssoftware für ein bestimmtes Betriebssystem.1531 Allerdings kommt der
Vorschrift auch Bedeutung im Horizontalverhältnis zu. Denn wenn ihre Voraussetzungen erfüllt sind, dürfen auch Programme dekompiliert werden, die mit dem neu
zu schaffenden Programm im Wettbewerb stehen und durch dieses ersetzt werden
können.1532 Das wird aus dem Wortlaut geschlossen, der entgegen anderer diskutier-
1528 Europäische Kommission, (s. Fn. 188), Tz. 747 – Microsoft; EuG, WuW/E EU-R 1307 ff. –
Microsoft/Kommission. Die Entscheidung der Kommission wird teilweise kritisiert, soweit sie
über die Regelung des § 69e UrhG hinausreicht: § 69e UrhG basiere auf einem Interessenkompromiss, der bereits wettbewerbsrechtliche Aspekte berücksichtige, s. Dreier in:
Dreier/Schulze, § 69e Rdnr. 6.
1529 Begr. d. RegE eines zweiten Gesetzes zur Änderung des Urheberrechtsgesetzes, BT-Drs.
12/4022, S. 13; Loewenheim in: Schricker (Hrsg.), § 69e Rdnr. 2. Umfassend zu Interessenkollisionen unter Berücksichtigung aller beteiligten Interessen Marly, S. 276 ff.
1530 Vgl. zur umstrittenen Regelung des § 69e Abs. 3 UrhG: Grützmacher in: Wandtke/Bullinger,
§ 69e Rdnr. 24; Loewenheim in: Schricker (Hrsg.), § 69e Rdnr. 22.
1531 Marly, S. 280 f.; Europäische Kommission, (s. Fn. 188), Tz. 37 ff. – Microsoft.
1532 OLG Düsseldorf, CR 2001, 371, 372; Grützmacher in: Wandtke/Bullinger, § 69e Rdnr. 8;
Haberstumpf in: Mestmäcker/Schulze, § 69e Rdnr. 7; Loewenheim in: Schricker (Hrsg.), §
69e Rdnr. 12 jeweils m.w.N. Dazu wurde vorgeschlagen dieses Ergebnis über Art. 6 Abs. 3
der Software-RL, der durch § 69e Abs. 3 UrhG umgesetzt wurde, zumindest dann zu korrigieren, „wenn ein Programm so gestaltet und angeboten wird, daß es das kompilierte Programm auf dem Markt in einer wettbewerbsverfälschenden Weise ersetzt“, Moritz, CR 1993,
257, 266.
242
ter Formulierungen die Interoperabilität „mit anderen Programmen“ und damit nicht
nur mit dem dekompilierten Programm ermöglichen will.1533 Welchen Abstand das
zu schaffende kompatible Programm – in horizontaler oder vertikaler Richtung –
vom dekompilierten Programm haben muss, wird durch die allgemeinen Regelungen
des Urheberrechts festgelegt. Das neue Programm muss unabhängig geschaffen
worden sein und darf nicht als eine reine Bearbeitung des Ausgangsprogramms
erscheinen.1534 § 69e Abs. 2 Nr. 3 UrhG hat insofern keine eigenständige Bedeutung.1535 Eine rein funktionale Nachschaffung bleibt damit aber erlaubt.1536
Welchen konkreten Nutzen die Vorschrift hat, bleibt unklar.1537 Zumindest gab es
in der bisherigen Rechtsprechungspraxis kaum Fälle, in denen diese Norm eine
zentrale Rolle spielte. Dies kann einerseits darauf zurückzuführen sein, dass die
Dekompilierung schwer zu verfolgen ist, da sie regelmäßig im Betrieb des potentiellen Verletzers stattfindet.1538 Andererseits kann es daran liegen, dass eine Reihe
wichtiger Hersteller ihre Schnittstellen ohnehin offenlegen, was vor allem in der
Wachstumsphase ökonomisch rational ist.1539 Bei „open source“-Projekten gehört
die Offenlegung der Schnittstellen dagegen schon zur grundlegenden Politik.1540 In
jedem Fall ist die Vorfeldwirkung der Regelung nicht zu unterschätzen. Denn dass
Hersteller in bestimmten Situationen den Anreiz zu einer Abschottung der Schnittstellen haben, ist zumindest seit dem Microsoft-Verfahren offensichtlich.
3. Patentrecht
Computerprogramme können auch Gegenstand des Patentrechts sein. Zwar ist der
Schutz von Programmen für Datenverarbeitungsanlagen als solche gem. § 1 Abs. 3
Nr. 3, Abs. 4 PatG und Art. 52 Abs. 2 lit. c, Abs. 3 EPÜ ausgeschlossen. Jedoch
nimmt die Rechtsprechung von BGH und EPA die Patentfähigkeit an, wenn das
1533 Moritz, CR 1993, 257, 266; Loewenheim in: Schricker (Hrsg.), § 69e Rdnr. 12; Grützmacher
in: Wandtke/Bullinger, § 69e Rdnr. 8.
1534 Haberstumpf in: Mestmäcker/Schulze, § 69e Rdnr. 9; Loewenheim in: Schricker (Hrsg.), §
69e Rdnr. 9.
1535 Haberstumpf in: Mestmäcker/Schulze, § 69e Rdnr. 15; Loewenheim in: Schricker (Hrsg.), §
69e Rdnr. 21; Grützmacher in: Wandtke/Bullinger, § 69e Rdnr. 22. Vgl. dagegen zur umstrittenen Frage, ob § 69e Abs. 2 Nr. 3 UrhG eine Vorverlagerung des Schutzes auf die Entwicklung und Herstellung bewirkt einerseits Haberstumpf in: Mestmäcker/Schulze, § 69e Rdnr. 15
u. Grützmacher in: Wandtke/Bullinger, § 69e Rdnr. 8 und andererseits Loewenheim in: Schricker (Hrsg.), § 69e Rdnr. 21 u. Marly, S. 321 f.
1536 Grützmacher in: Wandtke/Bullinger, § 69e Rdnr. 22. Anders kann sich dies bei einem Schutz
von Software durch Patentrecht, vgl. Kraßer, S. 170 f.
1537 Hoeren in: Möhring/Nicolini, § 69d Rdnr. 1 stellt den Sinn der Regelung wegen der zugrunde
liegenden technischen Schwierigkeiten überhaupt in Frage.
1538 Dreier in: Dreier/Schulze, § 69e Rdnr. 7.
1539 Dreier in: Dreier/Schulze, § 69e Rdnr. 7 u. Teil 3 C. II. 1.
1540 Dreier in: Dreier/Schulze, § 69e Rdnr. 7 u. die Hinweise in Teil 2 C. II. 5.
243
Programm technisch im Sinne des patentrechtlichen Erfindungsbegriffes ist.1541
Benötigt der Entwickler einer Software, die zu einem patentgeschützten Programm
kompatibel sein soll, nun die entsprechenden Schnittstelleninformationen, ist er
zunächst dem faktischen Problem ausgesetzt, dass der reine Objektcode für den
Menschen nicht lesbar ist. Anders als der Urheberrechtsschutz hängt der Patentrechtsschutz zwar von einer Anmeldung des Patents ab, bei der die Erfindung offenbart werden muss (vgl. § 34 PatG). Jedoch werden die für die Herstellung von Interoperabilität notwendigen Informationen aus dem Quellcode in diesem Verfahren
zumeist nicht oder nicht in entsprechender Qualität offen gelegt.1542
Die Herstellung von Interoperabilität hängt daher von der patentrechtlichen Zulässigkeit von Maßnahmen des „reverse engineering“, etwa der Dekompilierung,
ab.1543 Eine dem § 69e UrhG entsprechende Schutzbeschränkung besteht im Patentrecht nicht.1544 Daher kommt es auf Anwendung der allgemeinen Regeln an. Zunächst müsste das Dekompilieren eine Verletzungshandlung i.S.d. § 9 PatG darstellen. Werden die Schnittstelleninformationen in einem anderen Programm genutzt,
was zur Herstellung von Interoperabilität notwendig ist, kommt dies regelmäßig
einer Neuherstellung des Erfindungsgegenstandes gleich, die bei einem Erzeugnispatent dem Schutzrechtsinhaber durch den § 9 S. 2 Nr. 1 PatG vorbehalten ist.1545
Die Beurteilung beim Verfahrenspatent gem. § 9 S. 2 Nr. 2 PatG ist schwieriger:
Abzugrenzen ist zwischen einer Anwendung des Verfahrens und den Vorbereitungshandlungen hierfür. Solche können etwa im Herstellen einer Vorrichtung oder
eines Hilfsmittels zur Anwendung des Verfahrens liegen und sind noch nicht patentverletzend.1546 Die Anwendung eines als Verfahren geschützten Programms beginnt
spätestens mit dem Ablaufen des Programms,1547 eventuelle aber auch schon mit
dem Laden des Programms.1548 Eine genaue Abgrenzung fällt jedoch schwer, da
Rechtsprechung für den Bereich der Software hier fehlt.1549
1541 BGH, GRUR 2004, 667 ff. – Elektronischer Zahlungsverkehr; BGH, GRUR 2000, 498 ff. -
Logikverifikation; EPA, GRUR Int. 1995, 909, 911 f. – Universelles Verwaltungssystem/SOHEI; EPA, GRUR Int. 1999, 1053, 1055 f. – Computerprogrammprodukt/IBM. Vgl.
ausführlich hierzu Bacher/Melullis in: Benkard, PatG, § 1 Rdnr. 107 ff. u. Kraßer, S. 145 ff.
1542 Pohlmann/Müglich, S. 78 f.; Weyand/Haase, GRUR 2004, 198, 201. Vgl. kritisch zur Forderung einer obligatorischen Vorlage des Quellcodes als Offenbarung bei einer computerprogrammbezogenen Erfindung Tauchert, GRUR 2004, 922 f.
1543 Vgl. hierzu Pohlmann/Müglich, S. 78 ff.
1544 Nur das Halbleiterschutzgesetz enthält in § 6 Abs. 2 Nr. 2 und Nr. 3 Regeln, die Situationen
des „reverse engineering“ erfassen. Eine Anwendung dieser Regelungen auf das Patentrecht
scheidet zumindest in den relevanten Fällen jedoch aus, vgl. Pohlmann/Müglich, S. 82.
1545 Pohlmann/Müglich, S. 83. Zum Verbot der Neuherstellung BGH, GRUR 1973, 518, 520 –
Spielautomat II; Scharen in: Benkard, PatG, § 9 Rdnr. 36 m.w.N.
1546 BGH, GRUR 2005, 845, 847 – Abgasreinigungsvorrichtung; Keukenschrijver in: Busse, § 9
Rdnr. 88; Scharen in: Benkard, PatG, § 9 Rdnr. 49.
1547 Scharen in: Benkard, PatG, § 9 Rdnr. 49.
1548 Kraßer in: Lehmann (Hrsg.), S. 221, 275 f. Rdnr. 119.
1549 Pohlmann/Müglich, S. 84.
244
Bedeutsam ist daher, ob sich aus den patentrechtlichen Beschränkungen eine eindeutige Beurteilung der Herstellung von Interoperabilität durch Dekompilierung
ergibt. Nach § 11 Nr. 1 PatG nicht vom Patentschutz erfasst wäre die Handlung,
wenn sie im privaten Bereich und zu nichtgewerblichen Zwecken vorgenommen
würde.1550 Eine weitere Freistellungsmöglichkeit bietet § 11 Nr. 2 PatG, wenn die
Handlung Versuchszwecken dient und sich auf den Gegenstand der patentierten
Erfindung bezieht. Dafür müsste ein Versuch im Sinne des § 11 Nr. 2 PatG vorliegen. Ein Versuch in diesem Sinne ist jedes planmäßige Vorgehen zur Gewinnung
von Erkenntnissen, und zwar unabhängig davon, welchem Zweck die erstrebten
Erkenntnisse zu dienen bestimmt sind.1551 Dabei muss der Gegenstand der Erfindung
Objekt der Versuchshandlung zum Zweck der Erlangung von Erkenntnissen sein.1552
Ausgenommen sind daher Versuche, die die Erfindung zum Mittel der Versuchshandlungen machen.1553 Dies rechtfertigt sich durch den Zweck des Patentrechts,
den technischen Fortschritt zur fördern und nicht zu hemmen.1554 Bei der Dekompilierung zur Herstellung von Interoperabilität geht es aber nicht darum, neue Erkenntnisse über die dekompilierte Software zu gewinnen, sondern darum, das eigene,
neue Programm interoperabel, und damit vielleicht erst marktfähig zu machen.1555
Das Forschungsprivileg wird daher in der Regel hier nicht greifen, womit sich eine
vom Urheberrecht abweichende Rechtslage ergibt.1556 Auch die patentrechtliche
Zwangslizenz gem. § 24 PatG wird dies wegen ihrer hohen Anforderungen nicht
korrigieren können.1557
Die Schwierigkeiten bei der Rechtfertigung von Dekompilierungshandlungen im
Patentrecht können zu Konflikten mit dem Urheberrecht führen, wenn eine Handlung im Patentrecht verboten und im Urheberrecht erlaubt ist. Für diesen Fall
enthielt der „Vorschlag für eine Richtlinie des Europäischen Parlaments und des
Rates über die Patentierbarkeit computerimplementierter Erfindungen“ der Kommission vom 20. 2. 2002 eine Regelung.1558 Art. 6 des Vorschlags sah vor, dass zur
Herstellung von Interoperabilität zulässige Handlungen im Sinne der Software-
RL,1559 also vor allem die urheberrechtliche erlaubte Dekompilierung, von den patentrechtlichen Regelungen unberührt bleiben sollen. Allerdings wurde der Richtlinienvorschlag am 6. 7. 2005 durch das EU-Parlament in zweiter Lesung abge-
1550 Die urheberrechtlichen Ausschlussbefugnisse wirken jedoch auch hier, vgl. Weyand/Haase,
GRUR 2004, 198, 200 f.
1551 BGH, GRUR 1996, 109, 112 – Klinische Versuche; Scharen in: Benkard, PatG, § 11 Rdnr. 6.
1552 BGH, GRUR 1996, 109, 113 – Klinische Versuche.
1553 BGH, GRUR 1996, 109, 114 – Klinische Versuche.
1554 BGH, GRUR 1996, 109, 114 – Klinische Versuche; Scharen in: Benkard, PatG, § 11 Rdnr. 6;
Kraßer, S. 813.
1555 Pohlmann/Müglich, S. 85 f.
1556 Pohlmann/Müglich, S. 86; Weyand/Haase, GRUR 2004, 198, 200 f.
1557 Vgl. Pohlmann/Müglich, S. 91 f. Zu den Voraussetzungen der Zwangslizenz BGH, GRUR
1996, 190 ff. – Polyferon; Kraßer, S. 857 ff.
1558 ABl. EG Nr. C 151 E vom 25. 6. 2002, S. 129 ff.
1559 S. Fn. 31.
245
lehnt.1560 Ob die urheberrechtliche Beschränkung zugunsten der Dekompilierung
eine Sperrwirkung für die Ausübung von Patentrechten entfaltet, bleibt damit umstritten.1561
4. Bewertung
Die technische Abschottung von Produkten und darauf antwortende „reverse engineering“-Bemühungen gab es schon vor dem Aufstieg von Software und anderer
digitaler Güter in der Informationsgesellschaft.1562 Die Komplexität von Softwarecode macht dies jedoch heutzutage zu einem zentralen Problem der betroffenen
Industrie.1563 Mechanismen, die den immaterialgüterrechtlichen Schutz gegenüber
Folgeinnovationen begrenzen, finden hier ihre Fortsetzung auf technischem Gebiet.
Im Bereich des herkömmlichen Urheberrechts ist es unproblematisch auf bestehenden Leistungen aufzubauen; es ist einzig die Abgrenzung zwischen unfreier Bearbeitung gem. § 23 UrhG und freier Benutzung gem. § 24 UrhG zu beachten.1564 Die
urheberrechtliche Dekompilierungsschranke in § 69e UrhG setzt dies im Softwarebereich fort und stellt sicher, dass legale Nutzungen nicht faktisch durch die Schwierigkeiten der Technik verhindert werden. Eine solche Regelung ist elementar für
eine arbeitsteilige Wirtschaft, auch wenn sie nur „abschreckende“ Wirkung und
keine Bedeutung in der Rechtsprechung hat. Inwieweit sich das Patentrecht in diese
Funktionsweise einfügen lässt, ist vor allem von der Entwicklung des übrigen patentrechtlichen Softwareschutzes abhängig.
Wie schon bei der Erörterung des Bearbeitungsrechts, kann auch hier festgestellt
werden, dass horizontale und vertikale Wirkungsrichtung schwierig voneinander
abzugrenzen sind. Die Intention der Dekompilierungsschranke aus § 69e UrhG liegt
ganz klar in einer Ermöglichung von Folgeprodukten bzw. der Funktionsfähigkeit
von Folgemärkten. Zudem ist die reine Imitation von Softwareprodukten durch
„reverse engineering“ ohnehin nicht zweckmäßig. Eine direkte Bedrohung des Innovationsanreizes ist daher ausgeschlossen. Zu Wettbewerb durch interoperable Produkte kann es jedoch kommen, wenn die technische Funktionalität des Originalprogramms mit der von interoperabel gemachten Programmen austauschbar ist. Inso-
1560 Europäisches Parlament, Legislative Entschließung des Europäischen Parlaments zu dem den
Gemeinsamen Standpunkt des Rates im Hinblick auf den Erlass der Richtlinie des Europäischen Parlaments und des Rates über die Patentierbarkeit computerimplementierter Erfindungen (11979/1/2004 – C6-0058/2005 – 2002/0047(COD)).
1561 Für eine solche Sperrwirkung etwa Konrad/Timm-Goltzsch/Ullrich in: Ullrich/Lejeune
(Hrsg.), Teil I Rdnr. 819 m.w.N.; ablehnend aber z.B. Lehmann, GRUR Int. 1991, 327, 335 f.
1562 S. zum „reverse engineering“ in traditionellen Industrien Samuelson/Scotchmer, 111 Yale L.J.
1575, 1582 ff. (2002).
1563 Einen Marktüberblick liefert Pohlmann/Müglich, S. 3 ff.
1564 S. oben Teil 3 B. I.
246
fern könnte man diese Schranke als vertikale Begrenzung mit einem in den horizontalen Bereich überschießenden Gehalt deuten.
III. Reparaturklausel im Geschmacksmusterrecht
Eine Beschränkung des Immaterialgüterschutzes, die explizit einer vertikalen Rationalität folgt, ist die im Geschmacksmusterrecht diskutierte „Reparaturklausel“. Sie
soll einen Konflikt zwischen Autoherstellern und freien Ersatzteillieferanten lösen,
ist aber sowohl wirtschaftspolitisch als auch immaterialgüterrechtlich umstritten. Im
Folgenden soll zunächst der Grundkonflikt und die betroffenen Interessen dargestellt
werden (1.). Daraufhin sollen die Grundlagen für einen geschmacksmusterrechtlichen Schutz von Ersatzteilen erläutert werden (2.). Sodann ist der Vorschlag für eine
Reparaturklausel darzulegen (3.), in die immaterialgüterrechtliche Systematik einzuordnen und zu bewerten (4.).
1. Interessenlage
Im der Diskussion um eine „Reparaturklausel“ im Geschmacksmusterrecht (Designrecht) stehen sich die Interessen von Automobilherstellern und freien Herstellern
von Ersatzteilen gegenüber. Kern des Streits ist der Geschmacksmusterschutz für
sog. „must-match“-Autoteile. Das sind sichtbare Teile des Autos, die im Schadensfall durch identische Teile ersetzt werden müssen, um das Auto auch optisch wieder
voll in Stand zu setzen.1565 Beispiele hierfür sind Motorhauben, Kotflügel, Türen,
Stoßstangen, Spiegel, Scheinwerfer, Leuchten und Autoglas.1566 Kann der geschmacksmusterrechtliche Schutz auch ausgeübt werden, wenn solche Teile zu Reparaturzwecken angeboten werden, werden unabhängige Hersteller vom Ersatzteil-
1565 Riehle, GRUR Int. 1993, 49, 62; Drexl/Hilty/Kur, GRUR Int. 2005, 449, 450.
1566 Eekhoff/Fischer/Jänsch/Roth, S. 5 f.; Riehle in Geiss/Gerstenmaier/Winkler/Mailänder
(Hrsg.), S. 175, 186 f.; Bechtold, Die Kontrolle von Sekundärmärkten, S. 79. Hiervon zu unterscheiden sind die sog. „must-fit“-Teile. Dies sind nach Art. 8 Abs. 2 GGV und § 3 Abs. 1
Nr. 2 GeschmMG solche Teile, „die zwangsläufig in ihrer genauen Form und ihren genauen
Abmessungen nachgebildet werden müssen, damit das Erzeugnis, in das das Muster aufgenommen oder bei dem es verwendet wird, mit einem anderen Erzeugnis mechanisch zusammengebaut oder verbunden oder in diesem, an diesem oder um dieses herum angebracht werden kann, so dass beide Erzeugnisse ihre Funktion erfüllen“. Ein Beispiel hierfür sind die
Verbindungsmuffen eines Auspuffrohrs, die sich in die technische Gestaltung der Kfz-
Unterseite einpassen müssen, s. Bechtold, Die Kontrolle von Sekundärmärkten, S. 79, Fn.
315; Eichmann in: Eichmann/v. Falckenstein, § 3 Rdnr. 11. Geschmacksmusterrechtlicher
Schutz ist für solche Teile gem. Art. 8 Abs. 2 GGV und § 3 Abs. 1 Nr. 2 GeschmMG ausgeschlossen.
Chapter Preview
References
Zusammenfassung
Das Immaterialgüterrecht soll die Imitation von geistigen Leistungen verhindern. Damit wirkt es zunächst horizontal gegen direkte Konkurrenz. Es verleiht jedoch auch Schutz gegenüber Dritten, die das geschützte Gut als Input auf anderen Märkten nutzen. Dies kann als vertikale Schutzrichtung bezeichnet werden. Obwohl diese Schutzrichtungen verschiedene Auswirkungen auf die Produktion immaterieller Güter haben, wird im Immaterialgüterrecht nicht zwischen ihnen differenziert.
Die vorliegende Arbeit untersucht anhand dieser Unterscheidung die schutzrechtsinternen Grenzen des Immaterialgüterrechts. In einer ökonomischen Analyse werden zunächst die Wirkungen der vertikalen Kontrollbefugnisse dargestellt. Anschließend wird analysiert, inwieweit die ökonomischen Erkenntnisse ins Recht Einzug gefunden haben und welche Hebel es zur Justierung vertikaler Kontrolle gibt. Diese Betrachtungsweise schärft das Verständnis des Immaterialgüterrechts als Marktorganisationsrecht und schafft eine tragfähigere Grundlage für die Bewertung und Justierung der schutzrechtsexternen Grenzen. Darüber hinaus trägt sie zu einem „more economic approach“ im Immaterialgüterrecht bei.