Constitutional affairs legal affairs

Workshop: Legal aspects of free and open source software 
____________________________________________________________________________________________ 
 
65
Including open standards requirements or preferences in tender requirements is 
straightforward: the properties of open standards could be described, together with a 
justification, if required. Since the justification is part of the essential needs as determined 
by the public agency, a specific definition of the term 'open standards' is, while useful, less 
important. For software applications, the needs of a public agency may typically require 
that: 

 
the standard is implementable by all potential providers of equivalent technologies, 
ensuring sustainability and full competition with no advantages for some players 
based on patent or copyright royalties or restricted availability of the technical 
specifications; in addition, the standard should not discriminate against open source 
software solutions
98
. 

 
the development of the standard is open and transparent, so that the public agency 
is not dependent on one party for the future of the standard, and may even 
influence its further development 

 
no restriction on re-use, so that the public agency can be certain that other public or 
private organisations can use the standard, and so that the use of the standard in 
open source solutions - which are often not compatible with re-use restrictions - is 
possible. 
Note that these typical public agency needs can be met by standards that fulfil several 
published open standards definitions. 
5.1.3 Open 
source 
As mentioned at the start of this section, it is not good practice to simply state that 
software should be "open source". Rather, the properties of open source software should be 
described and justified.  
Open source is not part of the technical nature of the software; it applies to the conditions 
under which the software is provided. Thus, the desired properties of open source could be 
included in the form of mandatory requirements in the description of the subject matter of 
the contract, or in the contract documents (cahier de charges). Open source can be 
included as a preference rather than a mandatory requirement including open source 
requirements as award criteria. 
Including open source requirements is straightforward: the properties of open source could 
be described, together with a justification, if necessary. The needs of a public agency may 
typically require that: 

 
the ownership of the software is transferred to the public agency, with no 
restrictions on what the agency can do with the software; OR:
99
 

 
the software may be used for any purpose, as the public agency does not want to be 
restricted in how it can use (or allow others to use) the software; 

 
the public agency or a third party of its choice may study the source code, as the 
public agency wants to be sure of the functioning of the software; alternatively, the 
public agency may require that any member of the public can study the source 
code, in order to promote transparency of government processes, or enable other 
parties to provide support and training associated with the software; 

 
the public agency or a third party of its choice may modify the software, as the 
public agency does not wish to be dependent on the original vendor for bug-fixes, 
adaptations and other modifications; 
 
                                                 
98 The open source non-discrimination requirement is included in the draft version 2.0 of the European 
Interoperability Framework. 
99 Note that some of the requirements  below may be met by proprietary software under specific licensing terms, 
but if all of these requirements are met, the software is by definition open source. 

---

Policy Department C: Citizens' Rights and Constitutional Affairs 
____________________________________________________________________________________________ 
 
66

 
the public agency can distribute the software, with source code and modifications, to 
anyone of its choice and provide recipients with the same abilities to use, study, 
modify and redistribute, because the public agency needs to ensure that citizens and 
firms and other agencies that access its services using the software or variants of 
the software do not need to become customers of the original vendor in order to do 
so; for example, a national administration may wish to be able to pass on the 
software, without extra costs, to other administrations at the local, regional, 
national or European levels. 
When supported by an official policy at European, national or local level, such requirements 
may not need explicit justification in each tender. Even if there is no official policy, such 
criteria need only to be justifiable - i.e. if questions are raised - rather than justified in each 
tender. But there is no harm providing explicit justification and references, and it is always 
a good practice to (briefly) explain why certain criteria are present. For instance, the 
explanation for the Dutch government's preference for open source software is the 
"promotion of a level playing field in the software market and promotion of innovation and 
the economy". 
5.1.4 
Open source for redistribution 
When procuring software for the purpose of potential redistribution it is important to clarify 
specific redistribution conditions for the component being procured, to ensure that the 
public authority does not face licensing difficulties combining that component with other, 
separately acquired software, for further redistribution.  
To address such cases, Spain has adopted Royal Decree 4/2010 implementing the National 
Interoperability Framework planned in the eGovernment Law of 11/2007.
100
 According to 
RD Article 16.1, the licensing conditions of applications owned by Public Administrations 
that can be made available for other Public Administrations or for the citizens, must: 

 
allow the free use/reuse of these applications; 

 
exclude the software appropriation by a third party;  

 
protect the administration from liability, support and warranty obligations. 
Therefore, if the distribution is decided, it must be under open source conditions (combined 
with strong “copyleft” conditions for avoiding the exclusive appropriation that would happen 
if the software could become proprietary). 
This means that, by default (and by choice, when it is appropriate), the Spanish 
administration will distribute its software under the terms of the European Union Public 
Licence (the OSI approved licence which has the same value in 22 European languages)
101
.  
5.2 Other 
requirements 
In addition to technical, functional requirements and the non-technical properties of open 
source and open standards, calls for tender typically contain also other criteria for awards 
and for determining the eligibility of bidders.  
One property of open source software that distinguishes it from proprietary software is that 
small, innovative companies, limited only by their skills and abilities rather than their 
dependence on the software proprietor, can provide it on an equal basis. However, small 
companies may have difficulties meeting stringent eligibility criteria with regard to financial 
sustainability.  
                                                 
100 The Royal Decree (text in Spanish) is published at: 
http://www.csae.mpr.es/csi/pg5e41_ingles.html
. On 
ePractice see the presentation and comments from Miguel A. Amutio (in English) 
http://www.epractice.eu/en/cases/eni
 and comments from P-E. Schmitz on OSOR 
http://www.osor.eu/communities/eupl/blog/impact-of-the-spanish-royal-decree-4-2010-of-8-january-2010-1
. 
101 Similar provisions can be found in other recent policies in Member States, such as the 1 June 2010 directive of 
the Government of Malta enabling, where appropriate, the distribution of its public sector software under the EUPL 
- http://ictpolicies.gov.mt/docs/GMICT_D_0097_Open_Source_Software_v1.0.pdf  

---