NOePatents - Petition gegen Software Patente in der EU

1. Einführung in diesen Petitionstext

Die LUGS und die anderen Unterzeichner fordern, dass Software weiterhin nicht patentierbar sein soll, und dass folglich die Aenderung des EPUe, dies zu ermöglichen, abgelehnt werden soll.

Da dieser Text, als Petition, von verschiedenen Parteien (Unterschreibende, IGE, etc) mit sehr verschiedenen Vorbildungen (in Gesetzen und in Software erstellen) gelesen wird, wird möglichst wenig Vorwissen über Gesetze und erwähnte Technologien seitens des Lesers vorausgesetzt. Daher werden Grundlagen, die nicht Allgemeinwissen sind, erklärt, auf Kosten der Grösse des Textes.

Dieser Text addressiert folgende Themen:

Urheberrecht (Copyright)

Urheberecht dient dem Ziel, mehr Werke für die Allgemeinheit zu erstellen, indem den Autoren von Werken das Recht gegeben wird, die Bezahlung der Entwicklungskosten für ihre Werke durch die Benutzern der Werke, in Form einer Lizenzabgabe auf jede Kopie dieses Werkes, zu verlangen.

Urheberrechte verbieten daher, für eine limitierte Zeit, Kopien eines geschützten Werkes herzustellen und zu vertreiben, ohne eine Genehmigung vom Autor zu besitzen, die er nur gegen Bezahlung geben wird.

Urheberrechte haben keine Auswirkung auf die Möglichkeit anderer Autoren, ein konkurrenzierendes Werk zu erstellen, zu vertreiben oder zu nutzen.

Patentrecht

Patentrecht dient dem Ziel, mehr technologische Neuerungen zu veröffentlichen und damit das Wissen der Allgemeinheit zugänglich zu machen, indem den Patentinhabern das Recht gegeben wird, zu verhindern, dass jemand anders aus ihren Erfindungen den Nutzen zieht und sie leer dabei ausgehen.

Patente verbieten daher, für eine limitierte Zeit, Konkurrenzprodukte auf Basis der neuen Technologie herzustellen und zu vertreiben, ohne eine Genehmigung vom Inhaber zu besitzen, die er nur gegen Bezahlung geben wird.

Patente haben daher grosse Auswirkungen auf die Möglichkeit anderer Entwickler, ein konkurrierendes Produkt zu entwickeln. Daher muss ihr Nutzen mit dem Schaden den sie anrichten abgewogen werden.

Diese schädlichen Auswirkungen sind es, welche die Open Source Entwickler zunehmend in ihrer Arbeit hindern und die in dieser Petition ausgedrückte Opposition hervorrufen.

3. Vorgeschichte des Europäischen Patent Uebereinkommens

Dieses Abkommen beinhaltet einen Artikel, der u.a. "Computer Programme als solches" von der Patentierbarkeit ausschliesst. Eben dieser Artikel soll nun u.a. an der bevorstehenden Konferenz in München aus dem EPC gestrichen werden.

Eine von einem Hersteller eingestellte Gruppe von Entwicklern erstellt einen textuellen Beschrieb, was der Computer machen soll (Source Code). Dieser Source Code wird beim Hersteller umgewandelt in das eigentliche ausführbare Program (Binary Code). Kopien vom Binary Code ohne Source Code werden an die Benutzer verteilt, gegen Bezahlung einer Lizenzgebühr per Kopie, aus der dann der Hersteller, seine Entwickler und die Investoren bezahlt werden.

• Weil Binary Code stets für einen bestimmten Rechnersystem (Hardware plus Betriebssystem) generiert werden muss, müssen die Benutzer sich auf die vom Softwarehersteller unterstützten Systeme beschränken. Zusammen mit dem Wunsch der Hersteller, Kosten zu sparen, indem sie möglichst wenige weit verbreitete Systeme unterstützen, entsteht somit der Druck auf die Benutzer, zu dominanten Systemen zu wechseln. Dies reduziert die Anzahl Benutzer der anderen Systeme und fördert diese Zentralisierungstendenz. Die Auswahl an Systemen verschwindet, zum Nachteil der Benutzer.

• Weil der Benutzer keinen Source Code hat, kann er unmöglich Fehler der Software ausbügeln oder gar die Software an neue Systeme anpassen. Er ist abhängig von der Bereitschaft des Herstellers, dies zu tun, was nur zu oft nicht der Fall ist, wenn es nicht profitabel ist.

