Constitutional affairs legal affairs

Workshop: Legal aspects of free and open source software 
____________________________________________________________________________________________ 
 
63
4.1.3 Repositories 
Open source software is actually downloaded from repositories of software, or via 
catalogues. Communities of practice can often be found attached to such repositories.  
4.2 
Identifying and selecting software 
When a number of open source software applications appear to meet an organisation's 
needs, an evaluation and selection can be performed. This could, first, act as a filter for 
general reliability and quality as described above, including by taking into consideration 
issues such as maturity, size of the community, availability of commercial support from 
various sources, etc. And finally, the selection of the software is based on its matching the 
previously defined functional requirements.  
Functional requirements can be matched to the software documentation - website, software 
manual, etc. Open source software can simply be downloaded and tested - without 
deployment, or in pilot deployments - to examine the extent to which it meets functional 
requirements
96
. 
Finally, an analysis may be performed of the costs of meeting the functional requirements 
with the open source software. The solution that is the most cost-effective may be chosen - 
considering all the various criteria discussed above. If the solutions identified through this 
process are unsuitable, the procedure of acquisition through downloading can be 
abandoned, and replaced with a call for tenders for purchasing open source software as 
described in the next section. 
4.3 
Tenders for evaluation, support, customisation, services 
Downloading software free of charge does not mean there will be no associated costs. 
While in some cases it may be possible for a public agency to provide all the support for a 
particular software application in-house, it will often make sense to contract this out. This 
will naturally require a call for tenders. 
To begin with, the process of identification, evaluation and selection of software to 
download does not have to be performed (entirely) in-house at the public agency. 
Depending on skills and resources available, it could be useful to have a public contract for 
some of these tasks. A condition in such calls for tenders may, if justified, exclude the 
winning bidder from further contracts (such as for services, support) related to the software 
selected with their assistance, to prevent a conflict of interest and ensure their role as an 
honest evaluator of open source download choices
97
. Of course, a new tender is not 
required for every case of software selection. This assistance for evaluation and selection 
could also be performed by a firm with a pre-existing contract for such on-going 
consultancy services. 
When a final selection has been made for the choice of software to be downloaded, with or 
without the assistance of a contractor, the software has to be installed, maintained, and 
supported. Note that downloading software with no contractual arrangements is free of 
charge, but also means that the software usually comes with minimal warranties. In fact, 
this is true also for much proprietary software, especially "off-the-shelf" software, where, 
although many users assume large vendors bear some responsibility for their software, in 
fact, software licences typically disclaim warranties. As with proprietary software, entering 
into a service or quality assurance contract of some sort is the main method for a public 
agency to share some of the responsibility for its use of open source software. 
The software may be customised - the ability to be customised extensively is a key 
advantage of open source software, and customisation may be one reason why open source 
                                                 
96 Of course, proprietary software can also be included in pilot deployments, although if this involves expenditure 
it may require a formal procurement procedures. 
97 An automatic exclusion, according to the case law of the European Court of Justice C-21/03 Fabricom, 
contravenes the EC Public Procurement directive and such exclusion should be operated only on a case-by-case 
basis, with bidders “given the opportunity to prove that, in the circumstances of the case, the experience which he 
has acquired [through the execution of a previous contract such as the selection of technologies or software 
applications] was not capable of distorting competition” 

---

Policy Department C: Citizens' Rights and Constitutional Affairs 
____________________________________________________________________________________________ 
 
64
was selected by the public agency in the first place. For customising public sector software, 
a paid contractor will usually have to be selected.  
For all such additional services, open, competitive calls for tenders should be used to select 
suppliers. In order to foster the developer community around the selected software, it may 
be useful to introduce as a criterion in such tenders the level of interaction and contribution 
the tenderer has within the appropriate community. This can be evaluated through 
objective metrics such as: the number of posts the vendor (or employees) makes to 
community online forums; the number of software bug reports filed, bug fixes submitted, 
or code contributions; the sponsorship and participation of events related to the specific 
software community such as conferences, workshops, hackathons, etc. 
A key property of open source software is that anyone can provide support or other 
services, depending on their skills. The market is thus fully competitive. No proprietary 
control or advantage rests with an "owner" or "sponsor", or their dealers and agents. In a 
call for tender placed for the purchase of specific proprietary software or related services - 
which works against a competitive market and may violate procurement regulations - only 
the proprietor itself, or dealers who are necessarily dependent on the proprietor, can bid. In 
a call for tenders placed for the purchase of services related to a specific open source 
software system, any independent supplier can bid. In fact, this distinction is similar to the 
difference that one can find between a tender for the supply of Peugeot cars or services for 
Peugeot cars (for which only firms dependent on Peugeot can bid), and a tender for fuel 
and tyre service for a car (for which anyone with no ties to a particular car company can 
bid). 
 
5 PURCHASING OPEN SOURCE SOFTWARE  
Recommended best practice procurement is based on the definition of functional 
requirements - which may include properties that are equivalent to the characteristics of 
open source software, or the characteristics of open standards. 
5.1 Defining 
requirements 
Calls for tenders for open source software - like all calls for tenders - should be based on 
functional requirements, not on specific products or vendors. Properties of open standards 
or open source software may be part of these requirements - either as minimum 
requirements, or as properties that will be favoured. 
5.1.1 Functional 
requirements 
The author recommends that the tender specify the function of the software in detail, to 
ensure transparency and objectivity in the procurement process. The purpose of the 
software to be acquired and its essential attributes should be described in a vendor-neutral 
manner. This is a general principle of public procurement; the author focuses here on the 
additional functional requirements relating to the open source nature of the software, and 
open standards. 
5.1.2 Open 
standards 
Provided that this is justifiable due to the interoperability needs of the procuring agency, 
open standards can be required just as any standards. Open standards can be required 
either by referring to the open standards by name, or by referring to an official list of open 
standards. However, if no definition of open standards has been adopted or is applicable to 
the procuring public agency, nor any officially approved list of open standards can be cited, 
the standard may have to be defined in terms of functional specifications. The functional 
properties of “openness”, as described below, could be included among the tender 
specifications. This way, the openness of standards can be specified as a preference 
(through the weight given to it in the award criteria), or a requirement (by making it a 
mandatory in the specifications).  

---