A Dutch study has recently been translated and published in English, "The acquisition of (open-source) software", by Nederland Open in Verbinding (NOiV), which finds that in Europe, gratis software does not require tendering and so gratis Open Source software can be freely downloaded without having to go through the usual purchase process. If service is required, that service would, however, require going through the normal purchasing process, but as a separate matter. It's a guide to acquisition and implementation of Open Source software, and the authors are very interested in any input, comments, suggestions you might have.
NOiV is the group that "informs and advises the Dutch public sector
about the possibilities of open source software and stimulates the
use of open source software in their information systems". I had an opportunity to ask NOiV's Maarten Wijnen-Meijer a few questions. Obviously, the most important question has to be, what happens now that OOXML has been approved as an ISO standard?
Here are my initial questions and his answers, and then we'll get to the most important question:
Q: How did the idea start to do the study? And who was involved? (Lawyers presumably.)
Maarten Wijnen-Meijer: For the last two years we have been advising Dutch government agencies on how to embed open source software in their IT strategy. On one hand we focus on the existing application portfolio, and we look for particular open-source software applications that might have a positive business case associated with them. On the other hand we focus on the way future software applications will be acquired in order to give open source software an equal chance.
At that time we had a manual describing how government agencies might require software in their tender specifications. But one question that was unanswered was whether open source software had to be tendered at all. This has resulted in a new guide which answers this new questions and also incorporates some of the finding of the older manual.
The legal study for the Dutch version was done by law firm Stibbe. This version was prepared together with a lot of different stakeholders from different parts of the Dutch government. I would particularly like to thank Ruart Jagt of the ICTU foundation for his involvement. For the English version the text was translated by a translation agency. Legal references were updated by me to refer to the Directive 2004/18/EC directly instead of to the Dutch texts that are based on this directive. We therefore expect our conclusion to be valid in all European member states.
Q: How have the results of the study been received?
Maarten: First let me summarize the results. The first result is that the acquisition of gratis software does not require a call for tender. This means that there are now two ways to acquire software: by simply downloading it, in the case the software is free, or by calling a tender. Secondly, regardless of which scenario is chosen, we promote that government agencies consider openness as a possible requirement. Some applications of software might require the availability of source code; others might require the possibility to modify it. Government agencies should simply state those requirements and find software under a license that fits those requirements, whether that license is open source or not.
The results have not been contested. This comes as no surprise to me given the amount of care we put in the initial version and the number of knowledgeable people that were involved in its making. The guide was released in Dutch December last year and 1000 copies were made. It has been very popular, which was the reason we have printed another 500 copies and made an English translation.
Q: In a few words, can you tell our readers why you believe that no tender is required, the legal basis for your conclusion?
Maarten: In simple words, the tender law governs the spending of government money. If no money is spent (or more accurately, if there is no remuneration) the law does not apply.
There is one exception. If government agencies call a tender for services for software they have freely acquired, service suppliers should not be limited in their ability to provide that support. In the case of open source software there is a level playing field for service suppliers. If there is not yet a market for certain services, a government agency could decide to build time into the tendering procedure so that any service supplier can develop the requested services.
Q: Is your finding applicable, do you believe, in the US as well or predominantly in Europe?
Maarten: As I said earlier, we believe the main conclusions are valid in other EU countries as well. I have no knowledge of the tender law in the United States.
Then I noticed something in the study that caught my attention and led me to ask the most important question, namely what happens now?
The study lists four basic requirements of software for governments,
interoperability, flexibility, transparency, and supplier independence -- and obviously Open Source is ideally suited to provide all four. Then in a section about requirements for software, I noticed this: For example, there is a European directive regarding the reuse of information. This states that governments must make their documents available in formats that are not bound to specific software, where possible and where appropriate. Open standards fulfill this requirement. Since the recent ISO FAQ says some claim the purpose of OOXML is to provide additional functionality ODF does not, namely to render Microsoft legacy documents, I wondered if OOXML, despite being approved as an ISO standard, can qualify under this directive. The directive is in article 13 of Directive 2003/98/EC of 17 November 2003 on the re-use of public sector information. It reads:
(13)
The possibilities for re-use can be improved by limiting
the need to digitise paper-based documents or to process
digital files to make them mutually compatible. Therefore, public sector bodies should make documents available in any pre-existing format or language, through
electronic means where possible and appropriate. Public
sector bodies should view requests for extracts from
existing documents favourably when to grant such a
request would involve only a simple operation. Public
sector bodies should not, however, be obliged to provide
an extract from a document where this involves disproportionate effort. To facilitate re-use, public sector bodies
should make their own documents available in a format
which, as far as possible and appropriate, is not dependent on the use of specific software. Where possible and
appropriate, public sector bodies should take into
account the possibilities for the re-use of documents by
and for people with disabilities.
Obviously, this is optional, but the tilt, I think, has to be toward ODF. So I added another question: Q: Does the ISO approval of OOXML mean that it will be deemed by the Dutch government as an "open" standard now automatically? The recent ISO FAQ justifying having both ODF and OOXML stated that some claim that OOXML provides additional funtionality, namely rendering of legacy documents. Of course, it is Microsoft making that claim, and it is Microsoft legacy documents that it claims to be able to do better, and since its additional functionality stems precisely from its proprietary knowledge, which under the OSP is not available to GPL programs as I understand it, how can OOXML meet the requirements of independence of a single vendor?
Maarten:In March, Tom Peelen, a policy maker at the Dutch ministry of Economic Affairs, said that ISO's approval for OOXML would not immediately make it a standard that can be used by Dutch public administrations. OOXML will have to be approved by a commission on government standards. To be considered, the new standard may, for example, not have any patent restrictions and must have been approved by an open process. These are not the only criteria used,
Peelen later added. The commission, the 'Forum Standaardisatie',
will also consider how it relates to standards it approved earlier,
such as ODF, which the committee approved last year.
Peelen, in March: "To us, ODF is a very important standard."
Source: http://ec.europa.eu/idabc/en/document/7562 . Comments and suggestions are welcome and can be sent to him directly, if you wish, at maarten.wijnen-meijer [at] ictu [dot] nl in addition to any comments you make here.
A paper version of this guide can be ordered by governments (limited supply) by sending an email to Maarten. The guide is also available digitally (cover: PDF, text: PDF, ODF) under the GNU Free Documentation License. If you prefer to read it in the original Dutch, you can.
***********************************
The Acquisition of (Open-Source) Software
A guide for ICT buyers in the public and semi-public
sectors
I
Publication information
II
December 2007, OSOSS, Version 1.0
This document contains general information. Where statements are made about open-source software, these refer to generally used open-source software licences such as the GNU GPL, GNU LGPL, MPL, EUPL, BSD, MIT, Artistic or Apache licences. Appropriate legal advice must always be obtained if buyers encounter specific legal issues. The creators of this text, ICTU, OSOSS and Stibbe, are not responsible for the consequences or any damage arising from the use of this document.
The following existing OSOSS documentation was consulted in creating this document. Unfortunately this documentation is only available in Dutch:
- OSOSS (2004). Open source – a legally sensible choice.
- OSOSS (2004). Software licences. To continue with open-source software, or not?
- OSOSS (2004). Guide to managing legal risks of the government in OSS.
- OSOSS (2005). Manual of Open Standards and Open-Source Software in tenders. Open standards and open-source software and tendering rules.
This document may be reproduced, distributed and adapted according to the provisions of the GNU Free Documentation Licence, version 1.2 or later, as published by the Free Software Foundation. The sections titled ‘Publishing Information’, ‘Foreword’, ‘Afterword’ and ‘Acknowledgements’ are designated Invariant Sections. The Front-Cover Text is ‘Based on an OSOSS publication’. There is no Back-Cover Text. The licence can be found at http://www.gnu.org/licenses/fdl.txt. For more information and an editable version of this document, please visit http://www.ososs.nl.
March 2008, NOiV, Version 1.1
Since January 2008 the OSOSS programme office has been succeeded by the programme office Netherlands in Open Connection (NOiV). This programme office facilitates the execution of the action plan Netherlands in Open Connection and is responsible for the translation of this manual into English. Some small corrections were made.
III
Foreword
The Dutch government has devoted attention to the use of open-source software and open
standards for some time. Initially especially in its service to citizens and businesses, but also
increasingly as a means to facilitate cooperation between governments. IT systems simply work
better if standards are open and software can easily be adapted to the changing needs of users.
Many decision-makers feel that open-source software and open standards are above all a
subject for and of information technologists.
With this guide, we are attempting to make it clear that opting for open-source software is
primarily a sourcing issue. It is an issue that can and must be addressed by budget owners,
supported by IT staff and buyers. Only if the budget owner and/or user of a system endorses the
necessity and usefulness of openness will open-source software be successful.
With the action plan Netherlands in Open Connection, attention to acquiring and using
open-source software will again be increased. The goals of this action plan apply to the state
government, local governments and the (semi-)public sector; in short, all principals from the
primary process and in the ICT departments of all government organisations must consider:
- increasing interoperability between and with the various elements and forms of service of
the eGovernment by accelerating the use of open standards
- reducing dependence on suppliers in the use of ICT by accelerating the deployment of open
standards and open-source software
- promoting a level playing field in the software market and also promoting innovation and
the economy by strongly encouraging the use of open-source software and by a preference
for open-source software in the case of equal suitability.
This policy is not without obligation and to be able to start work, the OSOSS programme office
has described two scenarios for the acquisition of software. Both scenario's give great attention
to the role of open-source software. In one scenario, purchasing and tendering is not required;
in the other, open and closed software solutions must be compared equally.
IV
This document is intended for everyone in the public sector dealing with software purchasing.
This is usually the ICT department, purchasing department and the internal client. Given this
target group, the document assumes some familiarity on the part of the reader with the
purchasing process as well as with tendering rules. For this reason, the document does not
contain a complete description of the purchasing process; it discusses only those elements that
are relevant to the purpose of this document.
I hope this guide will assist you in consciously applying government policy regarding
open-source software and open standards, thereby contributing to an open government that is
accessible.
Siep Eilander
Chief Procurement Officer,
Government of the Netherlands
V
Table of Contents
1 Openness and sustainability............. 1
1.1 Properties of sustainable systems...................1
1.2 What is open-source software?...................... 1
1.3 What are open standards?............................2
1.4 Openness and sustainability........................ 3
1.5 Policy regarding open source and open standards............ 5
2 Determining purchasing needs....................6
2.1 IT architecture............................6
2.2 Set of requirements.........................6
2.3 Tendering and gratis software..............7
2.4 Costs and benefits.........................7
2.5 Choice of acquisition scenario...............8
3 Scenario A: Downloading open-source software...............10
3.1 Market research..........................10
3.2 General quality review...................10
3.3 Functional review........................11
3.4 Most economically advantageous choice..................11
3.5 Acquiring supplemental services...............12
4 Scenario B: Purchasing open-source software...............13
4.1Preparing the contract documents..................13
4.2Requiring standards...............................13
4.3Requiring standards to be open....................14
4.4Promoting the open-source nature of software.............15
4.5Awarding and equal suitability...................16
VI
5 In conclusion..................17
5.1 Agreement and liability.............17
5.2 Cooperation................17
6 More information...................19
Appendix A: Tendering legislation aspects of OSS...........21
A.1 Tendering obligation for OSS acquisition?..................21
A.2 OSS as a need or a want?................25
Appendix B: Tendering legislation aspects of open standards............28
B.1 What is an open standard?................28
B.2 Open standards as a need or a want?..............28
Appendix C: Obligation law and copyright law aspects of OSS............31
C.1 Situation 1: Government downloads OSS without the involvement of a third party.......................32
C.2 Situation 2: Government acquires OSS from an open-source service provider.......33
C.3Subjects relating to both Situation 1 and Situation 2...................36
VII
Reading guide
The relationship between the subjects in this document is presented below. The principles that governments may use in acquiring IT facilities are given first. These principles recur emphatically in the concepts of open-source software and open standards. The purchasing process is represented at the bottom; only a few components are discussed. The core of this document is the two acquisition scenarios, containing practical tips on how software can be acquired.
VIII
1 Openness and sustainability
1.1 Properties of sustainable systems
Some properties consistently recur when discussing software in government: -
Interoperability information in the system must be available and accessible
- Flexibility the system must be able to be adapted to new requirements
- Transparency the operation of the system must be discernible
Each of these properties is at the core of at least two of the following documents: the action
plan Netherlands in Open Connection, the European Commission's European Interoperability
Framework, the ICTU foundation's Netherlands Government Reference Architecture (NORA),
the OSOSS Manifesto of Open Governments and finally the principles of appropriate IT use (or
governance) formulated by Prof. Hans Franken, described in Computer en Recht (Computing
and Law).
Open-source software and open standards prove to be very well suited to providing these
properties. This makes it more than worthwhile to consider using open-source software. It
is also the reason that the government has previously decided that the use of open-source
software must be encouraged.
The importance of these properties depends on the specific situation in which the soft-
ware will be used and by whom. It remains up to the tendering department to determine
the extend to which these properties are needed at the time of the actual acquisition.
A specific determination of needs will indicate how the need can be fulfilled with open-source
software and open standards. These principles recur as a guideline in the scenarios discussed
in this document.
1.2 What is open-source software?
The idea behind open-source software is that the user of the software has certain freedoms
in applying the software. Whereas software licences commonly limit the rights of the user
regarding copyright, open-source licences in fact grant the user additional rights. The most
significant freedoms offered by open-source software are:
i. The user may use the software freely and without restriction
ii. The user may view the source code
iii. The user may improve and add to the source
iv. The user code may distribute the source code
1
The terms under which software may be used are always set out in software licences.
Commonly used open-source licences are the GNU General Public Licence (also known as
GPL), the GNU Lesser General Public Licence (LGPL), the BSD licence, the Mozilla Public
Licence (or MPL) and finally the Apache licence.
All open-source licences, however, offer the user the above freedoms by definition. These
freedoms are subject to some basic conditions in practice. Together with the freedoms, these
basic conditions have been set out by the Open Source Initiative in the Open Source Definition.
Every licence complying with this standard is an open-source licence. Licences presented to
the Open Source Initiative and approved are OSI certified.
The most important basic conditions of the Open Source Definition are:
1. The licence must not forbid anyone to give away at no charge, or to sell, the software or
part thereof.
2. The licence may not discriminate against users or groups of users and may not prohibit a
particular application of the software.
1.3 What are open standards?
The European Interoperability Framework includes the following definition for open standards:
1. The standard is adopted and will be maintained by a not-for-profit organisation, and its
ongoing development occurs on the basis of an open decision-making procedure available
to all interested parties (consensus or majority decision etc.).
2. The standard has been published and the standard specification document is available
either freely or at a nominal charge. It must be permissible to all to copy, distribute and use
it for no fee or at a nominal fee.
3. The intellectual property - i.e. patents possibly present - of (parts of) the standard is made
irrevocably available on a royalty-free basis.
4. There are no constraints on the re-use of the standard.
The last two criteria are explicitly included to ensure that open standards can always be
implemented in open-source software. These criteria ensure that everyone can apply the
standard freely and that no one has a preferential position. Open standards thereby offer
everyone the same opportunities.
2
Open-source software and open standards often go hand in hand. This is because open-source
software generally uses open standards more than closed software does. There are several
causes of this. The development of an open standard often results in an initial reference
implementation of the new standard in open-source software. Open-source software projects
also frequently result in new open standards. Finally, many open-source projects have the
explicit purpose of using open standards.
1.4 Openness and sustainability
Some properties of sustainable systems were described earlier in this chapter, followed by a
description of what open-source and open standards are. In practice, these issues are very
closely related.
1. Interoperability. This property ensures that people have access to their own data and
can connect systems to each other without technical or legal obstacles. Open standards
are required for interoperability. Especially where governments work together, store
data for longer periods or communicate with citizens, interoperability is necessary. For
example, there is a European directive regarding the reuse of information. This states
that governments must make their documents available in formats that are not bound
to specific software, where possible and where appropriate. Open standards fulfil this
requirement.
2. Flexibility. This property means that systems can be adapted and expanded for new
wants and needs. IT systems usually last a long time, often much longer than originally
budgeted. Therefore it is important for an IT system to be able to grow with an
organisation. This is easily achieved with open-source software because the source
code is available and can be freely adapted.
3. Transparency. For some systems, it is important to be able to understand their
operation. The Dutch Information Security Code, for example, points to the fact that
the availability of the source code is an advantage from a security perspective.
The government can actively investigate the quality of its software and report problems
early. Sometimes the availability of the source code is in fact required. The Personal
Information Protection Agency (College Bescherming Persoonsgegevens), for example,
requires a code review for systems working with sensitive personal information. Auditing
is also compulsory when systems deal with state secrets, based on the Dutch
Government Service Information Security Ordinance special information (VIR-BI).
3
4. Supplier independence. In the case of open-source software, the free source code
means that open-source software can be developed by multiple parties and that various
service providers have the ability to support the software fully or offer training and
custom work. Governments are not dependent on a single supplier in this case. If a
supplier decides to stop developing or supporting a particular package, governments
have the last resort of finding another supplier. This guarantees continuity. The Dutch
Personal Information Protection Agency also indicates that the source code should
be available for certain systems working with personal information, for reasons of
continuity.
Regarding open standards, each supplier can support them in an effective manner.
End users can thereby potentially choose from software packages from more software
suppliers. Closed standards, in contrast, often limit end users in their choices. Because
closed standards are often made available to only one or a few suppliers, the range of
software supporting the standard is artificially limited.
The above includes general considerations. These indicate the importance of open-source
software and open standards. Obviously, government organisations must determine on a case-by-case basis how important these properties are. For asystem that is used only once for a
non-critical purpose, many of these requirements are not relevant. For systems used intensively
for longer periods, these properties are much more important.
4
1.5 Policy regarding open source and open standards
In September 2007, the secretaries of state of the Ministry of Economic Affairs and the Ministry
of Internal Affairs and Kingdom Relations sent an action plan to the house, titled Netherlands in
Open Connection. In the action plan, the government expresses `a preference for open-source
software in the case of equal suitability'.
This policy is intended to strongly encourage the use of open-source software. The underlying
goal is the `promotion of a level playing field in the software market and promotion of innovation
and the economy.' This guide explains how open-software can specifically be included as an
equivalent option.
This action plan presents new policy regarding open standards. Starting in 2008, the public
sector is working on the principle of `comply-or-explain and commit' regarding open standards.
Governments must use open standards unless there are significant arguments not to do so. In
that case, the organisation must commit to the intention to apply open standards as soon as the
arguments no longer apply.
One open standard is mentioned by name: the Open Document Format. This open ISO standard
is intended for office documents such as text documents and spreadsheets. Governments will
be introducing this standard in stages in 2008 for reading, writing and exchanging documents.
Governments will be ably to rely on experts of the Dutch government when implementing this
new policy. They will be able to draw from the basic list of open standards and be able to use
an interoperability framework.
5 2 Determining purchasing needs
2.1 IT architecture
IT facilities support the goal and processes of an organisation. For this reason, it is important
for IT purchasing to be done from a broad perspective on the organisation as a whole. Such
a broad perspective is also known as an organisation architecture, in which the goals of the
organisation are described, the composition of the organisation, the processes it performs and
the IT facilities used in doing so.
These aspects of an organisation are strongly interrelated. A change regarding one aspect has
consequences for another. An organisation architecture can describe how these aspects are to
develop with regard to each other in a controlled manner, so that the organisation can operate
even better in the future.
Closely related to this organisation architecture is the IT architecture. This describes in more
detail the available IT facilities and the processes and departments that it supports. The IT
architecture should be the starting point in determining an IT need.
An example of an IT architecture is the Netherlands Government Reference Architecture
(NORA), developed by the ICTU foundation for the electronic government initiative. The purpose
of NORA is to promote coherence and cooperation between governments. NORA is a reference
architecture, meaning that governments can base their own architecture regarding
e-government on NORA, translating the principles of NORA to their own situation.
2.2 Set of requirements
The purpose of acquiring software is to fulfil an IT need. Making a good choice requires a
description of this need in a set of requirements. This set can be used to compare alternative
solutions. The set of requirements is the basis for acquiring software, regardless of how the
software is acquired.
The set of requirements should also consider the desired openness of the software. The
previous chapter indicated the importance of open-source software and open standards
for the sustainability of IT systems in terms of interoperability, flexibility, transparency and
supplier-independence. The use of open standards is the norm. Open-source software must be
considered seriously, so governments must consider the question of the importance of the
properties of open-source software previously discussed, given the IT need.
6
2.3 Tendering and gratis software
Generally, government organisations are free to use gratis software without tendering. This also
applies to open-source software, provided, therefore, that it is free of charge (see A.1). In
practice, however, that is not always the case. Open-source software licences state that open-
source software may be used freely and at no charge. Therefore there is no licence fee attached
to open-source software. This does not mean that providers of open-source software should
offer their software free of change.
Providers are free to request other types of compensation than a fee for the right of use, such as
a fee for making the software available on a carrier or via the Internet, or for providing manuals
and user support.
In the event that acquiring the open-source software costs money, the normal purchasing
procedure must be followed for the acquisition of the open-source software and any
accompanying services and the question of whether there should be a tendering requirement
should be asked. In the event that the open-source software is acquired free of change, the
tendering legislation does not apply and the software can be freely downloaded, i.e., without
any form of tendering. This, however, says nothing about the acquisition of accompanying
services, which are subject to tendering legislation.
2.4 Costs and benefits
The right to use software may be free of charge, but the actual use of software is never gratis.
Licensing fees are just part of the total cost of using software. Hence the total cost of ownership
(TCO) is often mentioned regarding software. Ideally, a TCO calculation includes all costs of the
software, allowing software to be compared objectively regarding costs.
Costs that can be included in a TCO calculation include the acquisition cost of the software,
the cost of required hardware, cost of installing and administering the software, cost of training
employees, etc. In addition to these direct costs, indirect costs can be included, such as the
cost as a result of loss of the software.
Three important notes can be made regarding the practical applicability of TCO studies. First,
there is no consensus on which costs are to be included in calculating TCO. This sometimes
makes it difficult to compare TCO studies. Second, a TCO study provides no insight into
7
benefits such as productivity gains. Finally, TCO studies are about money, whereas some costs
and benefits are of a qualitative nature, such as flexibility and supplier-independence.
It is therefore much better to analyse all costs and benefits associated with an IT system during
the entire period of use. Such an analysis can in part be determined using offers from a tender.
In the event that government organisations switch to using software without tendering, it is
advisable to conduct an analysis.
2.5 Choice of acquisition scenario
In terms of software acquisition, the government has two possible acquisition scenarios. In one, the
software is downloaded free of change, in the other the software is obtained through a tendering
procedure. It is up to each individual government organisation to determine which scenario is
most desirable in which situation. Each scenario has advantages and disadvantages.
In the case of tendering, all activities related to finding, describing and evaluating software are
actually carried out by the suppliers of the software. The results are then presented free of
charge to the government organisation in the form of offers. Based on this, the government can
evaluate functionality as well as estimate the costs and benefits of using the software.
In the case of a government organisation acquiring the software itself by downloading, it relies
on its own expertise. Knowledge is required, and possibly a large amount of time, to find all
available gratis software and analyse it in terms of function and quality. Depending on need, this
package could also be compared with available software packages that are not free. Finally,
governments themselves must analyse the costs and benefits, as gratis software is not always
cheaper. On the other hand, governments could of course contract out these activities.
Finally, there is a difference in acquiring accompanying services. When software is downloaded
free of change, any supplementary services must be tendered separately. In the event of
software being tendered, any services can be included in the tendering.
In summary, the two scenarios have the following properties:
Downloading
gratis
software
|
Purchasing
software
|
Large
emphasis on market research
|
Large
emphasis on specification
|
Knowledge
required
|
Market
does some of the thinking
|
Services
to be tendered separately
|
Services
can also be tendered immediately
|
8
The scenarios are described in more detail in the subsequent chapters. This involves standard
off-the-shelf software and both scenarios are intended to reach a transparent and objective
choice. The scenario of downloading software, however, assumes that governments have
come to the conclusion, based on the set of requirements, that the properties of open-source
software are particularly important.
9 3 - Scenario A:
Downloading open-source software
3.1 Market research
Tendering legislation prescribes a number of procedures intended to enable governments to
select the best possible product or service under the most favourable terms. Since tendering
legislation is not applicable to the acquisition of gratis open-source software, governments
themselves must carefully examine the manner in which they obtain gratis open-source software.
This activity is intended to determine the supply of open-source software. In the normal purchasing
process, the government organisation receives a number of offers based on the specifications
in the contract documents. These offers describe software packages that the suppliers consider
suitable. Without such offers from the market, a government organisation must seek suitable
software packages itself. There are various places on the Internet where information on available
open-source software packages can be found:
Freshmeat.net Overview of software, particularly open source
OpenSourceXS.info Overview of open-source software
OSAlt.com List of open-source alternatives to well-known closed software
The OSOSS website also has a summary of open-source products and reference projects in
which this software is used within the government. This enables a government organisation to
create a total overview of software that is able, at first glance, to fulfil the set of requirements.
3.2 General quality review
Market research can result in a range of open-source software packages, which can compel
a government to pre-select from among them. For offers based on a set of specifications in
the contract documents, the market has already pre-selected a number of software packages
based on the desired functionality and quality. If governments are to obtain open-source software
themselves, they will have to determine functionality and quality themselves, or have it
determined for them. Generally, the more easily an open-source software package can be found,
the more likely it is to be a high-quality product.
To objectively assess the quality of open source software, governments can use open source
software quality models. These models contain criteria allowing governments to compare
open-source software packages with each other. Some common criteria are the age of
the software package, the degree to which it is actively developed, the availability of
documentation, the existence of a clear project plan, the number of users and support by service
providers.
10
Information on service providers can usually be found on the websites of the open-source
software packages. OSOSS also has a page on its website with an overview of service providers
that have experience with open-source software as well as the government.
The need for these properties, however, depends on the type of software and the type of user and
will need to be determined separately for each case.
3.3 Functional review
The last step in determining potentially suitable open-source software packages is evaluating
functionality. In the case of open-source software, functionality can be determined based on
different sources. The website and documentation for the software often make a good first
impression. The software can of course also be downloaded free of change and tested in a test
environment. Finally, the open-source software packages that are left at this stage of the process
probably have a very active user group that can be queried about functionality.
Based on a functional comparison, a further choice can be made of a number of open-source
software packages that comply demonstrably with the set of requirements in terms of quality and
functionality.
3.4 Most economically advantageous choice
The last step in the process is choosing a specific software package based on the list that was
obtained in the previous steps. As indicated in the previous chapter, governments should not be
distracted by the fact that the software has no licence fees as such. All costs and benefits related
to the various software packages, both quantitative and qualitative, must be analysed thoroughly.
If the result of the analysis is very negative, a government organisation can revert to the normal
purchasing process as described in scenario B.
11
3.5 Acquiring supplemental services
Although open-source communities are known for their great informal support ability, this is not
a replacement for intensive professional support. Once a government organisation has selected
and downloaded an open-source software package, it is free to acquire any supplemental
services. These services may consist of installing the software, management and maintenance
and making custom adjustments to the open-source software package.
These services are acquired through the normal purchasing process: by tendering the services or
by purchasing them from existing umbrella organisations. If the cost of the services is below the
threshold in effect, a government organisation is free as always to award the contract, provided
the principles of tendering legislation are observed.
Open-source software is open and independent of suppliers. Where pre-existing and freely
available open-source software is involved, every supplier is able to offer the same services.
Should it be the case, however, that there are still few suppliers who can offer services for the
software package, a government could decide to build time into the tendering procedure so that
the market can develop the requested services. The government organisation can also opt to
tender the software and the services as a single contract at the same time, so that the choice of
product does not present an obstacle in terms of competition law in any event (see Appendix A).
Furthermore, in the event of doubt regarding competition in view of the product choice made,
taking the safe route is recommended. Little effort will be required to place the software and the
services in the market as a single contract. The set of requirements is available at this stage and
there is usually a tender to acquire the services nonetheless.
12
4 Scenario B:
Purchasing open-source software
4.1 Preparing the contract documents
This chapter addresses the normal procedure for purchasing software and any supplemental
services. Here as well, government organisations have the option of assigning special value to
the properties of open standards and open-source software.
For the purpose of elaboration, it is important to make a distinction between open-source
software and open standards. Standards refer to the functioning of the software. These are
technical specifications. Open standards are standards complying with certain non-technical
conditions. The concept of open-source software refers to the licence under which the software
is provided.
The following sections will discuss in more detail how governments can support the importance
of the properties of open-source software and open standards in their contract documents
as a need or want. Such supporting arguments are always required in view of the required
proportionality.
4.2 Requiring standards
Standards are technical specifications and as such as part of the set of requirements. Standards
of an official European nature may be included in the contract documents as needs or wants
without further discussion. In addition to official European standards, there are official national
standards. These may be used if there are no European standards. The government can also
choose to describe the technical characteristics of the desired standard (see B.2.i).
Standards are often mentioned by name in contract documents because it is virtually impossible
to describe the underlying specifications of the standards. Standards corresponding to the
stated standard in terms of functionality but having a different name, however, should not be
immediately excluded. Therefore in contract documents the name of a standard must always
be followed by the phrase `or equivalent'. This prevents discrimination. Room for alternatives is
limited by the detail with which the need is expressed.
13
4.3 Requiring standards to be open
In terms of using open standards, the 'comply or explain and commit' applies. This means that
when tendering software, governments must refer where possible to open standards and avoid
closed standards. To prevent suppliers offering an 'equivalent' closed standard nonetheless,
it may be necessary to indicate in the contract documents why it is important for the desired
standard and any alternative 'equivalent' standard to be an open standard (B.2.iii).
The first chapter described the properties of open standards. These properties are briefly
summarised below. For each property, a text is included enabling the contracting authorities to
provide evidence as to why the desired standards must be open standards:
1. Open decision-making procedure
This property ensures that the contracting authorities are not dependent on one party for the
administration and continued development of the standard. The open decision-making
procedure makes it possible for different interests to be considered in administration and
continued development. It offers the tendering government organisation itself the option to exert
influence on the direction in which the standard develops.
2. Specification readily available
Publishing a standard allows the standard to be implemented by independent of the
administrator of the standard. This increases the independence of the tendering government
organisation. Particularly in information chains involving many parties, publishing the standard
promotes accessibility. When information is stored for longer periods of time, the availability of
the specification of the document format ensures that the information can be read at a later
date.
3. No intellectual property claims
No licence fees based on intellectual property rights are charged for the use of standards.
The royalty-free basis for use means that there is no financial barrier for other participants in the
information chain and other software developers to implement or even use the standard.
Therefore, this is an important prerequisite for the future accessibility of government
information. This is also a prerequisite for implementing the standard in open-source
software.
14
4. No restrictions on reuse
Restrictions on reuse of the standard can exclude some parties in the information chain from
using the standard in question. For example, a standard could apply only for government
parties. If there are market parties in the information chain, these would then be excluded
from using the standard in that case. For a tendering government organisation, this may mean
that the organisations and institutions to which the tendering government organisation
provides data or from which the tendering government organisation receives data cannot
use the standard. In that case, the standard may have much less added value for the
tendering government organisation. This property is also a prerequisite for implementing the
standard in open-source.
15
4.4 Promoting the open-source nature of software
It is not possible for contract documents to simply express a demand or desire for software to
be open source. Instead, a government organisation must specifically argue why the individual
properties of open-source software are required or desired for the government organisation. (See
Appendix A.2)
The previous chapter described the importance that the properties of open-source software may
have. The degree to which the properties of open-source software can be desired or demanded
depends on the type of application. These requirements or wishes can then be included in the
contract documents as award criteria.
Government policy is intended to prefer open-source software in the case of equal suitability. This
guide indicates in a general sense how open-source software can be incorporated. Governments
can, however, also include this principle very explicitly in the contract documents and refer to the
reason underlying the policy, which is the `promotion of a level playing field in the software market
and promotion of innovation and the economy'.
4.5 Awarding and equal suitability
At the end of the tender, a government must choose from the various offers. There are two
potential award criteria: the most economically advantageous offer and the lowest price. Only
software that fulfils the requirements will be eligible. In the case of the most economically
advantageous offer, the wants are also included in consideration to arrive at a total score. In the
case of the lowest price, only the price of the offer is examined.
In the case of equal suitability, open-source software is preferred. Software is equally suitable
if it has the same price if the lowest price is chosen, or if the result is the same if the most
economically advantageous offer is chosen.
16
5 In conclusion
5.1 Agreement and liability
Open-source licences, like almost all closed-source software licences, exclude the liability of the
provider to a large degree if not entirely. The software is supplied as is. Any risks are thereby for
the software user, as is customary with closed software.
A first category of risks is that the government as the user may be liable if it appears that the
open-source software package infringes on third-party intellectual property. A second category
of risks is damage arising from shortcomings, faults or use.
If the software is acquired through a tendering procedure, the offer may include exemptions
and guarantees. If the government puts open-source software to use without the involvement
of a supplier, it is difficult to designate a third party with which the government can agree on
exemptions or guarantees regarding the open-source software. For more information, see
appendices C.1 and C.2.
A major advantage of open-source software is of course that the government has complete
control over the software and can audit or adapt the software if desired to avoid risks.
5.2 Cooperation
When a government organisation has acquired open-source software and any supplemental
services in one of the two scenarios in this document, an entirely new process may begin.
Open-source software offers the software user an active role. This is possible in a number of
ways.
In the smallest form, adjustments to open-source software are shared with the open-source
community. This allows adjustments and additions made by governments to be incorporated in
the basic product. This gives the government's investments a broader purpose. Furthermore, the
government's administrative burden on such adjustments and additions is reduced.
In its largest form, governments could develop open-source software together to carry out tasks.
An interesting new open-source licence in this context is the European Union Public License
(EUPL). This licence has been specially developed by and for the European Commission.
The licence is aligned with European legislation and is intended to promote the exchange of
open-source software between governments.
17
But even without developing software and sharing it, governments can play an active part. Many
governments face comparable problems and challenges. Sharing knowledge and expertise re-
garding the use of open-source software can save a great deal of time and money. There are now
initiatives to this effect at various levels of the Dutch government.
18
6 More information
Policy
Ministries of Economic Affairs and Home Affairs. Netherlands in Open Connection. http://www.ososs.nl/noiv/en
Openness in ICT
OSOSS (2006). Manifesto of Open Governments. http://www.ososs.nl/manifest_open_overheden/en
Architecture
Kenniscentrum (2007). Reference architecture (in Dutch). http://www.e-overheid.nl/atlas/referentiearchitectuur/
European Commission (2004). European Interoperability Framework. http://europa.eu.int/idabc/
Open-source software licences
Open Source Initiative (2006). The Open Source Definition. http://opensource.org/
OSOSS (2004). Open Source Licence Models (in Dutch). http://www.ososs.nl/node/46
IDABC (2007). European Union Public Licence (EUPL v.1.0) http://ec.europa.eu/idabc/en/document/6523
Open standards
European Communities (2004). European Interoperability Framework. http://europa.eu.int/idabc/
Standardization Forum (2008). Towards a Dutch Interoperability Framework. http://www.forumstandaardisatie.nl/english/
Standardization Forum (2008). Publicatie lijst met open standaarden per 1 maart 2008. http://www.forumstandaardisatie.nl/nieuws/artikel/145/
OSOSS (2004). Open Standards Catalogue (in Dutch). http://www.canos.nl
Purchasing and open source
OSOSS (2005). Open Standards Manual and Open-Source Software in tenders. Open standards and
open-source software and tendering rules (in Dutch). http://www.ososs.nl/node/12330
Open source quality models
Open Source Maturity Model by CapGemini: http://www.seriouslyopen.org
QSOS by Atos Origin: http://www.qsos.org
Open Business Readiness Rating by Carnegie, O'Reilly, Intel and others: http://www.openbrr.org
Total cost of ownership
OSOSS (2004). Investing in openness (in Dutch). http://www.ososs.nl/node/7262
19 Liability
OSOSS (2004). Guide to managing legal risks of the government in OSS (in Dutch).
http://www.ososs.nl/node/10045
OSOSS (2004). Open source a legally sensible choice (in Dutch). http://www.ososs.nl/node/15135
20
A.1 Tendering obligation for OSS acquisition?
A.1.i. Public contract
Regarding OSS, it is interesting to ask whether its acquisition, i.e., without the acquisition
of supplemental services, actually needs to be tendered by the government.1 Generally,
a contract must be tendered, aside from exceptions set out in the regulations, if there is (i) a
contracting authority and (ii) a contract requiring tendering. Given the context of this Guide, it
may be assumed that there are indeed a contracting authority. After all, the Guide has been
written for purchasing governments. The question of a contract requiring tendering,
however, requires a more critical approach. The main concept to determine the material area of
application of the current tendering legislation is 'public contract'. This arises from article 29 of
the Directive 2004/18/EC of the European Parliament and of the Council of 31 March 2004 on the
coordination of procedures for the award of public works contracts, public supply contracts and
public service contracts (hereinafter referred to as Directive 2004/18/EC). The main rule of article 29
is that the government must organise a European tender when awarding a public contract. It should
therefore first be determined whether the acquisition of OSS by the government qualifies as a
public contract.
Article 2, parts a, b, c, and d of Directive 2004/18/EC indicates that a public contract should
be understood as a written agreement for remuneration, or pecuniary interest. The 'pecuniary
interest' element in particular may be reason to conclude that the acquisition of OSS does not
involve a public contract, the result being that the acquisition does not require tendering. A closer
examination follows. However, the 'agreement' element could also lead to the same conclusion.
The literature does defend copyright permission for the use of OSS being obtained in the form
of a unilateral non-focused legal action by the copyright holders, by which they waive their right
to exercise their copyright authority towards 'the user'2 (in contrast to a reciprocal agreement
between the collective of rights holders and the user of the software).3 If this interpretation is in
fact followed, the extension thereof is the conclusion that no agreement arises, therefore there
is no public contract and acquisition does not require tendering. However, since views on this
interpretation are not uniform, there will be no further discussion of the 'agreement' element
here.4
21
A.1.ii Pecuniary interest
The words 'for pecuniary interest' mean that if there is to be a tendering obligation, contracting
authorities must provide consideration that is monetary, or able to be valued monetarily, on
awarding a contract. In other words, if a gratis service or delivery is obtained, the 'contract' in
question need not be tendered. This also applies to acquisition of gratis OSS.5 The question,
however, is when a gratis service or delivery is involved, or more specifically gratis acquisition
of OSS.
It can be derived from relevant jurisprudence and literature6 that the concept of 'for pecuniary
interest' requires a functional explanation. In other words, it should not be decided too hastily that
there is no counter-performance that can be valued monetarily.
With OSS, there is in any event one conceivable specific situation that does involve pecuniary
interest. It is not inconceivable that a sum of money should have to be paid to acquire OSS. For
OSS for which an open-source licence applies that meets the Open Source Definition, no licence
fee (compensation for copyrighted use) may be charged for disseminating the relevant software.
This, however, does not prevent a party that provides OSS from asking for compensation of a
different type. Instead of a licence fee, for example, such a party could ask for compensation
for providing a carrier containing a copy of the OSS. Other types of compensation are also
conceivable in the relationship between the providing party and the obtaining party. If a fee is
requested, it is obviously no longer the case that OSS is acquired free of change. The amount
of money in question will then have to be compared to the applicable threshold amounts to
determine whether a contract requiring tendering is involved.7
22
A.1.iii Supplemental services
The points discussed above have been consistently based on the assumption that the
government has no need for supplemental services and wishes only to acquire OSS. In practice,
however, in addition to acquiring OSS, there will also be a need for supplemental services
consisting of software configuration, custom development, implementation services, maintenance
and administration. What is the influence of this altered set of needs on the answer to the question
of whether OSS acquisition should be tendered? The role of the ban on subdivision8 is particularly
interesting in this sense. In the case of a need to acquire OSS on one hand and supplement
services on the other, does the ban on subdivision mean that these two parts can only be placed
in the market as a single contract?
The ban on subdivision refers to determining the value of the contract to be placed in the market.
The essence of the ban is that if the government actually requires a contract to be carried out,
for example, consisting of the acquisition of OSS and supplemental services, the individual parts
that the contract consists of cannot be placed in the market separately in order to circumvent
the effect of the Directive 2004/18/EC, because the individual parts each represent a value below
the threshold amount. From this follows that the ban on subdivision refers to situations in which
the individual parts of a contract have some value each time but that that value is too low to
be able to determine a tendering obligation. Following on from this, it can be observed that the
ban on subdivision is not a factor if it has already been determined that OSS is acquired free of
change. After all, even if it is assumed that the two parts (acquisition and supplemental services)
logically form one contract, it does not matter in terms of determining the value whether the acquisition portion is split off or not. The total value remains the same. The separate part regarding
the acquisition of OSS in fact represents no value at all.9 In short, the relevant gratis OSS can
be acquired without tendering in this situation and it should be determined separately whether
the supplemental services exceed the threshold amount, followed if necessary by a tendering of
those supplemental services.
The ban on subdivision, however, will be a factor if an amount is to be paid to acquire OSS that
is below the threshold amount. As such, the acquisition portion may not require tendering due
to its low value, but if acquisition and supplemental services are linked such that there is in fact
one contract, the individual values must be added and the contract must then be tendered as a
whole if necessary, if the threshold amount is exceeded and no other exemptions apply. By way
of illustration, there may be such entanglement if the government needs OSS but it is also known
23
that the OSS in question will require adjustments in some areas to be connected to existing
systems.10
Another question that is a factor regarding supplemental services is whether a product choice
does not excessively determine the choice of supplemental-service provider in advance (by
means of acquisition without costs of a particular type of open-source software). Furthermore,
if so, is this objectionable in terms of competition law. We believe there is nothing wrong with
this in principle. One of the properties of OSS is in fact that products and services can be d
eveloped, or continue to be developed, on it by everyone, using the freely available source code.
If only one provider offers services for an OSS product, it will apparently have been the choice
of other suppliers not to develop or offer other products or services.
The answer to the second question, however, is different if there has in fact been insufficient
competition, or no competition, on the relevant service market. This situation could occur if
the source code for an open-source software product has in fact not been freely available (or
not available for long enough) to the relevant service market. Consider a situation in which a
provider of newly developed open-source software keeps the software to itself for a while to
be able to develop accompanying services at the same time. It would then be possible for the
provider to have a more or less exclusive position in terms of a service portfolio just after the
software is provided to the government organisation, without the position having arisen in a
natural manner. This could also manifest itself in the form of a knowledge advantage for the
supplier that did have the source code. In that case, the role of the government is not entirely
without obligation. By choosing a product, the government helped to create such a situation.
In this case, there are two ways for the government to cause a level playing field to be created
nonetheless. The government can make the open-source software acquired generally available,
including the source code, and incorporate sufficient time in the tendering procedure to give
other suppliers time to develop the requested services. The government organisation can also
opt to tender the software and the services as a single contract at the same time, so that the
choice of product does not present an obstacle in terms of competition law in any event.
24
A.2 OSS as a need or a want?
If the government needs to acquire software and fulfills that need by means of tendering, the
relevant question arises of whether it may specifically prescribe that it wishes to acquire OSS. In
other words, can OSS be incorporated in the tendering documents as a want or a need?
A.2.i Classifying OSS
We believe the various properties of OSS should be qualified in terms of tendering law as award
criteria, not as a technical specification. The definition of a technical specification is apparent
from Annex VI, article 1, part a and b of Directive 2004/18/EC. The core of the definition (for public contracts for deliveries and services) is that it involves a specification to describe the required
properties of a product or service. The properties of OSS refer not to software or its technical
characteristics but in fact the terms of use, legal and otherwise. The properties of OSS refer to
aspects such as availability of the source code and the conditions for modification and further
distribution of the software.
Directive 2004/18/EC recognises two types of award criteria: lowest price and most economically
advantageous entry. If the government opts to evaluate the offer on more elements than just price,
it will automatically arrive at the most economically advantageous entry. The government is free to
apply various subcriteria to determine the most economically advantageous entry, as long as they
relate to the object of the tender. Article 53 of the Directive 2004/18/EC mentions as an example
`the quality, price, environmental characteristics, (...) date and deadline for delivery or execution'.
The terms of use (legal and otherwise) to which the properties of OSS refer fit these examples. They
in fact refer to the object of the tender and serve to define the most economically advantageous
offer.11
A.2.ii Basic terms
OSS is not a fixed concept. Simply prescribing OSS as a need or a want in a tender will
therefore not be permitted, as this is in conflict with the transparency principle.12
25
The government will therefore need to define, using specific characteristics, what is meant by OSS if
the content of the contract is to be clear (or potentially clear) to everyone in the same way.13There then
remains the question of whether it is permitted to apply the properties of OSS as a need or want in a
tender. The answer to that question is brief in that there are no regulations prohibiting this.
However, the following prerequisites must be taken into account:
- The government must always prepare the contract documents as objectively as possible
for a tender. The contract may not be written with a particular product and/or a particular
supplier in mind. This arises from the principles of objectivity and non-discrimination. The
government can comply with these principles by functionally representing its needs in the
tendering documentation. The properties of OSS, which are often essentially of a legal
nature, must be reviewed in terms of their function. If in fact this functional purpose is
presented in the tendering documents, the likelihood is greatest that suppliers of products
that the government had initially perhaps not considered can participate in the tender. This
is not only in the interest of the relevant suppliers but also that of the government, which will
have a broader choice of solutions fitting the contract documents.
- The various characteristic of OSS prescribed in a tender as a need or a want are qualified as
award criteria.14Directive 2004/18/EC says nothing more regarding award criteria than that
the criteria must be related to the object of the tender.15Aside from this specific rule, however,
the proportionality principle always applies underlyingly.16The stated needs and wants
must always be proportionate to what contracting authorities wish to obtain by means of a
tender and should also not be more restrictive than is necessary. In essence, this involves a
weighing of interests between the interests of the government and those of the suppliers.
The proportionality principle (together with the transparency principle) means that the
government will always have to be able to account for its application of a given need or
want, as well as why the goal is presented as a need or as a want. After all, a need has more
serious consequences than a want. A need has a `knock-out' character. If the government
cannot provide accountability regarding a given property, or in other words if it follows from
the weighing of interests that the importance of stating the need or want is less than another
interest belonging to the market, the need or want in question must be abandoned.
26
The aforementioned accountability may consist of various arguments often based on the need
as such and the circumstances in which it arose. A relevant circumstance might be, for example,
that legislation and regulations prescribe certain characteristics of OSS.
27
Tendering legislation aspects of open standards
B.1 What is an open standard?
A standard is an agreement between two or more parties on the configuration and significance of
data. Standards are often used in the ICT sector, for example, to make different types of hardware
and software components more exchangeable. Where significant here, two types of standard can
be defined: open and closed. Open standard are characterised by a number of elements:
1.The standard is adopted and
will be maintained by a not-for-profit organisation, and its
ongoing development occurs on the basis of an open decision-making
procedure available to all interested parties (consensus or
majority decision etc.).
2. The standard has been published
and the standard specification document is available either freely
or at a nominal charge. It must be permissible to all to copy,
distribute and use it for no fee or at a nominal fee.
3. The intellectual property -
i.e. patents possibly present - of (parts of) the standard is made
irrevocably available on a royalty-free basis.
4. There are no constraints on the
re-use of the standard.
Closed
standard are standards not fulfilling these conditions. Standards
may be kept closed because standards, if they are to be designated
original under the Copyright Act, should be considered works
protected by copyright. This gives the author the option of
permitting publication and reproduction by third parties only under
certain conditions (such as payment).17
28
authorities can award the contract. A reference to standards (i.e., i and ii) must always include the words 'or equivalent'.
Entrants are always entitled to demonstrate that the solution they propose is equivalent to
the stated standards, performance requirement or functional requirement. If the government
therefore wishes to refer to an open standard, it must determine whether a European or
international standard is involved, or, in the absence thereof, a national standard, or a
performance requirement or functional requirement. As soon as an affirmative answer can be
given, it will be possible subject to the prerequisite to be discussed below to use the open
standard as a technical specification in a tender. When are these standards or requirements
involved?
- The terms performance requirement and functional requirement are self-explanatory.
In the context of information technology, these are requirements describing a
performance that the technology to be supplied must be able to achieve, and
requirements describing a function that the technology to be supplied must contain or
be able to perform. According to Directive 2004/18/EC, environmental characteristics
are also included in this category of technical specifications.
-
A standard is defined in Annex VI, article 2 of Directive 2004/18/EC as: 'a technical
specification approved by an accredited standards institute for repeated or continuous
application and not required to be observed.' A European, international or national
standard is then involved if the relevant standard is established by a European,
international or national standards institute and provided to the public.
B.2.ii Prerequisite
Aside from the aforementioned rules regarding the use of technical specifications, the proportionality principle also plays a part in the use of open standards. The needs and wants stated must
always be in a reasonable proportion to what the contracting authority wishes to obtain by means
of a tender and should also not be more restrictive than necessary. The proportionality principle
(together with the transparency principle) means that the government will always have to be able
to account for its application of a given need or want, as well as why the goal is presented as a
need or as a want. Based on the content of the open standard, the need to place a contract in the
market and the use of the open standard in doing so, as well as the circumstances in which that
need has arisen, the government must ensure accountability.
29
B.2.iii Other elements associated with open standards
The aforementioned properties of open standards must be distinguished from the content of
an open standard, which therefore qualifies as a technical specification. These properties are
not part of the standard itself but determine its open nature. In a given case, the government
may have an interest in the open standard in fact being observed by suppliers rather than a
closed equivalent, for example. To prevent suppliers having offered a closed equivalent in such
a case from demanding acceptance of their solution offered by invoking article 23, part 4 or 5 of
Directive 2004/18/EC, the government may also include one or more properties of open standards
as part of the award criteria. Obviously, the government must be able to argue for the use of those
properties in view of the required proportionality.
30
C - Obligation law and copyright law aspects of OSS
In general, the government will acquire open-source software in one of the following ways:
1. the
government downloads the open-source software directly from the
Internet without the involvement of a third party;
2. the
government acquires the open-source software including additional
service (through a tender) from a third party.
The
following text will discuss how the government can limit the risks
of using open-source software as much as possible in both
situations. Software may contain errors, resulting in damage. This
is true of both closed and open-source software. Virtually all
open-source licences exclude liability for this type of damage.
Although liability can largely be excluded under Dutch law,
liability for intent cannot be excluded. Such provisions are
considered void as they are in conflict with morality (art. 3:40 of
the Civil Code). What is less clear is whether the restriction or
exclusion of liability for damage resulting from gross culpability
or deliberate recklessness is also in violation of morality by
definition.
Furthermore,
a judge will always consider the circumstances of the case in ruling
whether it is reasonable and acceptable to invoke liability
limitation. In the event that someone distributes open-source
software and has consciously hidden a virus in it, the distributor
can probably be charged regardless of the liability exclusion.
This is of course on the condition that
there is an attributable shortcoming. Open-source projects also often
involve many different developers. There is a likelihood that the
software contains portions to which third parties hold rights
without their having given permission for the use or further use of
those portions. This can have negative consequences for the free use
of the software.
The
question of whether open-source software should be tendered was
previously discussed in Appendix A and will therefore not be discussed further in this chapter.
31
C.1 Situation 1: Government downloads OSS without the involvement of
a third party
C.1.i Risk-limiting measures in the absence of an implementation partner
After downloading, the government will usually be bound by an open-source software licence.
These licences characteristically exclude the liability of the supplier to a large extent, if not
entirely, just as with almost all closed-source licences. In other words, the software is supplied
as is. In that case, the supplier accepts no liability whatsoever for any shortcomings, faults
or damage that may arise from use. In this situation, the government cannot fall back on any
contractual assurances it has obtained from an open-source service provider.
Therefore it is important for the government to do extensive product orientation when acquiring
open-source software. Such an orientation can involve an examination of the origin and
popularity of the open-source software, which indicates the number of interested parties
involved. For example, the guarantees built into the open-source project to prevent copyright
infringements can be determined. It is also important to establish who is offering the software and
which well-known parties are affiliated with the software project. The government will also need
to look at the community built around the open-source software. The government therefore has
an obligation to investigate in that context, especially when the software is offered free of change.
The government as consumer may be expected to investigate to some extent by means of
tests and audits the functional properties of a product and the legal conditions under which the
software is acquired. Version numbers, readme files and documentation for open-source
software, for example, may indicate the stability of the software.
Another way to prevent potential risks is to take out insurance. There are insurers who provide
coverage for liability due to infringement of intellectual property rights. Such insurers will assign
great importance to the procedures followed in the development of the software. Also important
will be the precautionary measures taken by the insured party to limit damage as much as
possible in the event of disasters. This can include emergency plans, alternative options, back-up
and recovery procedures.21
32
C.2 Situation 2: Government acquires OSS from an open-source
service provider
If the government controls the implementation and administration of open-source software
and therefore has not contracted it out to a third party, it is difficult to designate a third party
with which the government can agree on exemptions or guarantees regarding the open-source
software. This is different with government bodies opting for a tendering procedure regarding
the delivery, implementation and administration: these can include the service provider's liability
(or increased liability) in tendering procedures. Of course, in the case of open-source contracts
below the threshold amount, the government can negotiate with service providers on exemptions
and guarantees. In this situation, we assume that the government will sign a contract, whether via
a tendering procedure or not, with an open-source service provider that supplies the open-source
software and offers additional services.
Note: in this situation as well, it is important for the government, aside from the contractual
assurances it may negotiate, to take the precautionary measures discussed for Situation 1,
including extensive product selection and investigation of the underlying open-source community.
C.2.i Limiting damage in the event of errors in the open-source software and in the event
of infringement on intellectual property rights in the use of open-source software
A government organisation wishing to cover itself for damage caused by software errors will
have to make good arrangements with the service provider that implements or administers the
software. For example, a government organisation can require its service provider to give certain
guarantees regarding the maximum outage period for the information system. Regarding
potential infringement of intellectual property rights as well, good arrangements with the
service provider implementing the software in the government can contribute to risk management.
Open-source licences generally permit additional agreements in this regard. The government
can, for example, agree on indemnification with its service provider.
33
C.2.ii Which specific arrangements could governments make with suppliers regarding
guarantees/liability/indemnification?
Subject
|
Additional
arrangements
|
Guarantee
|
Guarantee
that the service provider is entitled and authorised to supply
the open-source software, grant the rights of use and provide the
services under the agreement to be signed.
|
Guarantee
that fulfillment of the agreed performances is not in violation
with other agreements signed by or on behalf of the service
provider.
|
Guarantee
that the product supplied fulfills the terms of normal compliance
(for instance article
7:17 of the Dutch Civil Code)
|
Guarantee
that the open-source software is efficient, proper and coherently
written
|
Guarantee
that the open-source software is suitable for use in connection
with hardware and software in use in the government
|
Guarantee
that the open-source software is suitable for the purpose for
which the government acquired it
|
Guarantee
that the open-source software meets technical standards
(including international standards) and standards (including open
standards)
|
Guarantee
that the open-source software contains no hidden functionality,
including viruses, worms, etc.
|
Liability
|
Require
that if the service provider demonstrably falls short in
fulfilling its obligation(s), it will be liable to the government
for compensation of damage incurred or to be incurred by the
government
|
Indemnification
|
Declaration
that the programme does not violate the rights of third parties
and that the government is indemnified by the service provider
for the consequences of a stated infringement of intellectual
(property) rights of said third parties, personality rights and
claims regarding knowledge, unfair competition and the like
included, regarding the reproduction, publication or use of the
open-source software
|
The
service provider will pay all established judicial and
extra-judicial costs and damages or settlement fees inasmuch as
they refer to such a claim. The client will report the damage to
the service provider in writing as quickly as possible.
|
34
Subject
|
Additional
arrangements
|
Guarantee
|
The
service provider engages to take all measures, at its own
expense, that may contribute to prevention of stagnation on the
part of the Client and limitation of the additional costs and/or
damage to be incurred.
|
The Client declares that it is prepared, if it invokes the above indemnification, to leave the handling of the matter, including settlement negotiations, to the service provider provide the
cooperation reasonably required to the service provider if
requested. The service provider engage to compensate the Client
immediately for the costs for the Client associated with the
cooperation it requests.
|
It should be noted that the degree to which the above legal safeguards can actually be agreed
on with the service provider obviously depend on the nature (e.g., standard vs custom software)
and size of the specific purchase contract. This applies equally to the purchase of closed-source
software.
C.2.iii Maintaining open-source software
It is important to reach a good maintenance agreement with the service provider enlisted by the
government for implementation. The government may try to divert, by means of the contract, da-
mage that it could incur as a result of maintenance not being continued onto the service provider
that has assumed responsibility for the maintenance.
As with closed software, however, it is still important to perform extensive product selection with
open-source software. Such a selection can involve an examination of the origin and popularity
of the product, which indicates the number of community members involved. These aspects may
determine the continuity of maintenance.
But what if the community ceases to exist? The advantage of open-source software is then that
the source code is freely available, so that all parties having knowledge of the relevant software
can offer support, in principle.22 Now that the government body also has the source code, it
can oversee proper documentation of the software and the modifications made to it, so that the
government body is less vulnerable as well. After all, the government body may assume maintenance or assign it to a third party.
35
C.2.iv Which specific arrangements could governments make with suppliers regarding
maintenance?
Subject
|
Additional
arrangements
|
Maintenance
|
Guarantee
that the open-source software continues to fulfil the
specifications set out in writing during the term of the
maintenance agreement, including at peak times.
|
Obligation
for the service provider to inform the government as quickly as
possible of errors/faults in the open-source software
|
Obligation
for the service provider to document user experiences regarding
the open-source software and offer modifications or additions to
the open-source software by means of new versions
|
Guarantee
that the open-source software will be fully operational at least
. . .% of the time that it is used on government equipment
|
C.3 Subjects relating to both Situation 1 and Situation 2
C.3.i Will the purchased open-source software be combined with closed-source
software?
Before the government acquires open-source software, it will have to determine whether it will
distribute the software to third parties in combination with closed-source software. If that is the
case, the government must take into account the `viral/infectious nature' of certain open-source
software licences, such as GPL.23
In short, the viral effect means that if open-source software is combined with closed-source
software, the ultimate software product should be covered by the relevant viral open-source
software licence if reproduced as a whole. Opponents of open source believe that this viral nature
does not acknowledge the intellectual property rights to the closed-source software used. This
is, however, not the case at all. The underlying idea with GPL, for example, is that open-source
software must always be freely available on redistribution. If the government intends to combined
closed-source software with open-source software (provided under a viral licence) to develop
a new programme, it must be aware that suitable arrangements may have to be made with the
copyright holder to the closed-source software. This can prevent misunderstandings and avoid
copyright infringement on this software. Merely bundling GPL-licensed software with another
36
work that is not covered by the terms of GPL, for example, does not cause the other work to be
covered by the effect of GPL.24
It should be noted, perhaps superfluously, that modifications made to software distributed under
GPL can be applied normally for personal use. Only once the modified software is made public is
the government required to distribute the software under the terms of GPL.
C.3.ii In what cases are the adaptations to open-source software subject to a publication
obligation?
Whether a publication obligation exists regarding modifications to the open-source software
depends on the content of the applicable open-source software licence. Most open-source
software licences contain no general requirement to distribute open-source software (modified or
otherwise). Only once the government intends, due to its policy, to make open-source software
(modified or otherwise) to third parties, should the specific distribution terms of the applicable
open-source software licence be observed.
There are, however, open-source software licences, such as the Reciprocal Public Licence, that
require the licensee to return modifications made to the open-source software to the community,
regarding of whether the modified software is only used internally, or distributed to third parties.25
The BSD licence is a very different example that does not even require the licensee to provide
the source code when distributing derived works. When redistributed, the modified software
may even, under certain conditions, be converted into close--source software. Therefore it is
important for the government to determine for itself when acquiring open-source software whether
it wishes to distribute the software further and under what conditions. The consequences of using
a particular open-source software licence should therefore be documented at an early stage.
37 Afterword
This document has focused on acquisition of off-the-shelf software, with an emphasis placed
on open-source software and open standards. Two important acquisition scenarios have
been discussed. I hope this document thereby answers a number of pressing questions from
overnments about open-source software and acqu0sition. I also hope that it may help
governments to make the new policy on open-source software and open standards possible.
Of course, some issues have not received sufficient attention. First, not all software used by
governments is actually acquired. Software is increasingly being outsourced. In these cases as
well, there may be a role for open-source software. Another issue that was not discussed is
the sharing of open-source software between governments and the creation of open-source communities. These are just two subjects to which a further publication could justifiably be
devoted.
This guide is one of the initial resources for governments for starting to work with the new policy.
Other resources are also available starting in 2008. Two of these resources are a basic list of open
standards and an interoperability framework, focusing on the definitions and role of open and free
specifications in addition to open standards.
This guide is indeed not set in stone. Comments, suggestions and additions are therefore greatly
appreciated.
December 2007, Maarten Wijnen-Meijer, OSOSS
38
Acknowledgements
Many people contributed to the creation of this guide. First and foremost I would like to thank the
ICTU foundation and the EGEM and eFormulieren programmes for their joint financing. I would
also like to thank the following people:
- Christian van Seeters and Eva Visser of Stibbe for doing the legal research that is
included in the appendices and forms the basis of this guide.
- Rachid Guernaoui, Ruart Jagt and Ruud van Ooijen for their support from the ICTU
foundation.
- The members of the feedback group who contributed their thoughts on the desired
form and content of the guide: Arthur Holtgrefe (EZ), Peter Reimer (Bzk), Hans Dussel
(Regiebureau Inkoop Rijksoverheid), Karel De Vriendt (Europese Commissie, IDABC),
Bram Lamens (Belastingdienst), Frank Dane (Gemeente Den Haag), Marcel Smits
(Defensie), Indra Henneman (EGEM), Judith van Bemmel, Ruud Leether (Justitie),
Rob Koning (OC&W), John Konijn (Provincie Zuid-Holland), Jan de Jong (Rijkswater-
staat), Dirk Mansvelder, Ferry Middelink (UWV) and Nils Borgesius (VNG).
- Frank Heijligers as chairman of the ICT working group within PIANOo and Maaike
Daanen and Gesina Kingma on behalf of the Ministry of Economic Affairs for their legal
input.
- A number of external legal professionals for their thoughts in the interim: Mathieu Paapst
(Yacht), Kees Stuurman, Elisabeth Thole, Louis Jonker and Herwin Roerdink (Van Doorne),
Walter van Holst (Mitopics), Stephan Corvers (Covers Procurement Services), Franke van
der Klaauw-Koops (eLaw@Leiden) and Christiaan Alberdingk Thijm (Solv Advocaten).
39
1 There is no concrete jurisprudence available in response to the question as to whether the acquisition of OSS is subject to compulsory tendering.
2
For example, see article 9, GNU General Public Licence, version 3, 29 June 2007
3
For an extensive discussion of these two forms, see the NvvIR publication edited by Thole, E.P.M., Scholten, R., Seinen, W., Open
Source Software: An exploration of the legal aspects of open source software, 2005, p. 118 ff.
4
For further information, see Thole, E.P.M., Seinen, W., Open-source software licences: a civil-law analysis, in Computing and Law
2004/34.
5
Consider also a comparable situation, which is gratis acquisition of freeware such as Adobe Acrobat Reader.
6
For European jurisprudence, see for example EcoJ 18 January 2007, case C-220/05 (Auroux/Roanne). For Dutch cases,
see for example Court of The Hague 31 January 2001, case-list number 00/297, and Subdistrict Section of Court of
Amsterdam 17 October 2002, KG 02/2084. Finally see the example cited in Pijnacker Hordijk, E.H., Van der Bend, G.W.,
Van Nouhuys, J.F., Aanbestedingsrecht. Handboek van het Europese en het Nederlandse Aanbestedingsrecht., Den Haag
2004, p. 70.
7
It could still be conceivable that there is compensation that does not consist as such of the payment of a sum of money but
can be valued in monetary terms. This can include the obligation for the acquirer to make every change and addition to the
OSS available in source-code form to the original rights holder(s) if the software is adapted. The OSS to be made available,
including modifications and additions, represents an economic value. One example in this context is the Reciprocal Public
Licence, version 1.1, 1 November 2002. Article 6.0 of the RPL states: 'You hereby grant to Licensor and all third parties a
(...) licence (...) to use (...) Your Extensions, in any form.'
8
See article 9, part 3 of Directive 2004/18/EC
9
In that case, a point of interest for the government is often that it has tendered framework agreements for the
supplemental services intended here. The required OSS can then be acquired for free and the required supplemental
services may be obtained under one of the existing framework agreements
10
If the acquisition of OSS is not free and the total value of the contract (acquisition of OSS and supplemental services) is
above the applicable threshold amount, existing framework agreements will often be insufficient. After all, the framework
agreements usually refer only to services such as programming, maintenance and consultancy. Software acquisition is not
covered.
11
Furthermore, a contracting authority is free to prescribe or not to prescribe a award criterion in the form of a minimum
requirement that the supplier simply must fulfil. The award criterion in that case is a delivery requirement by nature.
12
See, among other things, ECCJ, 29 April 2004, C-496/99 (Succhi di Frutta). It is established jurisprudence for the European
Court of Justice that all terms and conditions of the granting procedure are formulated in a clear, precise and unambiguous
manner in the tendering documents so that all properly informed and normally attentive entrants can understand the
correct scope and interpret it in the same manner.
13
For an elaboration of some of these properties, see the publication by the ICTU foundation, Manual of Open Standards and
Open-Source Software in Dutch and European Tenders, version 2.1, May 2005, as well as www.opensource.org/docs/osd,
which further explains the Open Source Definition.
14
Further explanation will follow in the next section of part 3 of the Guide.
15
See article 53, Directive 2004/18/EC.
16
This principle will be codified in tendering law, at least according to the proposed law currently before the Upper Chamber.
17 See also footnote 16, part A, p. 26 ff.
18
Directive on Deliveries (93/36/EEC) and Directive on Services (92/50/EEC).
19
European standards may also include national standards, but these must be national standards implementing European
standards.
20 It is also important to note that there are various gradations of deliberate recklessness. In any event, the extent to which it is permissable for an OSS supplier/distributor to invoke its limitation of liability must be determined for each case individually. Facts and circumstances that are important in that sense include the price paid and other license conditions, the relationship (including power relationships) between the parties, expectations created regarding the OSS and the degree to which the scope of the liability limitation/exclusion was known or should have been known to the parties.
21
A.W. Duthler, `Advantages and disadvantages of open-source software', in: A.W. Duthler (ed.), Privacy, security, efficiency
and trust: new challenges for the government, The Hague, June 2003
22 See also footnote 3, p. 21.
23 The fact that this may be a risk in practice is evident from the Progress vs. MySQL case, in which open-source software was distributed combined with closed-source software without the source code being released. See http://www.networkworld.com/news/2002/0305settlegpl.html.
24
See art. 5 of GPL3: 'A compilation of a covered work with other separate and independent works, which are not by their
nature extensions of the covered work, and which are not combined with it such as to form a larger programme, in or on a
volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a
covered work in an aggregate does not cause this Licence to apply to the other parts of the aggregate.'
25
See www.opensource.org/licenses/rpl.php and http://en.wikipedia.org/wiki/Reciprocal_Public_License.
|