> Date: Sat, 9 Feb 2013 22:40:33 +0100
> From: meo@polito.it
> To: nexa@server-nexa.polito.it
> Subject: [nexa] UN PASSO INDIETRO PER IL SOFTWARE LIBERO
>
>
> 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 (Meo9
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> nexa mailing list
> nexa@server-nexa.polito.it
> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa