Brevetti software: un romanzo giallo

La vicenda dei brevetti software è più intricata di una spy story, e, come in ogni spy story che si rispetti, non mancano gli eroi positivi e negativi, i colpi di scena e le imboscate. Cercheremo qui di dipanare la matassa tenendo due obiettivi in vista: da un lato analizzare i brevetti software nell’ottica della questione del controllo e diffusione della conoscenza, tema di cui ci siamo già occupati in passato parlando di software libero; in secondo luogo, mettere in luce alcuni meccanismi poco nobili del fare politica nelle sedi europee.

Ma procediamo con ordine. Cosa sia un brevetto è spiegato nella scheda. Per capire come si sia giunti alla situazione attuale, è utile ripercorrere per sommi capi il dibattito sui brevetti software, iniziato a cavallo tra gli anni ’60 e ‘70.

Nella maggior parte dei Paesi europei, il software viene da subito generalmente inquadrato nella categoria dei "beni immateriali" per i quali, in base alla natura del bene stesso, sono previsti due tipi di tutele: nel caso delle creazioni intellettuali il diritto d’autore, in quello delle innovazioni industriali il brevetto. Due tipi di protezione quindi. La normative nazionali devono però armonizzarsi coi trattati internazionali in materia. Fondamentale, in particolare, nel 1973, la convenzione di Monaco sui brevetti, che stabilisce esplicitamente che il software non può essere considerato innovazione e, dunque, non è brevettabile. Il principio alla base della decisione è che il software non è tecnologia ma scienza, e che i programmi software sono equiparabili a leggi scientifiche e metodi matematici sui quali non si può concedere alcun diritto di esclusiva. In accordo col trattato di Monaco, le normative europee, italiana compresa, inquadrano quindi il software nel contesto del diritto d’autore, assimilando i programmi software a opere letterarie.

Questione chiusa? Niente affatto. Una serie di revisioni della convenzione, la prima già nel 1986, erodono i limiti inizialmente posti alla brevettabilità del software, stabilendo, ad esempio, che solo le "innovazioni tecniche" possono essere brevettate, ma evitando accuratamente di definire cosa si intenda per "tecnico", lasciando quindi ampio margine di interpretazione. In secondo luogo, la materia viene affrontata anche negli Stati Uniti, e qui, nel giro di un solo decennio, si passa dal netto rifiuto all’esplicito favore della brevettabilità dei programmi software.

Eccoci finalmente ai nostri giorni. La partita si gioca ora a livello di Unione Europea, e qui, al termine di un travagliato iter, lo scorso 7 marzo viene approvata dal Consiglio Europeo una direttiva sui brevetti che di fatto garantisce ampia, si direbbe indiscriminata, brevettabilità dei programmi per computer.

Quali sono i rischi collegati a questa nuova normativa? In primo luogo, la direttiva non pone di fatto limiti né vincoli specifici a quanto può essere coperto da brevetto, aprendo così la strada non tanto ai brevetti software, quanto ai brevetti sulle idee implementate in un software. Si proporrà di conseguenza anche in Europa, come già negli Stati Uniti e in Giappone, il problema della proliferazione di brevetti estremamente generici e onnicomprensivi perché svincolati dallo specifico contesto tecnologico e astratti dalla concreta implementazione. Brevetto, e relativo monopolio, copriranno quindi non una ben definita applicazione di un’invenzione (ad esempio, algoritmo, interfaccia grafica, formato di dati, soluzione di un requisito) ma tutte le possibili applicazioni di tale invenzione.

La durata di un brevetto, poi, è del tutto inadeguata al contesto del software, dove il panorama tecnologico muta radicalmente in pochi anni. Il rischio è quello di ritrovarsi alla scadenza del brevetto con un’invenzione sì liberamente disponibile, ma ormai obsoleta e quindi inutile.

In terzo luogo, il costo di acquisizione di un brevetto è relativamente elevato – nell’ordine delle decine di migliaia di euro – alla portata, quindi, solamente delle grosse società. Questo non giova certo all’industria europea del software che è costituita per lo più di piccole e medie imprese.

