Brevetti software, il dibattito continua

Roma – Mi ama, non mi ama,.. mi ama, non mi ama! – Il singolare caso della margherita OGM
Il software ha un carattere del tutto originale, che lo rende diverso da qualunque altro “prodotto” dell’ingegno umano, esso infatti non solo è informazione, conoscenza, ma è anche, e spesso soprattutto, un bene strumentale. Per questo motivo ritengo potenzialmente fuorvianti metafore ed analogie con altri elaborati figli dell’ingegno umano e limiterò le mie considerazioni esclusivamente ai programmi per elaboratori.

Alcuni giorni fa, a valle dell’ editoriale apparso sulla Margherita on-line a firma di Paolo Zocchi, ritenni opportuno commentare le romantiche suggestioni che vorrebbero possibile la realizzazione di un programma che produca odori: come è noto infatti i programmi per loro natura sono inodori e questo nella maggior parte dei casi è una fortuna anziché no, ma l’errore che si nasconde dietro questa singolare ipotesi è preoccupante.

Preoccupa l’idea che i programmi siano, nell’accezione proposta, qualcosa di diverso rispetto ad una semplice descrizione di un metodo effettuata ricorrendo ad un linguaggio non naturale, quale che sia il linguaggio scelto e l’algoritmo descritto.

L’attribuire al software un valore diverso dall’essere una rappresentazione matematica di un concetto del tutto slegata dalle leggi fisiche dell’universo, come scrisse lo stesso Donald Knuth nella lettera del 1995 all’ufficio brevetti statunitense, è un errore che può indurre a ritenere orwellianamente determinati programmi più uguali di altri, arrivando ad immaginare un ipotetico spartiacque dove da una parte ci sono i programmi innovativi, che “odorano”, e dall’altra quelli che, per converso, “puzzano”, in quanto banali rielaborazioni di altri programmi già esistenti.

Il problema di stabilire quale software possa essere brevettabile è antico: l’ufficio brevetti statunitense, nonostante le preoccupazioni espresse dalla Federal Trade Commission, dopo oltre dieci anni di pratiche non ha saputo porvi rimedio, né si profila uno scenario in cui l’Europa saprà meglio districarsi, visto e considerato la quantità di brevetti già oggi accettati dallo European Patent Office in barba alla convenzione di Berna del 1971, visto e considerato il tempo medio di evasione impiegato per stabilire se un’idea sia o meno brevettabile (in media 17 ore, stando a quanto riportato da un responsabile dell’EPO nel corso di un incontro tenutosi a Bruxelles, ndr), visto e considerato infine che gli uffici brevetti sono realtà private, il cui “modello di business” si basa essenzialmente sul recepimento del brevetto piuttosto che no (si veda in proposito cosa riporta il sito dell’ufficio brevetti).

Tale preoccupazione peraltro è ben espressa anche nel citato editoriale, dove si ipotizza che multinazionali senza scrupoli (ma potrebbero benissimo essere uffici legali nazionali) brevettino quanto “inventato” nell’ambito di progetti Open Source, comunicando al lettore implicitamente l’idea secondo la quale gli uffici brevetti abbiano delle politiche di recepimento piuttosto lasche.

Ma venendo alla questione, a mio parere centrale, di “dare vita ad un sistema fortemente competitivo nelle ICT”, è fondamentale ricordare che il problema è e rimane l’incertezza: il programmatore, dipendente di una multinazionale o libero professionista, che si sieda per scrivere un programma non sa e non può sapere se quello che sta realizzando è o non è coperto da uno piuttosto che cento brevetti, visto e considerato che nemmeno gli stessi uffici brevetti dispongono di strumenti per la “navigazione” dei brevetti registrati, come dimostra l’esistenza di casi di sovrapposizione tra brevetti.

