[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