• Ebensowenig kann der Benutzer neue Fähigkeiten addieren, ohne die Bereitschaft des Herstellers. Die Entwicklung neuer innovativer Software auf Basis älterer wird verhindert. As Folge davon wird das Rad immer wieder neu erfunden, zumeist nicht runder.

• Ebensowenig kann der Benutzer sich davor schützen, dass ein Hersteller ein Produkt einstellt, ebenfalls weil es nicht mehr profitabel ist, und gar keine Korrekturen, Anpassungen oder Erweiterungen mehr herstellt.

8. Neu: die Open Source Software Methode

• Ein Projekt wird in der Mehrzahl aller Fälle (>90%) von einen einzelnen Benutzer initiiert, der ein simples Program für den Eigengebrauch erstellt, also ohne Verkaufsabsicht. Der Profit für den Autor ist es, die Software zu haben, wie bei jeder selbstgeschriebenen Software.

• Diese Software verteilt der Autor nun aber an alle anderen interessierten Benutzern, kostenlos, ohne Garantie, aber mit Source Code. Oft wird sogar nur als Source Code verteilt, ohne Binary Code, da Open Source Benutzer ja alle die notwendigen Mechanismen besitzen, um Source Code in Binary Code für ihr spezifisches System umzuwandeln. Diese Mechanismen zu erstellen waren die ersten Open Source Projekte.

• Für manche Benutzer ist das Program in diesen Zustand bereits gut genug. Die können es sofort nutzen. Ohne Kosten und ohne Einschränkungen.

• Andere Benutzer, denen das Program nicht gut genug ist, können nun aber davon eigene Programme ableiten, durch Erweiterung, anstelle von durch eigenes Schreiben von Null auf. Dies erhöht die Wahrscheinlichkeit, dass sie es machen werden und auch einen Nutzen haben.

• Der Erst-Autor ist nun aber auch bereit, diese Erweiterungen entgegen zu nehmen und in seine Version einzubauen, denn er profitiert möglicherweise auch von den Erweiterungen, in dem Fall, dass sie einer Funktion entsprechen, die er noch zu programmieren vor hatte, oder gar nie in Betracht zog. Eben diese Erweiterungen zu bekommen ist sein Grund für die Publikation.

• Der Erst-Autor stellt nun die vereinte Version allen Benutzern zur Verfügung. Der Code ist damit für mehr Leute gut genug. Und weitere Personen entscheiden sich nun, lieber auf die gesammelte Arbeit aufzubauen, als statt dessen von vorne anzufangen. Und produziern so weitere Erweiterungen, die in die Sammlung einfliessen.

• Auf diese Weise sammelt sich ein Programm zusammen und wird genau so gross und fähig wie industriell hergestellte Software. Gigabytes von Linux und BSD (ein Konkurrenzsystem zu Linux) sind sicher das augenfälligste Beispiel dafür.

• Die meisten Benutzer werden nie selber etwas programmieren, weil andere ihnen zuvorgekommen sind. Aber sie profitieren auch von der gesammelten Arbeit und haben immer noch die Möglichkeit etwas zu addieren, wenn es sein muss. Für sie ist Source Code mehr wie eine Versicherungspolice, hoffentlich muss man es nicht benutzen, aber es ist beruhigend sie zu haben.

9. Prinzipbedingte Stärken von Open Source

• Portabel auf beliebige Rechnersysteme. Ohne dass der Erst-Autor diese unterstützen muss.

• Ausmerzbarkeit von Fehlern und Anpassungen auf neuen Rechnern.

• Möglichkeit neue Fähigkeiten zu addieren, ohne das Rad neu erfinden zu müssen.

• Garantie, dass diese Fähigkeiten erhalten bleiben, so lange jemand Interesse an dem Program hat und es weiter pflegt.

• Fähigkeiten der Software entsprechen realen Bedürfnissen (sonst hätte keiner sie erstellt), nicht den Vorstellung von Markforschungsabteilungen der Hersteller, die oft ihr Ziel verfehlen.

• Kostenlos, da keine Hersteller/Entwickler/Investoren davon leben müssen. Die Autoren schreiben ja alle für ihren Eigenbedarf, finanziert von ihrer Anwendung ihres Computers.

