alfonsofuggetta.org

Sono stato a Bruxelles a parlare di brevetti software. A valle della discussione che ho avuto, ho ripensato a tutta una serie di temi e considerazioni su questo argomento. Vorrei provare a buttare giù alcune riflessioni che non vogliono essere in alcun modo statement definitivi, ma solo spunti di discussione. Riprendo anche quanto scrivevo qualche tempo fà.

Il problema di fondo

Sui brevetti si è discusso e si sta discutendo moltissimo. Purtroppo, gli argomenti a favore e contro si intrecciano spesso in modo sbagliato o confuso. A volte, gli argomenti sono usati in modo strumentale da chi vuole sostenere l’una o l’altra tesi. Molte altre volte, a mio parere, ci sono proprio errori di analisi che portano a considerazioni e o conclusioni errate o “ill-conceived”.

Credo sia necessario innanzi tutto cercare di ricordare cos’è un brevetto. Un brevetto è definito dalla legge italiana nel seguente modo:

1. Possono costituire oggetto di brevetto per invenzione le invenzioni nuove che implicano un’attivita’ inventiva e sono atte ad avere un’applicazione industriale.
2. Non sono considerate come invenzioni ai sensi del comma 1 in particolare: a) le scoperte, le teorie scientifiche e i metodi matematici; b) i piani, i principi ed i metodi per attivita’ intellettuali, per gioco o per attivita’ commerciale ed i programmi di elaboratore; c) le presentazioni di informazioni.

Ma come si articola nel concreto un brevetto? Vediamo ancora la legge:

1. Alla domanda di concessione di brevetto per invenzione industriale debbono unirsi la descrizione e i disegni necessari alla sua intelligenza.
2. L’invenzione deve essere descritta in modo sufficientemente chiaro e completo perche’ ogni persona esperta del ramo possa attuarla e deve essere contraddistinta da un titolo corrispondente al suo oggetto.

Sembra ovvio, ma per brevettare qualcosa bisogna fornirne una descrizione. Se brevetto la distribuzione desmodromica della Ducati, devo fornire una descrizione dettagliata di come la distribuzione è strutturata e funziona. Quindi devo spiegare come un altro “potrebbe attuarla”. Quindi, ciò che si brevetta è la specifica del bene o del processo. Non si brevetta l’oggetto in sè, quanto la sua specifica. Vediamo che succede nel caso del software.

I brevetti software

Quando si parla si brevetti software, spesso si intendono cose diverse. Proviamo a farne un elenco di possibili interpretazioni:

• Il codice di un’applicazione, il software “vero e proprio”.
• Il software in quanto elemento “embedded” che fa funzionare un dispositivo che realizza una certa funzione (per esempio, il software che gestisce un controllore a bordo di un veicolo).
• Un principio tecnico-scientifico come “l’idea di generazione di codice” o “is-not”.
• Un metodo o un processo (es., “one-click”).
• Un algoritmo come bubble-sort.
• La specifica di qualcosa.

Il codice sorgente è una implementazione. Come tale, secondo me non ricade nella definizione di brevetto. È quindi corretto dire, come dice la legge italiana, che non si possono brevettare i “programmi di elaboratore”. Ma se vogliamo essere coerenti, non ha neanche senso brevettare il software in quanto elemento di controllo di un oggetto embedded, cioè quello che invece accade in base alla normativa europea esistente. Mi sono abbastanza convinto che non ha senso applicare il concetto di brevetto a qualunque cosa sia “codice sorgente”. Non ha senso, sia in generale, sia che lo si consideri “embedded” in qualche aggeggio.

Però, allo stesso modo, ci sono “computer implemented invention” che possono ricadere nella definizione di brevetto, così come la distribuzione desmodromica è una “steel and mechanics implemented invention”.

Nel mio precedente post, consideravo il caso del linguaggio grafico sviluppato al Politecnico. Prendiamo un caso ancora più ovvio: UML. UML è un linguaggio definito in modo abbastanza preciso dall’OMG. In base a tale definizione (o specifica), è possibile costruire editor e strumenti che permettono di creare e manipolare diagrammi UML.