Esiste infine il nodo dell’Ufficio Brevetti Europeo (EPO), l’organismo incaricato di valutare le domande di brevetti. L’EPO ha evidenziato negli anni passati limiti strutturali (risorse economiche e di organico), culturali (competenze per valutare l’originalità delle proposte ricevute) ed etiche ("vive" dei ricavi derivanti dai brevetti concessi). Limiti che verranno necessariamente acuiti dal flusso di nuove richieste di brevetti software. Va notato, poi, che l’EPO ha già iniziato da qualche anno ad accettare brevetti software, ancora per qualche tempo, evidentemente, di validità assai dubbia. Le ultime analisi effettuate confermano, tuttavia, che degli oltre 30.000 brevetti di questo tipo concessi, la maggior parte è estremamente generico e legato ad "innovazioni" triviali e che oltre il 50% è stato appannaggio di compagnie americane e giapponesi.

Ma come si è arrivati all’attuale normativa? Proviamo a ripercorrerne i passaggi chiave. Nel febbraio del 2002, la Commissione Europea propone una direttiva sui brevetti che garantisce ampia brevettabilità del software. Nel settembre del 2003 il Parlamento Europeo approva, però, una serie di emendamenti alla proposta della Commissione che ne rovesciano sostanzialmente lo spirito, ponendo forti e chiari vincoli alla brevettabilità del software. Nel maggio del 2004, il Consiglio Europeo annuncia un accordo politico su una versione della direttiva simile nello spirito a quella della Commissione, ignorando quindi il voto del Parlamento.

Ma a questo punto una serie di eventi scompagina le carte in tavola. Prima, l’allargamento dell’Unione fa cambiare i numeri necessari per l’approvazione rapida della direttiva. Poi, alcuni Stati, prima fra tutti la Polonia, inizialmente favorevoli, ritirano il loro appoggio.

La presidenza olandese prova comunque a far passare la direttiva come "A-item", cioè approvabile senza discussione, inserendola all’ordine del giorno degli incontri dei ministri dell’agricoltura. Il giochetto viene ripetuto per ben tre volte, ma senza successo per l’opposizione ora dell’uno ora dell’altro Paese.

All’inizio di quest’anno, la conferenza dei presidenti di gruppo del Parlamento approva all’unanimità una risoluzione in cui chiede di riazzerare il processo della direttiva: anche questo richiamo del Parlamento viene del tutto ignorato. Contemporaneamente, i lobbysti pro-brevetti mettono in campo tutte le loro forze. Microsoft si premura di far notare al governo danese che la mancata approvazione della direttiva la costringerà a trasferire altrove gli 800 posti di lavoro della controllata Navision. Le successive dichiarazioni ("Siamo stati fraintesi: non era una minaccia") non suonano convincenti né tranquillizzanti.

Infine, l’ultimo atto: il 7 marzo scorso la presidenza lussemburghese annuncia il raggiungimento di un accordo sulla direttiva al termine di una seduta viziata da numerosi errori procedurali e i cui passaggi chiave sono misteriosamente assenti in tutte le registrazioni audio e video pubbliche.

Ora il testo della direttiva tornerà al Parlamento per la seconda lettura, ma vincoli di regolamento (in particolare, il fatto che gli assenti contino come favorevoli) riducono al lumicino le speranze di modifica.

Come si vede, la questione dei brevetti software è importante per diversi motivi. Da un punto di vista istituzionale, ha contrapposto, come forse mai prima nella storia dell’Unione, Parlamento e Consiglio, arrivando in più occasioni a sfiorare il punto di rottura. Dal punto di vista politico, poi, la vicenda ha dimostrato una sconcertante permeabilità del sistema alle pressioni e ai convincimenti delle lobby. Infine, ha dimostrato una preoccupante mancanza di progettualità e di visione su tematiche che avranno necessariamente un notevole influsso sullo sviluppo economico, tecnologico e quindi sociale dell’Europa.