[LUG-Ischia] Licenza d'innovare

[Linux User Group Ischia]

14-03-2005
Licenza d'innovare
Alfonso Gambardella 

Il 7 marzo, il Consiglio sulla competitività della Commissione europea ha 
rimandato al Parlamento il testo della "direttiva sulla brevettabilità del 
software". È l’atto più recente di una diatriba che va avanti dal 2002, da 
quando Commissione e Parlamento si rimpallano il documento a suon di 
emendamenti in cui la prima amplia ciò che può essere brevettato come 
software e il secondo lo restringe. 

Chi brevetta. E chi no 

Per entrare nel merito della disputa, possiamo valutare l’esperienza degli 
Stati Uniti, che hanno avviato la brevettazione "forte" sin dai primi anni 
Ottanta.
I problemi sono la crescita dei brevetti mirati non tanto a proteggere le 
proprie invenzioni quanto a bloccare quelle degli altri e il grande aumento 
delle citazioni in giudizio su questioni brevettuali. D’altra parte, 
brevetti più forti non sembrano aver scoraggiato le piccole-medie imprese 
high-tech. Sam Kortum e Joshua Lerner mostrano che nella seconda metà degli 
anni Ottanta, la quota di imprese che non avevano brevettato nel quinquennio 
precedente è aumentata rispetto alla seconda metà degli anni Settanta. 
Brownyn Hall e Rosemarie Ziedonis documentano entrambi gli effetti nei 
semiconduttori. E mostrano che l’effetto dell’aumento della litigiosità 
brevettuale e dei "blocking patent" è più marcato degli stimoli alle 
piccole-medie imprese innovative. Jim Bessen e Robert Hunt ottengono 
risultati analoghi proprio nel software. Anzitutto, i brevetti delle grandi 
imprese manifatturiere sono aumentati molto di più di quelli delle imprese 
di software: secondo i loro dati, le prime impiegano l’11 per cento dei 
programmatori e analisti di software e detengono il 75 per cento dei 
brevetti, mentre le seconde impiegano il 33 per cento dei programmatori e 
analisti e posseggono il 13 per cento dei brevetti software. Una differenza 
così marcata nella produttività brevettuale non può essere spiegata da 
differenze di efficienza, ma solo da differenze nella propensione a 
brevettare. Inoltre, Bessen e Hunt mostrano che, a parità di altre 
condizioni, le imprese con una maggiore propensione a brevettare hanno una 
intensità più bassa di ricerca & sviluppo (R&S). Un brevetto più forte, che 
protegge meglio chi brevetta nella difesa delle proprie innovazioni, rende 
la R&S più remunerativa, e dunque dovrebbe aumentarla e non diminuirla. Il 
sospetto è perciò che i brevetti non servano a proteggere le proprie 
innovazioni, ma a qualcos’altro, e probabilmente ad avere più potere 
contrattuale rispetto ai concorrenti e a bloccarne le innovazioni. 

Il modello open source 

Insomma, gli Stati Uniti sembrano essersi spinti un po’ troppo in là. E, in 
effetti, due rapporti della Federal Trade Commission e della National 
Academy of Science suggeriscono strade per riequilibrare il sistema. Ora, la 
posizione della Commissione è più articolata di quanto gli oppositori della 
direttiva sostengono. La direttiva metterebbe solo ordine in una materia in 
cui non c’è disciplina in Europa e, comunque, l’Ufficio brevetti europeo sta 
brevettando software da tempo senza guida da parte del legislatore. Inoltre, 
come ribadito l’8 marzo di fronte al Parlamento dal commissario alla 
Direzione mercato interno e servizi, Charlie McCreevy, la direttiva non 
consente di brevettare nulla che non sia già brevettabile oggi, ed è fatta 
in modo da consentire di brevettare soltanto contributi tecnologici 
importanti.
L’esperienza Usa ha mostrato però che la corsa alla brevettazione e 
l’aumento delle citazioni in giudizio sono stati un fenomeno troppo grande e 
socialmente costoso per sentirsi rassicurati dalle parole di un Consiglio 
comunitario, per quanto autorevole.  Al tempo stesso, l’open source è un 
modello nuovo e interessante di produzione del software, sta realizzando 
progetti e innovazioni utili per la società e andrebbe incoraggiato.
Perché non pensare anche a una direttiva che istituzionalizzi la Generalized 
Public License (Gpl)? La Gpl è il contratto principe dell’open source che 
impone a chi contribuisce a un programma open, del quale viene cioè messo a 
disposizione pubblicamente il codice sorgente, di mettere a disposizione il 
codice sorgente dei relativi miglioramenti. Il modello potrebbe essere 
adottato in contesti diversi e difatti si sta diffondendo in altri sistemi 
tecnologici, come le biotecnologie. La direttiva potrebbe definire il 
meccanismo e in particolare l’estensione del vincolo di pubblicità dei 
miglioramenti a valle, standardizzare le caratteristiche dei contratti Gpl, 
articolarne la tipologia e assicurarne il rispetto. Al di fuori del 
software, la Gpl potrebbe imporre pubblicità e licenze non esclusive sui 
migliormenti di un’innovazione.
La direttiva stimolerebbe poi la concorrenza tra i due sistemi. Chi inventa 
può brevettare o mettere le proprie innovazioni in campo aperto. Il 
meccanismo va studiato e precisato, ma sarebbe una bella innovazione 
istituzionale europea, una volta tanto in anticipo e non a rimorchio degli 
Stati Uniti. 

Per saperne di più 

Bessen, J. e R. Hunt (2004) "An Empirical Look at Software Patents", Working 
Paper 03-17, Federal Reserve Bank of Philadelphia.
Gambardella, A. e B.H. Hall (2005) "Proprietary vs Public Domain Licensing 
in Software and Research Products", NBER Working Paper 11120, www.nber.org.
Hall, B.H. e R. Ziedonis (2001) "The Patent Paradox Revisited: Determinants 
of Patenting in the US Semiconductor Industry, 1980-1994", Rand Journal of 
Economics 32 (1), 101-128.
Kortum, S. e J. Lerner (1999) "What is Behind the Recent Surge in 
Patenting", Research Policy 28, 1-22. 

Link ai rapporti Ftc e Nas:
http://www.ftc.gov/opp/intellect/
http://www7.nationalacademies.org/ocga/briefings/Patent_system_21st_Century. 
asp
########################################
......--.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
....|@_ @|   Linux User Group Ischia   ~
....|:_/ |          LUG-Ischia         ~
...//   \ \  @:. info@lug-ischia.org   ~
..(|     | ) www:.www.lug-ischia.org   ~
./'\_   _/~\  http://ischia.linux.it   ~
.\___)=(___/~~~~~~~~~~~~~~~~~~~~~~~~~~~~