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.