Sfido chiunque a farsi un giro sull’archivio dei brevetti software attualmente registrati presso l’USPTO e a verificare se questo possa in qualche modo essere “di stimolo alla circolazione delle idee e della conoscenza”, o se questo non possa essere più semplicemente ricondotto a quello che numerosi economisti chiamano un campo minato, ovvero uno spazio in cui non è dato sapere a priori se e quando poseremo un piede su una “mina” (il brevetto, appunto) depositata chissà quando da qualcunaltro. Non è infatti da sottovalutare la potenza deflagrante della pratica dei cosiddetti submarine-patent, brevetti registrati su cui il cui detentore anziché reclamare i diritti attende pazientemente la diffusione dei programmi che implementano l’idea descritta siano sufficientemente diffusi, per poi poter ottenere la massima efficacia nella richiesta di royalty.

Ma ciò che proprio non comprendo è da dove nasca l’affermazione di Zocchi secondo la quale le grandi aziende aggirino la legislazione sui brevetti attraverso il diritto d’autore, laddove aziende italiane del calibro di Engineering e Zucchetti hanno sostenuto, pubblicamente e presso istituzioni italiane ed europee, l’esatto contrario.

Come è noto, infatti, il fronte di imprese italiane contrarie all’istituto del brevetto si sta sempre più allargando: ieri nel corso dell’incontro “Il futuro del software” l’ing. Valli, in rappresentanza di Assintel, ha sostenuto le ragioni del no, e da oltre due anni numerose imprese hanno preso parte attiva alla lotta contro la brevettabilità del software, contribuendo alla vittoria della prima battaglia (emendamento del testo originale in prima lettura al parlamento, ndr) e, si spera, contribuendo ad una seconda vittoria, che deve puntare, è bene ricordarlo, ad appoggiare gli emendamenti proposti da Rocard, e non un esiguo e marginale sottoinsieme di essi come ipotizzato da Zocchi.

Il mio augurio è che i numerosi interventi in risposta all’articolo siano uno spunto per rielaborare una posizione meno lontana dalle imprese e dal territorio, aiutandole a poter continuare a lavorare in questo mercato, senza venirne escluse definitivamente a causa di una direttiva così scellerata.

Roberto Galoppini
Presidente Consorzio CIRS


Roma – Spettabile redazione, vi scrivo in merito agli articoli pubblicati venerdì relativi al dibattito sulla mai abbastanza contestata normativa della Brevettazione del Software. Non sono né un avvocato, né un imprenditore né tantomeno un politico: sono un semplice studente universitario che è ormai in procinto di chiudere (parola grossa, ma ci sta) gli studi e guadagnarsi una laurea in Ingegneria Informatica. Nulla di ché, si tratta di una laurea di primo livello, ma è pur sempre una laurea in campo informatico. Non ho quindi nessuna pretesa di fornire un parere tecnico, ma di esprimere semplicemente il pensiero di uno studente che purtroppo ha trovato la sua strada nell’informatica e nelle tecniche di programmazione.

Già, creare software è la mia massima aspirazione, e questa idea si rafforza ogni qualvolta mi capita di creare qualche programma utile e/o funzionale. Ma anche che abbia un certo grado di prestazioni minimo.

La prima fase di progettazione dove si sceglie su quali strutture dati poggiare le fondamenta del sistema, la scelta del tipo di algoritmi, la loro implementazione e l’esecuzione di test ad-hoc che non fanno altro che confermare la bontà della propria scelta; e se questa non dovesse rivelarsi propriamente corretta, un’eventuale revisione del codice e l’applicazione di un diverso approccio nel funzionamento può portare ad ancora più soddisfazione, specialmente se il risultato è uno dei migliori che si possa ottenere.

Ci può anche stare una ulteriore fase di ottimizzazione, nella quale si studia il codice creato statement per statement alla disperata ricerca di un ordine di operazioni che può portare ad eliminare comandi superflui. Ognuna di queste fasi ha un suo fascino, ma solo se la mente è libera di correre dove vuole.

Beh, alla fine sono accettabili (e forse necessari) anche dei paletti dati da specifiche di progetto (se un cliente ti chiede un piccolo editor di testo, mica bisogna prepararne uno un grado di comandare direttamente gli utensili per stampare sulla carrozzeria di una auto).

