319
Art. 64 EPÜ i. V. m. § 9 PatG begründen. In einem solchen Fall ist durch die Aufnahme der Schnittstellen in die Erfindungsbeschreibung nicht viel gewonnen.1706
Diesbezüglichen Konflikten kann durch eine spezifische Schrankenbestimmung
in Anlehnung an die bereits in § 11 PatG enthaltenen begegnet werden. Zwar dient
§ 11 bislang in erster Linie der Ausnahme solcher Handlungen, denen eine gewerbliche Bedeutung abgesprochen wird, dies ist jedoch nicht sein einziger Zweck.1707
§ 11 PatG ist auch im Lichte der im Dritten Kapitel unter A. angestellten Überlegungen zu betrachten, insbesondere im Hinblick auf die angestrebte Förderung technischen Fortschritts. Patentrechtlicher Ausschließlichkeitsschutz darf sich nicht auf
solche Handlungen erstrecken, die für die technische Entwicklung vonnöten sind.
Dazu gehört angesichts der beschriebenen ökonomischen Besonderheiten von Computerprogrammen auch und in erster Linie die Herstellung von Interoperabilität. Daher widerspricht es der Systematik des § 11 PatG nicht, eine entsprechende Schrankenregelung aufzunehmen:
§ 11/Art. XY
Die Wirkung des Patents erstreckt sich nicht auf
…
x. die Verwendung von Schnittstelleninformationen zur Herstellung eines interoperablen Produkts.
Diese Regelung ist in Verbindung mit der notwendigen Offenlegung der Schnittstellen wesentlich effektiver als die urheberrechtliche, weil sich die dargestellten
Geheimhaltungsprobleme nicht stellen.
V. Im Besonderen: „Softwarepatente“ und freie Software
Sucht man nach einer Lösung für die Patentierbarkeit von Computerprogrammen, so
ist es unvermeidlich, sich auch dem mittlerweile bereits mehrfach erwähnten Phänomen „Open Source“ und den Auswirkungen einer Patentierbarkeit auf diese Form
der Softwareentwicklung zu stellen.1708 Ein Großteil der Argumente gegen eine Patentfähigkeit von Computerprogrammen stammt von dieser Seite.1709 Offenbar hat
die agressive Politik der „Community“1710 erheblich dazu beigetragen, dass einer-
1706 Vgl. Weyand/Haase, GRUR 2004, 198, 201.
1707 Kühnen, in: Schulte, PatG, 8. Aufl. 2008, § 11 RdNr. 5ff.; Keukenschrijver, in: Busse, PatG,
§ 11 RdNr. 5 beschreibt eingehend den „tieferen Sinn“ der Vorschrift.
1708 Vgl. dazu auch schon Böcker, in: Lutterbeck/Bärwolff/Gehring, Open Source Jahrbuch 2007,
S. 511ff.
1709 Vgl. ganz bezeichnend Nitschke, Geistiges Eigentum ist Diebstahl, in: Forum Recht Online,
3/2002, abrufbar unter http://www.forum-recht-online.de/2002/302/302nitschke.htm.
1710 Diese Bezeichnung wird von den Akteuren selbst verwendet, vgl. Wiebe, in: Spindler,
Rechtsfragen bei Open Source, 2004, S. 245.
320
seits die EU-Softwarepatentrichtlinie gekippt wurde1711, und andererseits die Entwicklungsform endlich „ernst genommen“ und nicht mehr als „a matter for freaks“
betrachtet wird. So hat etwa Microsoft den Kunden von Novell – einem der bedeutendsten Linux-Distributoren1712 – kürzlich zugesagt, sie nicht aus dem Patentportfolio von Microsoft in Anspruch zu nehmen.1713 In der jüngsten Fassung (v3) der weiter oben erläuterten GPL finden sich ausdrückliche Regelungen für solche Dreipersonenverhältnisse und zu anderen Patentproblemen,1714 die so bislang noch in keiner
anderen Open Source-Lizenz zu finden sind.
Zur Erinnerung: Open Source ist durch einige Besonderheiten gegenüber „herkömmlicher“ Software gekennzeichnet.1715 Der Quelltext der Datenverarbeitungsprogramme wird, in der Regel mit Hilfe des Internets, der Allgemeinheit zugänglich
gemacht. Mit Hilfe bestimmter Lizenzbedingungen wird dem Nutzer ein unentgeltliches Vervielfältigungs-, Verbreitungs-, Nutzungs- und Bearbeitungsrecht eingeräumt, welches jedoch mit restriktiven Auflagen verbunden ist, wie mit den Weiterentwicklungen und Verbesserungen des zugänglich gemachten Codes zu verfahren
ist. Am bedeutsamsten ist die sog. „Replikationsklausel“1716, die jeden Ersteller von
abgeleiteten Programmbearbeitungen verpflichtet, das jeweils abgeleitete Werk zu
denselben Bedingungen wie das Ursprungswerk der Öffentlichkeit zur Verfügung zu
stellen.
1. Notwendige Berücksichtigung von Open Source aufgrund seiner
wirtschaftlichen Bedeutung
Weiter oben wurde dargelegt, wie erheblich die wirtschaftliche Bedeutung frei entwickelter Programme mittlerweile ist.1717 Es gilt, diese hohe Bedeutung und die
anerkannten Vorteile, die der freie Zugang zum Quellcode mit sich bringt, auch bei
einem patentrechtlichen Schutz von Computerprogrammen zu erhalten. Dabei ist
aber zu beachten, dass das hinter der GPL stehende Geschäftsmodell nur eines unter
vielen ist,1718 und zudem zu vermuten ist, dass sein Erfolg ohne den Gegenpart
1711 Nack/Phélip, GRUR 2001, 322, 323f. weisen darauf hin, dass die Open Source Bewegung
auch mitverantwortlich dafür war, dass es im Rahmen der EPÜ-Verhandlungen nicht zu einer
Streichung des Ausschlusses kam. Dazu a. Bardehle, Mitt. 2001, 145, 146f.; Mitt. der Kommission, KOM (99) 42 v. 5. Februar 1999, abgedruckt in GRUR Int. 1999, 335, 339f.
1712 www.novell.com/de-de.
1713 http://www. microsoft.com/interop/msnovellcollab/faq.mspx. Diese Tatsache ist ein Indiz
dafür, dass die Bedrohung von Open Source durch die patentfreundliche „Programminsutrie“
nicht so hoch ist wie von den Akteuren vermutet.
1714 Zur GPLv3 vgl. Jaeger/Metzger, GRUR 2008, 130; Böcker, in: Lutterbeck/Bärwolff/Gehring,
Open Source Jahrbuch 2007, S. 511ff.
1715 Näher dazu oben Zweites Kapitel, B. II.
1716 Diesen Begriff hat Horns, Jur-PC Web-Dok 223/2000, Abs. 42, eingeführt.
1717 S. o. Zweites Kapitel, B. II. 4.
1718 S. a. Nack, in: FS König, 2003, S. 359, 365.
321
„Kommerzialität“ erheblich schrumpfen würde.1719 Es darf also auch nicht zu einer
Benachteiligung proprietärer Programme kommen.
2. Potentielle Gefahren für Open Source durch das Patentrecht
Um eine detaillierte Wiedergabe all der bisher ins Feld geführten Argumente von
Seiten der Patentgegner1720 kann es an dieser Stelle nicht gehen, zumal sich die
meisten Aspekte mit den bereits oben zur grundsätzlichen Legitimation des Patentschutzes für Computerprogramme untersuchten decken.1721 Untersucht werden soll
daher nur, welche Aspekte tatsächlich zu einer Bedrohung von Open Source durch
Patentrecht führen können.1722
Als Verletzungshandlungen kommen auch im Open Source-Bereich grundsätzlich
alle in den §§ 9, 10 PatG (ggf. iVm. Art. 64 Abs. 3 EPÜ) genannten Handlungen in
Betracht, je nachdem ob es sich bei dem Patent um ein Verfahrens- oder ein Vorrichtungspatent handelt. Dabei können jedoch einige der in § 11 genannten Privilegierungstatbestände einschlägig sein. § 11 Nr. 1 PatG nimmt etwa Handlungen zu
privaten Zwecken vom Schutzbereich des Patents aus, so dass zumindest so lange
keine „Gefahr“ besteht, wie kein gewerblicher Zweck vorliegt. Allerdings ist der
Vertrieb freier Software nicht schon deswegen als privat anzusehen, weil er unentgeltlich erfolgt. Einnahmen werden in der Regel aus anderen Quellen generiert, vgl.
oben Zweites Kapitel, B. II. Auch ist der Bereich der privaten Nutzung schon dann
überschritten, wenn die Programme wie üblich über das Internet getauscht und vertrieben werden.1723 Ein generelles Privileg für Open Source-Entwicklung ist § 11 Nr.
1 PatG daher nicht zu entnehmen.
Auch das in § 11 Nr. 2 PatG erlaubte Handeln zu Versuchszwecken, in dem die
Informationsfunktion des Patentrechts zum Tragen kommen soll, bedeutet keine generelle Freistellung der Open Source-Entwicklung. Die Benutzung des geschützten
Produkts zur Weiterentwicklung eines anderes Gegenstandes ist von der Ausnahme
nicht mehr erfasst.1724 Sie kann nur insoweit greifen, als es sich um eine bloße Ver-
1719 Pasche/v. Engelhardt, Volkswirtschaftliche Aspekte der Open-Source-Software Entwicklung,
2004, S. 12, 16; Shapiro/Varian, Linux Adoption in the Public Sector, 2003, kommen zu dem
Ergebnis, dass aufgrund der gegenseitigen Beeinflussung nur einer Mischung aus Open Source und kommerzieller Software effizient ist.
1720 Zum vertieften Studium sei hier auf Internetseiten wie www.patentfrei.org oder
www.nosoftwarepatents.com verwiesen.
1721 Dies hängt mit dem Umstand zusammen, dass die meisten Patentgegner aus dem Bereich
Open Source kommen.
1722 Dazu auch Wiebe, in: Spindler, Rechtsfragen bei Open Source, 2004, S. 256ff.; Jaeger/Metzger, Open Source Software, 2. Aufl. 2006, S. 169ff.
1723 Dazu Wiebe, in: Spindler, Rechtsfragen bei Open Source, 2004, S. 251; Esslinger/Betten, CR
2000, 18, 21.
1724 Scharen, in: Benkard, PatG, 10. Aufl 2006, § 11 RdNr. 6f.; Mes, in: ders., PatG/GebrMG, 2.
Auf. 2005, § 11 PatG RdNr. 5; dazu auch Wiebe, in: Spindler, Rechtsfragen bei Open Source,
2004, S. 252.
322
besserung handelt, und auch dann nur, wenn das Resultat der Entwicklung das Patent nicht verletzt. Bei bloß marginalen Fortschritten ist dies stets der Fall, so dass es
nur wenige Fälle gibt, in denen § 11 Nr. 2 PatG tatsächlich eine Freistellung bedeutet.
Eines des Hauptargumente der Open Source-Community gegen einen grundsätzlichen Patentschutz von Computerprogrammen war von Anfang an, dass in diesem
Bereich nie Patente beansprucht wurden. Der Erfolg freier Entwicklung beweise daher, dass Innovationsförderung durch Patente nicht notwendig sei, da man hier völlig ohne auskomme. Zu beachten ist dabei aber, dass Open Source in erster Linie ein
Konkurrenzprodukt zu proprietären Programmen darstellt, also nicht frei von jeglichem Wettbewerbsgedanken ist. Im Gegenteil ist die Konkurrenz zu proprietären
Produkten einer der Hauptanreize für eine schnelle Innovation im OS-Bereich.1725
Ohne Ausschließlichkeitsrechte kann sich auch die Open Source-Community nicht
vor einer Übernahme ihrer Entwicklungen schützen.
a) Lizenzpflicht für die Entwicklung und Innovationshemmung
Open Source-Gegner befürchten eine Innovationshemmung durch das Entstehen einer Lizenzpflicht am Code. Weiter oben wurde vor dem Hintergrund dieses Arguments bereits der Vorschlag gemacht, diesen vom Schutzbereich auszunehmen.1726
Mit einer derartigen Lösung können die meisten Befürchtungen der Open Source-
Entwickler ausgeräumt werden. Dann ist nämlich lediglich eine Recherche dahingehend erforderlich, ob es die zu programmierende Lösung für die konkrete Anwendung schon gibt. Dies ist wesentlich leichter zu bewerkstelligen als eine Coderecherche, da jede programmierte Lösung anhand ihrer Anwendung kategorisiert werden kann.
b) Probleme bei der unternehmerischen Patentrechtspolitik von Open Source-
Unternehmen
Angesichts der zunehmenden Patentierung von Softwarebausteinen insbesondere in
den USA sind Praktiken wie die Errichtung von Patentpools und das so genannte
Cross-Licensing, bei denen sich Unternehmen ihre Patente wechselseitig lizenzieren,
weit verbreitet und finden zunehmend mehr Anerkennung in der Industrie.1727 Eine
Teilnahme an diesen Mechanismen ist aber nur möglich, wenn eigene Patente mit
eingebracht werden können. Open Source-Entwickler melden, meist wegen der
1725 S. a. oben Zweites Kapitel, B. II. 4. und Drittes Kapitel, C. V. 1..
1726 Vgl. oben IV. 3. c) aa) ).
1727 Wenngleich diese Instrumente aus wettbewerblicher Sicht nicht uneingeschränkt positiv zu
bewerten sind. Vgl. Guellec/van Pottelsberghe de la Potterie, The Economics of the European Patent System, 2007, S. 101.
323
prinzipiellen Ablehnung von Patenten in der Präambel der GPL,1728 in der Regel
keine Patente an. Da sie deshalb auch nicht in der Lage sind, eigene Rechte einzubringen, können sie aus diesen Formen der Zusammenarbeit keinen Nutzen ziehen
und sind von der Verwendung der anderen eingebrachten Patente ausgeschlossen
bzw. müssen teure Lizenzgebühren tragen.
Allerdings hängt dieses Problem nicht mit der grundsätzlichen Patentierbarkeit
von Computerprogrammen zusammen, sondern mit der generell patentfeindlichen
Einstellung der OS-Entwickler.1729 Nimmt man den Quellcode eines Programms
ausdrücklich aus dem Schutzbereich des Patents aus, so besteht kein Grund mehr für
diese Einstellung, da auf diese Weise das Prinzip des freien Codes ausdrücklich gesetzlich festgeschrieben werden könnte.
c) Patentverletzung durch Open-Source-Entwickler
Ein häufig angebrachtes Argument ist die schon angesprochene Gefahr einer unbewussten Patentverletzung durch Open Source-Entwickler und die mit einer Inanspruchnahme durch den Patentinhaber verbundenen Kosten.1730 Die systembedingte
Offenheit des Quellcodes führt dazu, dass sowohl Patent- als auch Urheberrechtsverletzungen einfach erkannt werden können, da über den Quellcode leicht Einblick in
die Strukturen des Programms genommen werden kann. Im Vergleich dazu kann
eine derart einfache Recherche bei proprietär vertriebenen Programmen nicht vorgenommen werden, da der Binärcode nur wenig Information über das Programm
preisgibt.1731
Aufdeckung und Nachweis einer Rechtsverletzung sind bei Open Source deshalb
sehr einfach.1732 Das gilt nicht nur für vorsätzliche Handlungen, sondern auch für
unbeabsichtigte und sogar unbewusste. Proprietäre Software scheint also doppelt im
Vorteil: Weil der Quellcode geheim gehalten wird und eine Dekompilierung zur
Aufdeckung einer Patentverletzung nach §§ 69c iVm. 69e Abs. 1 UrhG verboten ist,
ist der Nachweis einer Patentverletzung nur schwer oder gar nicht möglich. Andersherum können aber die Inhaber von Patenten an proprietärer Software einfach feststellen, ob ein freies Programm geistiges Eigentum verletzt, da sie Einblick in den
Quellcode haben, den sie selbst Dritten verwehren.
Dazu ist zunächst anzumerken: Eine Verletzung ist auch dann eine Verletzung,
wenn sie leicht entdeckbar ist.1733 Es gilt, sie von vornherein zu vermeiden, auch für
1728 http://www.gnu.de/documents/gpl.de.html, Präambel: „Schließlich und endlich ist jedes
Computerprogramm permanent durch Patente bedroht.“
1729 Vgl. zur kritischen Einstellung der Open Source Bewegung zu jeder Art geistigen Eigentums
Schiffner, Open Source Software, 2003, S. 53.
1730 Vgl. u. a. Lutterbeck/Gehring, Softwarepatente, 2003, S. 3f.
1731 Hilty/Geiger, IIC 2005, 615, 634.
1732 Vgl. Jaeger/Metzger, Open Source Software, 2. Aufl. 2006, S. 177f.; Dazu auch Nack, in: FS
König, 2003, S. 359, 364ff.
1733 Nack, in: FS König, 2003, S. 359, 364.
324
Open Source-Entwickler. Das Argument, man könne schneller erwischt werden, ist
keines gegen die Sanktion, sondern eines gegen die Verletzung. Darüber hinaus ist
auch diese „Gefahr“ wesentlich geringer, wenn man den Quellcode explizit vom
Schutz ausnimmt, da dann durch die bloße Verwendung von Code keine Verletzung
mehr erfolgen kann.
d) Patentanmeldungen an Open Source-Code
Eine Bedrohung, der es auf anderer Ebene zu begegnen gilt, ist diejenige der Patentanmeldung an Open Source-Programmen, egal ob von kommerzieller Seite oder aus
den eigenen Reihen. Hier hat zuletzt das Patent auf das Anwendungssystem RTLinux
für Schlagzeilen gesorgt. Der Erfinder beanspruchte in den USA eine Anwendung,
die auf GPL-lizenziertem Code basierte und bekam das Patent.1734 Die GPL in ihrer
aktuellen (dritten) Fassung versucht diesen Anmeldungen aus den eigenen Reihen
weitestmöglich vorzubeugen.1735
Auf diese Weise können nämlich tatsächlich versteckte Rechte an einem Programm entstehen, die bei einer Weiterentwicklung verletzt werden. Dieses Problem
betrifft aber ebenfalls weniger die grundsätzliche Patentierbarkeit von Computerprogrammen als die Recherchetätigkeit der Patentämter im Hinblick auf die Neuheit
eines Programms und mithin deren Prüfungsstandards. Hier ist –neben der bereits
angesprochenen Verbesserung der Eingangsprüfung auch die Open Source-
Community selbst gefragt. Sie muss (weitere) Dokumentationsstellen einrichten, in
denen Entwickler ihre Neuerungen hinterlassen können, um ggf. belegen zu können,
dass es das beanspruchte Programm schon gibt, und den Patentämtern Zugriff auf
diese Datenbanken gewähren.1736 Diese Dokumentationsstellen könnten auch durch
die Patentämter selbst betrieben werden. Dies ist vorteilhaft, weil dann bei der Patenterteilung erleichterter Zugriff möglich ist.1737
Mögliche Koexistenz zwischen Patentrecht und Open Source
Schon bisher sind vor allem im Zusammenhang mit dem EU-Richtlinienentwurf
Lösungsvorschläge für eine Koexistenz von „Softwarepatenten“ und Open Source
1734 U.S.-Patent No. 5,995,745; vgl. unter http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1
&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&
l=50&s1= 5,995,745.PN.&OS=PN/5,995,745&RS=PN/5,995,745. Dazu Metzger, Kollision
in Echtzeit, Linux-Magazin 2001/07. Grundsätzlich steht einer solchen Patentierung nichts
entgegen, denn auch der auf Freier Basis arbeitende Programmierer erwirbt das Recht auf das
Patent aus § 6 PatG.
1735 Vgl. dazu Metzger, Risiko Softwarepatente? abzurufen unter www.ifross.de/ifross_html/
art11.pdf.; Böcker, in: Lutterbeck/Bärwolff/Gehring, Open Source Jahrbuch 2007, S. 511ff.;
Jaeger/Metzger, GRUR 2008, 130.
1736 So auch Wiebe, CR 2004, S. 881 ff., 886
1737 Den Versuch einer solchen Dokumentationsstelle gibt es unter http://eupat.ffii.org/pur
ci/index.de.html.
325
gemacht worden.1738 Zu den diskutierten Möglichkeiten gehört unter anderem die
schon erwähnte Nutzbarmachung der Zwangslizenz. Auch wenn es aus wettbewerblichen Gesichtspunkten grundsätzlich begrüßenswert scheint, dieses Instrument zu
stärken:1739 Für die Open Source-Entwicklung hilft es nur eingeschränkt weiter.1740
Da die Zwangslizenz durch Klage durchgesetzt werden muss, ist sie zur Absicherung einer schnellen, dynamischen Entwicklung nur bedingt geeignet.1741
Ebenfalls vorgeschlagen wurde, im Open Source-Bereich spezielle Patentpools zu
bilden, um Patentklagen abwehren und Kreuzlizenzierungspraktiken verfolgen zu
können.1742 Lutterbeck, Gehring und Horns wollen eine Treuhandinstanz, die OSS-
Projekte erfasst, Patentanträge verfasst und einreicht und eine rechtliche Interessenvertretung betreibt, einrichten.1743 Dazu ist Voraussetzung, dass eigene Patente erworben werden, was aber von der OS-Community derzeit noch grundsätzlich abgelehnt wird. Zudem ist auch die Kostenfrage ungeklärt.1744 Eine dem UrhWahrnG
vergleichbare Rechtsgrundlage im Bereich des Patentrechts, um eine den Verwertungsgesellschaften ähnliche Einrichtung ins Leben zu rufen und eine „Open Patents
License“ einzuführen, ist jedenfalls keine „Patentlösung“.1745 Abgesehen von einigen praktischen Problemen stellen sich hier auch kartellrechtliche Hürden in den
Weg.1746
Bereits weiter oben angesprochen wurde aber die grundsätzliche Möglichkeit, den
Quellcode aus dem Schutzbereich des Patents auszunehmen.1747 Sie geht zurück auf
das von Lutterbeck, Gehring und Horns in die Debatte eingebrachte und bereits weiter oben erwähnte Quelltextprivileg. Hiernach sollen für die Verwendung eines
Programms im Sourcecode besondere Ausnahmen gelten. Lutterbeck, Gehring und
Horns setzen hierfür bei den patentrechtlichen Schrankenbestimmungen an.1748 Das
„Herstellen, Anbieten, Inverkehrbringen, Besitzen oder Einführen von Software im
Quellcode“ soll demnach keine Rechtsverletzung begründen können. Allein das
dürfte indessen nicht ausreichend sein, da die Bearbeitung eines Programms bzw.
1738 Vgl. Lutterbeck/Gehring/Horns, Sicherheit in der Informationstechnologie und Patentschutz
für Softwareprodukte, 2000, S. 132ff.; Horns, Jur-PC Web-Dok 223/2000, Abs. 68ff.; Wiebe,
in: Spindler, Rechtsfragen bei Open Source, 2004, S. 260ff.; Jaeger/Metzger, Open Source
Software, 2. Aufl. 2006, S. 193 sprechen davon, die Risiken nicht zu überzeichnen.
1739 Für den Open Source Bereich in diesem Zusammenhang Wiebe, in: Spindler, Rechtsfragen
bei Open Source, 2004, S. 263.
1740 Anders scheinbar Blind et al., Softwarepatente, 2003, S. 207.
1741 Wiebe, in: Spindler, Rechtsfragen bei Open Source, 2004, S. 263.
1742 Lutterbeck/Gehring/Horns, Sicherheit in der Informationstechnologie und Patentschutz für
Softwareprodukte, 2000, S. 132ff.
1743 Dazu auch Horns, Jur-PC Web-Dok 223/2000, Abs. 73.
1744 Wiebe, in: Spindler, Rechtsfragen bei Open Source, 2004, S. 264.
1745 Wiebe, in: Spindler, Rechtsfragen bei Open Source, 2004, S. 264; Horns, Jur-PC Web-Dok
223/2000, Abs. 73, 74.
1746 Dazu Horns, Jur-PC Web-Dok 223/2000, Abs. 73.
1747 IV. 3. c) aa) ).
1748 Horns, Jur-PC Web-Dok 223/2000, Abs. 75.
326
die Benutzung von Code durch den Entwickler immer noch als Verwendung des
Verfahrens im Sinne von § 9 Nr. 2 PatG angesehen werden muss.1749
Als effektiver erweist sich in diesem Zusammenhang der bereits vorgestellte Ansatz, den Quellcode bereits dem Schutzbereich des Patents zu entziehen, im Folgenden „modifiziertes Quelltextprivileg“.1750 Beschränkt man den patentrechtlichen
Schutz auf den Komplexalgorithmus in Zusammenhang mit der in den Patentanspruch aufgenommenen konkreten Verwendung, und gestattet die Übernahme von
Code in einen anderen Zusammenhang, wären alle Argumente der „Community“
ausgeräumt, da die Wiederverwendung von Codebestandteilen ohne Weiteres möglich wäre und an ihnen auch kein Patent angemeldet werden kann. Eine Lizenzpflicht kann diesbezüglich dann nicht entstehen, so dass das Argument der Innovationshemmung weitestgehend entkräftet ist. Gleiches gilt für die Gefahr der unbewussten Patentverletzung durch Codierung aufgrund schwieriger Recherchebedingungen.
Für eine solche Ausnahme des reinen Codes vom Schutz spricht auch, dass in ihm
nicht die schöpferische Leistung des Programmierers liegt.1751 Eine solche Ausnahme widerspricht nicht der aufgestellten Behauptung, dass Idee und Ausdruck bei
Computerprogrammen nicht trennbar sind.1752 Hier geht es nämlich nicht um eine
Trennung der Idee vom Code, sondern darum, dass allein die Verwendung von Codebestandteilen ohne einen neuartigen Algorithmus einerseits keinen Patentschutz
begründen kann, und andererseits durch die Verwendung ähnlicher Codebestandteile
keine Patentverletzung ausgelöst wird, wenn der Algorithmus nicht übernommen
wird. Eine Begrenzung des Schutzes auf den Algorithmus ist in Abs. 2 des oben unter IV. entwickelten Gesetzesvorschlag einzuarbeiten, vgl. sogleich VI.
Der Gefahr, die durch eine mögliche agressive Patentpolitik proprietärer Unternehmen entstehen kann, ist bereits durch die diskutierten strengeren Prüfungsanforderungen gebannt. Gemeinsam mit der Tatsache, dass an Code kein Schutz gewährt
wird, dürften damit umfassende Freiräume für Open Source-Entwickler gesichert
sein. Was die (unberechtigten) Patentanmeldungen an freien Programmen angeht, so
kann dem durch die bereits vorgeschlagenen „Stempelstellen“ entgegengetreten
werden, sofern auch die Patentämter auf diese Zugriff haben. Patentanmeldungen
aus dem eigenen Lager beugt die GPLv3 vor.1753
1749 Wiebe, in: Spindler, Rechtsfragen bei Open Source, 2004, S. 263.
1750 Lutterbeck/Gehring/Horns, Sicherheit in der Informationstechnologie und Patentschutz für
Softwareprodukte, 2000, S. 132.
1751 Drittes Kapitel, C. III. 2. b).
1752 Drittes Kapitel, C. III. 1. b) dd).
1753 Dazu Jaeger/Metzger, GRUR 2008, 130; Böcker, in: Lutterbeck/Bärwolff/Gehring, Open
Source Jahrbuch 2007, S. 511ff.
327
VI. Zusammenfassung und Gesetzgebungsvorschlag
Die vorstehenden Überlegungen haben gezeigt, dass einer grundsätzlichen Zuordnung der Computerprogramme zum Patentrecht nichts entgegensteht und dass diese
im Gegenteil in Bezug auf die Innovationsförderung aufgrund der ihr immanenten
Offenlegungspflicht jedes geschützten Programms dem rein urheberrechtlichen
Schutz im Sinne der im Dritten Kapitel unter A. angestellten Überlegungen sogar
überlegen ist.
Die bislang gegen „Softwarepatente“ vorgebrachten Argumente, wie eine drohende Innovationsblockade, die Erteilung von Trivialpatenten und eine generelle
Verstärkung wettbewerbswidriger Effekte auf dem Markt für Computerprogramme
sind nicht belegbar oder erweisen sich als nicht gegen den Patentschutz als solchen,
sondern gegen seine bisherige Ausgestaltung gerichtet.1754 Diese Ausgestaltung gilt
es ohnehin zu präzisieren, weil sich, wie im Dritten Kapitel unter D. dargestellt, der
bisherige Ausschlusstatbestand als unpräzise und damit unbrauchbar erwiesen hat.
Gefahren resultieren allenfalls aus einem im Sinne der Überlegungen unter A. zu
weiten Schutzbereich, der unter anderem den bislang unklaren Anforderungen an die
Erfindungsbeschreibung zuzurechnen ist. Unter Wettbewerbsaspekten bedenklich
erscheinenden Auswirkungen eines zu weiten Patentschutzes kann entgegen gewirkt
werden, indem Computerprogramme aufgrund ihrer Besonderheiten nicht pauschal
mit anderen Erfindungen zusammen geregelt werden, sondern im Rahmen einer eigenen Vorschrift, die in EPÜ, PatG und ggf. auch in die zukünftige Regelung eines
Gemeinschaftspatents aufzunehmen ist. Sie muss eine gesetzliche Begrenzung des
Schutzbereichs und die damit zusammenhängenden Aspekte der Erfindungsbeschreibung, erhöhte Anforderungen an die erfinderische Tätigkeit und eine formale
Verbesserung der Qualität der Prüfung in den Patentämtern sicherstellen.
In erster Linie gilt es, den Schutzbereich des Programmpatents in angemessener
Weise zu beschränken, um einen zu großen und daher wettbewerbshindernden
Äquivalenzbereich zu vermeiden.1755 Dies erfolgt durch eine Begrenzung des Schutzes auf eine konkrete Problemlösung, die einschließlich des sachlichen Anwendungsbereichs in die Anspruchsfassung aufgenommen werden muss. Dadurch erfolgt eine Dezimierung des monopolisierten Bereichs auf eine bestimmte Lösung
eines beschriebenen und sachlich spezifizierten Problems, so dass andere Lösungswege desselben Problems offenbleiben. Gleichzeitig werden aufgrund der genaueren
Kategorisierungsmöglichkeiten Transparenz und Recherchemöglichkeiten verbessert. Im Bereich der Biotechnologie hat man sich mit § 1a Abs. 4 PatG bereits für
eine ähnliche Lösung entschieden.
Eng mit der Begrenzung des Schutzbereichs zusammen hängt die Frage nach einer angemessenen Erfindungsbeschreibung und der notwendigen Offenbarung der
patentierten Erfindung.1756 Entgegen einiger auch in jüngerer Zeit vorgestellter Vor-
1754 Vgl. oben I. 2.
1755 Dazu IV. 2.
1756 Abschnitt IV. 3.
Chapter Preview
References
Zusammenfassung
Die vorliegende Arbeit will langjährige Missverständnisse und Schwierigkeiten des immaterialgüterrechtlichen Schutzes von Computerprogrammen endgültig ausräumen. Die Betrachtung aus wettbewerbsorientiertem Blickwinkel auf der Grundlage der technischen und ökonomischen Besonderheiten ist – soweit ersichtlich – die erste Untersuchung, die sowohl das Urheber- als auch das Patentrecht einbezieht und dabei eine umfassende Neuregelung vorschlägt.
Dr. Lina Barbara Böcker befasst sich im Rahmen ihrer Tätigkeit am Institut für Wirtschafts-, Wettbewerbs- und Regulierungsrecht an der Freien Universität Berlin in erster Linie mit wettbewerbsrechtlichen Problemen des Immaterialgüterrechtsschutzes und allgemeinem Zivilrecht.