Certamente, non ha senso brevettare il singolo editor per UML, il suo codice sorgente, cioè il software che lo implementa. Ma perchè non dovrebbe essere possibile brevettare la specifica di UML? È una situazione del tutto analoga alla distribuzione desmodromica:

• È una specifica e non una implementazione.
• È un’invenzione e non una scoperta scientifica.
• C’è voluto tempo per definirla.
• Come nel caso della distribuzione desmodromica, chiunque possieda la specifica di UML, può costruire un editor. E in effetti ci sono tanti editor di UML.

Ovviamente, qualcuno potrebbe dire che UML si basa su concetti e idee già noti. È il problema della “prior art” e della verifica della reale novità dell’invenzione. Ma questo problema si pone per tutti i brevetti e non solo per il software. Analogamente, esiste un problema di precisione della descrizione: descrivere con precisione una specifica è complesso. Infine, ci sono concetti che costituiscono, specie con il passare del tempo, dei principi tecnico-scientifici di valore universale: l’idea di object-orientation non è in quanto tale brevettabile. Ma possiamo escludere a priori cose come “la specifica” di UML? Perchè lei no mentre “la specifica” della distribuzione desmodromica sì?

Un tema delicato è quello degli algoritmi. Ovviamente, non ha senso brevettare quanto è già parte del patrimonio tecnico-scientifico della società (es., bubble-sort). Ma che succede se invento un nuovo algoritmo realmente innovativo? Su questo ho dei dubbi visto che si ricade nel concetto di specifica: cosa è MPEG se non la descrizione di un algoritmo?

In realtà, quindi una prima questione importante è capire veramente cosa vuol dire brevetto e quale è la sua trasposizione nel campo del software. Molte delle cose che si dicono (da una parte e dall’altra) si basano a mio parere su concetti e fondamenti errati.

È evidente che se si usasse l’approccio che abbozzo nelle righe precedenti, il numero di “cose” brevettabili si riduce molto: potrei brevettare solo quelle “invenzioni” per le quali posso fornire una specifica precisa, come nel caso di UML.

Ma è anche una questione di opportunità

In realtà, gli argomenti più convincenti che ho sentito contro i “brevetti software”, comunque siano stati definiti, sono altri.

Il primo argomento è di tipo generale. I brevetti (in generale) sono usati sempre più come arma difensiva o per motivi di carattere commerciale (bloccare un competitor). Quindi si rivelano sempre più come qualcosa che ostacola l’innovazione e lo sviluppo della società. È un po’ quello che emerge se si osserva il dibattito in USA e il fatto che ci sono sempre più voci contro i brevetti in generale o, perlomeno, questo tipo di brevetti. Mi sembra quindi di poter dire che i brevetti in generale devono essere riconsiderati alla luce della loro vera capacità di promuovere l’innovazione.

Il secondo argomento è più specifico. Perchè un brevetto sia efficace, il rapporto tra il periodo di tempo per il quale ha senso coprire un’invenzione con un brevetto e il tempo necessario ad ottenere il brevetto deve essere molto alto: se impiego anni per avere un brevetto che ha valore solo per due-tre anni, non ne vale la pena. È un inutile spreco di risorse. Nel caso del software, potrebbe essere che molte invenzioni hanno un periodo di “novità” relativamente breve (qualche anno appunto). Quindi potrebbe essere del tutto inutile brevettare. Certo, a questo punto non sarebbe più una questione di “possibilità” ma di “opportunità”.

Si tratta quindi, mi pare, di un problema di carattere generale per quanto riguarda l’utilità dei brevetti e di opportunità per quanto concerne le “computer implemented invention”.

Brevetti e open source

Ovviamente, tutta questa discussione nasce per via dell’open source. A Bruxelles credo di aver capito meglio le motivazioni di chi si oppone al concetto di brevetto “software” in quanto pericolo per la comunità open source.

