Workshop: Legal aspects of free
and open source software
____________________________________________________________________________________________
51
This briefing paper shows how open source software can even be downloaded free of
charge without a call for tenders, and provides criteria that can be included in tenders to
ensure good practice procurement of software.
Public procurement of software has long been far from a "level playing field", and
widespread preferences in public tenders for specific, named, proprietary software and their
vendors is one justification of why this paper is useful.
This briefing paper examines the following areas:
Software public procurement landscape
Software public procurement needs & principles
How open source can be a functional requirement
Downloading software vs procurement through tenders
How open source functional requirements translate
to tender requirements
This briefing paper is about procurement of software, but it should be noted that one of the
properties of open source is that it promotes collaboration and participation, rather than
just consumption through public procurement. The EU's own Open Source Observatory
(now available on the JoinUp portal at joinup.ec.europa.eu) provides a platform for open
source software collaboration among public agencies in Europe.
1 INTRODUCTION
1.1
Software public procurement landscape
At the European level, there are no binding policies on open source software procurement,
although there are some at the level of Member States or regions. The
guidelines described
in this briefing paper are applicable in any context within EU Member states, regardless of
the existence of any policy, following European procurement regulations alone, with no
need for any specific open source policies.
Anti-discrimination (“equal treatment”) is a general principle of procurement regulations,
but this refers to equal treatment of potential economic operators: vendors of solutions
meeting tender requirements. It does not refer to technical standards, or licensing
regulations for software – i.e. it is possible to specify particular licensing requirements
(such as open source licensing) when that is required and justified for the purposes of a
tender.
Previous
studies
80
provide evidence which suggests that in public procurement of ICT,
practices that “
do not constitute an equal treatment of all economic operators”
81
are
apparent in tenders on more than an “exceptional basis”, as required by EU law
82
. In
particular, these studies have pointed out the frequency of mentioning the names of
specific companies and their products, or to require compatibility with previously purchased
proprietary ICT products.
In one study, a keyword search for tenders on TED, the EU’s public procurement tool,
showed that 149 tenders included brand names.
83
Another similar sampling on a larger
80 Cf. OpenForum Europe (2008). OFE Monitoring Report: Discrimination in Public
Procurement Procedures for
Computer Software in the Member States. Brussels: OFE.; Ghosh, R.A. (2005). An Economic Basis for Open
Standards. FLOSSPOLS project. Brussels: European Commission.; Ghosh, R.A., Glott, R., Schmitz, P., Boujraf, A.
(2008). OSOR Guidelines public procurement and Open source Software. Public Draft Version. Brussels:
European
Communities.
81 European Union (2011). Guidelines for public procurement of ICT goods and services - SMART 2011/0044.
Tender
Specifications. Brussels: European Union.
82 Reference to specific products or sources is allowed on
"an exceptional basis, where a sufficiently precise and
intelligible description of the subject-matter of the contract [in functional terms or with reference to European
standards] is not possible", Directive 2004/18/EC, Article 23(8).
83 Ghosh, R.A. (2005). An Economic Basis for Open Standards. FLOSSPOLS project. Brussels: European
Commission.
Policy Department C: Citizens' Rights and Constitutional Affairs
____________________________________________________________________________________________
52
scale, published on OSOR
84
“
showed that 567 of 3615 software tenders (16%) between 4
January 2006 and 30 August 2008 contained one or more of the top 10 software brands”
85
.
In addition, the study cited showed that the top company in
the list was clearly dominant,
with a 36.1% share of those tenders that did specify brand names (the second company
was mentioned in 20.2% of the tenders)
86
.
The European Commission, in a call for tenders for a study, quoted these figures to note
that such practice “doesn’t constitute an equal treatment of all economic operators who
could potentially deliver the product or service that is asked for. Therefore it is allowed only
exceptionally. 16% of the cases seem to imply more than an exceptional use of brand
names”
87
. Such procurement practice can stem from several reasons. As previous research
on public procurement of software in European national administrations has shown, it can
be based on a conscious decision to favour compatibility of newly
purchased software with
proprietary systems that were previously in use
88
. It can also be based on lack of
awareness and knowledge of how to adhere to practices in public procurement of ICT that
are in line with the European regulatory framework.
89
1.2 Public sector needs: transparency, sustainability, cost-
effectiveness
Public sector consumers of software have an obligation to support interoperability,
transparency and flexibility, as well as economical use of public funds. When it comes to
public procurement, the principles applied to the public sector require them to support (and
certainly not to harm) competition through their procurement practices.
They are also obliged to avoid explicitly harming competition in the market of private
consumers. Thus, public agencies should not require citizens
to purchase or use systems
from specific vendors in order to access public services, as this is equivalent to granting
such vendors a state-sanctioned monopoly.
They are also obliged to ensure the best cost-to-service ratio over the long term.
These principles are not only the basis for policy documents such as the
European
Interoperability Framework; they are also implied by the legislative framework governing
public procurement, such as Directive 2004/18/EC on public supply contracts and Directive
2004/17/EC on utilities, and Directive 98/34/EC on the provision of information in the field
of technical standards and regulations
90
.
2 PROCUREMENT PRINCIPLES
2.1 Open
Standards
Good practice eGovernment services should provide access based on open standards –
defined below - see section 0– as standards that are
implementable by all potential
providers of equivalent technologies, including open source software. In particular,
government should never require citizens to purchase or use systems from specific vendors
in order to access public services: as described above, such a requirement would be
equivalent to granting those vendors a state-sanctioned monopoly.
84 Ghosh, R.A., Glott, R., Schmitz, P., Boujraf, A. (2008). OSOR Guidelines public procurement and Open source
Software. Public Draft Version. Brussels: European Communities.
85 European Union (2011). Guidelines for public procurement of ICT goods and services - SMART 2011/0044.
Tender
Specifications. Brussels: European Union.
86
Supra note 84
87
Supra note 81
88
See supra note 83
. Naming brands or vendors is not the only way to favour specific vendors; the European
Commission previously noted that hardware procurement discriminated in favour of Intel by mentioning specific
processor clock rates without explicitly naming “Intel”. EC Press release IP/04/1210, October 13, 2004
89 Ghosh, R.A., Glott, R., Schmitz, P., Boujraf, A. (2010). Guideline on public procurement of Open Source
Software. Brussels: European Commission.
90 These were specifically referred to by the EC in its announcement regarding the investigation on public
procurement of computers, concerning tenders specifying “Intel or equivalent”. EC Press release IP/04/1210,
October 13, 2004.