Linee guida su acquisizione e riuso di software per le pubbliche amministrazioni

Linee guida su acquisizione e riuso di software per le pubbliche amministrazioni

Le linee guida AGID del 9 maggio 2019 attuano gli articoli 68 e 69 del CAD e disciplinano il ciclo decisionale che le pubbliche amministrazioni devono seguire quando acquisiscono software o intendono metterlo a riuso. Il documento è rivolto alle amministrazioni pubbliche di cui all’art. 1, comma 2, d.lgs. 165/2001, nel rispetto delle eccezioni previste per ordine e sicurezza pubblica, difesa e sicurezza nazionale e consultazioni elettorali.

Quadro normativo e finalità

Le linee guida si fondano sul principio che l’acquisizione di software da parte della PA debba avvenire nel rispetto di economicità, efficienza, tutela degli investimenti, riuso e neutralità tecnologica. Esse sostituiscono la circolare 63/2013 e si coordinano con il Codice dei contratti pubblici, con la disciplina in materia di protezione dei dati personali, con le regole tecniche AGID su accessibilità, interoperabilità e sicurezza del software.

Il testo valorizza l’art. 69 CAD come norma di spinta verso l’open source nella PA: le amministrazioni titolari di software sviluppato su specifiche indicazioni del committente pubblico devono rendere disponibile il codice sorgente completo della documentazione, in repertorio pubblico, sotto licenza aperta e in uso gratuito. Il riuso è descritto come uno strumento che deve moltiplicare buone pratiche, ma che può anche amplificare scelte tecniche errate; per questo la responsabilità della valutazione di conformità normativa resta in capo all’amministrazione che prende a riuso il software.

Oggetto delle linee guida

Nel perimetro del documento rientra il software in senso ampio: applicazioni web e desktop, applicazioni mobile, componenti, framework, librerie, plugin, sistemi operativi e siti web. Il termine software comprende non solo il codice, ma anche gli artefatti prodotti nel ciclo di sviluppo e utilizzo, come documentazione, manuali, asset grafici e materiali analoghi, come già richiamato dall’art. 69 CAD.

Titolarità del software e presupposti del riuso

L’amministrazione deve considerarsi titolare del software, ai fini dell’art. 69, quando lo abbia commissionato con contratto che attribuisca a essa tutti i diritti di proprietà intellettuale e industriale, oppure quando il software sia stato realizzato da risorse interne. La mancata acquisizione della titolarità non può essere giustificata da mere condizioni economiche più favorevoli: l’assenza di titolarità è rilevante solo se l’acquisizione risulti eccessivamente onerosa per comprovate ragioni tecnico-economiche.

Anche le personalizzazioni o i moduli destinati a interagire con software proprietario devono essere, ove possibile, acquisiti in titolarità pubblica: l’obbligo riguarda il solo modulo sviluppato, che deve essere separato dal resto e rilasciato secondo le regole del software ex novo, con chiara indicazione della dipendenza proprietaria.

Valutazione comparativa per l’acquisizione

L’art. 68 CAD impone una valutazione comparativa tecnica ed economica tra più soluzioni disponibili sul mercato: software sviluppato per conto della PA, riuso di software della PA, software libero/open source, software cloud, software proprietario in licenza d’uso e combinazioni delle precedenti. Le linee guida strutturano il processo in tre macro-fasi.

Macro fase 1 – Individuazione delle esigenze. L’amministrazione deve definire fabbisogni e vincoli, redigendo un documento descrittivo delle esigenze. Devono essere considerati il contesto organizzativo, i flussi operativi, gli obiettivi, i requisiti indispensabili e non, la disponibilità di bilancio, i tempi di messa in esercizio e gli ulteriori vincoli normativi, tra cui design dei servizi, interoperabilità, accessibilità e sviluppo sicuro.

Macro fase 2 – Soluzioni a riuso e open source. La PA deve prima verificare se esistono soluzioni riusabili messe a disposizione da altre amministrazioni su Developers Italia; solo in assenza o insufficienza di tali soluzioni può passare alla ricerca di software open source di terzi. La valutazione deve considerare conformità normativa dichiarata, copertura dei requisiti, presenza di manutentore, vincoli e dipendenze, disponibilità di competenze interne, diffusione del progetto nella PA e vitalità della community. Sul piano economico, va stimato il TCO includendo installazione, formazione, integrazione, personalizzazione e verifiche di compliance. Se una soluzione soddisfa i vincoli di budget e tempi, la PA procede all’approvvigionamento secondo il Codice dei contratti pubblici.

Macro fase 3 – Soluzioni proprietarie o sviluppo ex novo. Se le soluzioni a riuso e open source non risultano idonee, la PA deve esaminare soluzioni proprietarie e, contestualmente, la possibilità di realizzazione ex novo. Per le soluzioni proprietarie sono richieste conformità a interoperabilità, privacy, sicurezza, accessibilità e possibilità di esportazione gratuita e aperta dell’intera base dati per evitare lock-in. La comparazione deve considerare anche costi di cloud, integrazione, formazione e TCO. Se si opta per lo sviluppo ex novo, l’amministrazione deve predisporre uno studio di fattibilità con stima di attività, costi e tempi. In ogni caso, l’acquisto o lo sviluppo deve essere effettuato seguendo le procedure del Codice dei contratti pubblici.

