[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ohne Kryptographie wirtsch. Zusammenbruch



Axel Horns wrote:
> Im XIX. Jahrhundert gab es eine Diskussion um Sinn und Zweck des
> Patentschutzes von Erfindungen. Die Befuerworter des Patentschutzes
> (die sich, wie wir alle wissen, historisch durchgesetzt haben)
> argumentierten unter anderem, durch den Patentschutz werde es
> moeglich, die Einzelheiten einer Erfindung freizuegig an die
> Oeffentlichkeit zu bringen, ohne befuerchten zu muessen, um die
> Fruechte betrogen zu werden.

In der Tat hat das Patenrecht zwei Seiten oder "Ursachen": Einerseits
möchte es das geistige Eigentum derjenigen schützen, die echte
Innovation produziert haben. Andererseits soll es aber auch diejenigen,
die sich für Innovation interessieren, über den Stand der Technik
informieren und sie mit Knowhow versorgen. Zwar können diese Parteien
die neuen Techniken nicht direkt nutzen, aber sie können in diese
Richtung weiterforschen und so selbst neues schaffen.

> Koennte eine generelle Patentfaehigkeit von Algorithmen die
> Bereitschaft der Softwareproduzenten erhoehen, sich in die
> Quellentexte sehen zu lassen?

Die tatsächliche Situation im Patentwesen, besonders in Bezug auf
Software und Softwarepatente ist doch so, daß der zweite Aspekt oft
nicht mehr gegeben ist. Patente werden mehr als Mittel zum Aufhalten
konkurrierender Innovation genutzt. Meiner persönlichen Meinung nach hat
aktuelles Patentrecht in Bezug auf Software eine ganze Reihe von
Strukturbugs, obwohl es grundsätzlich eine gute Sache ist:

1. Viel zu lange Laufzeiten (25 Jahre, richtig? 10 wären schon 
   sehr lange).
2. Erteilung von sehr breiten Trivialpatenten (XOR und 
   vergleichbare Techniken).
3. Kein Zugang zu patentierten Verfahren für Open Source
   Bewegung.

Fehler 1 ist sehr leicht zu korrigieren durch eine Einschränkung der
Patentlaufzeit. Der Innovationszyklus der Industrie liegt, getrieben
durchs Moores Gesetz, bei drei Jahren. Drei oder dreieinhalb
Innovationszyklen müssen als Schutzzeitraum ausreichen.

Fehler 2 ist ein Fehler, der nicht gut im Vorfeld zu korrigieren ist,
sondern der durch entsprechende Dienstanweisungen bei der Erteilung von
Softwarepatenten dauerhaft und immer wieder korrigiert wird. Das setzt
natürlich ziemlich viel Fachkunde bei den betreffenden Sachbeareitern
voraus. Oder man installiert ein System des Peer Review, durch das man
solche Patentierungsversuche abfangen kann. Ich halte dies für das am
schwersten wiegende Problem auf diesem Gebiet.

Fehler 3 ist verwandt mit dem, was ich oben unter "Nichtberücksichtigung
des anderen Aspektes des Patentsystems" subsumiert habe. 

Angenommen man hätte eine formale, verwaltungstaugliche Definition von
"Open Source" für Software und von "Schnittstellenoffenheit" für
Datenformate (SGML vs. Wordformat...) und einen Zertifizierungsprozeß
zur Erteilung dieser beiden Prädikate. Dann muß man bei der
Monopolgewährung für den Innovator diejenigen Leute ausnehmen, die
zertifizierte Open Source Software produzieren oder die Programme zum
Umgang mit zertifiziert offenen Datenformaten erzeugen. 

Leute, die solche Programme erstellen, tragen uneingeschränkt zur
Vergrößerung des Wohlstandes der Entwicklergemeinschaft bei, indem sie
ihren Code hergeben. Sie verdienen besondere Förderung durch das
Patentrecht - man darf ihre Arbeit nicht durch zusätzliche Kosten und
durch Generve bei der Erteilung von Lizenzen behindern. Das bedeutet,
daß jemand, der Open Source Software erstellt (und sich das offizielle
Open Source Siegel dafür holt) automatisch unlimitiert und kostenfrei
Lizenzen zur Nutzung patentierter Verfahren in seiner Software bekommen
muß. Die Lizenz gilt natürlich nur, solange das betreffende Programm
Open Source bleibt und nur in Zusammenhang mit dem Einsatz der
betreffenden Patente in diesem Programmpaket.

Offene Formate sind ebenfalls wichtig - ich glaube, diesen Konsens haben
wir hier auf der Listen schon gefunden. Ein klassisches Beispiel für ein
Nichtoffenes Format ist zum Beispiel das MP3-Format: Fraunhofer
behauptet, Patente auf die Erzeugung von MP3-Dateien zu haben und geht
gegen die Ersteller von MP3-Encodern vor, die solche Dateien erzeugen
können. Dieses Vorgehen trifft auch die Ersteller von Open Source
MP3-Encodern - und damit ist MP3 als offenes Datenformat gestorben.
Zusammenbruch der Entwicklergemeinschaft -> Zusammenbruch der
Innovation. Genau das Gegenteil dessen, was Patente eigentlich bewirken
sollen. Auch hier muß ein Verfahren gefunden werden, daß den Erstellern
von Open Source Software schnell, unbürokratisch und kostenfrei Zugang
zu Lizenzen verschafft.


Sprengstoff liegt bei der ganzen Sache auf dem Gebiet der
Komponentenware. Es ist ein Leichtes, OCXe, shared libraries oder
Kernelmodule zu schreiben, die Open Source sind und deren einziger Zweck
die lizenzkostenfreie Nutzung der patentierten Sachen ist. Konkurrenzen
des Patentinhabers würden solche Komponentenware herausgeben und dann
propietäre Software erstellen, die nur mit diesen freien Komponenten
zusammen ablauffähig ist. Es kann weder im Sinne der Patentinhaber NOCH
im Sinne der Open Source Developer Community sein, daß eine solche
Situation eintritt - hier verlieren alle Parteien. Es muß also eine
Regelung gefunden werden, die diese Situation angemessen behandelt und
kein Schlupfloch bietet, aber dennoch die Funktionsfähigkeit der Open
Source Community sicherstellt.

Gelingt dies, sind Software-Patente eine ausgezeichnete Sache. Mißlingt
dies - und es ist ein politischer Prozeß! - entsteht eine furchtbare
Katastrophe, die Innovation schwer behindern kann und die kommerziellen
Softwareentwickler mit großen Rechtsabteilungen in eine sehr
übermächtige und für die Gesamtheit wenig wünschenswerte Position bringt
(cf. RMS,  "The Right to Read" oder wie es heißt).

Es ist die Frage, ob man an dieser Problematik öffentlich rühren möchte,
bevor man ein solides Konzept hat...

Die Herangehensweise wäre auf jedenfall von der Reihenfolge her die
folgende:

1. Definition der Begriffe Open Source und Schnittstellenoffene 
   Software als zwei unterschiedlich weitgehende Aspekte derselben
   Bewegung.

   Dabei sind existierende Definitionen, etwa wie sie durch Debian
   entworfen wurden, zu berücksichtigen und als Vorbild zu nehmen,
   wenn man der Bewegung nicht Schwung nehmen möchte.

2. Installation eines Zertifizierungssystems für diese beiden
   Prädikate.

   Dabei sind bestehende Peer Review-Systeme (manche 
   Linux-Distributionen sind so etwas -> wieder Debian)
   mit zu integrieren, wenn man diese Synergien nutzen will
   (was man muß!).

3. (Parallel dazu): Klärung der Probleme mit Komponentenware.

Nach Abschluß von 2 und 3 kann man sich dann mit

4. dem Problem der Schaffung eines entsprechenden Patentwesens
   befassen.

Dabei sollte man nicht vergessen, daß Softwarepatente vom Wesen her
wesentlich weitgehender sind als gewöhnliche Patente: Software ist
kristallisiertes Expertenwissen, darüber hinaus kann sie auch
Prozeduren  kondensieren und in formale Abläufe gießen, was zuvor nicht
"genormt" war. Kontrolle über Software ist immer auch Kontrolle über
Abläufe innerhalb bestimmter Gemeinschaften. Schon alleine deswegen
können Softwarepatente ohne ein Schlupfloch wie freie Open Source
Lizenzen nicht erfolgreich sein: Sie zementieren sonst Dinge, die
beweglich bleiben müssen.

Kristian

-- 
SH Online Dienst GmbH, Kristian Koehntopp,
Siemenswall, 24107 Kiel, +49 431 386 436 00
Using PHP3? See our web development library at
http://phplib.shonline.de/ (GPL)