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
Dostları ilə paylaş: |