Ernstige Tekortkomingen
Reactie op rapport van de Avdiescommissie Software Octrooien (Commissie Giskes)
Op 28 mei jl. heeft de Adviescommissie Software octrooien (hierna: de Adviescommissie) haar advies inzake de Softwareoctrooien richtlijn uitgebracht.
CONCLUSIE
1 Ernstige problemen bij verlening softwareoctrooien
De Adviescommissie beschrijft zeer ernstige problemen bij de verlening van octrooien op software.
2 CII = software
De Commissie maakt duidelijk dat er geen onderscheid te maken is tussen "Computer Implemented Inventions" en software.
3 Pure software patenteerbaar?
De Adviescommissie stelt dat software technisch is en meent dat software om deze reden patenteerbaar moet zijn. Er kan met evenveel recht gesteld worden dat software niet technisch is, dit is een woordenspel. Belangrijker is dat hiermee het uitgangspunt dat pure software niet patenteerbaar dient te zijn, verlaten wordt. De Adviescommissie steekt de Rubicon over. De politieke vraag is of we dit willen. De vraag is ook of het verstandig is: nooit is aangetoond dat octrooien op software de innovatie bevorderen, het onderzoek moet nog beginnen. En er is een waslijst aan problemen geconstateerd. Er wordt flankerend beleid voorgesteld, met betrekking tot onder andere interoperabiliteit en kwaliteit. Er is geen enkele zekerheid of en wanneer dit flankerende beleid gestalte zal krijgen. Zullen de problemen ooit opgelost worden, of zullen ze onoplosbaar blijken? Hoeveel jaren zullen de deuren wagenwijd open staan? Het is te vroeg om de Rubicon over te steken.
4 Flankerend beleid
Het is de vraag of flankerend beleid succesvol kan zijn:
Het verkleinen van de inventieve stap is gedaan ten behoeve van grote bedrijven [1]. Inderdaad merkte een vertegenwoordiger van Siemens onlangs op dat er incidenten zijn, maar dat zij slechts zelden voorkomen – we weten in Nederland, met dank aan de Adviescommissie, onderhand wel beter. Deze grote bedrijven zijn een duidelijke en stevige tegenkracht tegen de voorgenomen vergroting van de inventieve stap. Er zijn miljoenen producenten van software over de hele wereld. Het is onbekend wat er al gebeurd is, wat nieuw is. Ook omdat van veel software de bouwtekeningen, de broncode, geheim is. Als je al niet weet wat nieuw is, is het onmogelijk te weten wat werkelijk vernieuwend is. De schaalgrootte en snelheid van softwareontwikkeling zijn zodanig, dat het octrooisysteem hier mogelijk niet anders kan dan falen. De ontwikkeling van computerprogramma's vindt vooral op incrementele wijze plaats, grote innovaties zijn vrijwel altijd de cumulatie van vele kleine. Het patenteerbaar maken van kleine stapjes en bijdragen heeft geleid tot fragmentatie, een stortvloed aan ongewenste octrooien. Het verhogen van de drempel leidt tot oneerlijkheid. Wie krijgt het octrooi, het bedrijf dat 100 stapjes toevoegde, of het bedrijf dat één grotere bijdrage leverde? Het octrooisysteem werkt niet goed in velden waar de ontwikkeling sterk cumulatief is. Het octrooirecht heeft hier geen oplossing voor.
We achten het heel wel mogelijk dat binnen de grenzen van het huidige octrooirecht geen bevredigende oplossing gevonden kan worden voor het octrooieren van software. Een werkelijke vernieuwing van het octrooisysteem kan het beste afgedwongen worden door software vooralsnog volledig van octrooiering uit te sluiten. Indien we software nu uitsluiten, kunnen we over 5 jaar nog altijd anders beslissen. Indien we software nu niet uitsluiten, hebben we over 5 jaar een berg softwareoctrooien waar we 20 jaar aan vast zitten. Een compromis is het steunen van de amendementen van het EP die dataprocessing uitsluiten en vernieuwend gebruik van natuurkrachten eisen. Zonder een sterke stok achter de deur gebeurt er niets. Dit geldt ook voor het bereiken van een regeling voor de interoperabiliteit.
5 Kosmetische amendementen
Voor het geval er onverhoopt wel een richtlijn tot stand komt beveelt de Adviescommissie een aantal punten aan.
De Adviescommissie geeft in bijlage 2 “Belangrijke punten voor Nederland indien een richtlijn tot stand komt” aanbevelingen. Deze zijn naar onze mening volstrekt onvoldoende. Inhoudelijk triviale softwareoctrooien zitten in de Raadsversie ingebakken. Hier wordt niets aan gedaan. Het is verbijsterend dat de Adviescommissie een krachtige aanpak op het gebied van triviale vindingen voorstaat zonder in te gaan op de ruime faciliteiten die dergelijke triviale vindingen geboden worden in de huidige Richtlijn. De Adviescommissie maakt haar werk niet af. Methoden van zakendoen worden patenteerbaar. Interoperabiliteit wordt niet in de richtlijn geregeld. We moeten er maar op hopen dat het ooit nog eens ergens geregeld zal worden.
6 Samenstelling Commissie
Juist het MKB, een belangrijke bron van innovaties en schepper van zo'n 80% van de nieuwe werkgelegenheid in Europa moest vertegenwoordiging in de Adviescommissie ontberen. In haar huidige samenstelling omvatte de Adviescommissie naast de Voorzitter een Philips-werknemer, een voormalig directeur van een volle Philips-dochteronderneming en een promovendus.
De conclusies liegen er niet om: er wordt een waslijst aan problemen geconstateerd bij de verlening van octrooien op software. Het is aan u en aan de Kamer de finale, politieke conclusie te trekken. Ons inziens laten de geconstateerde problemen geen andere keus toe dan alle steun aan het Raadvoorstel – dat beoogt de gewraakte praktijk te codificeren – te onthouden. Deze stellingname geeft steun aan de beoogde doelen: intrekking richtlijn en bereiken flankerend beleid. Een legitimering van de gewraakte praktijk kan uiteraard niet plaatsvinden, en zou bovendien een nieuw voorstel voor lange tijd uitsluiten. Nederland dient alle steun aan het Raadvoorstel te onthouden.
Voorkomen dient te worden dat de Raadsversie van de Richtlijn binnen enkele maanden van kracht wordt. Dit zal het geval zijn indien het Europees Parlement geen krachtige amendementen aanneemt. Nederland dient te bevorderen dat het EP de richtlijn stevig amendeert.
De door de Adviescommissie naar voren gebrachte punten nemen de zwakheid van de Raadstekst niet weg, integendeel. Zie verder onze bijlage.
- Tot slot betreuren wij het dat u tijdens voornoemde debat wederom heeft doen voorkomen dat de standpunten van voor- en tegenstanders van de Richtlijn dicht bij elkaar liggen. In onze brief van 13 maart jl. wezen wij u er al op dat u ons standpunt onjuist weergeeft. Het is dan ook teleurstellend dat dit in het kamerdebat van 2 juni jl. wederom plaats heeft gevonden. Wij zouden het dan ook op prijs stellen als u in het vervolg een correcte weergave van de meningen zou willen geven.
Bijlage
Bespreking bijlage 2 van de Adviescommissie, “Belangrijke punten voor Nederland indien een richtlijn tot stand komt”
In punt 4 wordt aandacht gevraagd voor de kwaliteit van octrooiverlening. We merken op dat de ondergrens in de Raadstekst voor een technische bijdrage “andere technisch effecten” zijn. Elk technisch effect boven wat we al kennen, is hiermee voldoende. Wat niet octrooieerbaar is, wordt octrooieerbaar door een minimale efficiëntiewinst [2]. Door het concept “andere technisch effecten” (art 4a2) zitten inhoudelijk triviale softwareoctrooien in de Raadstekst ingebakken. Een minimale efficiëntiewinst levert de maatschappij zo goed als niets op. De maatschappelijke kosten zijn echter zeer hoog: monopolies, uitsluiting, royalty's, transactiekosten, hogere prijzen, bedreiging interoperabiliteit, en een overmaat aan octrooien. Tegenover een minimale maatschappelijke winst staan dus zeer hoge maatschappelijke kosten. Een maatschappij die een dergelijke overeenkomst sluit, benadeelt zichzelf.
Het is verbijsterend dat de Adviescommissie de trivialiteit aan wil pakken maar in de Raadstekst verzuimt “andere technische effecten” te vervangen. De Adviescommissie maakt haar werk niet af.
In punt 1 wordt er gesteld dat methoden van zakendoen niet patenteerbaar moeten zijn. Dit wordt gesteld zonder beperking. In punt 3 blijkt dat zij wel patenteerbaar worden. Inderdaad maakt de Raadstekst methoden van zakendoen die een technische bijdrage leveren patenteerbaar. We merken op dat technisch een kardinaal verschil uitmaakt, en dat zonder gedefinieerd te zijn. Omdat volgens de Adviescommissie software technisch is, kan elke combinatie van een methode van zakendoen met software een octrooi opleveren. Tevens merken we op dat de ondergrens in de Raadstekst voor een technische bijdrage een “ander technisch effect” is. Zo zijn methoden van zakendoen niet patenteerbaar, tenzij er een minimale efficiëntiewinst geboekt wordt. Methoden van zakendoen moeten ons inziens nooit patenteerbaar zijn. Het is onnodig - mensen willen heus wel rijk worden. Methoden van zakendoen patenteerbaar maken levert geen maatschappelijke winst op (omdat het onnodig is), er is wel maatschappelijk verlies: monopolies, uitsluiting, royalty's, transactiekosten, hogere prijzen. Methoden van zakendoen moeten volledig worden uitgesloten. Indien de uitvinding waarmee de methode van zakendoen wordt gecombineerd een werkelijke uitvinding is, kan hij eigenstandig gepatenteerd worden.
In punt 2 wordt de uitsluiting van software als zodanig opgegeven, zonder dat er iets voor in de plaats komt dan goede voornemens.
Punt 3 beoogt algoritmen vrij te houden in andere toepassingen dan de geoctrooieerde. Echter, andere toepassingen zijn andere technisch effecten, en dus ook weer patenteerbaar. Niet alleen zijn alle algoritmen in software in principe patenteerbaar, ze zijn ook meerdere malen patenteerbaar. Hetzelfde geldt voor methoden van zakendoen.
Last but not least willen we opmerken dat indien er een richtlijn tot stand komt, de Nederlandse regering er klaarblijkelijk niet op staat dat de interoperabiliteit geregeld wordt. Dat komt dan hopelijk nog wel eens in ander verband... Wij achten deze houding lichtzinnig. Interoperabiliteit dient direct goed geregeld te worden.
Noten
[1] [DUT99] THE INNOVATION DILEMMA: INTELLECTUAL PROPERTY AND THE HISTORICAL LEGACY OF CUMULATIVE CREATIVITY Graham M. Dutfield & Uma Suthersanen Intellectual Property Quarterly 2004 p. 379-421 [2] http://www.elis.ugent.be/~jmaebe/swpat/cons.html
Powered by Plone Plone is Copyright © 2000-2005 by Alexander Limi, Alan Runyan, Vidar Andersen.