Sezione 6 – Ora che hai qualificato il tuo software come IA o come algoritmo deterministico, fai la ricognizione dei software in consegna alla PA

a cura di CNR-IFAC

Valentina Colcelli, Alessandra Langella, Nicola Zoppetti, Moreno Comelli

6.1 Prepara il registro dei software in consegna alla PA

Predisponi un Piano di Ricognizione dei Software (PdRS) che documenti i componenti software utilizzati e prodotti nell'ambito del progetto di Gemello Digitale Urbano (GDU), con l'obiettivo di garantire trasparenza sulle scelte tecnologiche adottate e di definire le condizioni di consegna al Comune.

Per ciascun software vengono rilevati provenienza, licenza, dipendenze e formato di rilascio, assicurando la tracciabilità dell'intero stack tecnologico del GDU.

Usa lo Schema n. 2_ PdRS — Software

6.2 Per completare il PdRS - software effettua il giudizio di compatibilità delle licenze

La stessa attenzione che è stata posta per i database/dataset rispetto alla Compatibilità tra licenze va posta per i software incorporati nei software rilasciati come prodotti nel GDU.

La licenza è al contempo un contratto e una dichiarazione programmatica di uso.

La licenza d’uso in genere comprende:

- La concessione della licenza
- Le limitazioni di uso
- La limitazione di garanzia
- La limitazione di responsabilità
- Le restrizioni all’esportazione.

Con riferimento alla distribuzione del software, questa analisi tiene in considerazione un’importante distinzione delle licenze in:

Licenze per il software proprietario
Licenze per il software libero

Nelle licenze per il software proprietario il sorgente è chiuso e non disponibile all’utente. Inoltre, i programmi accompagnati da queste licenze sono solitamente a pagamento.

Sono possibili diverse varianti delle licenze proprietarie:

Licenze trial (o versioni di prova): in questo caso l’utente prova il programma per un determinato periodo di tempo e la scadenza del termine comporta la fine della funzionalità del software. Per continuare l’utilizzazione, è necessario il pagamento di un corrispettivo seguito dall’invio di un numero seriale che comporta lo sblocco del programma. Da questo momento in poi il programma funzionerà correttamente e a tempo indeterminato
licenze shareware: la licenza permette all’utente di copiare e diffondere il programma con funzionalità ridotte rispetto alla versione completa. Il pagamento ulteriore sbloccherà le funzioni inibite.
Licenze freeware: l’utente ha a disposizione programmi completi senza alcun corrispettivo

Software libero

Si contrappone al software proprietario e la libertà per l’utente è declinata in una serie di prerogative quali:

Libertà di eseguire il programma per qualsiasi scopo (libertà 0)
Libertà di studiare come funziona il programma e di modificarlo in modo da adattarlo alle proprie necessità (libertà 1) l’accesso al codice sorgente ne è un prerequisito
Libertà di ridistribuire copie in modo da aiutare gli altri (libertà 2)
Libertà di migliorare il programma e distribuirne pubblicamente i miglioramenti apportati in modo tale che tutta la comunità ne tragga beneficio (libertà 3)
L’espressione software libero si differenzia dalla terminologia software open source che più specificamente attiene alla possibilità di accedere al codice sorgente e modificarlo

Rispetto alle licenze occorre distinguere tra

Licenze open source in base alle quali chiunque può utilizzare il programma senza limitazione così che lo studio del funzionamento, eventuali modifiche e distribuzione siano possibili
Licenze closed source: l’utente non può in nessun modo accedere al codice sorgente né modificarlo

L’interpretazione di una licenza è un’attività tecnico-giuridica complessa che implica la comprensione in contemporanea delle specifiche tecniche presenti e future di un software e le condizioni di utilizzo (e diffusione del medesimo). Per questo è necessario analizzare l’intero testo della licenza.

Le condizioni di licenza più importanti concernono:

Copyright e attribuzione all’autore: comporta l’obbligo di nominare l’autore del software, anche nel caso di open source. Quando il software è integrato con diversi apporti occorre determinare gli autori delle diverse porzioni.
Condizioni della licenza: in alcuni casi può essere obbligatorio riprodurre il testo della licenza e l’esclusione della garanzia.
Diffusione del codice sorgente
Nessuna garanzia: Significa che il destinatario/utente non può ritenere l’autore responsabile di eventuali danni
Rispetto alle categorie di licenze si possono indicare
Per struttura
licenze semplici in cui le principali condizioni sono il riconoscere l’autore quando si distribuisce il codice sorgente e l’assenza di responsabilità dello sviluppatore
licenze lunghe in cui sono incluse molte specifiche per il licenziatario

