di 

Valutazione comparativa per l’acquisizione dei programmi informatici: a cosa prestare attenzione

Per favorire l’utilizzo del software open source nella pa, il codice della pa digitale obbliga tutte le amministrazioni ad una valutazione comparativa tra soluzioni diverse (proprietarie e aperte), in modo da poter scegliere con congizione il prodotto e le licenze più vantaggiose. La settimana scorsa l’Agenzia per l’Italia Digitale ha pubblicato la circolare che illustra come effettuare questa valutazione. Come ci spiega Sarah Ungaro in questo articolo frutto della collaborazione con lo Studio Legale Lisi, in definitiva, prima di acquisire programmi informatici, una pa deve conoscere nel dettaglio le diverse tipologie di licenza d’uso presenti sul mercato.

Foto bbriceno rilasciata sotto licenza CC - http://www.flickr.com/photos/bbriceno/4883773602

Per favorire l’utilizzo del software open source nella pa, il codice della pa digitale obbliga tutte le amministrazioni ad una valutazione comparativa tra soluzioni diverse (proprietarie e aperte), in modo da poter scegliere con congizione il prodotto e le licenze più vantaggiose. La settimana scorsa l’Agenzia per l’Italia Digitale ha pubblicato la circolare che illustra come effettuare questa valutazione. Come ci spiega Sarah Ungaro in questo articolo frutto della collaborazione con lo Studio Legale Lisi, in definitiva, prima di acquisire programmi informatici, una pa deve conoscere nel dettaglio le diverse tipologie di licenza d’uso presenti sul mercato.

L’art. 68 del CAD (D.Lgs. 82/2005) prescrive alle pubbliche amministrazioni di effettuare una valutazione comparativa di tipo tecnico ed economico prima di acquisire programmi informatici o parti di essi.

Ma come possono le PA orientarsi nella miriade di soluzioni disponibili sul mercato?

Per questo motivo, l’Agenzia per l’Italia digitale ha di recente emanato la Circolare n. 63/2013[1], che illustra, attraverso l’esposizione di un percorso metodologico e una serie di esempi, le modalità e i criteri per l’effettuazione della valutazione comparativa delle soluzioni, ovviamente partendo da quanto previsto espressamente dall’art. 68 del CAD[2].

Tale norma, nello specifico, impone di considerare: il costo complessivo del programma o della soluzione quale costo di acquisto, di implementazione, di mantenimento e supporto; 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; le garanzie del fornitore in materia di livelli di sicurezza, di conformità alla normativa sulla protezione dei dati personali, di livelli di servizio (c.d. SLA, Service Level Agreement), tenuto conto della tipologia di software acquisito. 

In effetti, è indispensabile favorire una maggiore consapevolezza delle opportunità e dei rischi connessi alla scelta delle soluzioni software da parte dei responsabili dei procedimenti di acquisto nella PA. Spesso, infatti, le pubbliche amministrazioni delegano questa scelta a fornitori esterni che non sempre hanno i loro medesimi obiettivi. In proposito, uno dei maggiori fattori da evitare è rappresentato dalle situazioni di lock-in (ossia quelle nelle quali la PA si ritrova vincolata a utilizzare le particolari tecnologie di un determinato fornitore di servizi IT): occorre, invece, favorire la flessibilità, la portabilità e l’interoperabilità delle applicazioni informatiche delle pubbliche amministrazioni.

Per questi motivi, nelle Linee guida di AgID si raccomanda fortemente l’utilizzo di formati aperti e di standard tecnologici riconosciuti, tenendo conto soprattutto degli impatti legali e contrattuali (come, ad esempio, i modelli di licenza) nella valutazione comparativa.

In generale, dunque, le PA dovranno effettuare una scelta oculata, improntando la loro valutazione al rispetto dei principi di economicità e di efficienza, tutela degli investimenti, riuso e neutralità tecnologica, all’esito della quale potranno optare per:

- software sviluppato per conto della pubblica amministrazione (si tratta della soluzione per cui la PA affida lo sviluppo del software a un fornitore e quest’ultimo si impegna a consegnare alla PA il software sviluppato sulla base dei requisiti da questa definiti. Per esempio, nel ciclo di vita del software - analisi, progettazione, sviluppo, collaudo, rilascio, manutenzione - la PA potrebbe occuparsi delle fasi di analisi e progettazione, definendo i requisiti del software, per poi affidare lo sviluppo al fornitore; 

- riutilizzo di software o parti di esso sviluppati per conto della pubblica amministrazione (soluzione di “riuso” di un software della PA, o suoi componenti, già esistente e disponibile);

- software libero o a codice sorgente aperto (software soggetto a condizioni di licenza di software libero o open source da installare “on premise”); 

- software fruibile in modalità cloud computing (in questa soluzione la PA acquisisce il software come servizio secondo il paradigma c.d. “pay per use”; sono comprese in questa soluzione le adesioni a un contratto quadro che prevedono fruizioni in ASP[3], mentre non rientrano in questa soluzione progetti di consolidamento o virtualizzazione di Centri Elaborazione Dati);

 - software di tipo proprietario mediante ricorso a licenza d’uso

- software combinazione delle precedenti soluzioni (software realizzato con componenti appartenenti a più di una categoria tra quelle precedenti; ad esempio, software in cui una soluzione in riuso si appoggia su un middleware[4] open source e accede a un database proprietario, con componenti realizzate appositamente per conto dell’amministrazione destinataria della soluzione. È di fatto la tipologia di soluzione più comune tra quelle effettivamente in uso nelle pubbliche amministrazioni). 

Nelle Linee guida, inoltre, sono riportati utili esempi, al fine di rendere maggiormente comprensibile il contesto in cui tali valutazioni devono essere effettuate.

A tale scopo, in effetti, si precisa che per quanto riguarda le diverse licenze d’uso di prodotti software, queste possono sostanzialmente ricondursi a due grandi categorie, ossia le licenze d’uso di prodotti software c.d. proprietari e le licenze d’uso di prodotti software c.d. liberi. 

Con specifico riferimento alle licenze proprietarie, nella Circolare in commento si pone in evidenza che i soggetti titolari del diritto di sfruttamento economico del software impongono alcune condizioni e limitazioni a tutela del diritto di cui sopra, tra le quali, in estrema sintesi:

- la licenza di un software proprietario è, di norma, concessa in modo non esclusivo, dietro il pagamento di un prezzo (una tantum o canone), per un utilizzo che può essere a tempo determinato o a tempo indeterminato;

- la licenza può limitare l’uso a una sola copia o a un numero determinato di copie del software, può vincolarne l’installazione su un predeterminato apparato hardware o solo in determinate sedi del licenziatario ( c.d. “site license”), può non consentire l’uso condiviso in rete o limitare il numero di connessioni uniche o contemporanee, oppure ancora può necessitare per il suo funzionamento della presenza di ulteriori prodotti software proprietari;

- la licenza non consente la distribuzione, la modifica e ogni altra attività riservata al titolare del diritto di sfruttamento economico;

- il software è distribuito in formato binario e di regola non viene fornito il c.d. codice sorgente, perché solitamente ritenuto un segreto commerciale[5].      

A titolo di esempio, si fa presente che rientrano nella tipologia dei software proprietari in senso stretto i prodotti Microsoft Office, RealPlayer, Winzip, Adobe Photoshop e alcuni tra i più diffusi sistemi operativi quali Mac OS X, Microsoft Windows, ecc. 

Diversamente, la definizione di software libero è legata alla possibilità per gli utenti di eseguire, copiare, distribuire, studiare, cambiare e migliorare il software[6].

In estrema sintesi, come specificato nelle Linee guida, una licenza software, per potersi considerare open source, deve soddisfare i seguenti criteri: libera redistribuzione, inclusione del codice sorgente, creazione di prodotti derivati, integrità del codice sorgente originale, non discriminazione contro persone o gruppi, non discriminazione per campo d’applicazione, distribuzione della licenza, non specificità in riferimento a un prodotto, assenza di vincoli su altro software, neutralità rispetto alle tecnologie[7].

In definitiva, dunque, l’analisi comparativa delle possibili soluzioni che una pubblica amministrazione deve effettuare prima di acquisire programmi informatici non può prescindere dalla preventiva conoscenza, da parte delle stessa PA, delle diverse tipologie di licenza d’uso presenti sul mercato.

Da ultimo, nelle Linee guida si sottolinea che, in ogni caso, la scelta del percorso metodologico da intraprendere per l’acquisizione di programmi informatici nelle PA dovrà essere basata sulla valutazione della complessità organizzativa dell’amministrazione interessata, sulle competenze informatiche possedute dall’amministrazione stessa e sulla rilevanza della specifica acquisizione in esame.

*avv. Sarah Ungaro (Digital&Law Department – www.studiolegalelisi.it)

 


[1] In attuazione del comma 1-ter dell’art. 68 del CAD.

[2] Ai sensi del comma 1-ter, ove dalla valutazione comparativa di tipo tecnico ed economico, secondo i criteri di cui al comma 1-bis, risulti motivatamente l'impossibilità di accedere a soluzioni già disponibili all'interno della pubblica amministrazione, o a software liberi o a codice sorgente aperto, adeguati alle esigenze da soddisfare, è consentita l'acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d'uso.

[3] L'Application Service Provider (ASP) è un modello architetturale per l'erogazione di servizi informatici in base al quale gli stessi vengono gestiti centralmente da remoto presso un Service Provider, lasciando all'utente finale la scelta dei tempi e dei modi di fruizione del servizio

[4] Letteralmente “software di mezzo”, più precisamente si tratta di un software di connessione che consiste in un insieme di servizi e/o di ambienti di sviluppo di applicazioni distribuite, che permettono a più entità (processi, oggetti, ecc.), residenti su uno o più elaboratori, di interagire attraverso una rete di interconnessione nonostante eventuali differenze nei protocolli di comunicazione, architetture dei sistemi locali, sistemi operativi, ecc.

[5] Alcuni software proprietari, peraltro, vengono rilasciati con il codice sorgente o consentono di osservarlo secondo determinate condizioni. In questi casi gli utenti sono liberi di usare, studiare e, a determinate condizioni, modificare il software, ma sono vincolati da licenze o accordi di non divulgazione (NDA: Non-Disclosure Agreement) delle modifiche realizzate e di non ridistribuzione delle modifiche o anche per la semplice condivisione del software.
Peraltro, esistono anche software liberi “con licenza permissiva”, che permettono a chiunque di creare versioni proprietarie da ridistribuire. 

[6] In ogni caso, occorre sottolineare che software libero non vuol dire “software non-commerciale” o “software gratis”. Al contrario, lo sviluppo commerciale di software libero non costituisce affatto un caso insolito.  

[7] Alcuni esempi sono rappresentati dalle licenze GNU LGPL, BSD, MPL, PHP, Apache.