Principi Fondamentali

Preambolo

Il documento è stato redatto inizialmente come relazione della riunione del LinuxTrent tenutasi il 1 Giugno dedicata alla discussione del DdlMauroBondi. Ciò che ne è uscito in realtà è stato poi un documento che esprime efficacemente il pensiero del LinuxTrent sul disegno di legge e quali sono i principi fondamentali che il LinuxTrent auspica una Legge sul Software Libero contenga.

Principi

Uso di formati di dati liberi

I dati prodotti da qualsiasi programma utilizzato devono essere disponibili in qualsiasi momento in formato libero (secondo definizione all’articolo 2).

Motivazioni: semplificando un po’, la proprietà dei dati prodotti da un’applicazione è dell’utente che la usa. L’utente, tuttavia, può esercitare completamente i diritti che gli derivano soltanto se il formato in cui i dati sono salvati è libero. L’adozione di formati liberi consente di ottenere indipendenza da uno specifico prodotto e fornitore, interoperabilità tra programmi e versioni di programmi eterogenei, libertà per gli utenti interni ed esterni (cittadini, in questo caso) di scegliere il programma preferito per l’accesso ai dati (neutralità).

Conseguenze:

È necessario l’uso di software che permetta un salvataggio/esportazione dei dati in formato libero, in maniera automatica (periodicamente o ad ogni utilizzo), in maniera da garantire che l’archiviazione dei dati avvenga nel formato libero. Si nota che questo non richiede necessariamente l’uso di software libero.

Uso di software libero in applicazioni “sensibili”

Nota: uso il termine “sensibile” in attesa di una migliore definizione. In alcuni domini applicativi (“sensibili”) l’uso di software libero è una necessità inderogabile.

Motivazioni: esistono applicazioni che per la loro rilevanza dai punti di vista della sicurezza, confidenzialità e riservatezza delle informazioni trattate, criticità per l’impatto sulla vita dei cittadini, e altri motivi ancora, devono necessariamente essere software libero. L’esempio forse più chiaro di questo è un eventuale sistema di e-voting, ma il concetto è applicabile anche a casi meno esoterici. È chiaro che qui il problema è definire quali sono questi ambiti “sensibili”.

Conseguenze: La necessità del controllo sull’utilizzo dei dati da parte di un’applicazione software che gestisce i dati “sensibili” è una necessità e dev’essere garantito anche tramite leggi relative al codice penale, ammesso che non ci siano già (vedasi https://www.studiocelentano.it/privacy-disposizioni-generali/ Titolo II Art.7 2c), l’aiuto di un giurista sarebbe opportuno.

Diritto a sviluppo portabile

Il diritto di sviluppare, pubblicare e utilizzare un software originale compatibile con gli standard di comunicazione e con i formati di dati di un altro software, anche proprietario, deve essere garantito.

Motivazioni: Oltre a garantire l’accesso ai dati tramite formati liberi, è necessario garantire anche la possibilità all’Amministrazione di interagire come ritiene più opportuno con i dati conservati da un software permettendo in questo modo l’incrocio di più fonti dati, per esempio per fini statistici e comunque per migliorare il servizio al cittadino.

Conseguenze: Per ottenere l’interoperabilità fra gli applicativi è necessario perlomeno il salvataggio dei dati in un formato libero, come descritto nei punti precedenti, inoltre è preferibile un software che permetta l’accesso alle procedure interne che ne gestiscono la logica applicativa tramite protocolli standardizzati, migliorando quindi la qualità del dato stesso, evitando per esempio duplicazioni di dati in diversi archivi.

Disseminazione dei risultati di investimenti pubblici

Software sviluppati grazie a contributi pubblici devono essere rilasciati come software libero.

Motivazioni: software sviluppati grazie a finanziamenti pubblici devono tornare a vantaggio della collettività. L’unico modo per garantire questo ritorno dell’investimento è attraverso il rilascio di software libero. Nota che questo principio trova applicazione in molti enti pubblici, per esempio, l’Università della California, il MIT, etc.

Conseguenze: I nuovi software sviluppati sulle specifiche della Pubblica Amministrazione vengono rilasciati come Software Libero, questo significa rendere disponibile a partire da oggi una base applicativa che possa coprire le necessità della stessa, l’auspicabile collaborazione tra Centri di Ricerca e Pubblica Amministrazione porterebbe alla realizzazione di software libero di qualità e riutilizzabile in altri contesti liberamente, ottimizzando la spesa pubblica.

Principio di responsabilizzazione

a.k.a. ostacolo all’uso del software proprietario

Esistono dei casi in cui l’uso di software proprietario è una necessità (idealmente se e solo se il software proprietario in questione è l’unico disponibile). La scelta di utilizzare software proprietario deve però essere giustificata, vagliata e giudicata. Questo ha una doppia motivazione: 1) attuare un sistema di controllo così che i principi non rimangano solo sulla carta; 2) disincentivare l’adozione di software proprietario alzando un po’ di barriere burocratiche.

Motivazioni: La mancata adozione del Software Libero trasversalmente nella Pubblica Amministrazione è dettata da diversi fattori, tra cui: la mancata conoscenza dell’esistenza di alternative libere al software proprietario, l’affidamento della gestione del software specie nelle medio piccole realtà a consulenti esterni che hanno investito in passato in soluzioni proprietarie e non riescono nel breve termine a convertire l’investimento nel Software Libero.

Conseguenze: La necessità di giustificare l’adozione di un software proprietario comporta l’analisi delle eventuali alternative, questa attività può essere realizzata da una commissione di esperti del settore che vaglino le soluzioni libere e ne analizzino costi/benefici. Attività comunque già in fase di realizzazione in diverse parti del mondo come ad esempio il progetto Cospa del Consorzio dei Comuni di Bolzano http://www.cospa-project.org

Risorse Esterne

• La direttiva Stanca:

http://www.funzionepubblica.gov.it

La direttiva Stanca prevede che il CNIPA fornisca il supporto per l’orientamento nel mondo del Software Libero (io credo che in buona parte delle direttive ci sia uno sbagliato utilizzo del termine ‘Open Source’)

• Dossier della commissione sull’Open Source:

http://presidenza.governo.it/GovernoInforma/Dossier/open_source/open%20software%20PA.pdf

• Linee guida per il passaggio al software libero redatte dalla Comunità Europea

http://europa.eu.int/ISPO/ida/jsps/index.jsp?fuseAction=showDocument&parent=news&documentID=2517

http://europa.eu.int/ISPO/ida/export/files/en/1618.pdf

• Studio condotto nel 2003 dall’Agenzia Svedese per la Gestione Pubblica (http://www.statskontoret.se/)

http://www.statskontoret.se/english/stkengpub.htm#2003

Punti critici del ddl

Alcune debolezze del ddl sono già state raccolte in CommentiAlDdlMauroBondi. Dovremmo forse sistematizzarle (per articolo/per principio) e raccoglierle qui.