Kompromissmodell Nutzungsrecht?

[PILCH Hartmut <phm@a2e.de>]

> > Schliesslich engagiert sich ja gerade IBM sehr stark im OpenSource-
> > Bereich.
> >
> > Man sollte sich eher fragen, wo das wirtschaftliche Interesse
> > liegt, wenn Konzerne geschützte (durch Copyright oder Patente)
> > Sourcen dennoch offenlegen und zur Nutzung freigeben...
> 
> Bei angenommener Patentierung (bzw. Anmeldung zum Patent) muß ja
> offengelegt werden. Also kann ich auch nach Anmeldung ein Open-Source
> Projekt daraus erzeugen, bei dem die gewerbliche Weiterverwendung
> der Verfahren durch Dritte wirkungsvoll verhindert werden kann.

Sicherlich waere ein Regime, bei dem alle patentierten Verfahren zumindest
in quellenoffenen Programmen eingebaut und weitergegeben werden duerfen,
ohne dass die Autoren Aerger kriegen, ein grosser Fortschritt.

Wohlgemerkt bedeutet "quellenoffen" in obigem Zusamenhang nicht das
gleiche wie "Opensource^{tm}".  Z.B. koennten die Freetype-Entwickler 

	http://www.freetype.org/patents.html

eines Tages die freundliche Genehmigung von Apple erhalten, ihr Programm
weiter entwickeln und verbreiten zu duerfen, wobei Apple sich allerdings
vorbehalten wuerde, von Firmen, die Linux irgendwo einsetzen,
Lizenzgebuehren zu verlangen, weil ttflib auf der Distribution ist, dann
haetten wir noch immer ein schweres Problem.

Im Moment ist die Problemlage aber noch viel schlimmer:  Apple koennte
jederzeit die Weiterentwicklung von Freetype verbieten.  Aehnlich wie
Microsoft es mit VirtualDub gemacht hat.

Vielleicht koennte man das gerichtlich anfechten und auf dem Wege der
Rechtssprechung halbwegs ertraegliche Regeln durchsetzen, aber davon sind
wir in US und EU weit entfernt, obwohl es das System in den USA schon seit
ca 1981 gibt.  Das ist nicht ohne Grund so.  Die Patentjustiz wird nicht
zulassen, dass am absoluten Ausschlussrecht des "Erfinders" geruettelt
wird.  Und dabei hat sie mehr Argumente auf ihrer Seite als in der Frage
der "Aequivalenz zwischen Software und Hardware", die sie gerne als Grund
fuer die Aufweichung der Technizitaetslehre ins Feld fuehrt.  Wenn alles
so aequivalent ist, warum sollten dann im Bereich der Software andere
prozedurale Regeln gelten?  Zudem noch solche, die den wirtschaftlichen
Wert von Softwarepatenten und damit die Einnahmen des EPA mindern?  Darf
es nach EPA-Verstaendnis ueberhaupt je einen "Bereich der Software" geben?  
Ist nicht die angebliche Nichtfassbarkeit dieses Bereiches der Grund fuer
die Aushebelung der Technizitaetslehre?

> Der liebe Kunde hat sein "Open-Source", der Hersteller seine wie
> üblich geschützte Software. 

Obwohl das mit "OpenSource" nichts mehr zu tun hat, waere es ein grosser
Fortschritt gegenueber der heutigen US-Situation.  Aber niemand unternimmt
Schritte in diese Richtung.  Weder das EPA noch die Gesetzgeber noch IBM.

> Ob sich dies bei aktuellen Patentkosten rechnet, steht auf einem
> andern Blatt.

Und das ist auch wohl der Grund, warum die Vertreter des Patentwesens hier
nichts unternehmen.

Einem Patentwesen, welches seine zentralen Begriffe aufweicht, um neue
Einnahmequellen zu erschliessen, kann man nicht trauen.  Das EPA muss erst
die geltenden Gesetze beachten und das Vertrauen in die Unparteilichkeit
und Kontrollierbarkeit des Patentwesens wiederherstellen helfen.  Erst
dann koennte es ein Partner fuer Gespraeche ueber neue komplizierte
Schutzrechtskonzepte sein, von denen das EPA ohnehin nichts wissen will.

Bei einem Treffen im November 1999, wo J.P. Smets im EPA sein
Nutzungsrechtskonzept

	http://www.freepatents.org/adapt/useright/

vorstellte, reagierten die Software-Abteilungsleiter nur mit
Geringschaetzung.  Ihre "Argumente" waren die bekannten: 

- Wenn es fuer Loesungen einer Problemklasse gestern Patente gab,
  muss es die heute und morgen auch noch geben
- das Ausschlussrecht muss absolut sein

Alles andere interessierte die Leute nicht.  Sie machten sich nicht einmal
die Muehe, das Konzept zu begreifen, obwohl es sehr anschaulich
vorgetragen wurde.  Das haben sie nicht gelernt, und es hat keinen Zweck,
mit ihnen darueber zu diskutieren.

-phm