Software Open Source: Riuso nella PA

Software Open Source: Riuso nella PA

Indice dei contenuti – Software Open Source: Riuso nella PA

1. Un problema vecchio, una legge nuova (e spesso ignorata)
2. Il quadro normativo: articoli 68 e 69 del CAD
3. Cos’è davvero il “riuso” del software nella PA
4. Il catalogo Developers Italia: come funziona in pratica
5. Come pubblicare software a riuso: guida pratica per sviluppatori
6. Le best practice da seguire (e quelle da evitare)
7. La valutazione comparativa: un obbligo, non un’opzione
8. Dichiarazione di riuso: il passaggio che quasi tutti dimenticano
9. Conclusioni: formarsi per fare la differenza

1. Un problema vecchio, una legge nuova (e quasi sempre ignorata)

Immaginate due comuni italiani, distanti qualche decina di chilometri. Entrambi hanno bisogno di un sistema per la gestione delle pratiche edilizie online. Il primo spende 80.000 euro per svilupparlo da zero. Il secondo fa lo stesso, con un fornitore diverso, per un risultato praticamente identico. Nel frattempo, un terzo comune ha già rilasciato la sua soluzione in open source su GitHub, gratis, documentata e pronta all’uso.

Questo scenario non è un’ipotesi. È la norma, ancora oggi.

Il tema del riuso del software nella Pubblica Amministrazione è uno di quei capitoli della digitalizzazione italiana che rimane aperto da decenni: la legislazione è tra le più avanzate d’Europa, eppure la sua applicazione concreta è ancora lontana dal potenziale. Il Community Lab organizzato da Developers Italia il 10 luglio 2025 ha affrontato esattamente questo nodo, presentando linee guida, strumenti pratici e buone pratiche per sviluppatori e professionisti IT che lavorano con o nella PA. Un appuntamento denso, tecnico e finalmente operativo.

2. Il quadro normativo: articoli 68 e 69 del CAD

Prima di entrare nel vivo degli strumenti, è indispensabile conoscere le fondamenta giuridiche. Il Codice dell’Amministrazione Digitale (D.Lgs. 82/2005) dedica due articoli chiave al tema:

L’articolo 68 impone alle amministrazioni pubbliche di effettuare una valutazione comparativa prima di qualsiasi acquisizione di software. L’ordine di preferenza è tassativo: prima si cercano soluzioni a riuso di altre PA, poi software open source di terze parti, e solo in ultima istanza si può ricorrere all’acquisto di licenze proprietarie o allo sviluppo ex novo. Ogni scelta diversa dalla prima opzione va motivata.

L’articolo 69 stabilisce l’obbligo speculare: ogni PA che commissiona lo sviluppo di un software deve garantirsi la piena titolarità del codice e renderlo disponibile, sotto licenza aperta, alle altre amministrazioni che ne facciano richiesta. Non è una facoltà. È un obbligo di legge.

Le Linee Guida attuative, adottate da AgID con determinazione n. 115 del 9 maggio 2019 e pubblicate in Gazzetta Ufficiale, traducono questi principi in processi operativi dettagliati. Per chi sviluppa per la PA, ignorarle non è più un’opzione accettabile.

3. Cos’è davvero il “riuso” del software nella PA

Il termine “riuso” ha un significato tecnico-giuridico preciso in questo contesto, e non coincide semplicemente con “usare software open source”. Per le Linee Guida AgID, il software in riuso è esclusivamente quello rilasciato sotto licenza aperta da una pubblica amministrazione italiana e registrato nel catalogo ufficiale.

Il processo di riuso comprende tutta la filiera: dall’adattamento del codice originario al nuovo contesto, all’eventuale aggiunta di funzionalità specifiche, fino all’integrazione con i sistemi preesistenti. L’amministrazione che prende in riuso un software non paga i costi di progettazione e sviluppo originali: sostiene solo le spese di personalizzazione, installazione e formazione.