6.3 Glossario

Licenze Aperte	Si riferiscono a dati, contenuti o opere (es. dataset, documenti, immagini) e non necessariamente a software. Sono disciplinate da normative come: *Direttiva (UE) 2019/1024 sul riutilizzo dell’informazione del settore pubblico (Open Data Directive*). Codice dell’Amministrazione Digitale (CAD), art. 52 e ss., per il riuso dei dati pubblici. Consentono il riutilizzo, ma con condizioni variabili (es. attribuzione, non uso commerciale, condivisione allo stesso modo). Esempi: Creative Commons (CC BY, CC BY-SA, CC0), Open Data Commons.**
Licenze Open Source	Si applicano esclusivamente al software. Sono definite dall’Open Source Initiative (OSI) e devono rispettare criteri come: Accesso al codice sorgente. Libertà di modifica e ridistribuzione. Nessuna discriminazione di persone o ambiti di utilizzo. Normativa di riferimento: CAD art. 68 e Linee Guida AgID per il riuso del software nella PA. Esempi: GPL, MIT, Apache License, EUPL.
Le licenze possono essere definite anche per contenuto:
Public Domain	Una licenza di pubblico dominio è una licenza nella quale il detentore dei diritti rinuncia ai diritti di proprietà intellettuale. È la licenza consigliata per il rilascio di banche dati in Open Data, ove non ci si occupi di banche dati originali per scelta o disposizione di opere. Si ricorda che i diritti sui singoli elementi contenuti in una banca dati sono comunque coperti da una loro licenza individuale, che non è pregiudicata dal loro inserimento in una banca dati. Questa licenza, infatti, offre ai riutilizzatori una flessibilità totale e riduce le complicazioni collegate all’operatività su varie e diverse licenze con il potenziale conflitto di disposizioni che comporta. La più diffusa licenza in questo senso è la Creative Commons Zero (Codice SPDX: CC0-1.0).
Licenze Non-copyleft	Le licenze non-copyleft sono licenze aperte che garantiscono molta libertà e flessibilità di riutilizzo da parte degli utenti. Con queste licenze il detentore dei diritti richiede infatti solamente una frase che identifica la fonte del documento e, ove fattibile, un collegamento alle pertinenti informazioni sulla licenza, non ponendo limitazioni all’utilizzo o alla modifica dell’opera di ingegno. Queste licenze vengono utilizzate per componenti software che implementano adattatori o componenti che nascono per essere integrati in applicativi di terze parti. Il focus principale di queste licenze è posto sul riutilizzo nel maggior numero di programmi possibili. A differenza delle licenze copyleft, non esiste un obbligo di chi adatta questi componenti a rilasciare eventuali modifiche e miglioramenti, ma solo un riferimento per ottenere copia del codice sorgente originale. Esempi di queste licenze sono la licenza BSD, la licenza MIT e la licenza Apache - codici SPDX: BSD-3-Clause, MIT e Apache-2.0. Nota: l’utilizzo della licenza Apache è sconsigliato in quanto incompatibile con la licenza GNU GPL versione 2 (codice SPDX: GPL-2.0-only).
Licenze copyleft	Le licenze copyleft sono licenze che richiedono un’attribuzione all’autore originale ma che aggiungono le cosiddette clausole «virali». Il concetto di viralità impone a ogni successiva modifica di essere rilasciata sotto una licenza che non imponga ulteriori restrizioni all’utente. Si utilizzano per preservare la libertà del software a ogni successiva modifica, imponendo il rilascio in riuso di ogni eventuale modifica migliorativa da parte di terze parti. Si noti che è indispensabile fornire copia del codice sorgente solo all’atto della distribuzione o concessione in licenza del software, non al momento dello sviluppo. Questo tipo di licenza è consigliato per tutti gli applicativi software completi. La licenza più diffusa in questo senso è la GNU GPL (codice SPDX: GPL-3.0-or-later) o la GNU AGPL, sua modificazione che copre anche l’ambito di software distribuiti via rete (codice SPDX: AGPL-3.0-or-later).
Licenze copyleft – per le librerie	Ai fini di garantire flessibilità nel riutilizzo, ovvero permettere l’utilizzo di un componente software in un applicativo sotto qualunque licenza, la clausola di viralità può essere indebolita. Queste licenze vengono anche dette «a copyleft debole». Questa clausola aggiuntiva mantiene intatta la viralità per quanto riguarda modifiche sul codice del componente, ma permette l’integrazione esterna da parte di un software distribuito sotto qualunque licenza. Si noti che queste licenze contengono la cosiddetta «clausola di riproducibilità»: deve essere sempre possibile per l’utente di un software di terze parti sostituire il componente rilasciato sotto licenza LGPL con una sua versione modificata, senza modificare le funzionalità del software di terze parti. Questa clausola può essere problematica e non soddisfabile in alcuni ambienti embedded, ad esempio iOS. La versione più utilizzata è la licenza GNU LGPL (codice SPDX: LGPL-3.0-or-later), versione modificata della licenza GNU GPL.
Mozilla Public License (codice SPDX: MPL-2.0)	è una licenza a copyleft debole (a livello di singolo file), che garantisce la libera distribuzione del codice ma impone di non poter riutilizzare, all’occorrenza di modifiche, loghi, nomi, o altri marchi registrati del detentore dei diritti, salvo ulteriore autorizzazione
European Union Public Licence (EUPL)	è una licenza copyleft (la clausola dell’art. 5 è denominata «clausola copyleft»), resa flessibile dalla clausola di compatibilità, sviluppata dalla Commissione europea, e tradotta ufficialmente in tutte le lingue dell’Unione. Questa licenza allega una tabella di compatibilità con alcune delle licenze aperte più comuni. Codice SPDX: EUPL-1.2
Licenze Creative Commons	Esistono molte versioni delle licenze Creative Commons. Queste licenze, così come suggerito da Creative Commons stesso, non sono utilizzabili per proteggere software, ma solo altre opere di ingegno (ad esempio documentazione o testo). Le uniche licenze Creative Commons che possono intendersi licenze aperte ai sensi delle Linee guida AgID sono: Creative Commons Zero - dominio pubblico (codice SPDX: CC0-1.0). Creative Commons Attribution (versione 4 e successive) - una licenza non copyleft (codice SPDX: CC-BY-4.0) Creative Commons Attribution-Share Alike (versione 4 e successive) - una licenza copyleft (codice SPDX: CC-BY-SA-4.0)

