Guidelines on the acquisition and reuseof software for public administrations

italiaFeb 13, 2020

Table of contents

1

Preface
1.1 Purpose and structure of the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Software covered by these guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Software reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Subjects of the guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 Software compliance with regulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
1
2
3
3
4
4
5

2

Guidelines for acquiring software
2.1 Introduction and legislative context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Subject of the assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Comparative assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1
Description of solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2
Description of the assessment criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3
Description of macro-phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Macro-phase 1: Identification of requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1
Phase 1.1: Needs analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2
Phase 1.2: Identification of constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3
Phase 1.3: Drafting of the document describing the requirements . . . . . . . . . . . . . . .
2.5 Macro-phase 2: Analysis of reusable PA solutions and open source solutions . . . . . . . . . . . . .
2.5.1
Phase 2.1: Identifying reusable solutions for the PA . . . . . . . . . . . . . . . . . . . . . .
2.5.2
Phase 2.2: Assessment of reusable solutions for the PA . . . . . . . . . . . . . . . . . . . .
2.5.3
Phase 2.3: Procurement of the reusable solution for the PA . . . . . . . . . . . . . . . . . .
2.5.4
Phase 2.4: Identifying open source solutions . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.5
Phase 2.5: Assessment of open source solutions . . . . . . . . . . . . . . . . . . . . . . . .
2.5.6
Phase 2.6: Procurement of the open source solution . . . . . . . . . . . . . . . . . . . . . .
2.5.7
Phase 2.7: Impossibility determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Macro-phase 3: Analysis of other solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.1
Phase 3.1: Identifying proprietary solutions . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.2
Phase 3.2: Analysis of from-scratch solutions . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.3
Phase 3.3: Comparison of proprietary and from-scratch solutions . . . . . . . . . . . . . . .
2.6.4
Phase 3.4: Procurement of proprietary or from-scratch solution . . . . . . . . . . . . . . . .
2.7 Total Cost of Ownership (TCO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 Choice of software provision method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7
7
8
8
8
9
10
11
11
13
13
13
15
16
17
17
17
18
18
18
20
21
21
22
22
22

3

Guidelines for software reuse (Article 69)

25
i

3.1
3.2
3.3
3.4

3.5

3.6
3.7

3.8

3.9

ii

Introduction and legislative context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reuse model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Developers Italia and identifying software for reuse . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process of making software available for reuse under open licence . . . . . . . . . . . . . . . . . . .
3.4.1
Identifying a code hosting tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2
Registration of open software on Developers Italia . . . . . . . . . . . . . . . . . . . . . .
3.4.3
Responsibilities related to the release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Open licences and selecting a licence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2
Open software licences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.3
Choosing a licence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Releasing existing software under open licence . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Development of software from scratch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1
Releasing new software under open licence . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.2
Acquisition of ownership of software developed from scratch . . . . . . . . . . . . . . . . .
Maintenance of software by the owner administration . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.1
Ownership of the code developed during maintenance . . . . . . . . . . . . . . . . . . . . .
3.8.2
Release of modifications under open licence . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.3
Support for reusing administrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.4
Software not yet released under open licence . . . . . . . . . . . . . . . . . . . . . . . . .
Reuse of software or use of open source software . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1
Use of reusable or open source software . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.2
Modifications to reusable or open source software . . . . . . . . . . . . . . . . . . . . . . .

25
25
26
26
27
28
28
28
28
28
29
30
30
31
31
31
31
31
32
32
32
32
33

CHAPTER

1

PrefaceThis 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 (Teamper la Trasformazione Digitale):• Giovanni Bajo, Digital Transformation Team• 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.

1.1 Purpose and structure of the document
These guidelines are adopted in implementing Articles 68 and 69 of the Digital Administration Code (hereinafter
CAD):• as provided for in Article 68(1b), identifying in Chapter 2 Guidelines for acquiring software (page ??), themethods and criteria by which an administration must carry out the comparative assessment described in the
aforementioned article when selecting a method for acquiring software.
• as provided for in Article 69(2a), identifying in Chapter 3 Guidelines for software reuse (Article 69) (page ??),
the platform for the publication of source code under open licence and software documentation available forreuse by administrations, specifying the technical methods for use.
They also replace the previous Circular 63/2013, entitled ‘Guidelines for comparative assessment provided for by
Article 68 of Legislative Decree No 82 of 7 March 2005, the Digital Administration Code’ and its annexes.
This document and the methodology described within are to be understood as aids to a decision-making processthat remains under the full responsibility of administrations, when they share solutions as well as when they adopt
them for reuse in compliance with the regulations in force, in particular with regard to digital public administration,1

Guidelines on the acquisition and reuse of software for public administrations

public contracts and the protection of personal data. With reference to the latter area of law, EU Regulation 2016/679
has defined/specified principles and criteria that are particularly relevant with respect to the subject matter of theseguidelines. Among these principles and criteria, the requirement to consider data protection from the design stage andby default (Article 25 of the aforementioned regulation) is highlighted. Furthermore, attention should be paid to AgID
technical rules that may affect the subject matter, such as the Minimum security4 measures (Circular 2/2017)5 andGuidelines for the development of secure software6 .
This document is the starting point of a cultural process in which public administrations are the protagonists for theincreasing use of open software, as is evident from Article 69(1), which requires public administrations ‘that own
solutions and computer programs created at the specific instructions of the public client’ to ‘make the relevant sourcecode available, complete with documentation and released in a public repository under open licence. . . ‘
Therefore, the aforementioned regulation was the starting point for the preparation of these guidelines, highlighting
the vigorous drive of the legislator towards the increasing use of open source software by public administrations.
This can be seen from the simultaneous elimination of the provision of the so-called ‘reuse catalogue’, without thispreventing, if necessary, public administrations from entering into agreements (for example, on the basis of Article 15
of Law No 241/90) for the reuse of solutions that do not comply with the provisions of Article 69(1) and that cannot
fall within the scope of the cases dealt with here, which, it is stressed, must be those that are subject to an open licence.
In any case, the legislator, adopting this strong propensity towards open source for public administrations, has reasonably provided for a general exclusion, only for ‘justified reasons of public order and safety, national defence
and electoral consultations’ - in Article 69(1), final bullet point - , in order to safeguard those more sensitive areasof digital government of the country, which from the sharing and community management of open software may be
exposed to risk.
The approach described above, which favours open source, can also be inferred clearly from the wording of Article 69(2), which requires public administrations ‘in project specifications’ to ‘always be the owners of all rights toprograms and information and communication technology services, specifically developed for them’.
A safeguard has also been provided for in this case, uniquely for circumstances in which ‘this is excessively onerous
for proven technical-economic reasons’.
Consequently, Article 68 shall be understood and implemented in this document, in full compliance with the aforementioned interpretation of Article 69.
Public administrations are in the position to best know their requirements and will be capable of rejecting the methodology proposed here, in relation to its context, as well as to the characteristics of the acquisition to be carried out.
In this sense, the guidelines are not merely a regulatory tool, but suggestions for new follow-up, awareness andinformation processes.

1.2 Software covered by these guidelines
In order to dispel any interpretative doubts, in the context of Articles 68 and 69 of the CAD, the terms ‘programs’,‘solutions’, ‘computer programs’ and ‘ICT solutions’ are to be understood as the same. The subject matter of theobligation laid down by the provision in question is ‘software’. A non-exhaustive list of software thus covered bythese guidelines includes the following:• Web applications (front-end and back-end)• Desktop applications• Mobile applications• Semi-finished applications and components
4 https://www.agid.gov.it/index.php/it/sicurezza/misure-minime-sicurezza-ict
5 https://www.agid.gov.it/index.php/it/sicurezza/misure-minime-sicurezza-ict
6 http://www.agid.gov.it/sites/default/files/repository_files/documentazione/linee_guida_per_lo_sviluppo_sicuro_di_codice_v1.0.pdf

2Chapter 1. PrefaceGuidelines on the acquisition and reuse of software for public administrations• Frameworks• Libraries• Plug-ins• Operating systems• Websites (front-end and back-end)
These guidelines are intended for encouraging the rationalisation of solutions used in sectors/services familiar to
public administrations, such as, for example, human resources management, document management and storage,
management of decision-making processes, institutional communication and administrative transparency.
Furthermore, it is important to note that the term ‘software’, as used in this document, refers not only to the source
and/or executable code, but also to all artefacts produced during the process of developing and using software, i.e.
documentation, graphical assets, manuals, etc., as explained in Article 69(1).

1.3 Software reuseThe ‘reuse’ of software refers to the set of activities carried out to enable the software to be used within a different
context from that for which it was originally created, in order to satisfy requirements similar to those that led to its
initial development. The original product is ‘transported’ into its new context, enriched, if necessary, with additional
functionalities and technical characteristics that may represent ‘added value’ for its users.
Through the combined provisions of Articles 68 and 69 of the CAD, software for reuse is exclusively that released
under open licence by a public administration. Therefore, this is a subset of all open source software available foracquisition. These guidelines distinguish, where appropriate, the methods in which public administration software
under an open licence is acquired, in comparison to third-party open source software.
A fundamental condition of reuse in the context of public administrations is that an administration that ‘reuses’ software receives it free of charge from the transferring administration, and in acquiring it only incurs the costs of its
adaptation, not those of design and implementation.

1.4 Subjects of the guidelines
These guidelines are addressed to public administrations referred to in Article 1(2) of Legislative Decree No 165 of
30 March 2001, in compliance with the division of competence referred to in Article 117 of the Constitution, including
the port system authorities, as well as the independent administrative authorities of assurance, control and regulation,i.e. ‘institutes and schools of any class and grade, and educational institutions, autonomous state companies and administrations, the regions, provinces, municipalities and mountain communities and their consortia and associations,
university institutions, autonomous social housing institutes, chambers of commerce, industry, crafts and agriculture
and their associations, all non-profit national, regional and local public bodies, administrations, companies and bodies of the national health service, ARAN (l’Agenzia per la rappresentanza negoziale delle pubbliche amministrazioni- Contractual Representation Agency for Public Administrations) and the agencies cited in Legislative Decree No 300
of 30 July 1999 and CONI (Comitato Olimpico Nazionale Italiano - Italian National Olympic Committee) (for thelatter administration, up until the organic review of the regulations for the sector)’.
The provisions for the reuse of solutions shall not apply where there are ‘justified reasons concerning public order andsafety, national security and defence, and electoral consultations’.
With reference to the scope of application of these guidelines, it is hoped that public administrations will use thecooperation and collaboration tools provided by current legislation, such as collaboration agreements provided for by
Article 15 of Law No 241/1990, in order to implement co-design initiatives, broadening the sharing of knowledge,
decision-making processes and common paths, through, for example, centres of expertise and support throughout thelife cycle of the software.
1.3. Software reuse3

Guidelines on the acquisition and reuse of software for public administrations

1.5 Ownership
In accordance with Article 69 of the CAD, as regards reuse, an administration is to be considered as the owner ofsoftware designed to meet its own specifications whenever:• it has commissioned such a solution - by means of procurement or other negotiation circumstances of a similar
nature, regardless of the title given to the contract - and the contract provides for the acquisition of all
intellectual and industrial property rights over the software developed on behalf of the public administration,or in any case does not attribute such ownership to the contractor or to third parties.
• the software was developed by resources within the administration itself.
When negotiating a contract to commission the development of software, each administration must ensure, at theconclusion of the execution of the contract, their full and exclusive ownership of all rights over the software underdevelopment, unless this is excessively onerous for proven technical and economic reasons (from Article 69(2) of the
CAD).
Software under development refers to the parts of software actually developed in execution of the contract; it isunderstood that development could be based on the use of existing software components (e.g. open source libraries
and frameworks of third parties) for which acquiring ownership is not necessary, only a licence is required (whichmust be compatible with the purposes of reuse).
Failure to acquire ownership of the work cannot be used to obtain more advantageous economic conditions, since itdoes not constitute a proven technical-economic reason within the meaning of Article 69(2) of the CAD.
An administration, within the meaning of Article 69, must also acquire all intellectual and industrial property rights toany customisations or software modules intended to be integrated with or interfaced with proprietary software. In thiscase, the obligation set forth in Article 69 shall apply exclusively to the module or part of the software being developed;
this module must therefore be separated from the rest of the software and released in accordance with the methods
specified in Development of software from scratch7 , taking care to specify the required ownership dependency within
the documentation.
For example, wording such as the following, where present in software development contracts, allows for the administration to be deemed to be the owner of the rights in the sense required by Article 69 of the CAD:
• ‘the client will own the developed software’;• ‘the ownership of the IT solution covered by the contract will be attached to the client or administration’;• ‘at the end of the contract, the intellectual property of the IT solution under development will lie within thecompetence of the awarding administration’;• ‘all copyrights on the developed software will be transferred, after the completion of the work, to the awarding
administration, which will become the owner’;• ‘all economic exploitation rights as regards the contracted software shall lie within the competence of the awarding administration’.

1.6 Software compliance with regulations
Reusing software amplifies any selection made within the information technology field and is completely neutral withrespect to the quality or lack thereof of selections made. It can multiply the impact of good practice or, in the sameway, negatively enhance the impact of erroneous choices whose dissemination is undesirable.
In promoting the reuse and dissemination of software over which the intellectual property rights of an administration
are emphasised, along with the important economic and efficiency advantage, it is crucial to draw the attention of
7 https://docs-italia-staging.teamdigitale.it/italia/developers-italia/lg-acquisizione-e-riuso-software-per-pa-docs-en/it/new-version-master/
software-reuse/development-of-software-from-scratch.html/

4

Chapter 1. PrefaceGuidelines on the acquisition and reuse of software for public administrationsindividual administrations to the importance of the software being reused - as with the entire software range used byeach administration - complying with the regulations in force.
Since the process of acquiring software for reuse often includes customisations and aggregations of different components, some of which may no longer be in use or were released years earlier, it is important to remember that theverification of full compliance with the regulatory framework remains the responsibility of the administration thatreuses the software, since it alone is responsible for decisions taken within the assigned margins of discretion and inaccordance with the constitutional principles of good performance.

1.7 Glossary
Artefacts By-products created during software development that help describe functions, architecture, design andcommissioning; for example: functional requirements, description of databases and processes, the test set.
Code Hosting (tool) A platform that allows for the publication of the source code, organised into multiple repositories.
Code hosting tools often also offer functionalities related to software evolution such as ticketing systems, processes
for third-party code contribution, an area for downloading releases, etc. Within the framework of these guidelines, thetools chosen by the administrations must have minimum requirements in terms of functionality (3.4.1 Identifying acode hosting tool (page ??)).
Source code The source code (often referred to simply as ‘source’) is the text of a program written in a programming
language (e.g. C or Visual Basic) from which the final program used by the user is derived. Access to the source codeis essential for modifying a program.
Community Aggregation of natural and legal persons and resources (e.g. forums, chatrooms and technologies formeeting and interacting in a virtual location), with rules and a structure, aimed at the implementation and/or management of a common project.
Open format (data) The public data format, versioned, comprehensively documented and without restrictions at
implementation. An open format is a format recognised by a standardisation body and maintained in a shared manner
among multiple bodies that provide concurrent implementations, with a transparent process. The format must remain
consistent with the affirmed version.
Data format Data representation method.
Interoperability In the field of information technology, the capacity of different and autonomous systems to cooperate
and exchange information automatically, on the basis of shared rules.
Licence In the field of information technology, the legal text with which certain rights are granted to the software andthe data distributed, which would otherwise be reserved by exclusivity rights.
Lock-in A technical and economic phenomenon in which a generic user is unable to free themselves from a previously
made technological choice. This inability is typically caused by the high costs of changing technology but, in manycases, it may also depend on the adoption of proprietary solutions that prevent migration. The use of open formats
for data storage, and free access to such data (especially in the case of SaaS solutions) are prerequisites for avoiding
lock-in situations.
Open source This refers to a method in which software can be licensed. It is implemented by granting the public rights
to use, copy, modify and distribute copies, including modified copies, of the software; to do this, the source code mustalso be freely available. Also referred to as ‘free software’, ‘open software’ or ‘software released under open license’.
The certification body for software licences corresponding to this definition is the Open Source Initiative (OSI).
Repository Within a code hosting tool, a repository is the minimum containment unit for the source code of a pieceof software. The term ‘reportorio’ is its Italian translation (used for example in CAD Article 69(1)).
Reuse In the context of these guidelines, this refers to the process outlined by the CAD (Article 69) with which anadministration distributes (‘making available for reuse’) software that it owns in open source, for the benefit of other1.7. Glossary5Guidelines on the acquisition and reuse of software for public administrations

administrations that can use it (‘reusing’). All reusable software is open source, but not all open source software isreusable (since not all open source software is owned by an administration).
SaaS Software as a Service. Refers to a method of software distribution that does not involve installation on operators’
workstations, but that occurs through remote access to a server, for example by connecting to an address through abrowser. Wikipedia is an example of software distributed in Software as a Service mode.
Proprietary software This is software that has restrictions on its use, modification, reproduction or redistribution
imposed by the owner of the economic exploitation rights, i.e. the author or - in the event of a transfer of proprietary
rights - the assignee of the rights in question.
TCO Total Cost of Ownership: Approach used to assess all the costs of the life cycle of an IT resource calculated overa time window appropriate to the context of the assessment and that includes the cost of migration to another solution(e.g. acquisition, installation, management, maintenance and decommissioning). The TCO approach is based on theconsideration that the total cost of using an IT resource depends not only on the acquisition costs, but also on all thecosts that occur during the entire operating life of the resource itself.

6

Chapter 1. Preface

CHAPTER

2

Guidelines for acquiring software

2.1 Introduction and legislative context
For public administrations, the Digital Administration Code, hereinafter referred to as the CAD, governs the reuse ofopen solutions and standards.
Articles 68 and 69, which these guidelines aim to implement, also deal with the issues of reuse, software ownershipand open source code for public administrations.
The articles referred to have been modified by Legislative Decree No 179 of 26 August 2016 as well as Legislative
Decree No 217 of 12 January 2017. The latest update involved:• the amendment of Article 68, repealing paragraph 3 and transposing the content into Article 1(3)(la-) and Article 1(3)(lb-);• the rewording of Article 69(2);• the introduction of Article 69(2a);• the repeal of Article 70, which is entitled ‘Database of reusable computer programs’.
The text of Article 68 remains unchanged, except for the updating of the regulatory reference to Legislative Decree
No 50/20161 replacing the reference to the previous procurement legislation.
Up until the modification implemented by Legislative Decree No 217/2017, the following factors played a role in theacquisition of software by public administrations:• the electronic marketplace: ‘an acquisition and negotiation tool that allows for electronic purchases for amounts
below the European threshold value based on a system that implements procedures for selecting the contractor entirely by electronic means’ (of particular importance is the MePA (Mercato Elettronico per la Pubblica
Amministrazione - Electronic Market for Public Administration) managed by CONSIP);• framework conventions and agreements concluded, in accordance with the legislation in force, by CONSIP andby aggregators;• the national catalogue of reusable programs managed by AgID.
1 http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2016-04-18;50!vig=7

Guidelines on the acquisition and reuse of software for public administrations

The first two continue to carry out their functions, while the catalogue functions, repealed as such by the CAD, areassumed by the Developers Italia (https://developers.italia.it8 ) portal, which assumes the role of ‘platform’, or more
precisely of repository - according to the wording of Article 69(1) and of the platforms referred to in Article 69(2a).
This document reiterates that the ‘principles of economy and efficiency, investment protection, reuse and technologicalneutrality’ (Article 68(1) of the CAD2 ) are achieved by implementing the provisions of Article 69(2) of the CAD3 :’the reuse of computer programs owned by public administrations’ ensuring that the latter, in addition to being ownersof the software, make the software available through open source with the affixing of an open licence.

2.2 Subject of the assessment
The comparative assessment should be carried out when public administrations intend to acquire ‘computer programsor parts thereof ’. Therefore the subject of the assessment is software (as identified in 1.2. Software covered by theseguidelines) that meets the specific functional requirements of the administration.
For example, the acquisition of hardware components for information systems (servers, workstations, printers, etc.)
remains outside the scope of this document.
Further situations where the decision-making process proposed in this Chapter 2 is not applicable may involve, forexample:• the adoption of framework contracts already agreed, where such adoption is compulsory for administrations;• framework agreements, as instruments that exclusively define the general clauses that, within a given period oftime, regulate the contracts to be entered into (the specific characteristics of the individual supply are subsequently defined in Specific Contracts);• completion of projects or outputs for which a comparative assessment has already been carried out prior to theinitial acquisition;• tenders with the complete outsourcing of information systems as their objective, since the option of outsourcing
involves a strategic area that goes beyond the specific context of these guidelines and responds to administration
governance decisions and strategic objectives of a more general nature.
Please note that in the cases listed here, the Guidelines for software reuse described in Chapter 3 must still be applied.

2.3 Comparative assessment
2.3.1 Description of solutions
Article 68(1) of the CAD indicates the types of solution subject to comparative analysis by type of software:‘Public administrations acquire computer programs or parts thereof in accordance with the principles of economy andefficiency, investment protection, reuse and technological neutrality, following a comparative technical and economic
assessment of the following solutions available on the market:a) software developed on behalf of the public administration;b) the reuse of software or parts thereof developed on behalf of the public administration;c) free software or open source code;d) software that is usable through cloud computing;
8 https://developers.italia.it/
2 http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2005-03-07;82!vig=~art68
3 http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2005-03-07;82!vig=~art69