• Kleine und Mittelgrosse Unternehmen (KMUs) und Individuen, z.B. Internet Access und Dienstleistungs Provider, können diese Programme ohne grosse Kosten nutzen und weiterentwickeln. Dadurch können leichter neue Produkte und Dienste entstehen, die den Wirtschaftstandort Schweiz stärken. Die in Europa im Softwarebereich verbreiteten KMUs und Individuen können sich besser entwickeln.

• Keine Probleme mit kaputt gehenden Mechanismen zur Verhinderung von unbezahlten Kopien, da ja unbezahltes Kopieren und Benutzen ein explizit erwünschter Vorgang ist. Ebenfalls keine Gesetzte zum Verbot, solche Mechanismen zu umgehen, was bei deren Versagen oft die letzte Rettung ist.

Aus der Beschreibung, wie Open Source Software zustande kommt, kann man ableiten, was für Bedingungen nötig sind, damit Open Source als Methode ermöglicht werden kann:

• Kostenlose (für den Erst-Autor) Verteilbarkeit von Kopien der Software, damit er weitere Mitprogrammierer (die er im Voraus nicht kennt) erreichen kann. Dies wird heute durch das Internet gemacht, v.a. via den FTP Servern und dem World Wide Web (WWW).

• Kostenlose (für die Erweiterer) Rückmeldung von Aenderungen an den Erst-Autor, damit die Aenderungen in das Projekt einfliessen können. Dies wird heute v.a. via Email gemacht.

Folge: ein Patent auf eine Technologie verhindert vollständig jegliche Open Source Programme auf der Basis dieser Technologie. Das heisst, die Entwicklung von einem 100% auf Open Source basierten System, das konkurrenzfähig ist zu Closed Source, wird verunmöglicht.

• Die "Sørensen Video Codec" Technologie, die die Basis für das QuickTime 4 Multimedia Format bildet, ist patentiert. Daher wird es keine QuickTime 4 Player für Linux oder BSD geben, ausser Sørensen lässt sich einweichen, ihr Patent freizugeben.

• Die Audio Codec Technologie, die die Basis für .mp3 Audio bildet, ist patentiert. Dass es trotzdem Open Source MP3 Player gibt, ist nur dem Zufall zu verdanken, dass die Patentabteilung vom Fraunhofer Institut (Entwickler des Codecs) ihr Patent in Schweden nicht durchsetzen können (oder zumindest konnten). Also haben sie aufgegeben, es gegen die Open Source Entwickler vom Bladeenc Projekt durchzusetzen.

• Die "RSA" Technologie, die die Basis für viele Public-Key Verschlüsselungsprogramme bildet, ist patentiert (bzw war, das Patent lief im September 2000 ab). Dass es trotzdem solche Verschlüsselung in Open Source gibt, ist nur dem Zufall zu verdanken, dass das Patent für RSA in ganz Europa wegen Verfahrensfehler (Publikation in einem Fachjournal bevor Einreichung des Patentes) abgelehnt wurde.

12. Wirkung von noch mehr Patenten, insbesondere solche für Software

Jedes weitere Patent kann ein weiteres Dateiformat, aber auch ein User Interface Element, oder ein anderes Software Feature für Open Source Programmierer nicht nachbaubar machen. Man stelle sich vor, Pull-Down Menüs wären patentiert worden: es wären keine Open Source Programme mit graphischer Benutzeroberfläche möglich!

Konsequenz davon ist, dass Open Source Programme immer weiter hinter Closed Source Programmen zurückbleiben müssen, nicht durch schlechte Programmierer oder eine schlechte Methode, sondern durch ein gar nicht beabsichtigtes gesetzliches Verbot.

Als Folge verlieren die Benutzer die Auswahl an Software, und Rechnersystemen, die durch Open Source möglich wird. Neue innovative Entwicklungen werden verhindert.

Software Patente lösen ein kleineres Problem (Neuerungen verfügbar machen, das auch durch Reverse-Engineering gelöst werden kann, das kostet einfach Zeit oder Geld) und produzieren dafür ein grösseres Problem (Lizenzen bezahlen, das für Open Source nicht gelöst werden kann).

Aus diesem Grund fordert der LUGS die Delegation des IGE auf, in München gegen diese Ausweitung des Patentrechtes zu stimmen, und so diese schlechte Aenderung zu verhindern zu helfen.