Occorre anche tenere in considerazione l’outsourcing del software a terzi, ovvero la possibilità che un terzo incorpori l’open source nel risultato.

Rispetto alle licenze, si invita ad analizzarle con le seguenti specificazioni al fine di procedere alla corretta attribuzione della licenza finale di rilascio:

Fonte: il riferimento è al sito/i ufficiale/i di reperimento delle licenze
Indicazioni sulla licenza: si indicano gli standard e le categorizzazioni della licenza
Analisi della licenza: si esaminano le caratteristiche della licenza, estrapolandone le componenti fondamentali relative alle facoltà di utilizzazione.
Ove indicata “Applicazione della licenza a prodotti nuovi”: questa specifica - talvolta presente nella fonte- va tenuta in considerazione.

Licenza applicabile alla documentazione e allegati del software

Tutti gli allegati al puro codice sorgente del software quali commenti nel codice sorgente, documentazione, esempi, schermate dimostrative, video, ecc. si considerano inclusi sotto la stessa licenza del software stesso. In generale, non è quindi necessario determinare licenze diverse per questi contenuti, se rilasciate contestualmente al software e parte integrante di esso.

Nel caso di rilascio di documentazione a sé stante rispetto al software, o nel caso questa sia particolarmente corposa (oltre una decina di pagine stampate), si consiglia di attribuire comunque una licenza all’opera. Si rimanda al Focus box «Considerazioni sulla licenza da adottare» per una guida nella scelta della licenza migliore.

Focus box

Si ponga attenzione al profilo delle versioni, perché la licenza può essere modificata quando viene rilasciata una nuova versione. È, quindi, importante verificare ogni volta la versione di riferimento, perché ogni modifica potrebbe comportare obblighi molto più estesi

Si raccomanda di rilasciare il software con l’ultima versione della licenza, salvo i componenti distribuiti con licenze “-only”.

Focus box

Compatibilità tra le licenze

La compatibilità delle licenze dipende dalla cessione dei diritti intellettuali da parte dell’autore. Le licenze che in questo senso cedono meno diritti, al fine di preservare maggiormente nel tempo la libertà e riutilizzabilità del software creato, sono le licenze copyleft.

