Workshop: Legal aspects of free
and open source software
____________________________________________________________________________________________
57
potential tenderers"
94
. As a result of this, it is not possible to refer, for instance, to "Intel or
equivalent" microprocessors in public tenders.
3.2.3
Business / service model
The needs of the IT architecture and the organisation determine the best form in which an
IT solution should be structured, and this includes how it should be paid and accounted for.
As a result, certain business models and service models are naturally better fit for a given
set of requirements that are determined and defined by a public agency prior to
procurement.
This is not, in fact, drastically different from other areas of procurement. A public authority
may decide that it wishes to buy a car,
or lease it; to commission the construction of a
bridge for a fixed fee, or on a build-operate-transfer model.
All these choices involve discrimination between business models, and a preference for
some business models over others - simply because a defined set of requirements is better
(or only) met by businesses adopting one business model rather than another. Businesses
that use a business model that cannot meet the needs of the public agency will naturally
lose out. Leasing companies will lose out if an agency's needs are best met by buying
rather than leasing cars. This is not against the principles of equal treatment and non-
discrimination. However, favouring a particular
business (a vendor), instead of a
business
model, goes against the principles of equal treatment and non-discrimination. Defining
procurement requirements based on particular needs is, however,
fully in line with the
principles of equal treatment and non-discrimination - even if those needs can only be met
by certain business models.
Similarly, when it comes to IT, public authorities are free to choose solutions – and
business models - that suit their needs, as long as their needs are clearly justified. Often,
such choice - and discrimination - is made by default. For instance, a call for tenders for the
purchase of software licences "discriminates" against businesses that do not offer software
in the form of a product paid for at the time of purchase through licensing. A call for
tenders for software that can be modified, adapted and redistributed by the procuring
agency (such software may well meet the open source definition) "discriminates" against
businesses who only work on a model based on proprietary control and licensing software
for a specified number of users or computers. Of course,
businesses may use many
different models and are free to adapt their business models to better meet customers'
needs. There is no obligation on the part of a public body to adapt its requirements to the
preferred business models of particular firms.
3.2.4 Open
standards
Open standards in the acquisition of IT may be preferred, or required by policy. With or
without an explicit policy at European or national level, open standards may also be
preferred or required by policies specific to regions or to particular categories of
procurement.
Open standards may take the form of a functional requirement: e.g. it may be an essential
function of a new web-based eGovernment service that all citizens have the ability to fully
interact with it, without preference to customers of specific software or hardware vendors.
Open standards may take the form of technical requirements, for instance when specific
open standards are already in use and new acquisitions must work with them.
Open standards may also take the form of requirements that affect business models: e.g.,
a public authority wishes to have the full freedom to use in perpetuity the data files it
creates with new software applications, without being tied to the vendor of that software. It
is worth reiterating here the distinction between open standards and open source software.
Open standards can be implemented equally well by open source software and proprietary
software – and many proprietary software applications implement many open standards.
94 European Commission release reference IP/06/443 dated 4 April 2006; this is also a
reference to Directive
2004/18/EC, Article 23.
Policy Department C: Citizens' Rights and Constitutional Affairs
____________________________________________________________________________________________
58
For the purpose of this briefing paper, the main property of open standards is that the
associated intellectual property rights (patents, copyright) are licensed in such a way as to
make open source implementations possible.
3.2.5 Open
source
As stated previously, there is no EU-wide policy on the procurement of open source
software. There are several principles of the functioning of public authorities which may
justify the requirement of open source software. The acquisition of open source software
can be made on the basis of such justification; a general requirement in a call for tenders
for software solutions to be "open source" is not advisable (just as a requirement for
“proprietary software” or a brand name would not be advisable)
without further details or
justification.
As with open standards, open source software can be justified in terms of functional,
technical and business model requirements, such as the need to avoid dependence on a
single vendor, a need to pay for services rather than license fees, etc. The examples
provided above for open standards can to some extent apply as well to open source.
Further justifications specific to open source are described below.
As a functional requirement, a public authority may wish to ensure the transparency of
government processes. Many of these processes - e.g. for voting systems - are
implemented in software, and the only way to ensure its transparency may
be to require
that the source code be visible for public inspection.
As a technical requirement, a public authority may wish to be able to modify the software
(or have any third party of its choice modify it) in the future, in order to work with other
software, or have the software adapted to future needs.
As a business requirement, a public authority may wish to be able to distribute the software
internally or to other businesses, individuals or agencies with which it interacts, with no
additional cost based on the number of users. A public authority may even wish to be able
to make adaptations to the software before doing so (or have any third party of its choice
make such adaptations). Such requirements, if justified, are perfectly legitimate, and may
be effectively requirements for open source software.
In case software redistribution is a requirement, the public
authority should determine
whether or not it wishes to allow a third party to appropriate the software, i.e. to modify
and redistribute it, as if it was proprietary. This will determine the type of licence that
should be used in case of redistribution: permissive (in case it is determined that
modifications of the software may be made proprietary) or reciprocal (in case it is
determined that any redistribution of the software by third parties must remain modifiable
and redistributable: this is typically called a “copyleft” license and examples include the GPL
and the European Commission’s own EUPL).
Finally, especially in case the public authority wishes to distribute the software to other
authorities, business or citizens, a legitimate requirement is to
protect the administration
from liability, support and warranty obligations relating to redistributed versions of the
software.
The above requirements related to redistribution help determine the licence that will be
used for this redistribution. As discussed in the later section on ”Defining requirements”, an
early determination of this licence (or of a range of authorised licences) is important.
3.3
Examining costs and benefits
Public sector organisations need to keep the public interest in mind, and for procurement
this means that public funds should be spent in as cost-effective a way as possible. Freed
from the obligation of the short term financial cycles of the private sector, public
organisations are also obliged to maximise cost-effectiveness over the very long term.
However, with limited, short-term budget cycles, they need to find a good balance between
limiting the initial investments
and limiting the overall, long term cost.