Modalità di erogazione e cloud

Quando il software debba essere installato su server, la PA può scegliere tra SaaS, se disponibile e qualificato nel Marketplace Cloud AGID, e installazione su server nella propria disponibilità tramite il Cloud della PA. In quest’ultimo caso, le opzioni richiamate sono PSN, Cloud SPC Lotto 1 o Cloud Service Provider qualificati. La scelta deve essere supportata dal TCO.

Riuso del software e ruolo di Developers Italia

Il riuso è definito come utilizzo di software di titolarità di una PA, rilasciato in open source, in un contesto diverso da quello originario. Il riuso non è un mero accesso al software: l’amministrazione ricevente lo acquisisce gratuitamente, sostenendo solo i costi di adattamento, personalizzazione, installazione e supporto. Developers Italia svolge la funzione di piattaforma/repertorio e motore di ricerca per il software in riuso, sostituendo il precedente catalogo nazionale.

Regole per la messa a riuso e pubblicazione open source

Il processo di messa a riuso richiede: scelta di uno strumento di code hosting; scelta di una licenza aperta; pubblicazione del codice sorgente completo e della documentazione; registrazione del software su Developers Italia. Lo strumento di code hosting deve garantire accesso libero in lettura, registrazione pubblica gratuita, navigazione web, versionamento, issue tracker, code review, gestione dei rilasci e API. È preferibile una piattaforma SaaS, per evitare costi aggiuntivi.

Per la licenza, le linee guida indicano che la scelta deve essere coerente con l’obiettivo del riuso. Per nuovo software si raccomanda EUPL 1.2; se il software è principalmente fruito via rete, AGPL 3.0 o successive; per librerie e SDK, BSD 3-Clause; per la documentazione, CC-BY 4.0. La scelta diversa è possibile solo se motivata e se non limita il riuso né genera costi aggiuntivi.

Pubblicazione del software esistente e sviluppo ex novo

Il rilascio open source riguarda l’intero parco software di titolarità pubblica, non solo i nuovi contratti. Le amministrazioni devono censire il software esistente, verificare la titolarità e rilasciarlo ove sia ancora in uso; è escluso l’obbligo per software non più utilizzato da oltre cinque anni alla data di pubblicazione delle linee guida. Nei nuovi progetti il rilascio deve essere previsto sin dall’inizio dello sviluppo, e nei contratti di appalto la guida tecnica deve essere allegata alla documentazione di gara.

Manutenzione del software open source

Le modifiche al software in manutenzione fanno scattare l’obbligo di rilascio ex art. 69. Se esiste già un repository, le modifiche devono essere pubblicate lì prima dell’immissione in collaudo o produzione; la manutenzione deve monitorare anche le dipendenze e l’upstream, con priorità agli aggiornamenti di sicurezza. L’amministrazione titolare assume il ruolo di maintainer e l’operatore incaricato deve gestire le interazioni sul repository, rispondendo in tempi rapidi, valutando bug, richieste di funzionalità, contributi di codice e richieste di supporto. Le informazioni di sicurezza vanno trattate in modo riservato fino alla correzione, poi rese pubbliche.

Presa in riuso di software open source di terzi

Quando la PA prende a riuso un software open source non di titolarità pubblica e lo modifica, deve minimizzare la divergenza dal codice originario, preferendo plugin o estensioni piuttosto che modifiche del core. Le modifiche devono essere proposte al maintainer originale tramite issue o pull request, e la documentazione del repository deve dare conto delle differenze rispetto al progetto di origine. Se il maintainer recepisce integralmente le modifiche, il codice deve comunque essere pubblicato nello strumento di code hosting della PA per consentirne il riuso, indicando la provenienza.

Obblighi informativi e documentali nei repository

Gli allegati tecnici precisano che il repository deve contenere, tra l’altro, file LICENSE, README.md e publiccode.yml; quest’ultimo è essenziale per l’indicizzazione su Developers Italia. Il README deve riportare titolo, descrizione, contesto d’uso, prerequisiti, istruzioni di installazione, stato del progetto, contatti del maintainer, copyright e indirizzo per le segnalazioni di sicurezza. La documentazione deve essere in formato testuale versionabile; non sono ammessi PDF/ODT/DOCX per la documentazione tecnica principale.

Sicurezza e accorgimenti tecnici rilevanti

Nel rilascio open source devono essere rimossi password, certificati e credenziali reali; il codice morto va eliminato. È raccomandata l’adozione di modularità, package manager e file di configurazione per separare le specificità dell’amministrazione. Per applicazioni web esposte pubblicamente è consigliato il file security.txt. Le modifiche devono essere pubblicate tempestivamente e, ove utile, gestite tramite branching.

Sintesi finale per il professionista

Per la PA, le linee guida impongono un ordine di priorità: prima riuso di software pubblico, poi open source di terzi, infine soluzioni proprietarie o sviluppo ex novo. Al centro del sistema vi sono la titolarità pubblica del software sviluppato su commissione, la pubblicazione in open source, il coordinamento tramite Developers Italia e l’uso di strumenti e licenze che favoriscano il riuso senza lock-in, nel rispetto di sicurezza, privacy, interoperabilità e accessibilità.