Quando si parla di compatibilità occorre distinguere due casi:

1.La creazione di una nuova opera a partire da componenti già esistenti, con licenza unica
2.L’assemblaggio e la distribuzione di più componenti interagenti, ognuna con licenza differente.
3.Per quanto riguarda il caso di creazione di una nuova opera sotto una licenza unica (1), la matrice di compatibilità è la seguente:

Opere rilasciate sotto dominio pubblico sono rilasciabili con qualunque altra licenza
Opere rilasciate sotto licenze non-copyleft sono rilasciabili con licenze copyleft
Opere rilasciate sotto licenze copyleft possono essere solo rilasciate con licenze copyleft, a condizione che le due licenze siano compatibili

Nel secondo caso (2) invece:

Opere rilasciate sotto licenza di pubblico dominio, non-copyleft o copyleft debole possono interagire come componenti a sé stanti con qualunque altro applicativo, pur rispettando le eventuali clausole riguardo riferimenti al codice originale e la distribuzione di eventuali modifiche.
Opere rilasciate sotto licenza copyleft possono interagire come componenti a sé stanti solo con altri componenti rilasciati con licenza copyleft compatibile

Effettua il giudizio di Compatibilità delle licenze

Per fare il test di compatibilità ti consigliamo di usare i seguenti strumenti messi a disposizione dalla CE:

Il primo riguarda sia dati che software

https://interoperable-europe.ec.europa.eu/collection/eupl/solution/licensing-assistant/compatibility-checker

Il secondo solo software

https://interoperable-europe.ec.europa.eu/collection/eupl/solution/licensing-assistant/find-and-compare-software-licenses

Focus box

Considerazioni sulla licenza da adottare

Alla luce dell’analisi normativa e delle indicazioni fornite dalle Linee guida AgID, emerge come le pubbliche amministrazioni, nel caso di sviluppo ex novo di una soluzione software, siano tenute a rilasciare il prodotto sotto licenza aperta, garantendo il riuso da parte di altre amministrazioni e l’acquisizione in capo alla PA della piena titolarità di tutti i diritti relativi al software sviluppato. Le Linee guida richiamano infatti l’obbligo, previsto dall’art. 69 del Codice dell’Amministrazione Digitale, di rendere disponibile il codice sorgente completo della documentazione, pubblicandolo su piattaforme individuate da AgID e rendendolo riutilizzabile gratuitamente da altre PA, salvo motivate eccezioni legate alla sicurezza, alla difesa o alle consultazioni elettorali.

Dall’analisi delle diverse tipologie di licenze aperte illustrate si evidenzia come la scelta della licenza debba essere orientata agli obiettivi di riuso, interoperabilità e sostenibilità del software nel tempo. Date le citate premesse:

Le licenze di dominio pubblico (come CC0-1.0, idonea anche per il software, a differenza delle altre licenze Creative Commons) favoriscono la massima libertà di utilizzo e riutilizzo, garantendo flessibilità totale e riducendo le complicazioni derivanti dalla gestione di licenze differenti. Ciò le rende particolarmente adatte in tutti quei casi in cui lo scopo primario è favorire la più ampia diffusione del software e la sua integrazione in soluzioni eterogenee, senza imporre vincoli o condizioni aggiuntive sui derivati.
Le licenze copyleft – in particolare la GNU GPL o la GNU AGPL – risultano idonee quando l’interesse dell’amministrazione è quello di preservare la libertà del software e garantire che ogni modifica o miglioramento realizzato da terzi venga reso disponibile in forma aperta, evitando che il codice possa essere integrato in prodotti proprietari senza obbligo di condivisione delle modifiche. Le Linee guida evidenziano infatti come tali licenze siano consigliate per il rilascio di applicativi software completi destinati a una distribuzione ampia o potenzialmente soggetti a evoluzioni significative da parte della comunità o di altre amministrazioni

Schema n. 2_ PdRS — Software

PIANO DI RICOGNIZIONE DEI SOFTWARE

PdRS — Gemello Digitale Urbano

[NOME PROGETTO / COMUNE]

Titolo	Piano di Ricognizione dei Software (PdRS)
Progetto GDU	[Nome del progetto]
Ente committente / Comune	[Nome del Comune / PA]
Sviluppatore GDU	[Nome soggetto sviluppatore]
Data Steward	[Nome, ruolo, contatto]
Versione	1.0
Data di emissione	[GG/MM/AAAA]
Stato	Bozza / In revisione / Approvato

