Risultati
176 risultati
-
italia
Allegato C: Guida alle licenze Open Source
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 ...
-
italia
Allegato E: Tabella Sinottica degli elementi necessari al percorso decisionale
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ì ...
-
italia
Allegato B: Guida alla manutenzione di software open source
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 ...
-
italia
Allegato A: Guida alla pubblicazione di software come open source
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 ...
-
italia
Allegato D: Guida alla presa in riuso di software open source
Nel caso in cui il maintainer di un software open source la cui titolarità non sia attribuita ad una Pubblica Amministrazione, il cui abbia recepito integralmente le proposte di modifica (v. paragrafo precedente) presentate del l’Incaricato, quest’ultimo è comunque tenuto a pubblicare il codice nello strumento di code hosting dell’Amministrazione per metterlo a riuso, specificando nel README che tale codice è stato recepito dal progetto originario, con un link al repository dello stesso. Come prescritto dalle Linee Guida, il «software a riuso» è il software rilasciato da una Pubblica Amministrazione in adempimento all’art 69 del CAD. Quindi l’Amministrazione Pubblica che adotta un software open source non originato nel contesto della PA, è tenuta a metterlo a riuso, indicando la sua provenienza ...
-
italia
Linee Guida su acquisizione e riuso di software per le pubbliche amministrazioni
Queste linee guida sono in vigore dal 9 maggio 2019, come riportato in Gazzetta Ufficiale Serie Generale n. 119 del 23 maggio 2019 ...
-
italia
1. Premessa
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 ...
-
italia
Modello di governance
Durante la fase sperimentale la governance del DAF è in carico al Team Digitale che ha il compito di gestire attivamente la fase di sviluppo concettuale e implementativo dell’infrastruttura, insieme a tutte le fasi del ciclo di vita del dato, dall’ingestione all’analisi e sviluppo di applicazioni. Il Team Digitale si farà anche carico di ingaggiare i rapporti con le PA coinvolte nella fase di sperimentazione e lavorerà insieme a loro per lo sviluppo di casi d’uso indicati nella roadmap. Parallelamente, il Team Digitale, in stretta collaborazione con le istituzioni competenti, lavorerà per l’individuazione di una PA che prenderà in carico il progetto. Il Team Digitale e la PA selezionata lavoreranno in sinergia durante la fase di messa in produzione del DAF, durante la quale si effettueranno i passaggi di consegna e training ...
-
italia
Casi d’uso della fase sperimentale
A seguire un elenco di casi d’uso già individuati dal team di data scientist del DAF e su cui sono in corso attività di sviluppo e sperimentazione a best effort. Questo elenco è da considerarsi dinamico e pertanto sarà arricchito/modificato nel tempo sulla base delle attività concordate con le PA che partecipano alla fase sperimentale. All’interno delle schede di dettaglio sono indicate delle date di scadenza suscettibili a variazioni perché calcolate secondo le informazioni attualmente in nostro possesso. Esse devono infatti essere verificate con le PA coinvolte nelle singole sperimentazioni sulla base dei tempi necessari a queste ultime per fornire i dati o implementare i meccanismi di ingestion. L’elenco dei casi d’uso è il seguente: ...
-
italia
Roadmap di evoluzione
Lo sviluppo del DAF prevede due fasi principali:. Fase 2: Messa in produzione. La prima fase, le cui attività sono concentrate nel secondo semestre 2017, è finalizzata alla realizzazione della piattaforma tecnologica e alla sua sperimentazione sulla base di casi d’uso individuati in collaborazione con alcune PA selezionate. Sarà inoltre avviata una collaborazione con il Garante della Privacy per definire le modalità attraverso le quali le PA potranno formalizzare il rapporto con l’ente al quale, terminata la fase di sperimentazione, sarà affidata la gestione del DAF. In tal senso saranno anche stabilite le regole che, nel rispetto delle norme sulla privacy, definiranno le modalità di caricamento e di analisi dei dati sul DAF, nonché della diffusione dei dati e dei risultati delle analisi stesse. Nella fase successiva, che andrà a regime dopo che sarà ufficializzato l’ente a cui sarà affidata l’operatività e l’evoluzione del DAF e avviati gli opportuni interventi normativi, il Team Digitale ed AgID predisporranno le procedure atte a rendere operativo quanto prodotto durante la fase sperimentale. Di seguito una roadmap di alto livello, redatta in base alle informazioni e disponibilità delle PA con cui si è attualmente in contatto, e che potrà essere soggetta a cambiamenti e integrazioni in base ai futuri sviluppi. Entro Ottobre 2017: definizione delle PA centrali e locali coinvolte nella fase di sperimentazione. Si pubblicherà un elenco delle PA aderenti, con aggiornamento continuo. Entro Novembre 2017: rilascio secondo MVP del Dataportal che recepisce indicazioni degli utenti sulla base dell’utilizzo del primo MVP. Entro Dicembre 2017: Completamento onboarding delle PA coinvolte nella fase di sperimentazione. Entro Dicembre 2017: Rilascio della prima release del Dataportal. Entro Dicembre 2017: Definizione della governance a tendere del DAF e individuazione della PA che avrà in gestione il progetto. Da Gennaio 2018: passaggio di consegne e training verso la PA che gestirà il DAF. Attivazione processo di onboarding per le PA non ancora aderenti al DAF, sia centrali che locali. Entro Marzo 2018: sviluppo e rilascio dei casi d’uso elencati nel documento, con modalità best effort ...
-
italia
Benefici e Funzionalità per la PA
Il DAF fornisce un sistema di big data management e strumenti di analisi e utilizzo dei dati in modalità SaaS/PaaS, con l’obiettivo di sgravare il più possibile le PA da attività di gestione operativa e tecnica. Inoltre, esse avranno accesso al team di data scientist e data engineer che supporterà le PA nell’utilizzo delle funzionalità del DAF, e potrà prendere in carico richieste di analisi e sviluppo specifiche, da valutare caso per caso. Il DAF mette a disposizione di ciascuna PA aderente:. Un tool per generare dashboard e report. Un notebook per effettuare analisi sui dati presenti nel DAF a cui l’utente ha accesso. L’accesso a un insieme di dati utili per l’elaborazione di analytics. Di seguito, un elenco non esaustivo dei dati che a tendere saranno presenti nel DAF:. Dati delle basi di dati d’interesse nazionale: basi di dati autoritative rispetto alle “entità” che gestiscono (ad es. ANPR è autoritativa per l’”entità” residente). Nel DAF è possibile trovare una copia sempre aggiornata dei dati in esse contenute, fatte salve le eccezioni di norme e regolamenti, e in accordo con il Garante per la Privacy. Dati delle PA: le PA sincronizzeranno (cfr. Piano triennale) una copia dei dati utili a svolgere il proprio mandato istituzionale nonché i dati generati dai propri sistemi informatici (es. log). Tali dati sono accessibili da parte di tutte le PA, ad eccezione di quei dati sui cui vigono norme in materia di protezione dei dati personali. Open data standard: il DAF promuove la creazione di standard per la diffusione di open-data su temi di diffuso interesse pubblico (es. Mobilità, trasporti, turismo, eventi, ecc.). Grazie a tali standard un dataset può essere popolato in modo collaborativo da più PA. Dati di interesse pubblico di terze parti: il DAF raccoglie e mette a disposizione di tutte le PA dati di terze parti di potenziale interesse pubblico (es. dati provenienti dai social networks, dati forniti da aziende, ecc.). un servizio di pubblicazione di open-data di qualità: poiché il DAF ospita copie aggiornate dei dati presenti nelle basi di dati delle PA, ciascuna PA può decidere di abilitare un servizio per la pubblicazione dei propri open-data direttamente tramite apposite API esposte dal DAF. un insieme di data application che implementano casi d’uso di interesse per interi cluster di PA (es. Monitoraggio incidenti stradali e individuazione zone a rischio, Servizio per la verifica della qualità delle informazioni contenuti nelle basi di dati della PA, previsionali per i comuni, sentiment analysis, ecc.). servizi di accesso a best effort di eventi real-time (egestion) su flussi, eventualmente arricchiti e/o normalizzati, di dati veicolati verso il DAF e potenzialmente utili per la realizzazione di servizi non critici. Oltre a quanto messo a disposizione dalla piattaforma, attraverso il team di data scientist, il DAF offre un supporto alle PA per la costruzione di modelli di interconnessione delle diverse sorgenti dati, l’analisi dei dati, lo sviluppo di modelli di machine learning, il coordinamento dello sviluppo di data application e l’organizzazione di “competizioni” scientifiche su tematiche di interesse per la PA ...
-
italia
Cos’è il DAF
Il Data & Analytics Framework (DAF) è una delle attività atte a valorizzare il patrimonio informativo pubblico nazionale approvata dal Governo italiano nell’ambito del Piano Triennale per l’Informatica nella PA 2017-2019. L’obiettivo principale del DAF è di abbattere le barriere esistenti nell’interscambio dei dati pubblici tra PA e promuoverne l’utilizzo a supporto del decision making pubblico, ottimizzare i processi di analisi dati e generazione di sapere, standardizzare e promuovere la diffusione degli open data, promuovere e supportare iniziative di ricerca scentifica favorendo la collaborazione con Università ed enti di ricerca. Il DAF si compone di:. Nel data lake vengono memorizzati, nel rispetto delle normative in materia di protezione dei dati personali, dati di potenziale interesse quali, ad esempio: le basi di dati che le PA generano per svolgere il proprio mandato istituzionale; i dati generati dai sistemi informatici delle Pubbliche Amministrazioni come log e dati di utilizzo che non rientrano nella definizione precedente; i dati autorizzati provenienti dal web e dai social network di potenziale interesse della Pubblica Amministrazione;. big data engine utile ad armonizzare ed elaborare, sia in modalità batch che real-time, i dati grezzi memorizzati nel data lake e a implementare modelli di machine learning;. strumenti per l’interscambio dei dati, utili a favorire la fruizione dei dati elaborati da parte dei soggetti interessati, anche attraverso API che espongono dati e funzionalità ad applicazioni terze;. strumenti di analisi e visualizzazione dei dati offerti in modalità self-service agli utilizzatori del DAF. Un Dataportal, che rappresenta l’interfaccia utente per l’utilizzo delle funzionalità implementate nel DAF. In particolare, il dataportal si compone di:. un catalogo dei dataset basato su CKAN, che gestisce i metadati relativi sia ai dati contenuti nel DAF che agli open data harvestati dai siti delle PA;. interfacce utente per accedere ai tool di analisi e data visualization menzionati sopra;. un modulo riservato alle PA per gestire il processo di ingestion e gestione dei dati e metadati nel DAF;. un modulo per data stories, attraverso il quale gli utenti possono pubblicare le proprie analisi e collaborare con altri utenti. Da un team di esperti di dati, composto da data scientist, data engineer e big data architect che provvedono al disegno e all’evoluzione concettuale della piattaforma big data, alla costruzione di modelli di interconnessione delle diverse sorgenti dati, all’analisi dei dati, allo sviluppo di modelli di machine learning, al coordinamento dello sviluppo di data application e all’incentivazione della ricerca scientifica su tematiche di interesse per la PA. Si rimanda al capitolo 9 del Piano Triennale per maggiori informazioni ...