[Scuola] R: UN PASSO INDIETRO PER IL SOFTWARE LIBERO

Antonio Guermani antonio.guermani@inwind.it
Fri Feb 15 20:48:11 CET 2013


Ringrazio Ciurcina e Meo per il chiaro ed esauriente resoconto della vicenda.

Vista la mia ignoranza in giurisprudenza, spero di non dire corbellerie, nel 
qual caso mi scuso anticipatamente, e chiedo:

è possibile dare nomi e cognomi di chi ha proposto questa seconda modifica 
dell'art.68? 

Sia chiaro che non chiedo un'allusione o un pettegolezzo, chiedo molto 
semplicemente se ciò risulta agli atti o in qualche dichiarazione pubblica.
Mi pare altrettanto ovvio che non mi riferisco ai ministri firmatari della L.
221/2012 o del D.L. 179/2012, ma alle eventuali commissioni parlamentari e/o 
ministeriali che hanno steso il testo di legge.

Antonio Guermani

>dicembre con la L.221/2012
>----Messaggio originale----
>Da: meo@polito.it
>Data: 09/02/2013 22.43
>A: <scuola@lists.linux.it>
>Ogg: [Scuola] 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 (Meo)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>scuola mailing list
>scuola@lists.linux.it
>http://lists.linux.it/listinfo/scuola
>




More information about the scuola mailing list