6.4 Scopo del documento

Il presente Piano di Ricognizione dei Software (PdRS) è redatto per documentare, qualificare e pianificare la consegna dei componenti software sviluppati o utilizzati nell'ambito del progetto di Gemello Digitale Urbano (GDU). Il documento persegue due finalità distinte:

Ricognizione dei software utilizzati per la realizzazione del progetto (Tabelle a).
Ricognizione dei software da considerare prodotti del progetto e oggetto di consegna al Comune (Tabelle b).

* Tipologia/specifiche della licenza. ** Es.: database, input utente, file .csv/.txt; specificare se formato aperto o proprietario.

6.5 Software e applicativi utilizzati nel progetto GDU

6.5.1 Tabella a1 — Prodotti software open source

Nome	Versione	Data rilascio	Ling. / Modalità	Produttore	Licenza *	Input **	Output **

6.5.2 Tabella a2 — Prodotti software non open source

Nome	Versione	Data rilascio	Ling. / Modalità	Produttore	Licenza *	Input **	Output **

6.6 Schede componenti software (prodotti del progetto)

Ripetere la scheda seguente per ogni software considerato prodotto del progetto. Indicare le librerie, i linguaggi e i programmi integrati con le rispettive licenze.

6.6.1 Scheda componenti — Software X

Componente	Presente?	Dettaglio (se sì: quali, con quale licenza)
Librerie	☐ Sì ☐ No
Linguaggi utilizzati	☐ Sì ☐ No
Programmi integrati	☐ Sì ☐ No
Licenza scelta per il rilascio	—

6.6.2 Scheda componenti — Software Y

Componente	Presente?	Dettaglio (se sì: quali, con quale licenza)
Librerie	☐ Sì ☐ No
Linguaggi utilizzati	☐ Sì ☐ No
Programmi integrati	☐ Sì ☐ No
Licenza scelta per il rilascio	—

6.7 Software prodotti del progetto (da consegnare al Comune)

6.7.1 Tabella b1 — Prodotti software open source

Nome	Versione	Data rilascio	Ling. / Modalità	Produttore	Licenza *	Input **	Output **

6.7.2 Tabella b2 — Prodotti software non open source

Nome	Versione	Data rilascio	Ling. / Modalità	Produttore	Licenza *	Input **	Output **

6.8 Piano di consegna

ID	Scheda componenti compilata?	Consegnato?
Sof001	☐ Sì ☐ No	☐ Sì ☐ No
Sof002	☐ Sì ☐ No	☐ Sì ☐ No
Sof003	☐ Sì ☐ No	☐ Sì ☐ No
Sof004	☐ Sì ☐ No	☐ Sì ☐ No
Sof005	☐ Sì ☐ No	☐ Sì ☐ No

6.9 Elementi da consegnare al Comune

Tutti i software prodotti del progetto (Tabelle b), nella versione finale approvata.
Codice sorgente (ove applicabile), con documentazione tecnica.
Elenco completo delle licenze di tutti i componenti di terzi integrati nel GDU, con indicazione delle condizioni di subentro del Comune.
Istruzioni di installazione, configurazione e manutenzione.

6.10 Checklist operativa — Fine progetto

Da completare prima della chiusura del progetto:

☐ Tutte le Schede di Ricognizione dei Software completate (Tabelle a e b)

☐ Schede componenti compilate per ogni software prodotto del progetto

☐ Licenza finale di rilascio scelta e documentata per ogni software

☐ Elenco licenze componenti di terzi verificato e consegnato

☐ Piano di consegna aggiornato e controfirmato

☐ Piano di manutenzione GDU post-progetto concordato con il Comune

☐ Eventuali restrizioni di accesso o embargo documentate

6.11 Registro versioni e approvazione

Versione	Data	Autore	Modifiche	Approvato da
0.1	[Da compilare]	[Da compilare]	Prima bozza	—
1.0	[Da compilare]	[Da compilare]	Versione definitiva	[Da compilare]

6.12 Firme

Ruolo	Nome e Cognome	Organizzazione	Data
Responsabile GDU	[Da compilare]	[Da compilare]	[Da compilare]
Referente del Comune / PA	[Da compilare]	[Da compilare]	[Da compilare]
Resp. scientifico (se ente ricerca)	[Da compilare]	[Da compilare]	[Da compilare]

Il presente documento è soggetto a revisione periodica. La versione aggiornata sostituisce integralmente le versioni precedenti.