Numerosi dubbi, perplessità, discussioni sono sorte negli ultimi anni attorno alla possibilità che la Pubblica Amministrazione possa acquisire, sviluppare, riutilizzare e rilasciare software con codice sorgente aperto e libertà di utilizzo.

Frequentemente viene posta la seguente domanda: in queste attività la PA è differente rispetto a un qualsiasi altro soggetto privato? La risposta più semplice è: no, non lo è. Tuttavia, non sarebbe onesto affermare che la conclusione cui si giunge sia agevole e il percorso che la motiva sia identico con l’identica domanda fatta in riferimento a qualsiasi altra combinazione di soggetti in ambito privato.

In questa materia i dubbi più ricorrenti sono, ovviamente, di carattere strettamente giuridico perché la PA è legata a precise norme, sia generali che particolarmente dedicate alla tematica della tecnologia e del software. Per di più, le norme sono da un lato molto esigenti, dall’altro in vari aspetti decisamente sommarie, lasciando all’interprete e al giurista l’arduo compito di calarle nelle situazioni concrete.

Il quadro generale dell’informatica pubblica è da sempre considerato abbastanza deludente anche perché formatosi secondo modalità discontinue che dall’industria privata, se non propriamente volute, sono state fortemente influenzate. I sistemi informativi della PA risultano isolati tra loro, rigidi, poco o scarsamente scalabili e vi è un’inutile e dispersiva pluralità che fornisce elaborazioni parziali che non si integrano fra loro. Aver lasciato scegliere alle società private il compito di come fornire e gestire un sistema informativo pubblico ha affidato alle stesse funzioni proprie della PA, oltre che la conoscenza di dati che dovevano rimanere riservati.

Rendersi indipendenti dai produttori privati nell’ambito informatico è diventata per la PA un’esigenza, avvertita ormai da tempo. Per questo si sono concretizzate una serie di attività e iniziative istituzionali a più livelli. Sembra ormai chiaro ed evidente che l’Europa, quindi anche l’Italia, attraverso l’adozione di regolamenti, direttive, leggi, l’istituzione di organismi preposti e le sanzioni amministrative, vada verso l’adozione di una propria politica nel settore dell’informatica basata su alcuni principi fondamentali:

  • decidere sull’opportunità dell’introduzione di un sistema informativo piuttosto che un altro;
  • configurare e coordinare i vari sistemi tra loro;
  • gestire direttamente, anche con proprio personale, i vari sistemi adottati;
  • convertire, in ogni momento, la tecnologia alla base del sistema informativo in uso senza aggravi di costo;
  • poter usare e (far) riusare senza limitazioni le tecnologie acquisite.

Difficile immaginare di poter raggiungere gli obiettivi cui sopra se non attraverso l’acquisizione di tecnologie aperte e libere, di sistemi informativi interoperabili e basati su standard comuni e di programmi per elaboratore a codice sorgente aperto con libertà di utilizzo. Per questo, la PA, a qualunque livello locale o centrale che sia, dovrebbe scegliere di adottare “Open Source Software” o, meglio, “Free/Libre Open Source Software” (FLOSS, oppure, nella dizione del Codice dell’Amministrazione Digitale “Software Libero o a Sorgente Aperto) , principalmente per una questione di libertà e indipendenza dall’industria e dalle logiche privatistiche e non solo per questioni legate alla convenienza o alla qualità o perché obbligata dalla legge.

L’Italia ha definitivamente scelto di essere Open Source by default. Dopo un lungo percorso normativo e regolamentare durato dieci anni, le PA italiane sono oggi obbligate a vagliare e motivarel’impossibilità di accedere a soluzioni già disponibili all’interno della pubblica amministrazione, o a software liberi o a codici sorgente aperto, adeguati alle esigenze da soddisfare” (Circolare AgID 6 dicembre 2013 n.63) prima di procedere all’acquisizione di software proprietario.