Un esempio concreto: se un Comune ha sviluppato un portale per la prenotazione degli appuntamenti allo sportello e lo ha pubblicato a riuso, un altro Comune può prenderlo, adattarlo ai propri sistemi e metterlo in produzione pagando solo il lavoro di adattamento. Centinaia di migliaia di euro di risparmio potenziale, in un solo caso.

4. Il catalogo Developers Italia: come funziona in pratica

Il punto d’accesso operativo a tutto l’ecosistema del riuso è developers.italia.it, la piattaforma gestita da AgID che raccoglie il catalogo nazionale del software open source per la PA.

All’interno del catalogo ogni voce corrisponde a un software registrato, con le relative informazioni tecniche, la licenza, la documentazione e il link al repository pubblico (tipicamente su GitHub o GitLab). La ricerca è filtrata per categoria (gestione documentale, data visualization, gestione del personale, trasparenza amministrativa, ecc.).

Dal punto di vista dello sviluppatore, il catalogo si interroga anche via API. Un esempio di chiamata alle API pubbliche di Developers Italia per cercare software in una specifica categoria:

curl -s "https://api.developers.italia.it/v1/software?type=reuse&page=1" \
  -H "Accept: application/json"

La risposta restituisce un array di oggetti JSON con i metadati di ogni software registrato: nome, descrizione, URL del repository, licenza, amministrazione titolare e numero di PA che lo hanno già adottato. Un punto di partenza prezioso prima di avviare qualsiasi nuova commessa.

5. Come pubblicare software a riuso: guida pratica per sviluppatori

Se state sviluppando o manutenzionando software per una PA, ecco il flusso operativo da seguire per pubblicarlo correttamente a riuso.

Passo 1 – Verificare la titolarità. Il contratto di sviluppo deve prevedere esplicitamente che la PA committente acquisisca la piena proprietà del codice. Se il contratto non lo dice, la PA non ha titolo per pubblicarlo.

Passo 2 – Scegliere la licenza open source. Le licenze raccomandate dalle Linee Guida sono la EUPL v1.2 (di origine europea), la MIT, la Apache 2.0 o la GPL v3. La scelta dipende dal tipo di software e dalle esigenze di interoperabilità. Un classico file LICENSE nella root del repository:

EUPL-1.2
Copyright (c) 2025 Comune di Esempio

Passo 3 – Creare il file publiccode.yml. Questo è l’elemento tecnico cruciale che rende il software “visibile” al catalogo di Developers Italia. Si tratta di un file YAML standardizzato da collocare nella root del repository, che descrive il software in modo machine-readable. Un esempio minimo:

publiccodeYmlVersion: "0.2"
name: GestionePratiche
url: "https://github.com/comune-esempio/gestione-pratiche"
softwareVersion: "1.3.0"
releaseDate: "2025-06-01"
platforms:
  - web
categories:
  - document-management
developmentStatus: stable
softwareType: standalone/web
description:
  it:
    shortDescription: >
      Sistema di gestione pratiche edilizie per enti locali.
    longDescription: >
      Applicativo web per la protocollazione, gestione e
      tracciamento delle pratiche edilizie comunali.
legal:
  license: EUPL-1.2
  mainCopyrightOwner: Comune di Esempio
maintenance:
  type: internal
  contacts:
    - name: Mario Rossi
      email: m.rossi@comune-esempio.it

Passo 4 – Registrare il software sul catalogo. Una volta che il repository è pubblico e contiene un publiccode.yml valido, è sufficibile registrarlo tramite l’apposito strumento sul sito di Developers Italia. Il crawler di AgID indicizzerà automaticamente il software e lo renderà ricercabile nel catalogo.

6. Le best practice da seguire (e quelle da evitare)

Il Community Lab ha messo in evidenza alcune pratiche che distinguono un buon progetto di riuso da uno destinato a restare inutilizzato.

Da fare: Documentare tutto, sempre. Il codice privo di documentazione è inutilizzabile da chiunque non ne conosca la storia. README chiari, commenti nel codice, guide di installazione e requisiti di sistema sono il minimo indispensabile. Usare sistemi di versionamento semantico (1.0.0, 1.1.0, 2.0.0) e mantenere un CHANGELOG aggiornato. Strutturare il repository in modo che sia possibile eseguire una installazione di test in pochi minuti, idealmente con Docker e un docker-compose.yml già pronto.

