Risultati
132 risultati
-
italia
1.5. Titolarità
Ai sensi dell’articolo 69 del CAD in materia di riuso, un’amministrazione deve considerarsi titolare di un software realizzato su proprie specifiche indicazioni ogni qualvolta che:. il software sia stato realizzato da risorse interne all’amministrazione stessa. Ogni amministrazione deve, in sede di negoziazione di un contratto volto a commissionare lo sviluppo di un software, garantirsi, all’esito dell’esecuzione del contratto, la piena ed esclusiva titolarità di tutti i diritti sul software oggetto di sviluppo, salvo che questo risulti eccessivamente oneroso per comprovate ragioni di carattere tecnico-economico (dal comma 2 dell’articolo 69 del CAD). Per software oggetto di sviluppo, si intendono le parti di software effettivamente sviluppate in esecuzione del contratto; resta inteso che lo sviluppo potrebbe basarsi sull’utilizzo di componenti software già esistenti (es: librerie e framework open source di terzi) per le quali non è necessario acquisire titolarità ma solo licenza d’uso (che dev’essere compatibile con le finalità di riuso). La mancata acquisizione della titolarità dell’opera non può essere utilizzata per ottenere condizioni economiche più vantaggiose, poiché non costituisce comprovata ragione di carattere tecnico-economico ai sensi dell’articolo 69 comma 2 del CAD. Un’amministrazione, ai sensi dell’articolo 69, deve egualmente acquisire la totalità dei diritti di proprietà intellettuale e industriale su eventuali personalizzazioni o moduli software destinati a integrarsi o interfacciarsi con un software proprietario. In tal caso, l’obbligo di cui all’art. 69 avrà ad oggetto esclusivamente il modulo o la parte del software oggetto di sviluppo; tale modulo dovrà quindi essere separato dal resto del software e rilasciato secondo le modalità indicate in Sviluppo di software ex novo), avendo cura di indicare la necessaria dipendenza proprietaria nella documentazione. Ad esempio, espressioni come quelle che seguono, ove presenti nei contratti per lo sviluppo di software consentono di ritenere che l’amministrazione sia titolare dei diritti nel senso richiesto dall’articolo 69 del CAD:. «la proprietà della soluzione informatica oggetto del contratto farà capo al committente o all’Amministrazione»;. «al termine del contratto la proprietà intellettuale sulla soluzione informatica oggetto di sviluppo competerà all’amministrazione committente»;. «tutti i diritti d’autore sul software sviluppato verranno trasferiti, a seguito del completamento dell’opera, all’amministrazione committente che ne diverrà titolare»;. «tutti i diritti di sfruttamento economico sul software oggetto del contratto competono all’amministrazione committente» ...
-
italia
1.7. Glossario
Sottoprodotto realizzato durante lo sviluppo del software che aiuta a descrivere funzioni, architettura, progettazione e messa in esercizio; a solo titolo di esempio: requisiti funzionali, descrizione delle basi dati e dei processi, il set di test. Code Hosting (strumento di). Una piattaforma che consente la pubblicazione di codice sorgente, organizzato in più repository. Gli strumenti di code hosting offrono spesso anche funzionalità legate all’evoluzione di un software quali sistemi di ticketing, processi per la contribuzione di codice da parte di terzi, area per il download dei rilasci, ecc. Nell’ambito delle presenti Linee Guida, gli strumenti scelti dalle amministrazioni devono avere dei requisiti minimi in termini di funzionalità (Scelta di uno strumento di code hosting). Codice sorgente. Il codice sorgente (spesso detto semplicemente «sorgente») è il testo di un programma scritto in un linguaggio di programmazione (es. C o Visual Basic) dal quale si deriva il programma finale che l’utente usa. L’accesso al codice sorgente è essenziale per poter modificare un programma. Community. Aggregazione di persone, fisiche e giuridiche, e risorse (ad esempio forum, chat e tecnologie per riunirsi e interagire in una località virtuale), dotata di regole e di una struttura, finalizzata alla realizzazione e/o gestione di un progetto comune. Formato aperto (di dato). È un formato di dato pubblico, versionato, documentato esaustivamente e senza vincoli all’implementazione. Un formato aperto è un formato riconosciuto da un ente di standardizzazione e mantenuto in modo condiviso tra più enti che forniscono implementazioni concorrenti, con un processo trasparente. Il formato deve rimanere consistente con la versione dichiarata. Formato di dato. Modalità di rappresentazione del dato. Interoperabilità. In ambito informatico, la capacità di sistemi differenti e autonomi di cooperare e di scambiare informazioni in maniera automatica, sulla base di regole condivise. Licenza. In ambito informatico, il testo legale con il quale si concedono determinati diritti sul software e sui dati distribuiti, che altrimenti sarebbero riservati da diritti di privativa. Lock-in. Fenomeno di natura tecnica ed economica in cui un generico utente non riesce a svincolarsi da una scelta tecnologica precedentemente effettuata. Tale incapacità è tipicamente causata degli elevati costi legati al cambio di tecnologia ma, in molti casi, può anche dipendere dall’adozione di soluzioni proprietarie che impediscono di effettuare migrazioni. L’utilizzo di formati aperti per il salvataggio dei dati, e l’accesso libero a questi dati (soprattutto nel caso di soluzioni SaaS) sono prerequisiti per evitare fenomeni di lock-in. Open Source. È una modalità con cui il software può essere concesso in licenza. Si realizza attraverso la concessione al pubblico, dei diritti di uso, copia, modifica, distribuzione di copie anche modificate, del software; per fare ciò, è necessario anche che il codice sorgente sia liberamente disponibile. Altrimenti detto «software libero», «software aperto» o «software rilasciato sotto licenza aperta». L’ente certificatore delle licenze software corrispondenti a questa definizione è Open Source Initiative (OSI). Repertorio o Repository. All’interno di uno strumento di code-hosting, un repository è l’unità minima di contenimento del codice sorgente di un software. Il termine «repertorio» è la sua traduzione italiana (usata per esempio nel CAD Art 69, comma 1). Riuso. Nel contesto di queste Linee Guida, si intende il processo delineato dal CAD (art. 69) con il quale una amministrazione distribuisce («mettere a riuso») un software di cui ha titolarità in Open Source, a favore di altre amministrazioni che possano utilizzarlo («prendere a riuso»). Tutto il software a riuso è Open Source, ma non tutto il software Open Source è a riuso (poiché non tutto il software Open Source è di titolarità di una amministrazione). SaaS. software as a Service. Indica una modalità di distribuzione del software che non viene installato sulle postazioni degli operatori, ma che avviene attraverso l’accesso remoto a un server, per esempio collegandosi con un browser ad un indirizzo. Wikipedia, per esempio, è un software distribuito in modalità software as a Service. Software proprietario. software che ha restrizioni sul suo utilizzo, sulla sua modifica, riproduzione o ridistribuzione, imposti dal titolare dei diritti di sfruttamento economico, cioè l’autore o - in caso di cessione dei diritti patrimoniali - il cessionario dei diritti in questione. TCO. Total Cost of Ownership: Approccio utilizzato per valutare tutti i costi del ciclo di vita di una risorsa IT calcolato su una finestra temporale adeguata al contesto della valutazione e che include il costo di migrazione verso altra soluzione (eg., acquisto, installazione, gestione, manutenzione e smantellamento). L’approccio TCO è basato sulla considerazione che il costo totale di utilizzo di risorsa IT non dipende solo dai costi di acquisto, ma anche da tutti i costi che intervengono durante l’intera vita di esercizio della risorsa stessa ...
-
italia
1.3. Riuso del software
Si intende come «riuso» di un software il complesso di attività svolte per poterlo utilizzare in un contesto diverso da quello per il quale è stato originariamente realizzato, al fine di soddisfare esigenze similari a quelle che portarono al suo primo sviluppo. Il prodotto originario viene «trasportato» nel nuovo contesto arricchendolo, se necessario, di ulteriori funzionalità e caratteristiche tecniche che possono rappresentare un «valore aggiunto» per i suoi utilizzatori. Dal combinato disposto degli articoli 68 e 69 del CAD, il software in riuso è esclusivamente quello rilasciato sotto licenza aperta da una pubblica amministrazione. Questo è dunque un sottoinsieme di tutto il software open source disponibile per l’acquisizione. Le presenti linee guida distinguono, ove necessario, le modalità di acquisizione di software di pubbliche amministrazioni assoggettato a licenza aperta rispetto a software open source di terzi. Un aspetto fondamentale del riuso nel contesto della Pubblica Amministrazione è che l’Amministrazione che «riusa» riceve il software gratuitamente dall’Amministrazione cedente, e lo acquisisce sostenendo solo le spese di suo adattamento, ma non quelle di progettazione e realizzazione ...
-
italia
1.6. Conformità del software alla normativa
Il riuso del software è un canale di amplificazione di ogni scelta in ambito informatico ed è completamente neutro rispetto alla bontà o erroneità di tali scelte. Esso può agire da moltiplicatore dell’impatto delle buone prassi o, allo stesso modo, da moltiplicatore di scelte erronee la cui diffusione non è auspicabile. Nel promuovere il riuso e la diffusione del software sul quale insistono diritti di proprietà intellettuale di un’amministrazione, con un importante vantaggio economico e in termini di efficienza, è importante richiamare l’attenzione delle singole Amministrazioni sull’importanza che il software posto in riuso - come d’altra parte l’intero parco software in uso a ogni amministrazione - sia conforme alla disciplina vigente. Poiché il processo di acquisizione di un software in riuso spesso comprende personalizzazioni e aggregazioni di diverse componenti, alcune delle quali potrebbero non essere più in uso o rilasciate anche anni prima, è importante ricordare che la verifica della piena conformità ai contesti normativi rimane in capo all’amministrazione che prenda in riuso un software, poiché solo ad essa compete la responsabilità delle decisioni assunte nell’ambito dei margini di discrezionalità assegnati e nel rispetto dei principi costituzionali di buon andamento ...
-
italia
1.4. Soggetti destinatari
I soggetti destinatari delle presenti linee guida sono le pubbliche amministrazioni di cui all’articolo 1, comma 2, del decreto legislativo 30 marzo 2001, n. 165, nel rispetto del riparto di competenza di cui all’articolo 117 della Costituzione, ivi comprese le autorità di sistema portuale, nonché le autorità amministrative indipendenti di garanzia, vigilanza e regolazione, ossia «gli istituti e scuole di ogni ordine e grado e le istituzioni educative, le aziende ed amministrazioni dello Stato ad ordinamento autonomo, le Regioni, le Province, i Comuni, le Comunità montane. e loro consorzi e associazioni, le istituzioni universitarie, gli Istituti autonomi case popolari, le Camere di commercio, industria, artigianato e agricoltura e loro associazioni, tutti gli enti pubblici non economici nazionali, regionali e locali, le amministrazioni, le aziende e gli enti del Servizio sanitario nazionale, l’Agenzia per la rappresentanza negoziale delle pubbliche amministrazioni (ARAN) e le Agenzie di cui al decreto legislativo 30 luglio 1999, n. 300 e al CONI (per quest’ultima amministrazione fino alla revisione organica della disciplina di settore)». Non si applicano le disposizioni sul riuso delle soluzioni ove sussistano «motivate ragioni di ordine e sicurezza pubblica, difesa e sicurezza nazionale e consultazioni elettorali». Con riferimento all’ambito di applicazione delle presenti Linee guida, si auspica l’utilizzo da parte delle PP.AA. degli strumenti di cooperazione e collaborazione offerti dalla normativa vigente, quali gli accordi di collaborazione previsti dall’art. 15 L. 241/1990, al fine di realizzare esperienze di co-progettazione, ampliando la condivisione della conoscenza, di processi decisionali e di percorsi comuni, quali ad esempio centri di competenza e di supporto al ciclo di vita del software ...
-
italia
1.2. Software oggetto di queste linee guida
Al fine di fugare eventuali dubbi interpretativi, nel contesto degli articoli 68 e 69 del CAD le espressioni «programmi», «soluzioni», «programmi informatici» e «soluzioni ICT» sono da intendersi come equivalenti. L’oggetto dell’obbligo sancito dalla disposizione in commento è il «software». Un elenco non esaustivo quindi di software oggetto di queste linee guida è il seguente:. Applicazioni desktop. Applicazioni mobile. Componenti e applicazioni semilavorate. Framework. Librerie. Plugin. Sistemi operativi. Siti web (frontend e backend). È auspicabile che le presenti linee guida favoriscano la razionalizzazione delle soluzioni utilizzate nei settori/servizi comuni alle pubbliche amministrazioni, quali, ad esempio, gestione del personale, gestione e conservazione documentale, gestione dei processi decisionali, comunicazione istituzionale e trasparenza amministrativa. Inoltre, è importante notare che il termine «software», come usato in questo documento, non designa solo il mero codice sorgente e/o l’eseguibile, ma anche tutti gli artefatti prodotti durante il processo di sviluppo e utilizzo del software, cioè documentazione, asset grafici, manuali, ecc., così come esplicitato nel comma 1 dell’articolo 69 ...
-
italia
1.1. Finalità e struttura del documento
Le presenti linee guida sono adottate in attuazione dagli articoli 68 e 69 del Codice dell’Amministrazione Digitale (di seguito CAD):. come statuito dall’articolo 69, comma 2bis, individuano nel capitolo Linee Guida sul riuso del software (art. 69) la piattaforma per la pubblicazione di codice sorgente sotto licenza aperta e documentazione del software messo a riuso dalle amministrazioni, indicando anche le modalità tecniche di utilizzo. Inoltre sostituiscono la precedente circolare 63/2013, intitolata «Linee guida per la valutazione comparativa prevista dall’art. 68 del D.Lgs. 7 marzo 2005, n. 82 Codice dell’Amministrazione digitale» e relativi allegati. Questo documento e la metodologia in esso descritta sono da intendersi come ausilio a un percorso decisionale che rimane sotto la piena responsabilità delle amministrazioni, sia nel momento in cui condividano le soluzioni sia quando le adottino in riuso nel rispetto della normativa vigente, in particolare in materia di pubblica amministrazione digitale, contratti pubblici e protezione dei dati personali. Con riferimento a quest’ultimo settore del diritto, il Regolamento UE 2016/679 ha definito/precisato principi e criteri particolarmente rilevanti rispetto all’oggetto delle presenti linee guida. Tra detti principi e criteri, si evidenzia l’esigenza di considerare la protezione dei dati fin dalla progettazione e per impostazione predefinita (art. 25 Regolamento citato). Non andrà trascurato, altresì, il complesso delle regole tecniche di AgID che possono avere incidenza sulla materia, quali le Misure Minime di Sicurezza (circolare 2/2017) e le Linee guida per lo sviluppo del *software* sicuro. Il presente documento si pone come punto di avvio di un processo culturale che veda le PP.AA. protagoniste di un sempre maggiore ricorso al software aperto, come si ricava dalla lettura del primo comma dell’art. 69, che impone alle pubbliche amministrazioni «che siano titolari di soluzioni e programmi informatici realizzati su specifiche indicazioni del committente pubblico» di «rendere disponibile il relativo codice sorgente, completo della documentazione e rilasciato in repertorio pubblico sotto licenza aperta…». Da tale norma si è preso, pertanto, l’avvio per la predisposizione delle presenti Linee guida, avendo individuato nella norma appena richiamata il forte impulso del legislatore all’utilizzo sempre maggiore del software di tipo aperto da parte delle pubbliche amministrazioni. Ne sono prova la contestuale eliminazione della previsione del c.d. «catalogo del riuso», senza che ciò impedisca, eventualmente, alle PPAA di sottoscrivere accordi (ad es., in base all’art. 15 della Legge 241/90), per il riutilizzo di soluzioni che non siano conformi al dettato dell’art. 69 co. 1 e che non possano rientrare nelle fattispecie qui trattate, che, si ribadisce, devono essere quelle sottoposte a licenza aperta. In ogni caso, il legislatore, adottando tale ottica di forte propensione all’open source per le PPAA, ha ragionevolmente previsto una esclusione generale per le sole «motivate ragioni di ordine e sicurezza pubblica, difesa nazionale e consultazioni elettorali» - all’art. 69 co. 1 ultimo inciso - , al fine di salvaguardare quei settori più delicati del governo digitale del Paese, che dalla condivisione e gestione comunitaria del SW di tipo aperto potrebbero sentirsi esposti a qualche rischio. L’approccio sopra descritto, di favore per l’open source, si desume con chiara evidenza anche dal dettato del comma 2 dell’art. 69, che impone alle amministrazioni pubbliche «nei capitolati o nelle specifiche di progetto» di essere «sempre titolar[i] di tutti i diritti sui programmi e i servizi delle tecnologie dell’informazione e della comunicazione, appositamente sviluppati per ess[e]». Anche in questo caso è prevista una salvaguardia, per le sole ipotesi in cui «ciò risulti eccessivamente oneroso per comprovate ragioni di carattere tecnico-economico». Di conseguenza, l’art. 68 viene letto e vi viene data attuazione nel presente documento, in piena coerenza con la predetta lettura dell’art. 69. L’amministrazione pubblica è il soggetto che meglio conosce le proprie esigenze ed è in grado di declinare la metodologia qui proposta, in coerenza sia con il proprio contesto, sia con le caratteristiche dell’acquisizione da effettuare. In tal senso, le Linee guida si pongono non come mero strumento regolatorio, bensì come suggerimento per nuovi processi di accompagnamento, sensibilizzazione ed informazione ...
-
italia
3.2. Modello di riuso
Si descrive nel dettaglio il modello di riuso delineato dal CAD. Ciascun punto del seguente flusso viene specificato in una sezione successiva del presente documento. Fase di sviluppo. L’amministrazione «A» utilizza proprie risorse e/o ricorre ad un appalto per realizzare il software. In caso di appalto, come richiesto dall’art. 69 comma 2, l’amministrazione si garantisce l’acquisizione della titolarità di tutti i diritti di proprietà intellettuale e industriale sul software commissionato (Titolarità). Durante il corso della realizzazione del software e/o al termine della stessa, l’amministrazione pubblica il codice sorgente del proprio software sotto una licenza aperta, in una piattaforma che rispetta i requisiti identificati in queste linee guida (Scelta di uno strumento di code hosting), registrandone poi il rilascio dentro Developers Italia (Sviluppo di software ex novo). Fase di riuso. La licenza aperta consente all’amministrazione «B» di acquisire ed utilizzare il software dell’amministrazione «A» senza necessità di sottoscrivere alcuna convenzione, sottostando ai termini della licenza stessa. L’amministrazione «B» effettua una valutazione dello stato del software e dell’applicabilità al proprio contesto (Fase 2.2: Valutazione soluzioni riusabili per la PA), inclusa l’eventuale necessità di una personalizzazione. Se il software viene personalizzato, ove possibile, tale personalizzazione (in quanto sviluppo su specifica indicazione dell’amministrazione «B») è anch’essa soggetta a quanto prescritto dall’art. 69 comma 1, ed è quindi necessario rilasciare il relativo codice sorgente sotto licenza aperta ( Riuso di un software o utilizzo di un software Open Source). Il modello del riuso tramite software Open Source consente quindi di trovare un software, valutarlo e personalizzarlo senza stipulare alcuna convenzione con l’amministrazione che ha messo a riuso il software stesso, oltre all’accettazione della licenza Open Source che si perfeziona con il semplice download. Inoltre, il software è disponibile online e non è quindi necessaria alcuna richiesta di accesso. È importante però considerare che il software potrebbe non essere «pronto all’uso». L’amministrazione potrebbe quindi avere necessità di un intervento tecnico per installare il software, adattarlo alle proprie esigenze, formare il personale che dovrà usarlo, avere a disposizione supporto e manutenzione. Per tutti questi interventi, l’amministrazione può usare proprie risorse o forniture, poiché nessun vincolo da questo punto di vista è imposto all’amministrazione che ha realizzato il software e lo ha messo a riuso ...
-
italia
3.9. Riuso di un software o utilizzo di un software Open Source
Dal punto di vista normativo, le modifiche o personalizzazioni ad un software sotto licenza aperta sono soggette all’art. 69 comma 2 e devono essere quindi effettuate acquistando piena titolarità del codice sviluppato. Il riuso di software senza apporto di modifiche, invece, non configura l’obbligo di rilascio. Sotto il profilo di acquisizione della titolarità, il fatto che il software oggetto di modifica non sia di proprietà dell’amministrazione che effettua la modifica non esime quest’ultima dall’obbligo di acquisire la titolarità delle modifiche sviluppate. Si rimanda quindi a Titolarità. Viceversa, a livello tecnico, il processo per effettuare le modifiche è diverso dal processo di manutenzione descritto in Manutenzione di un software da parte dell’amministrazione titolare poiché gli interventi avverranno su un software del quale non si ha la piena titolarità e dunque è auspicabile un coordinamento tecnico, già descritto a livello di opportunità e benefici in Supporto alle amministrazioni che riusano. Il processo tecnico è dettagliato in Allegato D: Guida alla presa in riuso di software open source. In caso di appalto, si richiede che l’amministrazione alleghi la Guida tra i documenti tecnici di gara, per esempio come allegato al capitolato tecnico, in modo che i fornitori abbiano evidenza immediata del processo richiesto ...
-
italia
3.7. Sviluppo di software ex novo
Come già discusso in Titolarità, l’amministrazione deve assicurarsi la piena titolarità del software realizzato ex novo. Si rimanda al citato paragrafo per ulteriori informazioni ...
-
italia
3.1. Introduzione e contesto normativo
Il comma 1 dell’art. 69 definisce l’obbligo, per le pubbliche amministrazioni titolari di software realizzato su specifiche indicazioni del committente pubblico, «di rendere disponibile il relativo codice sorgente, completo della documentazione e rilasciato in repertorio pubblico sotto licenza aperta, in uso gratuito ad altre pubbliche amministrazioni o ai soggetti giuridici che intendano adattarli alle proprie esigenze». La nuova formulazione dell’art. 69, ai commi 2 e 2 bis, riportati di seguito, sottolinea lo scopo di favorire il riuso disponendo «che l’amministrazione committente sia sempre titolare di tutti i diritti sui programmi e i servizi delle tecnologie dell’informazione e della comunicazione appositamente sviluppati per essa», «salvo che ciò risulti eccessivamente oneroso per comprovate ragioni di carattere tecnico-economico» e che «il codice sorgente, la documentazione e la relativa descrizione tecnico funzionale di tutte le soluzioni informatiche… sono pubblicati attraverso una o più piattaforme individuate dall’AgID con proprie linee guida da adottarsi ai sensi dell’articolo 71» ...
-
italia
3.5. Licenze aperte e scelta di una licenza
Una licenza di software libero consente l’utilizzo gratuito del codice sorgente cui si riferisce, dettando però alcuni vincoli da rispettare. Pertanto, l’integrazione di più componenti di software libero rilasciati sotto licenze diverse richiede una analisi di compatibilità delle stesse. Tale analisi può risultare eccessivamente complessa se le licenze coinvolte sono molteplici, comportando costi aggiuntivi. In altre parole, una proliferazione di licenze diverse rende più difficile e oneroso il riuso del software, contravvenendo agli obiettivi delineati dall’art. 69 del CAD. Si propone quindi il seguente albero decisionale per la scelta di una licenza aperta:. Se il rilascio del software si riferisce ad una modifica di software Open Source esistente (quindi software preso a riuso da un’altra amministrazione o di proprietà di terze parti), l’amministrazione utilizzerà la stessa licenza con la quale è stato originariamente distribuito il software, per favorire la massima interoperabilità e riuso con altri utilizzatori del medesimo software;. Se si tratta di un software nuovo, tranne per le eccezioni specificate sotto, utilizzare la licenza EUPL v1.2 (codice SPDX: EUPL-1.2): https://spdx.org/licenses/EUPL-1.2.html. Questa licenza, scritta dalla Commissione europea, è stata scelta in quanto di tipo «copyleft», garantisce massima interoperabilità a livello europeo, ed è anche tradotta in italiano. Sono previste solo alcune eccezioni a questa indicazione generale:. se il software viene utilizzato principalmente via rete (es: tramite un browser), utilizzare la licenza «GNU Affero General Public License» versione 3 e successive (codice SPDX: AGPL-3.0-or-later): https://spdx.org/licenses/AGPL-3.0-or-later.html;. Questa licenza è stata scelta perché, oltre ad essere compatibile con la maggior parte delle licenze Open Source, obbliga chi modifica il codice a rilasciare i miglioramenti anche in caso esso venga utilizzato come parte di un servizio SaaS. se vengono rilasciati componenti software enucleati e con ampio campo applicativo (per esempio, le «librerie software» e gli «SDK»), utilizzare la licenza «BSD 3-Clause» (codice SPDX: BSD-3-Clause) https://spdx.org/licenses/BSD-3-Clause.html;. Questa licenza è stata scelta per garantire un utilizzo da parte di tutti gli attori quanto più libero possibile, permettendo di realizzare applicativi basati su queste librerie, rilasciabili sotto qualunque licenza. Questo genere di componenti software è utilizzato normalmente per favorire l’interoperabilità con le Pubbliche Amministrazioni, e trovano beneficio nella nascita di ecosistemi che includono applicativi di terze parti, inclusi software proprietari. Per la documentazione tecnica del software, utilizzare la licenza Creative Commons CC-BY 4.0 (codice SPDX: CC-BY-4.0) https://spdx.org/licenses/CC-BY-4.0.html. Questa licenza è stata scelta in quanto permette un riutilizzo semplice della documentazione e degli esempi di codice in essa contenuta. Si rimanda a Allegato A: Guida alla pubblicazione di software come open source per i dettagli tecnici su come apporre correttamente il testo di una licenza al codice sorgente nel momento della pubblicazione. Le licenze scelte hanno un vasto utilizzo nell’ecosistema Open Source, dunque si massimizza la possibilità di poter integrare componenti di terze parti rilasciate con licenze compatibili. L’amministrazione che volesse operare una scelta di licenza diversa da quella qui delineata deve motivarne le ragioni, analizzando la compatibilità tra le licenze adottate e quelle qui proposte, escludendo che la scelta limiti le opportunità di riuso ed assicurandosi che non comporti oneri aggiuntivi per le amministrazioni in fase di riuso. [1]. Stallman, The Free software Definition - https://www.gnu.org/philosophy/free-sw.it.html. [2]. https://www.opensource.org/. [3]. https://spdx.org ...