La roadmap che ha portato la PA all’Open Source si può sintetizzare come segue:

  • 2003: l’allora Ministro per l’Innovazione e Tecnologie adottava la direttiva denominata “Sviluppo ed utilizzazione dei programmi informatici da parte delle Pubbliche Amministrazioni” (Direttiva MIT), con la quale si intendeva fornire alla PA indicazioni e criteri tecnici e operativi per gestire efficacemente il processo di acquisizione di software. In particolare, si invitavano le Pubbliche Amministrazioni a “tener conto dell’offerta sul mercato di una nuova modalità di sviluppo e diffusione di programmi informatici, definita open source o a codice sorgente aperto”. La Direttiva MIT introduceva, inoltre, il concetto di “analisi comparativa delle soluzioni”. Le PA avrebbero dovuto cioè procedere all’acquisizione di software solo all’esito di una valutazione tra le diverse soluzioni disponibili sul mercato, optando, di volta in volta, tra a) sviluppo di programmi informatici ad hoc, b) riuso di programmi sviluppati da altre amministrazioni, c) acquisizione di programmi di tipo proprietario mediante ricorso a licenza d’uso, d) acquisizione di programmi a codice sorgente aperto ed e) combinazione tra le soluzioni ora menzionate.
  • 2005: con l’adozione del D.Lgs. 82/2005, Codice dell’amministrazione digitale (CAD), tutte le indicazioni della Direttiva MIT sulla acquisizione di software, venivano riproposte nell’articolo 68 senza sostanziali mutamenti, se non quello, non di poco conto, dell’elevazione a norma di legge di concetti fino a quel momento contenuti solo in un atto amministrativo. L’articolo 68 chiedeva ancora una volta alle Pubbliche Amministrazioni di far precedere la scelta del software di cui avvalersi da una puntuale valutazione comparativa tra le varie soluzioni possibili. La norma (ed è questo il punto fondamentale) attribuiva alle cinque opzioni lo stesso valore. L’amministrazione aveva unicamente l’onere di una valutazione tecnico economica che non presentasse profili di irragionevolezza per giustificare l’opzione prescelta.
  • 2012: veniva introdotto il comma 1-ter all’art. 68 a seguito della entrata in vigore della Legge n. 134/2012 (legge di conversione del D.L. 94/2012). Si consolidava il principio della preferenza del riuso e del software open source (FLOSS) in virtù delle altre opzioni a disposizione. In buona sostanza, la scelta di soluzioni software proprietarie, mediante l’acquisizione con licenze d’uso, diventava residuale e consentita solo allorquando si fosse riusciti a dimostrare che l’accesso a soluzioni a codice sorgente aperto o in riuso non portasse un vantaggio economico all’Amministrazione e, anzi, generasse un aggravio di spesa. Nonostante la chiara presa di posizione del Legislatore in favore del FLOSS, vi erano ancora dubbi sulla corretta interpretazione del nuovo testo dell’art. 68. In particolare, secondo alcuni, vi era ancora la possibilità di non esprimere alcuna preferenza per le soluzioni di riuso e di acquisizione di FLOSS, stante anche il fatto che AgID non aveva ancora provveduto a stabilire criteri e metodi per effettuare concretamente la valutazione comparativa.
  • 2013: viene istituito un tavolo di lavoro in AgID avente il precipuo scopo di definire le modalità ed i criteri da adottare per svolgere la valutazione comparativa. Il tavolo di lavoro si conclude dopo diversi incontri cui partecipano i rappresentanti dei maggiori protagonisti del mercato di riferimento e, dopo una breve consultazione pubblica da parte di AgID, vengono formulate e pubblicate le linee guida sulla valutazione comparativa (Circolare 6 dicembre 2013 n.63 emessa da AgID). La Circolare, oltre a (ri)affermare chiaramente quanto stabilito dall’art. 68 del CAD in riferimento alla preferenza del riuso e del FLOSS, si occupa delle specifiche e pratiche indicazioni su come effettuare la valutazione comparativa delle soluzioni disponibili sul mercato. Gli ultimi sospetti sulla preferenza o meno di FLOSS da parte della PA decadono definitivamente. 


Per effettuare la valutazione di “possibilità/impossibilità” delle soluzioni in riuso e FLOSS
, e dunque per applicare l’art. 68 comma 1 ter, la PA deve anzitutto effettuare la “valutazione comparativa” prevista dall’art. 68 comma 1 bis. Tale valutazione chiede che sia dato un peso e una valutazione che i criteri elencati hanno nel contesto dell’acquisizione di software. I criteri sono essenzialmente, oltre al costo complessivo del programma o soluzione (costo di acquisto, di implementazione, di mantenimento e supporto, costo di uscita), il 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 e, infine, le 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.

L’adozione di una soluzione in riuso o FLOSS è impossibile quando in almeno una delle macro aree sopra definite il punteggio della relativa soluzione è insufficiente. Inoltre, in caso di notevole differenza tra le valutazioni delle soluzioni, in cui la soluzione in riuso o FLOSS abbia un punteggio molto inferiore in un’area ritenuta molto importante (e come tale denotata da un “peso” molto alto), allora si considera che la soluzione FLOSS o in riuso non sia perseguibile.

Le iniziative di standardizzazione svolgono un ruolo fondamentale perché molto spesso passano da norme volontarie e tecniche a vere e proprie norme di dettaglio o comunque assumono valenza normativa in uno specifico settore. La standardizzazione non è un elemento imprescindibile, ma da un punto di vista pratico lo sviluppo di software FLOSS si deve basare su standard aperti, accessibili e interoperabili. In alcune sue modalità, il pieno svilupparsi del software FLOSS necessita di sviluppi cooperativi concentrati su un consenso tra gli sviluppatori delle decisioni base, per cui si sono adottati standard di fatto limitati allo sviluppo di singole macro applicazioni.

Utilizzare standard resta comunque un processo volontario e complesso e, per superare gli ostacoli derivanti dall’adozione di standard diversi nella produzione, intervengono i principi dell’interoperabilità. Tuttavia, la comunicazione fra sistemi continua di fatto a costituire un argomento complesso e annoso perché esistono diverse tipologie di comunicazione, ciascuna delle quali è dotata di caratteristiche che la differenziano dalle altre; i produttori continuano a definire – indipendentemente l’uno dall’altro – paradigmi ai quali attenersi non sempre compatibili fra di loro.

Lo Studio legale Array sarà presente giovedì 6 novembre 2014 all’Open Source Day per cercare di esporre l’attuale situazione dopo un anno dall’entrata in vigore delle linee guida sulla valutazione comparativa.