git clone https://github.com/comune-esempio/gestione-pratiche.git
cd gestione-pratiche
docker-compose up -d

Da evitare: Pubblicare codice con credenziali hardcoded (password, chiavi API, connessioni a database). Rilasciare software senza specificare chiaramente i requisiti di sistema e le dipendenze. Abbandonare il repository dopo il primo rilascio senza prevedere un piano di manutenzione, anche minimo.

7. La valutazione comparativa: un obbligo, non un’opzione

Uno degli errori più frequenti è avviare una gara d’appalto per lo sviluppo di un nuovo software senza aver prima condotto la valutazione comparativa prescritta dall’art. 68 del CAD. Questa non è una formalità burocratica: è un atto amministrativo che deve essere documentato e motivato.

Il processo corretto prevede di cercare prima nel catalogo Developers Italia le soluzioni a riuso. Se non se ne trovano di adeguate, si allarga la ricerca al software open source di terze parti. Solo in assenza di soluzioni soddisfacenti si può procedere con lo sviluppo ex novo o l’acquisto di licenze proprietarie, motivando la scelta in modo dettagliato negli atti di gara.

Questa sequenza non è negoziabile e i capitolati tecnici delle gare dovrebbero sempre riportare esplicitamente l’esito della valutazione comparativa svolta.

8. Dichiarazione di riuso: il passaggio che quasi tutti dimenticano

Quando una PA adotta un software preso dal catalogo di Developers Italia, è tenuta a effettuare una dichiarazione di riuso verso l’amministrazione cedente. Questo passaggio serve a creare trasparenza: l’ente titolare del software sa chi lo sta usando, può coinvolgerlo nelle attività di manutenzione evolutiva e costruire una comunità di pratiche intorno alla soluzione.

La dichiarazione si effettua direttamente tramite gli strumenti di collaborazione del repository (aprendo una issue o usando gli strumenti messi a disposizione su Developers Italia). Non è un atto complesso, ma è sistematicamente dimenticato. Ignorarlo significa perdere uno dei benefici principali dell’intero sistema: la creazione di reti di collaborazione tra enti pubblici che condividono le stesse esigenze.

9. Conclusioni: formarsi per fare la differenza

Il riuso del software nella PA non è solo una questione normativa. È una questione culturale, tecnica e organizzativa. Gli sviluppatori e i tecnici informatici che lavorano con la Pubblica Amministrazione si trovano ogni giorno a fare scelte che hanno un impatto diretto sull’efficienza e sulla spesa pubblica. Conoscere le regole del gioco — le Linee Guida AgID, il funzionamento del catalogo Developers Italia, la struttura del publiccode.yml, le licenze open source compatibili — non è un optional: è parte integrante della competenza professionale richiesta in questo settore.

Per chi vuole approfondire questi temi e acquisire una preparazione solida e aggiornata, Innovaformazione propone percorsi di formazione IT per la PA o per società IT che hanno fra i clienti la PA. Corsi pensati proprio per sviluppatori, ingegneri informatici e tecnici che operano nel contesto della pubblica amministrazione. I corsi coprono le tematiche legate alla digitalizzazione della PA, alle normative del CAD, all’open source e al riuso del software, con un approccio pratico e orientato all’applicazione immediata.

La formazione è erogata su richiesta, con corsi attivati in modalità online classe virtuale e calendario concordato direttamente con il cliente: massima flessibilità per enti e aziende che non possono permettersi di bloccare il proprio personale su date fisse.

Esplora il catalogo completo dei corsi QUI.

CONTATTI

Per informazioni su programmi, date e modalità di attivazione:

• info@innovaformazione.net
• 📞 347 101 2275 (Dario Carrassi)

Investire nella formazione IT per la PA oggi significa costruire una PA più efficiente, più digitale e capace di fare davvero sistema. Il codice che scrivi oggi potrebbe essere la soluzione che un altro ente riusa domani.

(fonte) (fonte) (fonte) (fonte)