Risultati
409 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.3. Valutazione comparativa
Vista l’eterogeneità delle soluzioni e la difficoltà ad effettuare comparazioni quantitative omogenee, come in caso di confronto tra una soluzione dalla quale possano essere ricavati costi certi (soluzione proprietaria in modalità on premise o in modalità cloud computing) e una soluzione da realizzare ex novo - per la quale si disponga soltanto dello studio di fattibilità - si è preferito indicare un processo decisionale attraverso la descrizione di Fasi e la loro organizzazione in Macro fasi. La seguente immagine riporta le Macro fasi che caratterizzano il processo decisionale per dare seguito alla valutazione comparativa prevista all’articolo 68 del CAD. Le Macro fasi individuate sono:. MACRO FASE 1:. Ha l’obiettivo di definire le esigenze specificando i bisogni e i vincoli (organizzativi ed economici) che condizionano le scelte per l’identificazione di una soluzione adeguata alle esigenze dell’amministrazione;. MACRO FASE 2:. Qui la pubblica amministrazione accerta la possibilità di soddisfare le proprie esigenze utilizzando una soluzione già in uso presso altre amministrazioni (di seguito «soluzioni a riuso delle PA») o a software libero o codice sorgente aperto (di seguito «soluzioni Open Source»). MACRO FASE 3:. Ove la Macro fase 2 non permetta di rispondere alle esigenze della Pubblica amministrazione, si persegue il soddisfacimento delle stesse attraverso il ricorso a programmi informatici di tipo proprietario, mediante ricorso a licenza d’uso e/o a realizzazioni ex novo. In quanto segue le Macro fasi individuate sono suddivise in Fasi, descrivendo le attività da realizzare in termini di criteri e metodologie da adottare ...
-
italia
2.1. Introduzione e contesto normativo
Per le Pubbliche amministrazioni il Codice dell’Amministrazione Digitale, di seguito denominato CAD, disciplina il riuso delle soluzioni e standard aperti. Gli articoli 68 e 69, che le presenti Linee guida hanno l’obiettivo di attuare, trattano nel medesimo contesto i temi del riuso, della titolarità del software e del codice sorgente aperto per le PPAA. Gli articoli richiamati sono stati modificati sia dal d.lgs. 26 agosto 2016 n. 179 sia dal d.lgs. 12 gennaio 2017 n. 217. L’ultimo aggiornamento ha comportato:. la riformulazione dell’art. 69, comma 2;. l’introduzione del comma 2 bis dell’art. 69;. l’abrogazione dell’articolo 70 rubricato banca dati dei programmi informatici riutilizzabili. Il testo dell’art. 68 è rimasto immutato, eccezion fatta per l’aggiornamento del riferimento normativo al D.Lgs. 50/2016 [1] in luogo del richiamo alla precedente normativa in materia di appalti. Fino alla modifica apportata dal D.Lgs. 217/2017, nell’acquisizione di software da parte delle pubbliche amministrazioni svolgevano un ruolo:. le convenzioni quadro e gli accordi quadro stipulati, ai sensi della normativa vigente, da CONSIP e dai soggetti aggregatori;. il Catalogo nazionale programmi riutilizzabili gestito dall’AgID. I primi due continuano a svolgere la funzione, mentre le funzioni del catalogo, abrogato in quanto tale dal CAD, sono assunte dal portale Developers Italia (https://developers.italia.it), che assume il ruolo di «piattaforma», rectius repertorio - secondo la dizione dell’art. 69 co. 1 -, e delle piattaforme di cui all’art. 69 co. 2bis. Il presente documento ribadisce che i «principi di economicità e di efficienza, tutela degli investimenti, riuso e neutralità tecnologica» (comma 1 dell’art. 68 del CAD [2]) si raggiungono attuando quanto previsto dal comma 2 dell’art. 69 del CAD [3]: «il riuso dei programmi informatici di proprietà delle pubbliche amministrazioni» garantendo che queste ultime, oltre ad essere titolari del software, rendano il software Open Source attraverso l’apposizione di una licenza aperta. http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2016-04-18;50!vig=. http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2005-03-07;82!vig=~art68. http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2005-03-07;82!vig=~art69 ...
-
italia
2.6. Macro fase 3: Analisi delle altre soluzioni
A seguito della precedente fase 3.3 l’amministrazione ha determinato una soluzione, con licenza proprietaria o da realizzarsi ex novo, che soddisfa le sue esigenze e provvede all’approvvigionamento della stessa secondo le procedure previste dal Codice dei contratti pubblici. Nel caso in cui si opti per la realizzazione ex novo, considerando i commi 1 e 2 dell’Articolo 69 che disciplinano la messa a riuso del software che verrà realizzato, si rimanda a Sviluppo di software ex novo per le informazioni su come progettare questa realizzazione per adempiere ai commi citati e metterlo così a riuso. Nel caso che si proceda ad una acquisizione di software proprietario sotto licenza, si ricorda che l’Amministrazione deve ove possibile acquisire la titolarità del codice sviluppato (come spiegato in Titolarità), per metterlo a riuso. La valutazione comparativa si considera conclusa. [1]. Analisi di Fattibilità per l’acquisizione delle forniture ICT ...
-
italia
2.7. Total Cost of Ownership (TCO)
Le valutazioni comparative economiche sono effettuate attraverso l’utilizzo di strumenti economico/finanziari quali il TCO (Total Cost of Ownership), che rappresenta il costo globale di un bene durante il suo ciclo di vita. Il TCO prende in considerazione sia i costi diretti che i costi indiretti, rappresentando il metodo consigliato sia per misurare i costi totali (attraverso l’identificazione di tutte le spese, in termini chiari e facilmente misurabili), sia per effettuare la suddetta valutazione comparativa durante la fase 3. Per eseguire correttamente un TCO, è necessario calcolare i costi dell’intero ciclo di vita del software e non solo quelli meramente necessari alla sua acquisizione, come per esempio:. Costi per la personalizzazione del software;. Costi di manutenzione (correttiva e evolutiva);. Costi di formazione del personale;. Costi di migrazione dei dati da precedenti soluzioni. In questa linea guida, è stato indicato di utilizzare il TCO in due diversi fasi: durante la Macro Fase 2 (come strumento per stimare il costo relativo all’acquisizione di un software open source), e durante la Macro Fase 3 (come strumento per valutare una eventuale scelta tra la realizzazione ex-novo e l’acquisizione di software proprietario). Ai fini dell’adempimento a questa Linea Guida, quindi, si richiede che in fase di analisi comparativa l’amministrazione effettui una stima dei costi secondo il modello qui delineato, tenendo sempre conto di tutto il ciclo di vita. Questa analisi dovrà essere tanto più accurata quanto grossa è l’acquisizione necessaria. Fornire modelli di calcolo del TCO per le esigenze delle amministrazioni va oltre gli obiettivi di questa Linee Guida, poiché le esigenze sono le più differenti. AgID potrà, in futuro, pubblicare dei modelli facoltativi, pronti all’uso, all’interno della piattaforma Developers Italia ...
-
italia
2.2. Oggetto della valutazione
La valutazione comparativa deve essere svolta quando le pubbliche amministrazioni intendano acquisire «programmi informatici o parti di essi». L’oggetto della valutazione quindi è un software (come identificato in 1.2. software oggetto di queste linee guida) che risponda a specifiche esigenze funzionali dell’amministrazione. A titolo esemplificativo, rimane all’esterno del perimetro di questo documento l’acquisizione di sole componenti hardware dei sistemi informativi (server, postazioni di lavoro, stampanti, ecc.). Ulteriori situazioni dove non è applicabile il percorso decisionale proposto in questo Capitolo 2 possono riguardare ad esempio:. accordi quadro, in quanto strumenti che definiscono esclusivamente le clausole generali che, in un determinato periodo temporale, regolano i contratti da stipulare (le caratteristiche specifiche della singola fornitura vengono successivamente definite in appositi Appalti Specifici);. completamento di progetti o realizzazioni per le quali la valutazione comparativa sia già stata effettuata preliminarmente all’acquisizione iniziale;. gare che abbiano come oggetto l’outsourcing completo dei sistemi informativi, in quanto la scelta dell’esternalizzazione riguarda un ambito strategico che esula dallo specifico contesto delle presenti Linee guida e risponde a scelte di governance dell’amministrazione e a obiettivi di carattere strategico di ordine più generale. Si noti che nei casi qui elencati si devono comunque applicare le Linee Guida sul riuso del Software descritte nel Capitolo 3 ...
-
italia
2.8. Scelta della modalità di erogazione del software
Nel caso in cui il software (a riuso, open source o proprietario) debba essere installato su server, l’amministrazione si potrebbe trovare a valutare la modalità di erogazione tra le seguenti opzioni:. installazione su un server nella disponibilità diretta dell’amministrazione. La scelta tra queste opzioni deve avvenire tramite il calcolo del Total Cost of Ownership come descritto nella sezione 2.7. Total Cost of Ownership (TCO). Secondo quanto disciplinato nel capitolo 3 del Piano Triennale per l’Informatica nella PA, ai fini dell’installazione su server nella propria disponibilità l’Amministrazione deve ricorrere all’utilizzo del cosiddetto Cloud della PA, scegliendo una delle seguenti opzioni di tipo IaaS:. installazione in Cloud SPC Lotto 1;. installazione in Cloud Service Provider Qualificati ai sensi della circolare AGID «Criteri per la qualificazione dei Cloud Service Provider per la PA» ...