Source: https://docs.italia.it/ricerca/tag/riuso/
Timestamp: 2020-04-04 22:03:36+00:00

Document:
Stabile (40)
Developers Italia (40)
riuso (0)
Non appena il repository pubblico è stato aperto, è necessario (MUST) effettuare la registrazione su Developers Italia, per garantire che venga indicizzato e presentato nel motore di ricerca presente sul sito. La registrazione avviene seguendo due passaggi:. Pubblicazione di un file publiccode.yml nella directory root del repository. «publiccode.yml» è uno standard che identifica il progetto come «software utile per la Pubblica Amministrazione», e contemporaneamente offre una serie di informazioni utili alla valutazione del software stesso per il riuso. Tale file verrà rilevato automaticamente dall’indicizzatore (crawler) di Developers Italia al fine della generazione della relativa scheda nel catalogo. La documentazione sul formato può essere trovata qui: https://github.com/italia/publiccode.yml. Aggiunta dello strumento di code-hosting al motore di ricerca. Al fine di accertarsi che Developers Italia identifichi correttamente il repository come di proprietà della pubblica amministrazione, è necessario registrare lo strumento di code-hosting (o meglio, la «organizzazione» all’interno dello stesso) la prima volta che viene usato, associandolo alla Pubblica Amministrazione. La procedura è da seguire è dettagliata qui: https://onboarding.developers.italia.it ...
Le disposizioni successive si applicano ove l’Amministrazione sia titolare di un repository. Aggiornamento delle dipendenze. Per tutta la durata dell’incarico di manutenzione, l’Incaricato è tenuto a monitorare i rilasci delle eventuali dipendenze incorporate nel software e a recepire eventuali aggiornamenti (MUST). Se il software è derivato da altro software, tale obbligo di monitoraggio e recepimento si applica anche al software originale (c.d. upstream). Eventuali incompatibilità o problemi di sicurezza insorti nel tempo dovranno essere documentati tempestivamente attraverso l’apertura di issue dedicate, da tenere aperte fino alla risoluzione, ed eventualmente anche nel file README. Nel caso di nuove versioni che risolvono problemi di sicurezza, l’aggiornamento delle dipendenze deve avere priorità assoluta. Descrizione del ruolo di maintainer. All’interno di un progetto open source, il maintainer è il soggetto che svolge un’attività di controllo e direzione degli sviluppi sul progetto, e a cui la community che afferisce al software (es: utilizzatori) può segnalare problematiche o discutere miglioramenti. Per tutta la durata dell’attività di manutenzione connessa al software, l’Amministrazione titolare svolgerà il ruolo di maintainer del progetto open source, affidandone l’esecuzione all’Incaricato, il quale inserirà il nome della propria azienda o ente e i riferimenti di contatto nei file README e publiccode.yml del repository, con l’eventuale data di termine dell’incarico. L’Incaricato dovrà quindi, per conto dell’Amministrazione, gestire l’attività sul progetto derivante dalle interazioni con gli utenti esterni. Interazione sul repository/issue tracker. Tutte le interazioni avviate da utenti esterni all’interno della piattaforma di code hosting, e in particolare attraverso il suo issue tracker, dovranno essere esaminate dall’Incaricato entro due giorni lavorativi (SHOULD), ed entro tale termine è necessario (MUST) fornire una risposta. La risposta può non essere esaustiva, e laddove non sia possibile rispondere approfonditamente subito è comunque opportuno dare un cortese riscontro con delle prime considerazioni. Risoluzione di bug. Le segnalazioni di bug ricevute da utenti esterni attraverso il sistema di issue tracking dovranno essere analizzate al pari di quelle ricevute dall’Amministrazione committente. Se la risoluzione fosse compatibile (in quanto a tempi e costi) con le attività previste dal contratto, potrà essere eseguita senza necessità di ulteriore approvazione. Se invece la risoluzione non fosse compatibile (in quanto a tempi e costi) con le attività di manutenzione prevista dal contratto, la issue dovrà essere mantenuta aperta, informando l’Amministrazione titolare della propria scelta. Il processo di diagnosi e risoluzione dovrà essere documentato pubblicamente all’interno dell’issue tracker, ad eccezione delle informazioni che hanno implicazioni sulla sicurezza dei sistemi in produzione, le quali dovranno essere mantenute riservate fino alla messa in funzione delle correzioni (MUST) e solo successivamente pubblicate (MUST), a beneficio di altri utenti del software. La issue di segnalazione dovrà essere mantenuta aperta fino alla risoluzione (MUST) ed è opportuno (SHOULD) chiedere all’utente originale di verificare in prima persona la bontà della risoluzione prima di chiuderla. In caso di mancata risposta dell’utente per trenta giorni, l’Incaricato può chiudere la issue, dopo aver documentato all’interno l’avvenuto collaudo della modifica. Richieste di nuove funzionalità. Le richieste di nuove funzionalità dovranno essere valutate dall’Incaricato, di concerto con l’Amministrazione, in relazione alla loro pertinenza al progetto. Se non ritenute pertinenti dovranno essere chiuse (SHOULD) fornendo una motivazione al proponente. Se ritenute pertinenti dovranno essere lasciate aperte fino all’eventuale implementazione (MUST), dando tuttavia rapido riscontro al proponente (MUST) con una valutazione sulla fattibilità tecnica della richiesta e suggerimento su eventuali altri modi per raggiungere l’obiettivo dichiarato. L’Incaricato può chiedere al proponente, se necessario, maggiori dettagli sul caso d’uso che motiva la richiesta (MAY). L’implementazione delle funzionalità richieste dovrà essere approvata dall’Amministrazione (MUST) nel caso che questo comporti degli oneri per la stessa (es: in caso il contratto sia strutturato con un modello a consumo). In alternativa, l’Incaricato può decidere in autonomia di dare seguito alla richiesta implementandola nel codice (MAY), senza causare oneri aggiuntivi all’Amministrazione e nel rispetto dei tempi del contratto (per esempio, in virtù di altri accordi commerciali sullo stesso software). Richieste di informazioni o supporto. Le richieste di informazioni sul progetto dovranno essere evase a cura dell’Incaricato entro 2 giorni lavorativi (SHOULD). Le risposte dovranno limitarsi alle caratteristiche tecniche del software e alle domande poste dagli sviluppatori o da altre Amministrazioni per finalità di comprensione del funzionamento tecnico, riuso, collaborazione o sviluppo. L’Incaricato non è tenuto a rispondere ad altri soggetti o fornire assistenza sull’utilizzo del software o dare risposte sull’uso che l’Amministrazione fa del software o in generale su altri argomenti di competenza dell’Amministrazione. Contributi di codice. I contributi di codice inviati attraverso i meccanismi di collaborazione previsti dalla piattaforma di code hosting scelta (ad es. attraverso una pull request) dovranno essere valutati dall’Incaricato (MUST) che provvederà a dare un riscontro all’utente con considerazioni sulla fattibilità dell’integrazione (MUST). L’Incaricato è tenuto ad incorporare tutti i contributi di codice (SHOULD) che non presentano incompatibilità con gli obiettivi della fornitura, fornendo al contributore adeguata spiegazione in caso di diniego ...
Al fine di agevolare la valutazione comparativa, attraverso un percorso decisionale per le PP.AA., che tenga conto delle indicazioni riportate sia nell’articolo 68 che nel 69 del CAD, si fa riferimento al quadro sinottico che segue:. Obbligo di mettere a riuso Art. 69 comma 1. Obbligo di acquisire la titolarità Art. 69 comma 2. Obbligo Valutazione economica (TCO) Art. 68 comma 1bis. Obbligo Valutazione tecnica Art. 68 comma 1ter. Assicurare l’interoperabilità tra PA Art. 68 comma 1bis. Garanzie sulla sicurezza Art. 68 comma 1bis. Conformità normativa in materia di privacy Art. 68 comma 1bis. Livelli di servizio adeguati Art. 68 comma 1bis. Software sviluppato per conto della pubblica amministrazione. Sì. Sì. Sì,. con l’esclusione dell’acquisto. Sì. Sì. Sì. Sì. Sì. Riutilizzo di software o parti di esso sviluppati per conto della pubblica amministrazione. Sì,. solo in caso di modifica. Sì. Sì,. con l’esclusione dell’acquisto. Sì. Sì. Sì. Sì. Sì. Software libero o a codice sorgente aperto. Sì,. solo in caso di modifica. No. Sì,. con l’esclusione dell’acquisto. Sì. Sì. Sì. Sì. Sì. Software fruibile in modalità cloud computing. Sì, solo per il software già di proprietà o implementato ad hoc per la PA. Sì, solo per il software già di proprietà o implementato ad hoc per la PA. Sì. Sì. Sì. Sì. Sì. Sì. Software di tipo proprietario mediante ricorso a licenza d’uso. No, ad eccezione del software creato per rendere possibile l’interoperabilità applicativa (ad esempio API). No, ad eccezione del software creato per rendere possibile l’interoperabilità applicativa (ad esempio API). Sì. Sì. Sì. Sì. Sì. Sì. Software combinazione delle precedenti soluzioni. Sì,. solo per il software già di proprietà o implementato ad hoc per la PA. Sì,. solo per il software già di proprietà o implementato ad hoc per la PA. Sì. Sì. Sì. Sì. Sì. Sì ...
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:. La creazione di una nuova opera a partire da componenti già esistenti, con licenza unica. L’assemblaggio e la distribuzione di più componenti interagenti, ognuna con licenza differente. Per quanto riguarda il caso di creazione di una nuova opera sotto una licenza unica, 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 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 originali 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 ...
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» ...
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 ...
La redazione del documento è stata curata dal gruppo di lavoro istituito con determina 237/2017, a composizione mista Agenzia per l’Italia Digitale e Team per la Trasformazione Digitale:. Viviana De Paola, AgID - Area Trasformazione Digitale. Daniela Intravaia, AgID - Coordinamento Attività Internazionali. Guido Pera, AgID - Area trasformazione Digitale. Umberto Rosini, AgID - Area architetture, standard e infrastrutture. Guido Scorza, Team per la Trasformazione Digitale ...
Queste linee guida sono in vigore dal 9 maggio 2019, come riportato in Gazzetta Ufficiale Serie Generale n. 119 del 23 maggio 2019) ...
Il modello di riuso sopra delineato è reso possibile dalla piattaforma Developers Italia di AgID. All’interno della piattaforma, viene resa disponibile una sezione dedicata al software reso disponibile per il riuso dalle amministrazioni. In particolare:. È disponibile una modalità per «registrare» in Developers Italia il software delle amministrazioni rilasciato in modalità Open Source ai fini del riuso, perché diventi facilmente individuabile da parte di altre amministrazioni ...
Il comma 1 dell’Art. 69 recita:. »Le pubbliche amministrazioni che siano titolari di soluzioni e programmi informatici realizzati su specifiche indicazioni del committente pubblico, hanno l’obbligo 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, salvo motivate ragioni di ordine e sicurezza pubblica, difesa nazionale e consultazioni elettorali.». Gli obblighi qui citati si riferiscono all’intero parco software sul quale insistono i diritti di un’amministrazione con la conseguenza che, a prescindere dall’esigenza di rispettare tali obblighi in occasione del perfezionamento di nuovi contratti, ogni amministrazione è tenuta a darvi tempestiva attuazione anche con riferimento al *software* già esistente ove sia titolare dei relativi diritti di proprietà intellettuale e industriale (come indicato in Titolarità). Dare attuazione a tali obblighi sul software già esistente costituisce un aspetto essenziale per la massimizzazione dell’efficacia della disposizione in commento e, più in generale, della buona prassi del riuso, giacché consente a altre amministrazioni di beneficiare senza ritardo delle opportunità offerte dal riuso, scongiurando il rischio che queste ultime si trovino a dover ri-acquistare soluzioni già appartenenti al patrimonio informativo pubblico e che, dunque, potrebbero essere utilizzate senza generare alcun ulteriore costo per la comunità. È quindi necessario che l’amministrazione provveda a censire il software di cui è già in possesso al fine di verificarne la titolarità, e in caso positivo proceda al rilascio sotto licenza aperta. Vista la rapida obsolescenza delle tecnologie digitali, e considerata l’importanza di favorire il riuso delle soluzioni disponibili, si ritiene escluso dall’obbligo di rilascio il software che non sia più in uso da parte dell’amministrazione da oltre 5 anni, con riferimento alla data di pubblicazione delle presenti linee guida. Le specifiche di dettaglio su come effettuare il rilascio sono contenute in Allegato A: Guida alla pubblicazione di software come open source. Laddove l’amministrazione non avesse le risorse necessarie per allineare la documentazione agli standard previsti della Guida, l’amministrazione deve procedere comunque immediatamente al rilascio di quanto abbia in possesso nello stato in cui si trova, fermo restando che la presenza di documentazione è requisito essenziale previsto dalla norma e sarà quindi necessario procedere al completamento e allineamento della documentazione al più presto per considerare l’adempimento concluso ...
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 ...
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 ...

References: Art. 69
 Art. 69
 Art. 68
 Art. 68
 Art. 68
 Art. 68
 Art. 68
 Art. 68