8

Chapter 2. Guidelines for acquiring software

Guidelines on the acquisition and reuse of software for public administrationse) proprietary software through the use of a user licence;f) a combination of the previous software solutions’.
The following list of definitions describes the six solutions provided by the legislation:
A - Software developed on behalf of the public administration A solution also known as the ‘make option’: thepublic administration entrusts the development of the software (either from scratch or through modifying existing
software) to a supplier and the latter undertakes to deliver the developed software to the public administration on thebasis of the defined requirements. For example, during the software life cycle (analysis, design, development, testing,release, maintenance) the public administration may take care of the analysis and design phases, defining the software
requirements and then entrust the development to the supplier.
B - Reuse of software or parts thereof developed on behalf of the public administration ‘Reuse’ of a public
administration software solution (or components thereof) that already exists and is available.
C - Free software or open source code software licensed under an open source licence (see 1.7 Glossary (page ??)).
In particular, this refers to all software distributed under an OSI-certified license (complete list9 ), as described in 3.5.2
Open software licences (page ??).
D - Software that is usable through cloud computing A solution in which the public administration acquires thesoftware as a service. This solution does not include HaaS (Hardware as a Service) and IaaS (Infrastructure as aService).
E - Proprietary software through the use of a licence Subject to proprietary software user licence conditions, to beinstalled ‘on premises’.
F - A combination of the previous solutions Software implemented with components belonging to more than oneof the previous categories. For example, software in which a reused solution relies on open source middleware andaccesses a proprietary database, with components specifically designed for the administration that is receiving thesolution. In fact, this is the most common type currently used in public administrations.
In addition, Article 69(1) of the CAD states that‘public administrations that are owners of IT solutions and computer programs made to the specific specifications of
the public client, have the obligation to make the relevant source code available, complete with documentation andreleased in a public repository under an open licence, free of charge’.
With regard to solution D) (Software that is usable through cloud computing), this is to be considered as a method forthe provision of IT services, and therefore can be occasionally combined with categories A), B), C) and E).

2.3.2 Description of the assessment criteria
Below is a brief description of the criteria required for the comparative assessment of solutions, for each of the criteria
listed in Article 68(1a) of the CAD10 .
Total cost In the context of this document, this is to be understood as the Total Cost of Ownership (TCO) of thesolution, calculated over a time window appropriate to the context of the assessment, including the cost of migration
to another solution (see also paragraph 2.4).
Use of open data formats The use, by the solution to be assessed, of standard and open formats (see Glossary) for the
representation of data, metadata and documents, aimed at ensuring interoperability between the computer systems of
public administrations and/or public service operators.
Use of open interfaces The use, by the solution to be assessed, of open interfaces, including Application Programming
Interfaces (API), i.e. public, documented and freely implementable/extendible interfaces, to ensure interoperability
between the computer systems of public administrations and/or public service operators.
9 https://opensource.org/licenses/alphabetical
10 http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2005-03-07;82!vig

2.3. Comparative assessment

9

Guidelines on the acquisition and reuse of software for public administrations

Use of interoperability standards The adequacy of the solution to be assessed, ensuring interoperability between
computer systems of public administrations and/or public service operators.
Security levels In the context of this document, this refers to the existence of suitable guarantees regarding the security
levels of the solution regardless of the legal nature of the owner of the software and/or the service provider in cloudcomputing mode.
Compliance with data protection legislation This refers to the processes/procedures that comply with data protection
legislation, regardless of the legal nature of the owner of the software and/or the service provider in cloud computingmode.
Service levels of the supplier This refers to the ability of the supplier to provide services in compliance with themetrics previously identified by the public administration in a Service Level Agreement (SLA).

2.3.3 Description of macro-phases
Given the varied nature of the solutions and the difficulty in making uniform quantitative comparisons, such as in
the case of comparing a solution from which certain costs may be derived (an ‘on premises’ proprietary or cloudcomputing solution) with a solution to be implemented from scratch - for which only a feasibility study is available- it was decided to specify a decision-making process through the description of phases and their organisation into
macro-phases.
The following diagram provides the macro-phases that characterise the decision-making process to follow up thecomparative assessment provided for in Article 68 of the CAD.

