lunedì 11 febbraio 2013

Un passo indietro per il software libero

In accordo con gli autori, ospito con grande piacere una riflessione a firma di Angelo Raffaele Meo e Marco Ciurcina sull'evoluzione normativa italiana in materia di software libero (o forse dovremmo dire "involuzione"?).
Per approfondire il tema, ricordo che in appendice al mio libro "Apriti standard!" si trova una ricostruzione delle principali fonti normative italiane in materia di standard aperti e interoperabilità.
Per qualche riflessione più aggiornata sulle recenti riforme in materia, vi segnalo invece questi miei articoli:
_______________________________________________

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 pubblica amministrazione 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 2003 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.
  • 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.
  • 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).
  • 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 2003?
Amara conclusione: come è difficile combattere contro i ricchi!

Angelo Raffaele Meo e Marco Ciurcina

(Questo articolo è rilasciato per volontà degli autori con licenza Creative Commons Attribuzione 3.0 Italia)

Nessun commento: