Risultati
98 risultati
-
italia
Annex C: Open source licence guide
Compatibility of licences depends on the transfer of intellectual property rights by the author. In order to preserve the freedom and reusability of software created over time, copyleft licences are the licences that yield fewer rights in this context. As regards compatibility, two scenarios must be differentiated:. The creation of a new work from existing components, with a single licence. The assembly and distribution of multiple interacting components, each with a different licence. As regards the case of creating a new work under a single licence, the compatibility matrix can be explained as follows:. Works released under a public domain can be released under any other licence. Works released under non-copyleft licences are releasable with copyleft licences. Works released under copyleft licences may only be released with copyleft licences, provided that the two licences are compatible. On the other hand:. Works licensed under a public domain, non-copyleft or weak copyleft may interact as stand-alone components with any other application, while respecting any provisions regarding references to the original code and the distribution of any modifications. Works released under a copyleft licence may only interact as stand-alone components with other components released under a compatible copyleft licence ...
-
italia
Annex D: Guide to reusing open source software
In the event that the maintainer of open source software whose ownership is not attributed to a public administration has fully implemented the modification proposals (see previous paragraph) presented by the Responsible party, the latter is still required to publish the code in the code hosting tool of the administration to allow it to be reused, specifying in the README file that this code has been transposed from the original project, with a link to the repository of the same. As prescribed by the guidelines, ‘reusable software’ is software released by a public administration in compliance with Article 69 of the CAD. Therefore, a public administration that adopts open source software not originating in the context of the PA, is required to make it available for reuse, indicating its origin ...
-
italia
Annex A: Guide to publishing software as open source
As soon as the public repository has been opened, registration on Developers Italia MUST be carried out, to ensure that the repository is indexed and available in the search engine on the site. Registration is a two-step process:. Publication of a publiccode.yml file in the root directory of the repository. A ‘publiccode.yml’ file is a standard that identifies the project as ‘useful software for the public administration’, and at the same time provides a range of useful information for the assessment of the software for reuse. This file will be automatically detected by the Developers Italia crawler in order to generate the relative data sheet in the catalogue. Documentation on the format can be found here: https://github.com/italia/publiccode.yml. Adding the code hosting tool to the search engine. In order to ensure that Developers Italia correctly identify the repository as belonging to the public administration, the code hosting tool (or rather, the ‘organisation’ within the same) must be registered the first time it is used, associating it with the public administration. The procedure to be followed is detailed here: https://onboarding.developers.italia.it ...
-
italia
Annex B: Open source software maintenance guide
All interactions initiated by external users within the code hosting platform, and in particular through its issue tracker, SHOULD be examined by the Responsible party within two working days, and within this period a response MUST be provided. The answer may not be exhaustive, and where it is not possible to answer in detail immediately, it is advisable to provide a courteous response with some initial considerations. Bug fixes. Bug reports received from external users through the issue tracking system must be analysed in the same way as those received from the awarding administration. If the fix is compatible (in terms of time and cost) with the activities provided for in the contract, it may be executed without further approval. If, on the other hand, the fix is not compatible (in terms of time and cost) with the maintenance activities provided for by the contract, the issue must be kept open and the administration informed of the decision. The diagnosis and resolution process must be publicly documented within the issue tracker, with the exception of information that has implications for the security of the systems in production, which MUST be kept confidential until the implementation of corrections and only then MUST it be published for the benefit of other users of the software. The issue report MUST be kept open until the fix and the original user SHOULD be asked to personally verify the quality of the fix before closing it. If there is no response for 30 days, the Responsible party may close the issue, after having documented the successful acceptance of the change. Requests for new functionalities. Requests for new functionalities must be assessed by the Responsible party, in agreement with the administration, in relation to their relevance to the project. If not deemed relevant, they SHOULD be closed and an explanation provided to the proposer. If deemed relevant, they MUST be left open until their possible implementation, but the proposer MUST be provided with rapid feedback and an assessment of the technical feasibility of the application and suggestions on any other way to achieve the stated objective. The Responsible party MAY ask the proposer, if necessary, for more details on the use case justifying the request. The implementation of the required functionalities MUST be approved by the administration in the event that this entails costs for the same (e.g. in the event that the contract is structured with a consumption model). Alternatively, the Responsible party MAY decide to follow up the request by implementing it in the code, without causing any additional burden to the administration and within the time-frame of the contract (for example, pursuant to other commercial agreements on the same software). Requests for information or support. Requests for information about the project SHOULD be processed by the Responsible party within 2 working days. The answers must be limited to the technical characteristics of the software and to questions posed by developers or other administrations for the purposes of understanding technical features, reuse, collaboration or development. The Responsible party is not required to respond to any other party or to provide assistance with the use of the software or to provide answers with regard to the use that the administration makes of the software or in general with regard to other matters for which the administration is responsible. Code contributions. Code contributions sent through the collaboration mechanisms provided by the chosen code hosting platform (e.g. through a pull request) MUST be assessed by the Responsible party who MUST provide feedback to the user with considerations on the feasibility of integration. The Responsible party SHOULD incorporate all code contributions that are not incompatible with the objectives of the provision, providing the contributor with adequate explanation in the event of refusal ...
-
italia
Annex E: Summary table of the elements required for the decision-making process
In order to facilitate the comparative assessment, through a decision-making process for public administrations, which takes into account the information contained in Article 68 as well as Article 69 of the CAD, reference shall be made to the following summary framework:. Oblig ation to reuse Artic le 69 (1). Oblig ation to acqui re owner ship Artic le 69 (2). Oblig ation for econo mic asses sment (TCO) Artic le 68 (1a). Oblig ation for techn ical asses sment Artic le 68 (1b). Ensur ing inter opera bilit y betwe en publi c admin istra tions Artic le 68 (1a). Secur ity guara ntees Artic le 68 (1a). Priva cy law compl iance Artic le 68 (1a). Adequ ate servi ce level s Artic le 68 (1a). Softw are devel oped on behal f of the publi c admin istra tion. Yes. Yes. Yes, with the excep tion of acqui sitio n. Yes. Yes. Yes. Yes. Yes. The reuse of softw are or parts there of devel oped on behal f of the publi c admin istra tion. Yes, only in the case of modif icati on. Yes. Yes, with the excep tion of acqui sitio n. Yes. Yes. Yes. Yes. Yes. Free softw are or open sourc e code. Yes, only in the case of modif icati on. No. Yes, with the excep tion of acqui sitio n. Yes. Yes. Yes. Yes. Yes. Softw are usabl e in cloud compu ting mode. Yes, only for softw are alrea dy owned by or imple mente d ad hoc for the PA. Yes, only for softw are alrea dy owned by or imple mente d ad hoc for the PA. Yes. Yes. Yes. Yes. Yes. Yes. Propr ietar y softw are throu gh use of a user licen ce. No, excep t for softw are creat ed to enabl e appli catio n inter opera bilit y (e.g. API). No, excep t for softw are creat ed to enabl e appli catio n inter opera bilit y (e.g. API). Yes. Yes. Yes. Yes. Yes. Yes. Softw are combi natio n of the previ ous solut ions. Yes, only for softw are alrea dy owned by or imple mente d ad hoc for the PA. Yes, only for softw are alrea dy owned by or imple mente d ad hoc for the PA. Yes. Yes. Yes. Yes. Yes. Yes ...
-
italia
1. Preface
This document was drafted by the working group established by Resolution No 237/2017, a collaboration between the Agency for Digital Italy (Agenzia per l’Italia Digitale - hereinafter AgID) and the Digital Transformation Team (Team per la Trasformazione Digitale):. Viviana De Paola, AgID - Digital transformation area. Daniela Intravaia, AgID - Coordination of international activities. Guido Pera, AgID - Digital transformation area. Umberto Rosini, AgID - Architecture, standards and infrastructure area. Guido Scorza, Digital Transformation Team ...
-
italia
2.5. Macro-phase 2: Analysis of reusable PA solutions and open source solutions
In the event that it is impossible to identify a solution that satisfies, at least to a large extent, the requirements of the administration, between ‘reusable PA solutions’ and ‘open source solutions’, a document is prepared (without format constrictions) that justifies the reasons for the ascertained impossibility, which will be kept with the documents filed for the proceedings. The public administration continues the comparative assessment exercise by following up with the phases anticipated within the next macro-phase 3 ...
-
italia
3. Obiettivo delle Linee guida
Le presenti Linee guida sono emanate - ai sensi dell’articolo 71 del Decreto legislativo 7 marzo 2005, n. 82 e successive modificazioni, recante il “Codice dell‘amministrazione digitale” (CAD) -dall’Agenzia per l’Italia Digitale, sentita la Banca d’Italia, in attuazione dell’articolo 5, comma 4, del CAD. In particolare, il quadro di riferimento è dato dall’articolo 5, comma 1 del CAD che statuisce l’obbligo per le pubbliche amministrazioni di «[…] accettare, tramite la piattaforma» messa a disposizione dall’AgID in attuazione dell’articolo 5, comma 2, del CAD, «[…] i pagamenti spettanti a qualsiasi titolo attraverso sistemi di pagamento elettronico, ivi inclusi, per i micro-pagamenti, quelli basati sull’uso del credito telefonico […]». Tale piattaforma è quella meglio conosciuta come Nodo dei Pagamenti-SPC e/o Sistema pagoPA (si veda il successivo paragrafo 8.3). Le Linee guida perseguono l’obiettivo del legislatore di cogliere le opportunità offerte dalle nuove tecnologie per facilitare le relazioni con i cittadini e le imprese. L’auspicato maggior utilizzo di strumenti di pagamento elettronici facilita la messa a punto di processi fortemente automatizzati per la gestione e la riconciliazione dei pagamenti da parte della Pubblica Amministrazione, nel rispetto delle soluzioni organizzative in essere. Le Linee guida per i pagamenti della Pubblica Amministrazione, tenuto conto del quadro normativo di riferimento, delineano le attività che le pubbliche amministrazioni, i gestori di pubblici servizi e le società a controllo pubblico devono mettere in atto per consentire l’esecuzione di pagamenti attraverso l’uso di strumenti elettronici, nonché le specifiche dei codici da utilizzare per il pagamento, la riconciliazione e il riversamento delle somme raccolte. L’Agenzia per l’Italia Digitale provvederà a tenere aggiornate le Linee guida per tener conto delle variazioni del quadro di riferimento normativo, dell’evoluzione del contesto tecnologico e delle mutate esigenze delle pubbliche amministrazioni e degli utilizzatori finali, quali beneficiari del servizio pubblico erogato ...
-
italia
11. Identificativi errati o incompleti del pagamento
Ai sensi degli articoli 24 e 25 del decreto legislativo 27 gennaio 2010, n. 11, gli Enti Creditori e i prestatori di servizi di pagamento non sono responsabili della mancata esecuzione o dell’esecuzione inesatta del pagamento se i dati identificativi del pagatore o del soggetto versante, le coordinate di addebito o di accredito del pagamento forniti dal pagatore o dal soggetto versante sono inesatti. Gli stessi non sono altresì responsabili della mancata esecuzione o dell’esecuzione inesatta del pagamento se i codici identificativi del versamento di cui al capitolo 7, forniti dal pagatore o dal soggetto versante, sono inesatti o mancanti ...
-
italia
12. Specifiche attuative
Alle presenti Linee guida sono allegati, quale parte integrante delle stesse, dei documenti di carattere tecnico per definire nel dettaglio le modalità attraverso le quali viene data pratica attuazione ai pagamenti in oggetto, e segnatamente:. Allegato A - Specifiche attuative dei codici identificativi di versamento, riversamento e rendicontazione. Allegato B - Specifiche attuative del Nodo dei Pagamenti-SPC. L’Agenzia per l’Italia Digitale si occuperà nel tempo di aggiornare le presenti Linee guida unitamente ai relativi allegati tecnici ...
-
italia
2. Definizioni
Ai fini delle presenti Linee guida si applicano le definizioni di cui all’articolo 1 del CAD. Inoltre, si intende per:. (a) - addebito diretto: un ordine di pagamento per l’addebito di un conto di pagamento del pagatore (o del soggetto versante) in cui l’operazione di pagamento è iniziata dal beneficiario in conformità al consenso del pagatore (o dal soggetto versante), eseguito sulla base degli standard SEPA pubblicati da EPC;. (b) - ATM (Automated Teller Machine): apparecchiatura automatica per l’effettuazione da parte della clientela di operazioni quali prelievo di contante, versamento di contante o assegni, richiesta di informazioni sul conto, bonifici, pagamento di utenze, ricariche telefoniche, ecc. Il cliente attiva il terminale introducendo una carta e digitando il codice personale di identificazione. In Italia, ad esempio, i circuiti Postamat e Bancomat si servono di ATM;. (c) - bollettino di conto corrente postale: bollettino precompilato dal creditore - o da compilare a cura del debitore - con cui il debitore effettua il pagamento con accredito sul conto di pagamento detenuto dal creditore presso Poste Italiane S.p.A.;. (d) - bonifico (bancario o postale): un servizio di pagamento per l’accredito sul conto di pagamento del beneficiario eseguito, sulla base degli standard SEPA pubblicati da EPC, a partire da un conto di pagamento del pagatore (o del soggetto versante) da parte del prestatore di servizi di pagamento detentore del conto di pagamento del pagatore (o del soggetto versante), sulla base di un’istruzione data dal pagatore (o dal soggetto versante);. (e) - carta di credito o di debito: strumento di pagamento costituito da una carta plastificata, dotata di banda magnetica e/o microchip, che in base a un rapporto contrattuale con l’emittente, abilita il titolare a effettuare pagamenti (es. tramite terminale POS o via internet);. (f) - conto di pagamento: un conto intrattenuto presso un prestatore di servizi di pagamento da uno o più utilizzatori di servizi di pagamento per l’esecuzione di operazioni di pagamento. Rientra nella nozione di conto di pagamento il conto corrente bancario o postale nei limiti in cui venga utilizzato per operazioni di pagamento, nonché il conto sul quale vengono addebitate e accreditate le operazioni di pagamento eseguite a valere su una carta di debito o di credito. (g) - Enti Creditori: le pubbliche amministrazioni e gli altri soggetti di cui all’articolo 2, comma 2 del CAD, nonché i gestori di pubblici servizi e gli altri soggetti che risultino comunque aderenti all’infrastruttura del Nodo dei Pagamenti-SPC;. (h) - EPC: European Payments Council (Consiglio europeo per i pagamenti) - sostiene e promuove la creazione della SEPA attraverso l’autoregolamentazione dell’industria bancaria. EPC definisce le regole comuni per i servizi di pagamento di base all’interno di un mercato competitivo, fornisce orientamenti strategici per la standardizzazione, formula le migliori pratiche a supporto e controlla l’attuazione delle decisioni prese;. (i) - gestori di pubblici servizi: le aziende e gli enti organizzati in forma societaria che gestiscono servizi pubblici;. (j) - IBAN: International Bank Account Number - numero identificativo internazionale di un conto di pagamento che individua senza ambiguità un unico conto di pagamento e i cui elementi sono specificati dall’Organizzazione internazionale per la standardizzazione;. (k) - istituto tesoriere: il soggetto finanziario affidatario del servizio di tesoreria o di cassa della singola amministrazione, ivi compresa la Banca d’Italia;. (l) - Nodo dei Pagamenti-SPC: piattaforma tecnologica per l’interconnessione e l’interoperabilità tra le Pubbliche Amministrazioni e i Prestatori di Servizi di Pagamento di cui all’art. 5, comma 2 del CAD;. (m) - pagatore: persona fisica o giuridica che effettua, direttamente o tramite un delegato (soggetto versante), un pagamento in favore di un ente per somme di denaro a vario titolo dovute;. (n) - POS (Point Of Sale): apparecchiatura automatica presidiata per la lettura di carte di pagamento (POS fisico) o servizio fruibile attraverso la rete internet (POS virtuale), messi a disposizione dai prestatori di servizi di pagamento, mediante i quali è possibile effettuare l’operazione di pagamento;. (o) - PSD: Payment Services Directive - la direttiva 2007/64/CE relativa ai servizi di pagamento nel mercato interno;. (p) - PSD2: Payment Services Directive - la direttiva 2015/2366 relativa ai servizi di pagamento nel mercato interno;. (q) - PSP: prestatore di servizi di pagamento - organismo che presta servizi di pagamento sul territorio della Repubblica in quanto ivi insediato o in regime di libera prestazione di servizi. Sono prestatori di servizi di pagamento gli istituti di moneta elettronica e gli istituti di pagamento nonché, quando prestano servizi di pagamento, le banche, gli uffici postali, la Banca Centrale Europea e le banche centrali nazionali se non agiscono in veste di autorità monetarie, altre autorità pubbliche, le amministrazioni statali, regionali e locali se non agiscono in veste di autorità pubbliche;. (r) - Ricevuta telematica (RT): attestazione informatica di avvenuto pagamento rilasciata dal prestatore di servizi di pagamento al pagatore, o al soggetto versante, nonché all’Ente Creditore;. (s) - Richiesta di pagamento telematico (RPT): disposizione impartita dal pagatore, o dal soggetto versante, al prestatore di servizi di pagamento contenente tutti gli elementi richiesti dall’Ente Creditore beneficiario per effettuare un pagamento informatico;. (t) - SEPA: Single Euro Payments Area (Area unica dei pagamenti in euro), ovvero un’area nella quale gli utilizzatori degli strumenti di pagamento - i cittadini, imprese, pubbliche amministrazioni e gli altri operatori economici - indipendentemente dalla loro residenza, possono effettuare e ricevere pagamenti in euro non in contanti sia all’interno dei confini nazionali che fra paesi diversi, alle stesse condizioni e con gli stessi diritti e obblighi. La SEPA riguarda 34 paesi (tutti i paesi dell’Unione Europea più l’Islanda, la Norvegia, il Liechtenstein, la Svizzera e il Principato di Monaco e San Marino). (u) - servizi pubblici: qualsiasi attività che si concretizzi nella produzione di beni o servizi che rispondano ad esigenze di utilità generale, non solo in termini economici ma anche in termini di promozione sociale, purché risponda ad esigenze di utilità generale o ad essa destinata in quanto preordinata a soddisfare interessi collettivi [1]. (v) - Sistema pagoPA: il sistema dei pagamenti a favore delle pubbliche amministrazioni e dei gestori di pubblici servizi;. (w) - soggetto versante: persona, fisica o giuridica, che effettua un pagamento su delega del pagatore;. (x) - SPC: Sistema pubblico di connettività di cui al Capo VIII del CAD. (y) - SPID: Sistema pubblico per la gestione dell’identità digitale di cittadini e imprese di cui all’articolo 64 e 64-bis del CAD;. (z) - strumento di pagamento: dispositivo personalizzato o insieme di procedure utilizzate dal prestatore di servizi di pagamento che consentono al pagatore, o al soggetto versante, di impartire richieste di pagamento informatico;. (aa) - utilizzatore finale: il soggetto (pagatore o versante) che effettua il pagamento di somme a favore di un Ente Creditore. Sentenze del Consiglio di Stato, Sezione Quinta, n. 319 del 3 aprile 1990 e n. 2605 del 9 maggio 2001 ...
-
italia
5. Strumenti di pagamento
Per effettuare i pagamenti elettronici possono essere utilizzati gli strumenti di pagamento messi a disposizione dai prestatori di servizi di pagamento, connessi con la piattaforma tecnologica di cui al paragrafo 8.3, quali: il bonifico, il bollettino postale, le carte di credito o di debito e ogni altro servizio di pagamento che, adeguatamente integrato con la piattaforma tecnologica, risulti rispettoso delle presenti Linee guida e dei relativi allegati tecnici, nonché di ogni ulteriore documento pubblicato dall’AgID per il Nodo dei Pagamenti-SPC. In merito, si precisa che, in considerazione dell’articolo 65, comma 2, del Decreto legislativo 13 dicembre 2017, n. 217, i prestatori di servizi di pagamento, non possono erogare nei confronti dei soggetti obbligati ad aderire al Sistema pagoPA, servizi di pagamento non integrati con il Sistema stesso, ad eccezione degli specifici strumenti di pagamento elencati alle lettere a), b), c) e d) che seguono. Di conseguenza, ove un soggetto obbligato ad aderire al Sistema abbia una specifica esigenza in materia di pagamenti, in via preliminare, dovrà valutare se tale esigenza possa o meno essere soddisfatta attraverso i servizi di pagamento erogabili in via integrata con il Sistema pagoPA e, solo in caso negativo, potrà richiedere e ottenere dai PSP l’erogazione di uno strumento di pagamento in modalità non integrata con pagoPA. Al fine di consentire all’utilizzatore finale di avere a disposizione tutti gli strumenti di pagamento, incluso il servizio di bollettino postale, ogni Ente Creditore, ove abbia già in essere un rapporto di conto corrente postale, ne censisce l’IBAN sul Sistema pagoPA, unitamente al conto corrente di tesoreria o di cassa. Per lo stesso fine, resta ferma la facoltà per ogni Ente Creditore di instaurare un rapporto di conto corrente postale, anche in seguito all’adesione al Sistema pagoPA. Ogni Ente Creditore, ove abbia in essere altri rapporti di conto corrente bancario o postale, potrà censirne i relativi IBAN sul Nodo dei Pagamenti-SPC. Al fine di consentire l’utilizzo di altri strumenti di pagamento elettronico disponibili, il Sistema pagoPA favorisce l’interconnessione con gli schemi, anche internazionali, di carte di pagamento come definite ai sensi dell’articolo 2, punti 33), 34) e 35) del regolamento UE 2015/751 del Parlamento europeo e del Consiglio del 29 aprile 2015 relativo alle commissioni interbancarie sulle operazioni di pagamento basate su carta. Pertanto, il Sistema pagoPA rappresenta il sistema nazionale dei pagamenti elettronici in favore delle Pubbliche Amministrazioni e degli altri soggetti tenuti per legge all’adesione, al quale gli Enti Creditori possono affiancare esclusivamente i seguenti metodi di pagamento:. a) «Delega unica F24» (c.d. modello F24) fino alla sua integrazione con il Sistema pagoPA;. b) Sepa Direct Debit (SDD) fino alla sua integrazione con il Sistema pagoPA;. c) eventuali altri servizi di pagamento non ancora integrati con il Sistema pagoPA e che non risultino sostituibili con quelli erogati tramite pagoPA poiché una specifica previsione di legge ne impone la messa a disposizione dell’utenza per l’esecuzione del pagamento. d) per cassa, presso l’ente e/o il soggetto che per tale ente svolge il servizio di tesoreria o cassa;. Per il conseguimento degli obiettivi di razionalizzazione e contenimento della spesa pubblica gli Enti Creditori hanno l’obbligo di dismettere ogni altra modalità di pagamento elettronico non interconnessa al Sistema pagoPA, fatto salvo quanto precisato al capoverso che precede. Inoltre, si precisa che per evitare che gli utenti possano eseguire dei bonifici non integratico con il Sistema pagoPA, è fatto divieto ai soggetti tenuti per legge all’adesione a pagoPA di pubblicare in qualsiasi modo l’IBAN di accredito. Resta però fermo che, laddove un utente, però, avendo in proprio memoria di tale IBAN, esegua un bonifico extra pagoPA, tale pagamento andrà comunque gestito dall’Ente Creditore quale singola eccezione, con l’auspico che tali eccezioni siano sempre di numero inferiore nel tempo ...