Constitutional affairs legal affairs

Workshop: Legal aspects of free and open source software 
____________________________________________________________________________________________ 
 
55
2.5 
“Level playing field” or open software? 
Current common public procurement practices for software are frequently biased in favour 
of specific proprietary software vendors. European procurement law may allow for such bias 
under specific, exceptionally justified situations. However, in practice, neither is this bias 
exceptional, nor is justification commonly provided.  
The scope of this briefing paper is the procurement of open source software. However, 
many of the principles and methods described in this briefing paper for the procurement of 
software – whether based on open source or open standards – can be used simply to 
ensure that procurement of software takes place in a fair environment. 
As will be explained in the respective sections below, any software procurement should be 
based on a clear definition of IT architecture, unbiased definition of requirements in 
functional rather than vendor- or brand-based terms and a complete rather than narrow 
and short-term estimation of costs and benefits. In addition, the methods described for 
procuring software based on open standards may well be relevant for software in general, 
justified by cost concerns. 
Software acquired after such a process and with such justification may well be proprietary, 
and will in that case have been properly acquired. Software acquired without such a 
process may well have been acquired improperly and in a biased fashion; if it provides 
explicit preference for particular vendors, without justification of exceptional circumstances, 
such acquisition may even be in violation of public procurement regulations. 
 
3  DETERMINING ACQUISITION NEEDS 
Public procurement is based on determining needs, identifying the IT architecture in which 
these must be implemented, translating these into requirements and evaluating available 
options through the procurement process.  
Interestingly, the acquisition of open source software does not necessarily require the use 
of the public procurement process (i.e. tenders), as purchases of proprietary software and 
services do. This special case is also discussed below. 
3.1 Defining 
IT 
architecture 
Public sector organisations have architectures that may differ in some respects from private 
organisations due to differences in their essential goals or principles. Saving costs is a 
principle that may be common to public and private organisations. Public organisations may 
differ in that they are obliged to save costs over the very long term - as they are using 
taxpayer funds and do not need to respond to short term business cycles. However, public 
organisations often have constraints in the form of budgets that are set for relatively short 
terms, and therefore still need to balance the short-term and long-term cost savings. 
Similarly, transparency is a particularly important principle for public organisations. 
The IT architecture needs of public sector organisations are strongly linked to 
interoperability and open standards. As noted in the European Commission White Paper on 
ICT Standardisation,
93
 “[p]ublic authorities need to be able to define their ICT strategies 
and architectures, including interoperability between organisations, and will procure ICT 
systems/services and products or components thereof, that meet their requirements.”  
Public authorities do not function in a vacuum, and have particularly strong requirements 
for the interchange of data: between different departments, different organisations, 
different levels of government – and stakeholders such as businesses and citizens. Public 
organisations also have obligations towards building sustainable and transparent systems.  
                                                 
93 European Commission, 2009. “White Paper on Modernising ICT Standardisation in the EU - The Way Forward”. 
COM(2009) 324 

---

Policy Department C: Citizens' Rights and Constitutional Affairs 
____________________________________________________________________________________________ 
 
56
Interoperability arrangements, when translated into requirements for an IT architecture, 
justify technical specifications based on open standards. The need to exchange certain data 
without barriers between citizens and the government, for example, is formalized into a 
requirement for transparency of those data. This requires transparency in the IT 
architecture for processes and systems concerned with those data. From this architectural 
need follows, in terms of technical specifications, the justification for open interoperability 
standards. 
3.2 Determining 
requirements 
Best practice IT procurement is based on defining clear requirements and finding the best 
match to them. While procurement processes such as calls for tenders, in practice, often 
ignore this principle to simply specify particular products or even vendors, this is not good 
practice and may violate procurement regulations. It also makes it more difficult to 
demonstrate the rationale behind any subsequent acquisition choices. 
Requirements can come in a number of forms, which are briefly described below. These are 
not in any way official categories but are only listed for illustrative purposes. 
3.2.1 Functional 
Functional requirements describe the purpose for which the IT solution is needed, and the 
functionality which it is expected to provide. A clear description of functional requirements 
is essential in order to ensure that procurement follows the principles of transparency and 
independence, and is pro-competitive and cost effective in the long term. An example of 
functional requirements would be a detailed description of the functionality that a system 
for, e.g., maintaining property records is expected to have. Functional requirements should 
not be defined in IT terms alone, but take in to account the needs to be addressed in the 
problem domain. 
3.2.2 Technical 
Technical requirements may also be important, if there are specific constraints or needs 
regarding the IT architecture and technologies with which the solution must fit. It should be 
noted that compatibility with previously purchased IT solutions may seem like a very valid 
technical requirement, but can also be a way of perpetuating the consequences of previous 
purchasing decisions, perpetuating vendor lock-in and preventing an unbiased procurement 
based on real organisational needs. Requirements for compatibility with open standards 
and no proprietary elements, i.e. full compatibility across multiple vendors and producers, 
increase the freedom of future procurement choices. When compatibility with a previously 
purchased system requires compatibility with proprietary technologies, it can work against 
the notion of interoperability across vendors and producers. Such interoperability is 
essential for the sustainability and long-term cost-effectiveness of software, as already 
explained above.  
In essence, compatibility criteria, when tied to previously purchased proprietary solutions, 
lock the buyer into that solution indefinitely, making its vendor's one-time win in a single 
contract a win for a much longer period of future procurements. Since a key principle of 
public procurement is that a purchase should not have consequences or limit the choice of 
the buyer after the originally planned lifetime for that purchase, perpetuating such lock-in 
is a poor procurement practice. 
In particular, the effect of previous procurement restricting the choice in future 
procurement should never last beyond the period foreseen in the original procurement – if 
a tender was initially for 3 years, the same tender should not result in limiting the choices 
of a future tender. Such long-term lock-in considerations are often not made in the 
procurement process, resulting in many tenders calling for branded software from named 
vendors. 
The European Commission itself has reiterated  that  "[under]  the  EU public procurement 
rules, contracting authorities may refer to a brand name to describe a product only when 
there are no other possible descriptions that are both sufficiently precise and intelligible to 

---