Personalmente, io ritengo che il software prodotto debba semplicemente produrre le funzionalità richieste dal cliente, e come è fatto è affar mio. Anche perché vorrei poter essere orgoglioso di quanto ho creato: se ho pensato a una soluzione per eseguire una certa operazione, e tale soluzione è ottima per il mio problema, non ho di certo voglia di stare a sentire uno che passa di li per caso e mi viene a dire “guarda, non puoi fare le cose in questo modo perché una idea simile la ho pensata io”; mi darebbe alquanto fastidio.

Come dire che in certe condizioni solamente i tuoi neuroni possono connettersi tra loro in quel modo e produrre quell’idea: se penso in un modo analogo al tuo mica vuole per forza dire che ti ho copiato, siamo in sei miliardi sulla Terra; è come dire che se costruisco una porta non posso metterci una maniglia perché il concetto di maniglia lo ha già “pensato” qualcun altro.

Scrivo pensato non a caso perché, da quanto scritto da Andrea Rossato un brevetto per software contiene solo una descrizione generica dell’algoritmo (perdonate l’ignoranza, ma io non ho mai visto un brevetto in vita mia). Per carità, non voglio assolutamente sembrare il solito maniaco del software Open Source o ancor peggio un sovversivo anarchico. Ritengo che come è stata formulata la cosa, non può funzionare, e in questo caso sono assolutamente d’accordo con Rossato e PLIO.

Si potrebbe anche dar ragione alla direttiva se i programmi creati possono includere al massimo uno o due brevetti, ma se ad ogni brevetto corrisponde un algoritmo, la condizione è soddisfatta solo per piccoli esercizi di programmazione di massimo 200 righe. Un programma di piccole dimensioni supera facilmente le 1000 righe di codice, il che vuol dire tra i 5 e i 10 brevetti, se si considera brevettabile un algoritmo che richieda tra 50 e 100 righe di codice. Un programma da 1000 righe inoltre genera file eseguibili da pochi KByte; un programma più serio ha degli eseguibili di dimensioni superiore al MByte, quindi può violare centinaia di potenziali brevetti, un costo davvero insostenibile per una PMI; figuriamoci per un libero professionista.

Ma ammettendo che l’insensatezza della proposta di legge passi sotto il naso di tutti, io avrei un solo dubbio: per cosa ho studiato a fare?

Il problema centrale è che per poter esercitare senza correre troppi rischi dovrei farmi assumere da una qualche multinazionale come IBM, Microsoft, Oracle e simili, e comunque dovrei passare ore e ore a cercare sul web quali brevetti violerebbe la riga di codice che ho appena scritto (sicuro, il controllo sarebbe riga per riga!!), e alla fine sviluppare software non sarebbe di sicuro appagante come lo è adesso. Alla fine, se non vengo assunto da una ditta che ha un ragguardevole portafoglio di brevetti, mi dovrei ridurre a un povero impiegato che cerca di trovare un modo per dribblare le idee altrui senza poter usare le proprie perché “poco originali”.

Alla fine questa non è innovazione, è solo tortura mentale della peggior specie: logorandosi per cercare una nuova soluzione allo stesso problema, porta all’esaurimento delle risorse e dello slancio necessari per poter terminare il lavoro cominciato. Per coloro che hanno iniziato a studiare informatica una situazione del genere non può far altro che freddare gli animi e portare a riconsiderare la propria scelta: non tutti hanno una mente paragonabile a quella di Leonardo, Einstein o qualsivoglia genio del passato. Non tutti possono avere l’inventiva per trovare un nuovo modo di eseguire una ricerca in una lista senza utilizzare un algoritmo di ricerca. È vero che in informatica un algoritmo può essere implementato in modi diversi, ma se è necessario un tipo di algoritmo, non è possibile sostituirlo con uno di un tipo diverso: se devo fare una ricerca, non posso usare un algoritmo di modifica!

E poi innovare vuol dire trovare diverse soluzioni a problemi complessi, e non sforzarsi per trovare l’ennesimo modo per fare la stessa cosa: la prima regola di un programmatore è che non si deve reinventare la ruota. Anche se non hai i soldi per pagarti un brevetto della malora. Anche perché chi non è un genio e vale davvero deve aver la possibilità di dimostrarlo indipendentemente dalle sue condizioni economiche e senza dover essere assunto dalla IBM di turno.

Rocco Pezzani