Constitutional affairs legal affairs

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.  

---