MACRO FASE 1
Individuazione delle esigenze
MACRO FASE 2
Analisi delle soluzioni a riuso delle PA e delle soluzioni
open source[lettera b), c) dell’art. 68 comma 1]
MACRO FASE 3
Analisi delle altre soluzioni[lettera a), e), f) dell’art. 68 comma 1]
10

MACRO-PHASE 1
Identification of requirements
MACRO-PHASE 2
Analysis of reusable PA solutions and open source solutions[letters (b) and (c) of Article 68(1)]MACRO-PHASE 3
Analysis of other solutions[letters (a), (e) and (f) of Article 68(1)]Chapter 2. Guidelines for acquiring software

Guidelines on the acquisition and reuse of software for public administrations

The macro-phases identified are as follows:
MACRO-PHASE 1: This phase aims to define requirements by specifying the needs and constraints (organisationaland economic) that affect the choices for the identification of a solution appropriate to the requirements of the administration;
MACRO-PHASE 2: In this phase the public administration considers the possibility of satisfying its own requirements by adopting a solution already in use by another administration (hereinafter referred to as a ‘reusable PA solution’) or free software or open source code (hereinafter referred to as ‘open source solutions’).
MACRO-PHASE 3: If macro-phase 2 does not allow the public administration to satisfy its requirements, the satisfaction of the same is pursued through the use of proprietary computer programs, through the use of a licence and/or
from-scratch products.
In the following section, the macro-phases identified are divided into phases, describing the activities to be carried out
in terms of criteria and methodologies to be adopted.

2.4 Macro-phase 1: Identification of requirements
In this macro-phase, the public administration defines the requirements (needs and constraints) that affect the options for the identification of a solution; it is recommended to prepare a document (without any format restrictions)describing the identified requirements to be used in phases that relate to the comparison and assessment of solutions.
MACRO FASE 1
Individuazione delle esigenze
Fase 1.1
Analisi del bisogno
Fase 1.2
Individuazione dei vincoli
Fase 1.3
Definizione delle esigenze
MACRO FASE 2
Analisi delle soluzioni a riuso delle PA e delle soluzioni
open source[lettera b), c) dell’art. 68 comma 1]
MACRO FASE 3
Analisi delle altre soluzioni[lettera a), e), f) dell’art. 68 comma 1]

MACRO-PHASE 1
Identification of requirements
Phase 1.1
Needs analysis
Phase 1.2
Identification of constraints
Phase 1.3
Definition of requirements
MACRO-PHASE 2
Analysis of reusable PA solutions and open source solutions[letters (b) and (c) of Article 68(1)]MACRO-PHASE 3
Analysis of other solutions[letters (a), (e) and (f) of Article 68(1)]2.4.1 Phase 1.1: Needs analysis
The administration defines its own needs for the identification of the software solution. In doing so, it takes into
account that defined in the Acquisition programme and in the Public works planning (Article 21 of Legislative Decree
No 50 of 18 April 2016).
The activities anticipated in this phase are:• an analysis of the context through the description of the characteristics of the administration: purpose, structure
and organisation;• a description of the operational flows involved in the software to be acquired, which the public administration
puts in place as a follow-up to the administrative procedures;• the optimisation assumptions for the flows in relation to the software to be acquired;

2.4. Macro-phase 1: Identification of requirements

11

Guidelines on the acquisition and reuse of software for public administrations

12

Chapter 2. Guidelines for acquiring software

Guidelines on the acquisition and reuse of software for public administrations• identification of the ‘tools’ (definition of objectives) needed to implement the identified operational processes;• declaration of requirements, i.e. the needs to which the software must respond, providing for a differentiation
between indispensable and non-essential requirements.
This phase concludes with the:• identification of the needs of the public administration.

2.4.2 Phase 1.2: Identification of constraints
The administration shall describe the constraints that will affect the supply of the software solution. The activities
anticipated in this phase are:• identification of the budget resources available (hereinafter Tbudget ) to ensure the availability and productionof the solution to be acquired (possible data reclamation and migration from existing systems, installation,customisation, integration with existing systems, training, start-up support, management activities, payment of
any surplus, etc.);• estimate of the time required to implement the solution (hereinafter referred to as Ttime ), which the public
administration can absorb;• any standards and guidelines that the software should follow in its technical implementation, such as for example:– AgID Design guidelines11 (which also includes compliance with Law No 4/2004 on accessibility);– AgID interoperability guidelines;– AgiD guidelines on the development of secure software12 .
• any other constraints of interest of the administration.
This phase concludes with the:• identification of constraints (economic and time-related) that affect the choices of the administration.

2.4.3 Phase 1.3: Drafting of the document describing the requirements
The administration shall draft a document describing its requirements to be used in the subsequent stages of thecomparative assessment.
The activities anticipated in this phase are:• drafting of the document describing the requirements, which shall contain the results of the previous phases 1.1
and 1.2.
This phase concludes with the:• availability of the document describing the requirements.

2.5 Macro-phase 2: Analysis of reusable PA solutions and open
source solutions
The public administration, starting from the availability of ‘reusable PA solutions’ and ‘open source solutions’, mustverify that their requirements have been satisfied with such solutions.
11 https://designers.italia.it/guide/
12 https://www.agid.gov.it/it/sicurezza/cert-pa/linee-guida-sviluppo-del-software-sicuro2.5. Macro-phase 2: Analysis of reusable PA solutions and open source solutions

13

Guidelines on the acquisition and reuse of software for public administrations

14

Chapter 2. Guidelines for acquiring software

Guidelines on the acquisition and reuse of software for public administrations

MACRO FASE 1
Individuazione delle esigenze
MACRO FASE 2
Analisi delle soluzioni a riuso delle PA e delle soluzioni
open source[lettera b), c) dell’art. 68 comma 1]
Fase 2.1
Selezione soluzioni riusabili per la PA
Trovata almeno una soluzione
Fase 2.2
Valutazione soluzioni riusabili per la PA
Trovata una soluzione
Fase 2.3
Approvigionamento della soluzione riusabile per la PA
Fase 2.4
Selezione soluzioni open source
Trovata almeno una soluzione
Fase 2.5
Valutazione soluzioni open source
Trovata una soluzione
Fase 2.6
Approvigionamento della soluzione open source
Fase 2.7
Accertamento impossibilità
SI
NO
MACRO FASE 3
Analisi delle altre soluzioni[lettera a), e), f) dell’art. 68 comma 1]

MACRO-PHASE 1
Identification of requirements
MACRO-PHASE 2
Analysis of reusable PA solutions and open source solutions[letters (b) and (c) of Article 68(1)]Phase 2.1
Selection of reusable solutions for the PA
At least one solution foundPhase 2.2
Assessment of reusable solutions for the PA
One solution foundPhase 2.3
Procurement of the reusable solution for the PA
Phase 2.4
Selection of open source solutions
At least one solution foundPhase 2.5
Assessment of open source solutions
One solution foundPhase 2.6
Procurement of the open source solution
Phase 2.7
Impossibility determination
YES
NO
MACRO-PHASE 3
Analysis of other solutions[letters (a), (e) and (f) of Article 68(1)]In order to rationalise the overall expenditure of public administrations, the verification process to ensure that requirements have been satisfied must first consider ‘reusable PA solutions’ and then ‘open source solutions’.
The implementation of Article 69 of the CAD13 ensures that ‘reusable PA solutions’ make the relative source code
available, complete with documentation, in a public repository under an open licence.
For further information, please refer to 3 Guidelines for software reuse (Article 69) (page ??).

2.5.1 Phase 2.1: Identifying reusable solutions for the PA
The administration identifies the candidate ‘reusable PA solutions’ that meet its requirements. The activities anticipated in this phase are:• a search for ‘reusable PA solutions’ that currently exist within the Developers Italia platform.
This phase concludes with the:• identification of ‘reusable PA solutions’ of interest to the public administration.
13 http://www.normattiva.it/atto/caricaArticolo?art.progressivo=0&art.idArticolo=69&art.versione=4&art.codiceRedazionale=005G0104&art.
dataPubblicazioneGazzetta=2005-05-16&atto.tipoProvvedimento=DECRETOLEGISLATIVO&art.idGruppo=14&a

2.5. Macro-phase 2: Analysis of reusable PA solutions and open source solutions

15

Guidelines on the acquisition and reuse of software for public administrations

2.5.2 Phase 2.2: Assessment of reusable solutions for the PA
Whereas the previous phase 2.1 made it possible to identify at least one ‘reusable PA solution’ of potential interest to
the public administration, through the implementation of this assessment phase the best ‘reusable PA solution’ shallbe identified. Solutions that meet the majority of needs and require modifications or customisation are also eligible atthis stage.
For each of the potential ‘reusable PA solutions’ of interest, steps shall be taken to:• check that at the very least, they conform to the regulations in force, which are detailed on the software data
sheet in Developers Italia. In particular:– compliance with the interoperability rules prescribed by the guidelines issued in implementation of Article 73 of the CAD;
– compliance with data protection regulations;– compliance with minimum levels of security for public administrations.
– compliance with accessibility requirements (Law No 4/2004).
• assess the quality of the solution through the following parameters, some of which can be found on the software
data sheet in Developers Italia:– degree of coverage of functional and non-functional requirements;– the presence of an expert technician for the software in question;– the possible presence of agreements with third parties entered into by the owner administration and usableby the assessing administration, regarding support activities for the installation and/or customisation of
the solution or, in any case, the methods of use for the solution itself (e.g. a regional in-house may makeopen source software available for its municipalities together with an agreement to provide installation andtraining services);– the presence of mandatory constraints and dependencies with other open software and/or proprietary software; for example, open source software may require a licence for a proprietary database, or it may requirea licence for a proprietary API for a cloud service;– the presence and level of competence of the internal resources of the PA, as regards the management ofenvironments and languages used in the solution;– the number and type of other public administrations using the open source project;– the viability of the open source project, through the assessment of visible indicators on the repository, suchas code activity, release history, user community, longevity of the project, number of unique developers.
• estimate the Total Cost of Ownership (S:sub:TCO) as described in 2.7 Total Cost of Ownership (TCO) (page ??),
with particular attention paid to:– any software installation costs in the PA cloud or costs for using the software through SaaS mode, where
present in AgID’s Cloud Marketplace;– any costs for the training of personnel, including those necessary for the training of the parties assigned tothe management of the solution as well as those for its use by the end-users;– any costs required to integrate the solution with its own systems;– any customisation costs, including those necessary to ensure functional and non-functional requirements,
not already present in the reusable software;– any costs for verifying compliance with the regulations in force.
• estimate the time for the production of the solution (hereinafter Stime );• any other estimates expressing the specificity of the administration.
16

Chapter 2. Guidelines for acquiring software

Guidelines on the acquisition and reuse of software for public administrations

In order to follow up on the assessment of the above, the public administration will have to prove that, if not already inits possession, it is capable of retrieving all the necessary information in the manner provided for by the regulations.
Therefore, if:• The cost (TCO) falls within the established budgetary constraints (S:sub:TCO< Tbudget );• Production times are compatible with the estimated times (S:sub:tempi< Ttempi );• Any other impediments are respected.
the administration shall identify the solution best suited to its requirements on the basis of the assessment carried out.
This phase concludes with the:• determination of the best ‘reusable PA solution’, or possible absence of a solution.

2.5.3 Phase 2.3: Procurement of the reusable solution for the PA
If, following the previous phase 2.2, the administration has determined a ‘reusable PA solution’ that meets its requirements, it shall provide for procurement. The reuse process is described in 3.9 Reuse of (page ??)software or use ofopen source software (page ??).
The comparative assessment shall be deemed to be complete.
In the event that the public administration has to bear costs during the procurement phase (e.g. customisation, installation, training), the administration shall acquire these services in accordance with Legislative Decree No 50/2016 andsubsequent amendments and additions. (hereinafter referred to as the Public Contracts Code).

2.5.4 Phase 2.4: Identifying open source solutions
If it is not possible to identify a ‘reusable PA solution’, the administration MUST expand its search for solutions,which meet its requirements, to ‘open source solutions’, i.e. software released under an open licence but not owned
by a public administration and therefore not published for reuse. Solutions that meet the majority of needs and require
modifications or customisation are also eligible at this stage.
The activities anticipated in this phase are:• identification of open source software projects whose ownership is attributed to parties other than public administrations. The identification process must be carried out, at the minimum, with the tools made available on
Developers Italia, and can also be extended to other international platforms that manage open source software
projects.
In identifying a solution, the public administration must verify:• if the software licence is among those suggested in this document or certified by OSI (complete list14 ).
• if the licence is compatible with the software licences that may be integrated with it and/or with its intended use;
This phase concludes with the:• identification of ‘open source solutions’ of interest to the public administration

2.5.5 Phase 2.5: Assessment of open source solutions
If the previous phase 2.4 has led to the identification of at least one ‘open source solution’ of potential interest, thebest ‘open source solution’ for the requirements of the public administration is identified in the assessment phase.
14 https://opensource.org/licenses/alphabetical

2.5. Macro-phase 2: Analysis of reusable PA solutions and open source solutions

17

Guidelines on the acquisition and reuse of software for public administrations

The assessment of open source software in this phase should follow the same assessment criteria as described forphase 2.2. Therefore, consider phase 2.5 as a duplication of phase 2.2, applied to a different set of software (thirdparty open source instead of reusable software).
This phase concludes with the:• determination of the best ‘open source solution’, or possible absence of a solution.

2.5.6 Phase 2.6: Procurement of the open source solution
If, following the previous phase 2.5, the administration has identified an ‘open source solution’ that meets its requirements, it shall proceed with the acquisition. The acquisition process is described in 3.9 Reuse of (page ??)software or
use of open source software (page ??).
The comparative assessment shall be deemed to be complete.
In the event that the public administration has to bear costs during the procurement phase (e.g. customisation, installation, training), the same shall acquire these services in accordance with the Public Contracts Code.

2.5.7 Phase 2.7: Impossibility determination
In the event that it is impossible to identify a solution that satisfies, at least to a large extent, the requirements of theadministration, 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 anticipatedwithin the next macro-phase 3.

2.6 Macro-phase 3: Analysis of other solutions
AAAIn order to satisfy its requirements, the public administration MUST also examine the opportunities offered byproprietary solutions and those built from scratch.

18

Chapter 2. Guidelines for acquiring software

Guidelines on the acquisition and reuse of software for public administrations

2.6. Macro-phase 3: Analysis of other solutions

19

Guidelines on the acquisition and reuse of software for public administrations

MACRO FASE 1
Individuazione delle esigenze
MACRO FASE 2
Analisi delle soluzioni a riuso delle PA e delle soluzioni
open source[lettera b), c) dell’art. 68 comma 1]
MACRO FASE 3
Analisi delle altre soluzioni[lettera a), e), f) dell’art. 68 comma 1]
Fase 3.1
Ricerca soluzioni proprietarie
Fase 3.2
Studio realizzazione ex-novo
Fase 3.3
Comparazione soluzioni proprietarie e realizzazione exnovo
Fase 3.4
Approvigionamento soluzione proprietaria o realizzazione ex-novo

MACRO-PHASE 1
Identification of requirements
MACRO-PHASE 2
Analysis of reusable PA solutions and open source solutions[letters (b) and (c) of Article 68(1)]MACRO-PHASE 3
Analysis of other solutions[letters (a), (e) and (f) of Article 68(1)]Phase 3.1
Identifying proprietary solutions
Phase 3.2
Analysis of from-scratch solutions
Phase 3.3
Comparison of proprietary and from-scratch solutions
Phase 3.4
Procurement of proprietary or from-scratch solution

2.6.1 Phase 3.1: Identifying proprietary solutions
The public administration must assess the proprietary solutions available on the market.
The administration must search for a solution with a proprietary licence, analysing the offerings in accordance with
the Public Contracts Code.
The administration must verify that the licensed software meets the following requirements (i.e. the absence of evenone of these makes the solution ineligible):• compliance with the interoperability rules prescribed by the guidelines issued in implementation of Article 73of the CAD;
• compliance with data protection regulations;• compliance with minimum levels of security for public administrations;• compliance with accessibility requirements (Law No 4/2004);• capacity to export free of charge, at any time, the entire database (including any type of index or metadata used
to implement the functionalities of the software itself) in standard format, open and documented, to avoid theoccurrence of lock-in, as better specified in ANAC guideline No 815 .
Among the software that respects the aforementioned requirements, the administration carries out a comparative analysis that takes into account the following criteria:• assurance that the functional requirements not determined in macro-phase 1 comply with those indicated in the
documentation;• assessment of the suitability of the solution to interoperate with the systems already in use in the administration;• any software installation costs in the PA cloud or costs for using the software through SaaS mode, where present
in AgID’s Cloud Marketplace;• any costs required to integrate the solution with the systems already in use by the administration;• any costs for training personnel to manage and administer the proposed solution;
15 https://www.anticorruzione.it/portal/public/classic/AttivitaAutorita/ContrattiPubblici/LineeGuida/_lineeGuida8

20

Chapter 2. Guidelines for acquiring software

Guidelines on the acquisition and reuse of software for public administrations• calculation of the TCO and its adherence to the available budget determined in the previous macro-phase 1.
This phase concludes with the:• identification of solutions with a proprietary user licence that meet the requirements of the administration.

2.6.2 Phase 3.2: Analysis of from-scratch solutions
The public administration, after having identified the existence or not of a proprietary solution suitable for its requirements, shall prepare a document containing a feasibility study1 with an estimate of the activities, costs and timerequired for the implementation of a solution from scratch that fully meets the requirements indicated in the document
concerning the analysis of needs, as described in 2.4.1 Phase 1.1: Needs analysis (page ??).

2.6.3 Phase 3.3: Comparison of proprietary and from-scratch solutions
In making a decision between the development of a from-scratch solution and the acquisition of a proprietary solution(the so-called ‘make or buy’ assessment), the administration assesses the advantages and disadvantages of both typesof solution, using the following list as a reference point:
Advantages of acquiring a proprietary solution:• quick commissioning;• full guarantee and application risk borne by the supplier;• supplier maintenance;• lower acquisition or subscription costs than full development;
Advantages of developing a from-scratch solution:• full compliance with needs and objectives;• ease of management (importing and exporting) of data;• medium/long-term TCO (Total Cost of Ownership);• sharing of the solution and therefore optimisation of the costs of sustaining it;• extension and updating;• reuse by other administrations.
Disadvantages of a proprietary solution:• periodic licences (monthly, annual subscriptions) or paid version updates;• rigidity of the operative flow or inability to adapt to the operational organisation of the public administration;• possibility of lock-in, i.e. excessive costs of changing the solution in the future;• economic stability of the supplier.
Disadvantages of a from-scratch solution:• more tasks to execute;• greater need for coordination;• longer commissioning times.
1‘Feasibility analysis for the acquisition of ICT
supplies <http://www.agid.gov.it/node/881>‘__

2.6. Macro-phase 3: Analysis of other solutions

21

Guidelines on the acquisition and reuse of software for public administrations

2.6.4 Phase 3.4: Procurement of proprietary or from-scratch solution
Following on from the previous phase 3.3, the administration identifies a solution, either with a proprietary licence ordeveloped from scratch, which meets its requirements and provides for the procurement of the same according to theprocedures set out in the Public Contracts Code.
If the from-scratch solution has been chosen, taking into account paragraphs 1 and 2 of Article 69 that govern the reuseof software that will be developed, please refer to 3.7 Developing software from scratch (page ??) for information on
how to develop this solution to comply with the paragraphs mentioned and thus enable it to be reused.
In the event that proprietary software is acquired under licence, please note that the administration must, where possible, acquire ownership of the developed code (as explained in 1.5 Ownership (page ??)), so as to enable it to bereused.
The comparative assessment shall be deemed to be complete.

2.7 Total Cost of Ownership (TCO)
Economic comparative assessments are carried out using economic/financial instruments such as TCO (Total Cost of
Ownership), which represents the overall cost of an asset during its life cycle. TCO takes into account both direct
and indirect costs, representing the recommended method for measuring total costs (through the identification of all
expenses, in clear and easily measurable terms), as well as for carrying out the above comparative assessment duringphase 3.
To correctly implement TCO, the costs for the entire life cycle of the software must be calculated and not only thoserequired for its acquisition, such as for example:• Costs for the acquisition of hardware and proprietary software licences required for commissioning the software
being acquired;• Costs for software customisation;• Maintenance costs (corrective and upgrading);• Personnel training costs;• Costs of data migration from previous solutions.
In these guidelines, it has been suggested to use TCO in two different phases: during macro-phase 2 (as a tool toestimate the cost of acquiring open source software), and during macro-phase 3 (as a tool to assist in choosing between
a custom-built creation and the acquisition of proprietary software).
In order to comply with these guidelines, the administration is therefore required to make an estimate of the costs
according to the model outlined here during the comparative analysis phase, while always taking account of the overall
life cycle. The accuracy of this analysis is especially important when the required acquisition is substantial.
Providing TCO calculation models for the requirements of administrations goes beyond the objectives of these guidelines, as such requirements are different. AgID may, in the future, publish optional ready-to-use models within theDevelopers Italia platform.

2.8 Choice of software provision method
If the software (reusable, open source or proprietary) is to be installed on a server, the administration may find itself
considering the following provision methods:
1. SaaS mode, if the software is available as a SaaS service in the Cloud Marketplace and is therefore qualified inaccordance with the AgID circular ‘Criteria for the qualification of SaaS services for the PA Cloud’;

22

Chapter 2. Guidelines for acquiring software

Guidelines on the acquisition and reuse of software for public administrations

2. installation on a server with direct availability for the administration.
The choice between these options must be made by calculating the Total Cost of Ownership as described in Section 2.7.
Total Cost of Ownership (TCO).
According to the provisions of Chapter 3 of the Three-Year Plan for IT in the PA, in order to install on an available
server, the administration must use the PA Cloud, choosing one of the following IaaS options:• installation in a PSN (Poli Strategici Nazionali - National Strategic Centres);• installation in a Batch 1 SPC Cloud;• installation in Qualified Cloud Service Providers in accordance with the AgID circular ‘Criteria for the qualification of Cloud Service Providers for the PA’.

2.8. Choice of software provision method

23

Guidelines on the acquisition and reuse of software for public administrations

24

Chapter 2. Guidelines for acquiring software

CHAPTER

3

Guidelines for software reuse (Article 69)

3.1 Introduction and legislative context
Article 69(1) defines the obligation, for public administrations that own software designed to the specifications of
the public client, ‘to make the relevant source code available, complete with documentation and released in a public
repository under an open licence, free of charge for other public administrations or legal entities that intend to adapt
it to their own requirements’.
The new wording of Article 69(2) and (2a), below, stresses the aim of encouraging reuse by taking steps to ensurethat ‘the awarding administration shall always hold all rights to the programs and services of the information andcommunication technologies specifically developed for it’, ‘unless this is excessively onerous for proven technical andeconomic reasons’ and that ‘the source code, the documentation and the relative functional technical description of
all the IT solutions. . . are published through one or more platforms identified by AgID with its own guidelines to be
adopted pursuant to Article 71’.

3.2 Reuse model
The reuse model outlined by the CAD is described in detail below. Each point of the following flow is specified in alater section of this document.
Development phase
1. Administration ‘A’, by carrying out the comparative assessment provided for by Article 68, according to that described in the acquisition section, decides that, to meet its requirements, it must resort to the full implementationof from-scratch software or customise existing open source software.
2. Administration ‘A’ uses its own resources and/or makes use of procurement to develop the software. In the caseof procurement, as required by Article 69(2), the administration guarantees the acquisition of ownership of all
intellectual and industrial property rights over the commissioned software(1.5 Ownership (page ??)).
3. During the course of the software development and/or at its conclusion, the administration publishes the sourcecode of its software under an open licence, on a platform that meets the requirements identified in these guide-25

Guidelines on the acquisition and reuse of software for public administrationslines (3.4.1 Identifying a code hosting tool (page ??)), then registers its release within Developers Italia (3.7
Developing software from scratch (page ??)).
Reuse phase
1. Administration ‘B’, which needs such software, during the comparative assessment phase, finds the software
made available for reuse by administration ‘A’, within Developers Italia (2.5.1 Phase 2.1: Identifying reusable
solutions for the PA (page ??)).
2. The open licence allows administration ‘B’ to acquire and use the software of administration ‘A’ without having
to sign a convention, subject to the terms of the licence.
3. Administration ‘B’ carries out an assessment of the status of the software and its applicability to its own needs(2.5.2 Phase 2.2: Assessment of reusable solutions for the PA (page ??)), including the possible need for customisation.
4. If the software is customised, where possible, such customisation (as developed on the specific instructions ofadministration ‘B’) is also subject to the provisions of Article 69(1), and therefore the relevant source code must
be released under an open licence ( 3.9 Reuse of software or use of open source software (page ??)).
The reuse model through open source software allows for software to be found, assessed and customised without
entering into a convention with the administration that made the software available for reuse, as well the acceptanceof the open source licence that is carried out through a simple download. Furthermore, the software is available online
and therefore no access request is required.
However, it is important to consider that the software may not be ‘ready to use’. The administration may therefore
require technical intervention to install the software, adapt it to its requirements, train staff who will use it, and ensurethat support and maintenance services are available. For all these interventions, the administration may use its own
resources or supplies, since no obligation from this point of view is imposed on the administration that created thesoftware and made it available for reuse.

3.3 Developers Italia and identifying software for reuse
The reuse model outlined above is made possible by AgID’s Developers Italia platform.
Within the platform, there is a section dedicated to software made available for reuse by administrations. In particular:• A ‘search engine’ is available to identify software for reuse. Through this engine, the administration can search
for free software released on the internet by other administrations, using consultation tools made available by
the platform (e.g. filters by type of software, type of administration);• Within Developers Italia, you can ‘register’ the administration software released in open source mode for reuse,so that it can be easily identified by other administrations.

3.4 Process of making software available for reuse under open licence
The process of making software available for reuse is as follows:
1. The administration identifies a code hosting tool. Once the tool has been identified, it can be utilised for all
software that is to be reused (3.4.1 Identifying a code hosting tool (page ??)).
2. The administration chooses an open licence to use (3.5 Open licences and choice of licence (page ??)).
3. The administration, using its own resources or through procurement, publishes the complete source code of
the software and the relevant technical documentation on the code hosting tool. This technological process is
described in Annex A: Guide to publishing software as open source (page ??), attached to these guidelines.
26

Chapter 3. Guidelines for software reuse (Article 69)

Guidelines on the acquisition and reuse of software for public administrations

The guide is written in such a way that it can be attached to a tender technical specification, to facilitate theacquisition of a service by entrusting the supplier with the obligations required by these guidelines.
4. The administration shall ‘register’ the software on the Developers Italia platform, so that it is indexed by thesearch engine and made visible to other administrations looking for reusable software.
The process outlined here is valid for existing software owned by administrations (3.6 Releasing (page ??)existing
software under open licence (page ??)), as well as for software that will be developed in the future (3.7 Developmentof software (page ??)from scratch (page ??)).

3.4.1 Identifying a code hosting tool
The release of software must be carried out through a code hosting tool, which is specialised in hosting and making
distributed software available under an open licence. There are many solutions on the market, both free and commercial.
Since the purpose of Article 69(1) is to encourage reuse between administrations, the tool must follow best practices interms of functionality for the publication of the source code, in order not to create additional costs for administrations
hoping to find and use the software.
In particular, the tool must at least have the following functions:• Free read access to the source code, without authentication;• Free and unobstructed registration, open to the public;• A web interface for viewing and browsing the code and its documentation;• The use of a version control system with the functionality of managing parallel branches of development;• An issue tracker system open to the public for read access without authentication and for write access following
authentication;• Implementation of at least one flow for sending modifications, code review and integration of the modification,
fully managed by the tool, open to the public;• A release management system;• Availability of an API to interface with the tool and extract data and metadata related to the repositories.
To simplify the choice, in Annex A: Guide to publishing software as open source (page ??) there is a non-exhaustive
list of the main platforms on the market that meet the requirements.
Some platforms fully adhering to the minimum parameters are available in SaaS mode (i.e. they can be used directly
via the internet without having to install a copy on a server), without any licence cost and without the need to sign
contracts or conventions; selecting one of these SaaS platforms is therefore to be considered preferential, in the eventthat there are no other technical constraints (e.g. integration requirements), so as not to create direct or indirect costs
for the administration.
The administration must choose a tool (or tools, where justified for organisational purposes) on which to release all
the software it owns. Alternatively, in Annex A: Guide to publishing (page ??)software as open source, (page ??)an
alternative process is outlined that leaves the choice to the party responsible for developing the software and/or releasing it on behalf of the administration (whether this party corresponds to a resource that is internal or external to theadministration).
Once one or more code hosting tools have been selected, the administration must provide adequate visibility of thetools on its web page, as detailed in the same guide (Registration of the (page ??)repository on Developers Italia(page ??)).

3.4. Process of making software available for reuse under open licence27

Guidelines on the acquisition and reuse of software for public administrations

3.4.2 Registration of open software on Developers Italia
Software released by the administration must be ‘registered’ in the search engine of Developers Italia, to facilitate
access by other administrations that are looking for reusable software.
The precise technical process for registration is indicated in the section Registering the repository on(page ??)Developers Italia (page ??).

3.4.3 Responsibilities related to the release
The administration that owns the software does not incur any specific obligation related to the release: it is not necessary to provide a warranty with the software, technical or user level support, nor financially support administrations
that reuse the software as regards costs or adoption procedures.

3.5 Open licences and selecting a licence
To release the software source code under an open licence, the administration must choose appropriate licence text.

3.5.1 Context
It should be noted that the legislator, in drawing up Article 69, has clearly indicated that the objective is to encourage
the reuse of the same software between several administrations. It is therefore important that the first consideration as
regards the importance of the choice of the licence is to assess the impact that the licence text has on the possibilityof reuse by other administrations.
Since the 1980s, the world of computer research and industry has produced numerous examples of licence texts foropen source software, with the aim of creating a global software sharing model. As the complexity of applications
increases, it has become increasingly important to work with ready-made components rather than to start developing
code from scratch each time.

3.5.2 Open software licences
An open licence, as understood in Article 69 of the CAD, is a licence that grants the user of software the following
freedoms:• Freedom to use the software as desired, for any purpose, without additional costs or restrictions;• Freedom to analyse how the software works and to modify it in order to adapt it to your needs;• Freedom to redistribute copies of the software;• Freedom to modify the software and publicly distribute the modified versions.1
Access to the source code, or equally to the format necessary to reproduce and modify the software, is a prerequisite
for respecting these freedoms.
Open Source Initiative2 (OSI) is an international organisation, recognised worldwide for the certification process ofsoftware licences that meet these requirements. An updated list of OSI-certified licences is available at the following
address (in alphabetical order): https://opensource.org/licenses/alphabetical
1

Stallman, The Free software Definition https://www.gnu.org/philosophy/free-sw.it.html
2 https://www.opensource.org/

28

Chapter 3. Guidelines for software reuse (Article 69)

Guidelines on the acquisition and reuse of software for public administrations

Compliance with Article 69 of the CAD, with regard to selecting the licence, must be carried out by choosing a licencefrom those certified by the Open Source Initiative. Alternatively, the administration that wishes to independently
provide for the drafting of text for a licence, may only use this text following certification by the Open Source Initiative,
to verify its adherence with the principles of open software. The process of sending a licence for approval is detailed
at this link: https://opensource.org/approval.
It should be noted that to uniquely identify licence text, SPDX categorisation3 may be used, which associates eachlicence (or combination) with a unique identifier and full name. An updated list of identifiers and their licence texts isavailable at this link: https://spdx.org/licenses/.
Attached to the guidelines (Annex C: Guide to open source licences (page ??)) there is a guide that delves further into
the topic of open source licences, which outlines the categorisation of the main types of licences and their features.

3.5.3 Choosing a licence
A free software licence allows for the free use of the source code to which it refers, while imposing certain constraints
that must be respected. As such, the integration of multiple free software components released under different licences
requires a compatibility analysis of the same. Such an analysis may be overly complex if there are multiple licences
involved, leading to additional costs.
In other words, a proliferation of different licences makes it more difficult and costly to reuse software, contrary
to the objectives outlined in Article 69 of the CAD.
Use of the following decision-making process is recommended for selecting an open licence:• If the software release refers to modifying existing open source software (i.e. software picked-up for reuse byanother administration or owned by third parties), the administration will use the same licence with which thesoftware was originally distributed, to facilitate maximum interoperability and reuse with other users of thesame software;• If it is new software, apart from the exceptions specified below, use the EUPL v1.2 licence (SPDX identifier:
EUPL-1.2): https://spdx.org/licenses/EUPL-1.2.html. This licence, developed by the European Commission,
has been selected as a ‘copyleft’ licence, guaranteeing maximum interoperability at European level, and has also
been translated into Italian. There are only a few exceptions to this general specification:– if the software is mainly used online (e.g. via a browser), use the ‘GNU Affero General Public Licence’ version 3 or above (SPDX identifier: AGPL-3.0-or-later): https://spdx.org/licenses/AGPL-3.
0-or-later.html;
This licence was chosen because, in addition to being compatible with most open source licences, it requires those
who modify the code to release improvements even if it is used as part of a SaaS service.
• if software components with a wide range of applications (e.g. ‘software libraries’ and ‘SDKs’) are being released, use the ‘BSD 3-Clause’ licence (SPDX identifier: BSD-3-Clause) https://spdx.org/licenses/
BSD-3-Clause.html;
This licence has been chosen to ensure that all stakeholders use it as freely as possible, allowing applications to becreated based on such libraries, which can be released under any licence. These types of software components arenormally used to facilitate interoperability with public administrations, and benefit from the emergence of ecosystems
that include third-party applications, including proprietary software.
• For software technical documentation, use the Creative Commons licence CC-BY 4.0 (SPDX identifier:
CC-BY-4.0) https://spdx.org/licenses/CC-BY-4.0.html. This licence was selected because it allows for easy
reuse of documentation and code examples contained therein.
Please refer to Annex A: Guide to publishing software as open source (page ??) for technical details on how to correctly
embed the licence text to the source code at the time of publication.
3 https://spdx.org16
16 https://spdx.org/

3.5. Open licences and selecting a licence29

