[Scuola] UN PASSO INDIETRO PER IL SOFTWARE LIBERO

[Angelo Raffaele Meo]

Vi sono uomini “che contano” che non amano fare un passo indietro, ma 
preferiscono far fare “passi indietro” a iniziative non gradite dai loro 
amici o protettori. Temiamo che sia questa l’amara riflessione a cui 
induce l’ultima modifica dell’art. 68 del D. Lgs. 82/2005 (detto “Codice 
dell’Amministrazione Digitale” o C.A.D.) introdotta nello scorso mese di 
dicembre con la L.221/2012 di conversione del D.L. 179/2012.
Ricordiamo un po’ di storia per comprendere la dimensione di quel passo 
indietro.
Il ministro Lucio Stanca del secondo Governo Berlusconi, sulla base 
delle indicazioni di una commissione di esperti da lui stesso 
costituita, firmò nel dicembre del 2005 una direttiva ministeriale che 
precisava i criteri da adottare nella scelta di un prodotto o soluzione 
software da parte della P.A.. Nella lista di quelli che potremmo 
chiamare i “criteri Stanca” comparivano anche il costo di uscita (ossia 
il costo associato alla sostituzione di un prodotto precedentemente 
installato con uno migliore), il potenziale interesse di altre 
amministrazioni al riuso, la valorizzazione delle competenze tecniche 
acquisite, la più agevole interoperabilità, l'uso di formati ed 
interfacce aperte, l'indipendenza da un unico fornitore o da un'unica 
tecnologia proprietaria, la disponibilità del codice sorgente per 
ispezione e tracciabilità. Chiunque si intenda di informatica sa che se 
quei criteri fossero stati adottati realmente, con ogni probabilità la 
nostra P.A. oggi acquisirebbe quasi esclusivamente software libero.
“Sfortunatamente” nel trasferimento delle regole della Direttiva Stanca 
nell'art. 68 del Codice dell’Amministrazione Digitale, i criteri 
individuati in quella Direttiva furono eliminati e quindi la preferenza 
per il software libero fu "addomesticata". Così le pubbliche 
amministrazioni hanno continuato a scegliere senza un indirizzo 
“politico” di favore per il software libero quali software acquisire, 
con un costo per il nostro Paese dell’ordine di una decina di miliardi 
all'anno, cifra superiore ai risparmi teorici attesi da una “spending 
review”.
Anche per questo molti salutarono con favore la modifica all'art. 68 
del C.A.D. introdotta la scorsa estate con la L. 134/2012 di conversione 
del D.L. 83/2012. Grazie ad un emendamento proposto da alcuni 
parlamentari, si affermò che l'acquisto di software in licenza 
(proprietario) fosse possibile solo quando la valutazione comparativa 
avesse dimostrato l'impossibilità di accedere a soluzioni in software 
libero o già sviluppate dalla P.A. ad un prezzo inferiore.
La regola avrebbe potuto essere migliore: infatti mancava l'indicazione 
dei criteri per realizzare la scelta e si rimetteva all'Agenzia per 
l'Italia Digitale l'individuazione di questi criteri. Insomma: c'era 
motivo di sperare che le persone incaricate di individuare questi 
criteri, avendo a cuore l'interesse del Paese, avrebbero recuperato i 
criteri della Direttiva del 2005 che, negli ultimi anni, sono stati 
recuperati nel portato normativo di diverse leggi regionali (la Legge 
della Regione Piemonte n. 9/2009, la Legge della Regione Puglia n. 
20/2012, ecc.).
Ma, come anticipato all’inizio, la seconda modifica dell'art. 68 del 
C.A.D. introdotta con la L. 221/2012 di conversione del D.L. 179/2012 
nel dicembre scorso, lascia molto perplessi. Infatti, essa individua i 
criteri secondo i quali si deve realizzare la valutazione comparativa, 
ma, sorprendentemente, "dimentica" i risultati del lavoro della 
Commissione istituita da Stanca e della successiva Direttiva ed indica i 
seguenti criteri di comparazione:
“a) costo complessivo del programma o soluzione quale costo di 
acquisto, di implementazione, di mantenimento e supporto;
b) livello di utilizzo di formati di dati e di interfacce di tipo 
aperto nonché di standard in grado di assicurare l'interoperabilità e la 
cooperazione applicativa tra i diversi sistemi informatici della
pubblica amministrazione;
c) garanzie del fornitore in materia di livelli di sicurezza, 
conformità alla normativa in materia di protezione dei dati personali, 
livelli di servizio tenuto conto della tipologia di software acquisito”.
Perché la nuova formulazione dei criteri di comparazione rappresenta un 
lungo passo indietro? Perché essa pare costruita ad arte per 
giustificare scelte diverse dall’adozione di software libero.
Esaminiamo separatamente i tre criteri.
“a) costo complessivo del programma o soluzione quale costo di 
acquisto, di implementazione, di mantenimento e supporto;”
Non è giusto porre sullo stesso piano i costi delle licenze – una 
perdita secca per il Paese – e i costi di un’eventuale assistenza 
tecnica, che sono invece combustibile per il motore dello sviluppo 
locale, soprattutto quando sono accessori all'adozione di software 
libero, che produce anche altre importanti vantaggi (riuso, accesso al 
codice sorgente, ecc.). Chiaramente si è preferito anteporre gli 
interessi degli amici a quelli del Paese.
“b) livello di utilizzo di formati di dati e di interfacce di tipo 
aperto nonché di standard in grado di assicurare l'interoperabilità e la 
cooperazione applicativa tra i diversi sistemi informatici della
pubblica amministrazione;”
Quel “nonché di standard in grado di assicurare l'interoperabilità e la 
cooperazione applicativa”
pone sullo stesso piano gli standard aperti e gli standard di mercato 
(proprietari).
“c) garanzie del fornitore in materia di livelli di sicurezza, 
conformità alla normativa in materia di protezione dei dati personali, 
livelli di servizio tenuto conto della tipologia di software acquisito”.
Secondo una tesi difensiva del software proprietario citata spesso 
alcuni anni orsono, il software libero sarebbe più vulnerabile agli 
attacchi a causa della disponibilità del codice sorgente. E’ stato 
scientificamente dimostrato che è vero esattamente il contrario e che la 
cosiddetta “security through obscurity” è un punto di debolezza e non di 
forza. Tuttavia, scommetteremmo l’equivalente di una licenza per mille 
macchine che in virtù del punto c la vecchia tesi della poca sicurezza 
del software libero sarà riproposta per giustificare scelte diverse.
Comunque, perché ignorare gli altri criteri che erano stati tanto 
lucidamente individuati dalla Direttiva del 19 Dicembre 2005?
Amara conclusione: come è difficile combattere contro i ricchi!

Marco (Ciurcina) e Raf (Meo)