[ Sven ]     [ Linux ]     [ GAOS e.V. ]     [ Softwarepatente ]     [ Heim ]

Software mit technischem Effekt?

Computer unterscheiden sich von allen anderen Geräten, die wir kennen: Sie sind Universalmaschinen. Ein Computer läßt sich durch Software nicht nur in irgendeine Vielzahl verschiedener Geräte verwandeln sondern insbesondere auch in eine Simulationsmaschine. Computer können beliebige Sachverhalte simulieren: Klimaentwicklungen, chemische Prozesse, den Flug eines Flugzeuges, Planetenbewegungen -- und sich selbst. Von dieser Fähigkeit des Computers, einen Computer zu simulieren, wird rege Gebrauch gemacht. So laufen zum Beispiel Programme, die in der Programmiersprache Java geschrieben sind, nicht direkt auf der Hardware eines Computers ab, sondern in einer sogenannten virtuellen Maschine, einem simulierten Standardcomputer. Ein anderes Beispiel für Umgebungssimulationen sind virtuelle 3D-Welten, in denen Objekte gemäß simulierter physikalischer Gesetze miteinander interagieren.

Die Simulationsfähigkeit des Computers wirft einige Fragen auf bezüglich der Begriffe Technizität und computerimplementierte Erfindung, die im Richtlinienentwurf der Kommission eine zentrale Rolle spielen. Die Proponenten gehen davon aus, daß es zur Abgrenzung zwischen reiner Software und computerimplementierten Erfindungen genügt, von (patentierbaren) Erfindungen einen technischen Effekt zu fordern, der über die bloße Verwendung eines Computers hinausgeht.

Was aber bedeutet dies im Lichte der Simulationsfähigkeit? Jeder externe technische Effekt, der unter Verwendung einer Softwarekomponente in der Außenwelt erzielen läßt, kann auch in einer reinen Softwareumgebung simuliert werden. Ein Computerprogramm interagiert ausschließlich über vorgegebene Schnittstellen mit der Umgebung. Es verfügt über keine Möglichkeit zu unterscheiden, ob sich hinter diesen Schnittstellen die reale Welt oder eine Simulation verbirgt. Es ist infolgedessen unmöglich sicherzustellen, daß eine Software tatsächlich einen technischen Effekt erzielt. Ob dies der Fall ist, hängt vielmehr von der Einsatzumgebung ab. Ebenso läßt sich umgekehrt nicht sicherstellen, daß eine Software keinen technischen Effekt erzielt. Zum Stand der Kunst in der Softwareentwicklung gehören beispielsweise abstrakte Schnittstellen, hinter denen sich beliebige Implementierungen eines allgemeinen Konzepts verbergen können. Eine Software, die solche abstrakten Schnittstellen benutzt, kann unmöglich unterscheiden, ob beispielsweise arithmetische Grundfunktionen nur Zahlen im Speicher manipulieren, oder ob im Hintergrund ein Roboterarm einen Abakus bedient.

Daraus ergeben sich fundamentale Probleme hinsichtlich der konsistenten Definition eines Technizitätsbegriffs für Software. Konsistenz ist zwingend erforderlich, denn nur so kann die nötige Rechtssicherheit geschaffen werden. Inkonsistente Begriffsbildungen würden dazu führen, daß wesentliche Fragen zwar formal korrekt von Gerichten, aber letztlich doch willkürlich und unvorhersehbar entschieden würden. Konsistente Begriffsbildungen hingegen sind nur möglich, indem man sich für eines der beiden Extreme entscheidet. Entweder wird jegliche Technizität im Zusammenhang mit Software verneint; in diesem Fall sind entsprechend klare Aussagen in der Richtlinie angebracht. Oder aber jeglicher Software wird ein möglicher technischer Effekt unterstellt, was der derzeitigen Formulierung widerspricht.

Zwar lassen sich solche Fragen grundsätzlich auch in der Rechtsprechung klären. Einige Mitgliedsstaaten mögen dies aufgrund ihrer Rechtstradition sogar für wünschenswert halten, weil sie dem Case Law generell eine herausragende Stellung einräumen. Es ist jedoch zu befürchten, daß es dann zu langwierigen juristischen Auseinandersetzungen kommt, die erhebliche Verunsicherung in der Wirtschaft auslösen können und deren Ergebnisse schwer vorhersehbar sind. Eine gründliche Prüfung des vorliegenden Entwurfs der Kommission scheint daher angebracht.

Links zum Thema liegen in unserem Wiki. Dort darf man auch gern Diskussionsbeiträge hinterlassen.


Sven Türpe, September 2003.