Il software e la conoscenza.
Intervista ad Alfonso Fuggetta, Docente di Ingegneria del Software presso il Politecnico di Milano.Secondo Lei, il software libero / open source è il frutto di una definizione (by FSF / OSI) o è liberamente definibile?
Io credo ci si debba riferire alla definizione sulla quale c'è una larga convergenza: software per il quale è possibile accedere "liberamente" al codice sorgente al fine di studiarlo, modificarlo, copiarlo e ridistribuirlo. Queste libertà sono codificate in licenze, alcune basate su copyleft, altre no. Direi che concordo con le definizioni di software libero e open source date da Potortì sul vostro sito e che ricalcano quelle che ho letto sul sito di Stallman.
Secondo Lei, il software libero /open source permette di diffondere la conoscenza?
È una domanda che suscita reazioni forti. Provo a rispondere sperando di riuscire ad essere chiaro.
Gli aspetti critici della conoscenza presenti in un programma informatico sono (almeno) tre:
1. Le tecniche di programmazione, cioè le modalità secondo le quali utilizzare linguaggi e strumenti per costruire pezzi di software. Per esempio, la sequenza di operazioni attraverso la quale creo una finestra in Swing con menù e dialog box. Sono quelli che in inglese vengono chiamati anche programming idioms. La visione e la modifica di codice esistente sono indispensabili per imparare le tecniche di programmazione (per esempio, come creare una finestra o serializzare un oggetto). Ma questo è sempre stato vero sin dagli albori dell'informatica, anche quando non si parlava di codice libero o aperto e non esistevano licenze quali la GPL.
2. La conoscenza del dominio applicativo. È la conoscenza relativa alla "porzione di mondo" per la quale sto sviluppando il codice. Questo tipo di conoscenza è poco distinguibile se considero software di sistema come Linux o Apache. Ma se prendo il software di controllo di un aeroplano o il software che gestisce una banca o una PA, allora questa conoscenza è cruciale. Non posso costruire e gestire questi pezzi di software se non conosco, rispettivamente, come sono fatti e come funzionano l'aereo da controllare, la banca o la PA. E non tiro fuori queste informazioni dal codice. È un dato assodato da anni. Non creo conoscenza di dominio perché posso leggere, capire e modificare il codice. È esattamente il contrario: riesco a leggere, capire e modificare il codice perché ho la conoscenza di dominio. Conoscenza che è trasmessa in altri modi: interagendo con le persone, lavorando sul campo, studiando su testi di settore...
3. La conoscenza architetturale. È la conoscenza circa l'architettura del sistema, cioè la sua struttura. Apache è un sistema architetturalmente "semplice". L'architettura di Linux è nota da decenni essendo ricavata da quella di Unix. Non ci sono grossi problemi ad acquisire questa conoscenza. Ma se considero sistemi diversi quali un software gestionale, un software di controllo o di altri sistemi minimamente complessi, l'accesso al codice sorgente dice proprio poco (mi viene da dire nulla). Lo sto sperimentando personalmente nel caso di software di controllo per elettrodomestici. Tanto è vero che esistono tecniche e strumenti per cercare (peraltro con risultati altalenanti) di ricavare dal codice in modo (semi)automatico informazioni di alto livello utili per capire l'architettura e struttura del software. Anche in questo caso vale il contrario di quello che si dice. Non è vero che acquisisco informazioni sull'architettura perché leggo il codice: riesco a capire il codice perché ho conoscenze sulla sua architettura (conoscenza trasmessami quasi sempre dai progettisti).
Se si guarda ai problemi critici delle aziende, si ha che ovviamente hanno bisogno di programmatori bravi che conoscano le tecniche di cui al punto 1. Ma i guai grossi nascono quando manca la conoscenza dei punti 2 e 3. E in quei casi il codice non serve. Ci sono programmi che non si riesce più a mantenere perché si ha il codice ma non si hanno più le persone che ne conoscono la struttura. È quello che mi dicevano l'estate scorsa in USA circa la decisione di Adobe di dismettere Framemaker per Mac OS X (chi me lo raccontava a UCI [n.d.r.: University of California, Irvine] è un sostenitore del free software).
Lei ha dichiarato di essere per il 98% contrario alla brevettabilità del software e per il 2% favorevole. I motivi della contrarietà li conosciamo. La preghiamo, invece, di parlarci di quel 2%.
Gli oppositori dei brevetti software dicono che basta il copyright. Io ritengo che esistano innovazioni che non possono essere tutelate dal copyright. Sul mio blog citavo l'esempio di un linguaggio grafico eseguibile sviluppato da alcuni miei colleghi del Politecnico. Descrivendo un sito web con questo linguaggio grafico è possibile generare e gestire in modo molto efficiente il codice del sito. Ora è indubbio che non ha alcun senso brevettare il concetto di generazione di codice. Né il codice del generatore (che può essere protetto con il copyright). Ma il vero asset del progetto è il linguaggio grafico, la sua sintassi e semantica. Una volta che è stata resa pubblica, chiunque può ricostruire uno strumento che replichi le stesse funzioni usando quel linguaggio che non può essere protetto con il copyright. Si può coprire da copyright l'articolo o il documento che descrive il linguaggio, ma ciò non preclude la possibilità di utilizzarlo senza alcun vincolo. Questo è uno dei casi per i quali credo che non si possa semplicemente dire "no". Il problema esiste e non mi sembra risolvibile semplicemente usando copyright o trademark. O negandone l'esistenza.
Secondo Lei, esiste una forma di brevetti software auspicabile?
La forma auspicabile penso possa essere così riassunta in modo schematico:
- Solo per quelle reali invenzioni che costituiscono un chiaro avanzamento dello stato della conoscenza.
- Solo per un periodo di tempo ben delimitato.
Certo, meglio nessun brevetto che una forma di brevettazione che replichi in Europa la situazione che esiste in USA.
