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.