1. In primo luogo, esiste il problema dei brevetti sul codice sorgente. Come scrivevo in precedenza, anche secondo me non ha senso brevettare il codice.
2. Un secondo problema è che se alcuni protocolli o tecniche sono coperti da brevetti, diviene impossibile sviluppare codice open source.

Questo secondo aspetto mi pare ancora una volta confuso. È ovvio che se qualcuno detiene il brevetto, per esempio, di MPEG (guarda caso, un’altra specifica!), chi lo volesse utilizzare deve in un qualche modo ottenerne una licenza (a meno che il proprietario del brevetto non lo voglia rendere utilizzabile senza vincoli), sia che voglia sviluppare codice proprietario, sia che voglia fare codice open source. Ma questo è “ovvio”: se la Ducati ha il brevetto della distribuzione desmodromica, chi la volesse utilizzare sulle proprie moto deve concordare la cosa con la Ducati. È quindi ovvio che se volessi scrivere un codec open source che usa MPEG devo in qualche modo fare i conti con chi ne detiene il brevetto. Ma a questo punto si torna alla questione generale dell’utilità di avere i brevetti in quanto tali, non tanto della questione dei brevetti software.

In verità, a me sembra di capire che il problema nasce non tanto per la questione del brevetto software, ma per come sono fatte le licenze open source e in particolare quelle come la GPL (virali). Una possibile soluzione per utilizzare del codice coperto da brevetto è di integrare (facoltativamente) nel codice open source le parti di codice sviluppate dal detentore o licenziatario del brevetto. È più o meno quello che accade quando si “compra” un plug-in per un programma (vedi un browser e i plug-in per visualizzare file PDF o TIFF): io ho già il programma e ne compro delle estensioni. La questione è che integrando codice GPL con codice che a priori non è GPL si viola la GPL. Il problema non si pone, credo, se si adottano schemi di licenze come la LGPL, che permettono di effettuare queste integrazioni. In questo modo, gli sviluppatori di programmi open source, nel caso non vogliano o possano acquisire le licenze di brevetti per loro utili, possono lasciare all’utente la possibilità di decidere se acquisire il componente necessario da chi detiene il brevetto e integrarlo nel proprio sistema. Ovviamente, questo ha senso se i brevetti sono rilasciati solo nei casi in cui ha senso farlo: se i brevetti sono rilasciati su qualunque sciocchezza siamo ovviamente in una situazione patologica.

Vi sono poi due altri problemi da considerare. Il primo sono le tecniche e le norme relative al DRM. Molti le associano al tema dei brevetti. Secondo me, sono un problema certamente importante, ma ortogonale rispetto al tema brevetti. Il secondo è una considerazione generale sull’effetto dell’introduzione in settore con basse barriere all’ingresso di norme che ne cambiano le caratteristiche. Introdurre regole che vincolano un settore così vasto suscita ovviamente reazioni forti. Inoltre, si possono ledere legittimi interessi già acquisiti. Per questo, è ancora più necessario riflettere con attenzione su cosa debba essere, se ce ne fosse veramente bisogno, un brevetto “software”.

Conclusioni

Non voglio con questo post in alcun modo proporre soluzioni o interpretazione definitive. Il mio post vuole semplicemente cercare di proporre un ragionamento sul tema. Spero che venga preso per quello che è e non utilizzato in modo strumentale per cominciare le solite zuffe senza capo nè coda.

A me sembra che esistano due questioni di fondo che hanno a che fare 1) con l’utilità nella nostra società del concetto di brevetto in generale e 2) la qualità dei brevetti che oggi vengono rilasciati. Nel caso del software, questo problema diviene ancora più delicato perchè la materia è più complessa data la natura del bene “software”. Sarebbe necessario approfondire l’argomento in modo laico, cercando di trovare risposte più convincenti di quelle molto semplicistiche che vengono proposte oggi sia da una parte che dall’altra.