[Gfoss] Fwd: [Discussioni] UN PASSO INDIETRO PER IL SOFTWARE LIBERO

[Paolo Cavallini]

Una lettura lunga ed interessante, secondo me.
Salulti.

-------- Messaggio originale --------
Oggetto: [Discussioni] UN PASSO INDIETRO PER IL SOFTWARE LIBERO
Data: Sun, 10 Feb 2013 15:24:07 +0100
Mittente: marco at softwarelibero.it
Rispondi-a: Discussioni sul software libero. <discussioni at softwarelibero.it>
A: discussioni at softwarelibero.it
CC: Angelo Raffaele Meo <meo at polito.it>

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)



_______________________________________________
http://lists.softwarelibero.it/mailman/listinfo/discussioni
Totale iscritti: 368 al 06/11/2010

Questa è una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione per il Software Libero.