Guidelines on the acquisition and reuse of software for public administrations

Selected licences have a wide use in the open source ecosystem, therefore the ability to integrate third-party components released with compatible licences is maximised.
An administration that wishes to select a licence differently from that outlined here must justify their reasons, analysing
the compatibility between the licenses adopted and those proposed here, ensuring that the choice does not limit opportunities for reuse and that it does not entail additional costs for administrations in the reuse phase.

3.6 Releasing existing software under open licence
Article 69(1) reads as follows:‘Public administrations that are owners of solutions and computer programs made to the specifications of the publicclient, have the obligation to make the relevant source code available, complete with documentation and released ina public repository under an open licence, for use free of charge for other public administrations or for legal entities
wishing to adapt them to their own requirements, except when there are ‘justified reasons of public order and safety,
national defence and electoral consultations’.
The obligations mentioned here refer to the entire software range on which the rights of an administration are emphasised, with the consequence that, regardless of the requirement to comply with these obligations when concluding new contracts, each administration is required to implement them promptly, including with reference to theexisting software where they own the relevant intellectual and industrial property rights (as indicated in 1.5(page ??)Ownership (page ??)).
Implementing these obligations on existing software is an essential aspect of maximising the effectiveness of theprovision in question and, more generally, of the good practice of reuse, since it allows other administrations to benefit
without delay from the opportunities offered by reuse, avoiding the risk that they will have to reacquire solutions
already belonging to the public information estate and that, therefore, could be used without generating any additional
cost for the community.
Therefore the administration must create an inventory of the software that is already in its possession in order toverify its ownership, and if so proceed to release under open licence.
Given the rapid obsolescence of digital technologies and the importance of encouraging the reuse of available solutions,software that has not been in use by the administration for more than 5 years is deemed to be excluded from the releaseobligation, with reference to the date of publication of these guidelines.
Detailed specifications on how to implement the release are contained in Annex A: Guide to publishing(page ??)software as open source (page ??). If the administration does not have the necessary resources to alignthe document with the standards set out in the guide, the administration must in any case immediately proceed withthe release of what it possesses in its current state, it being understood that the presence of documentation is an essential requirement set out in regulations and it will therefore be necessary to proceed with the completion and alignmentof the documentation as soon as possible in order to consider the obligation completed.

3.7 Development of software from scratch
If the administration, following the comparative assessment proposed in 2. Guidelines for acquiring software(page ??), chooses to develop software from scratch using internal resources or through procurement, it is important to comply with the provisions of Article 69, and in particular:• paragraph 1, which requires release under an open licence to allow for reuse by other administrations;• paragraph 2, which requires the administration to acquire ownership of the software being developed;• paragraph 2a, which confers the choice of platforms for the publication of the source code to these guidelines.
The following sections explore how to comply with the above provisions.

30

Chapter 3. Guidelines for software reuse (Article 69)

Guidelines on the acquisition and reuse of software for public administrations

3.7.1 Releasing new software under open licence
It is important that Article 69(1), which requires release under open licence, is considered from the outset of development and not only at the end of the entire process. The technical requirements for release are described in Annex A:
Guide to publishing software as open source (page ??).
The costs incurred in carrying out the work described in the guide will be significantly lower if the technical specifications described are followed from the outset of development.
In the case of procurement, it is essential that the authorities always include Annex A: Guide to the(page ??)publication of software as open source (page ??) among the tender documents, for example, in an annex to the technical specifications.
Conversely, if the administration were to be late in complying with Article 69(1), using a tender procedure subsequent
to the completion of the former, it would incur additional economic costs.
Therefore, it is recommended to develop the software directly on the selected code hosting tool, from the early stagesof design, without waiting for the preliminary version to implement the release.

3.7.2 Acquisition of ownership of software developed from scratch
As already discussed in 1.5 Ownership (page ??), the administration must ensure full ownership of software createdfrom scratch. Please refer to the aforementioned section for further information.

3.8 Maintenance of software by the owner administration
Software maintenance, whether upgrading or corrective, is an essential process in the life cycle, as it keeps the software updated as regards to rapid technological development, regulatory development and the new requirements of theadministration.
Furthermore, during maintenance, product software updates fall within the scope of Article 69 of the CAD and must
therefore be available for reuse. This section describes the maintenance procedure that we recommend to easily allow
for the reuse of these improvements.

3.8.1 Ownership of the code developed during maintenance
As already discussed in 1.5 Ownership (page ??), the administration must assume full ownership of software developed
from scratch, including any portion developed during a maintenance contract. Please refer to the aforementioned
section for further information.

3.8.2 Release of modifications under open licence
To release modifications to software, it is not possible to use the process previously described in 3.7.1 Releasing new
software under open licence (page ??); in fact, this process, regardless of the extent of the modification, would createa second source code repository separate from the original, creating high costs for any administration that, having
reused the original software, hopes to continue to benefit from its ongoing development.
The proper and cheaper way (both for the owner administration, and for those who hope to reuse the software in the
future) to maintain software under open licence is to adopt a specific development process in which every individualchange is carried out directly in the original repository containing the software, providing immediate evidence of thechange that has occurred.

3.8. Maintenance of software by the owner administration

31

Guidelines on the acquisition and reuse of software for public administrations

Furthermore, it is essential to communicate that the software is in the maintenance phase (by entering this information
during the software registration in Developers Italia), so that other administrations can take this into account in thecomparative assessment phase.
The entire process is described in technical detail in Annex B: Guide to maintaining (page ??)open source software(page ??). In the case of procurement, the administration is required to include the guide among the tender technicaldocuments, for example as an annex to the technical specifications, so that suppliers have immediate evidence of theprocess required.

3.8.3 Support for reusing administrations
Even if there is no guarantee or technical or training support obligation on the part of the owner administration towards
administrations that reuse the software, where the software is subject to upgrading maintenance, it is essential that theinternal resources or companies in charge of such maintenance provide basic support to those who report specificissues, or who wish to make (at their own expense) changes to the software.
In fact, the reuse model, allows for multiple administrations to invest in the same software, each with its own budget,
therefore incrementally adding to the value of the original software. However, for this process to work correctly, asa minimum, a technical coordination process between the public administration that maintains the software and theadministration that intends to modify it is desirable. Furthermore, this provides an opportunity to share development
plans and therefore investments between multiple administrations as regards the same software, with savings for publicfinancing.
This process of supporting software modifications is also detailed in the same guide Annex B: Guide (page ??)tomaintaining open source software (page ??).

3.8.4 Software not yet released under open licence
If the administration initiates a process of maintenance for software that it already owns, but for which it has not yet
released under an open licence, adding its initial release to the maintenance contract must be considered, because of
the lower cost that is normally incurred compared to carrying it out separately.

3.9 Reuse of software or use of open source software
The second chapter of these guidelines, dedicated to Article 68, outlines the process by which the administration
decides how to identify software.
If the administration, following the proposed comparative assessment, chooses to reuse existing software or to use
open source software, the process used is described in this section, and is the same in both cases.

3.9.1 Use of reusable or open source software
In general, it is not necessary to obtain authorisation from the owner of the rights to the software; in fact, thereuse model outlined for the use of open licences, allows for the adoption of software without the need to enter into
any convention or to make a request for access: software published as described in 3.6 Releasing existing software
under open licence (page ??), is immediately available for a requirements compatibility analysis, for customisationand for use.
As explained in 3.8.3 Support for reusing administrations (page ??), it is advisable to contact the current person in
charge of software maintenance, to agree, in a technical sense, how to carry out the required modifications in the mosteffective way and coordinate economic efforts.

32

Chapter 3. Guidelines for software reuse (Article 69)

Guidelines on the acquisition and reuse of software for public administrations

3.9.2 Modifications to reusable or open source software
From a regulatory point of view, modifications or customisations to software under open licence are subject to Article 69(2) and therefore must be implemented by acquiring full ownership of the code developed. However, the reuseof software without any modifications, does not constitute an obligation to release.
From the point of view of acquisition of ownership, the fact that the software being modified is not the property of
the administration making the modification does not exempt the latter from the obligation to acquire ownership of themodifications developed. Please refer to 1.5 Ownership (page ??).
Conversely, at a technical level, the process for making changes is different from the maintenance process described in
3.8 Maintenance of software by the owner administration (page ??), since the interventions will take place on softwarethat is not fully owned and therefore technical coordination is desirable, which was previously described in relation toopportunities and benefits in 3.8.3 Support for reusing administrations (page ??).
The technical process is detailed in Annex D: Guide to reusing open source software (page ??). In the case of procurement, the administration is required to include the guide among the tender technical documents, for example as anannex to the technical specifications, so that suppliers have immediate evidence of the process required.

3.9. Reuse of software or use of open source software

33