Workshop: Legal aspects of free and open source software
____________________________________________________________________________________________
65
Including open standards requirements or preferences in tender requirements is
straightforward: the properties of open standards could be described, together with a
justification, if required. Since the justification is part of the essential needs as determined
by the public agency, a specific definition of the term 'open standards' is, while useful, less
important. For software applications, the needs of a public agency may typically require
that:
the standard is implementable by all potential providers of equivalent technologies,
ensuring sustainability and full competition with no advantages for some players
based on patent or copyright royalties or restricted availability of the technical
specifications; in addition, the standard should not discriminate against open source
software solutions
98
.
the development of the standard is open and transparent, so that the public agency
is not dependent on one party for the future of the standard, and may even
influence its further development
no restriction on re-use, so that the public agency can be certain that other public or
private organisations can use the standard, and so that the use of the standard in
open source solutions - which are often not compatible with re-use restrictions - is
possible.
Note that these typical public agency needs can be met by standards that fulfil several
published open standards definitions.
5.1.3 Open
source
As mentioned at the start of this section, it is not good practice to simply state that
software should be "open source". Rather, the properties of open source software should be
described and justified.
Open source is not part of the technical nature of the software; it applies to the conditions
under which the software is provided. Thus, the desired properties of open source could be
included in the form of mandatory requirements in the description of the subject matter of
the contract, or in the contract documents (cahier de charges). Open source can be
included as a preference rather than a mandatory requirement including open source
requirements as award criteria.
Including open source requirements is straightforward: the properties of open source could
be described, together with a justification, if necessary. The needs of a public agency may
typically require that:
the ownership of the software is transferred to the public agency, with no
restrictions on what the agency can do with the software; OR:
99
the software may be used for any purpose, as the public agency does not want to be
restricted in how it can use (or allow others to use) the software;
the public agency or a third party of its choice may study the source code, as the
public agency wants to be sure of the functioning of the software; alternatively, the
public agency may require that any member of the public can study the source
code, in order to promote transparency of government processes, or enable other
parties to provide support and training associated with the software;
the public agency or a third party of its choice may modify the software, as the
public agency does not wish to be dependent on the original vendor for bug-fixes,
adaptations and other modifications;
98 The open source non-discrimination requirement is included in the draft version 2.0 of the European
Interoperability Framework.
99 Note that some of the requirements below may be met by proprietary software under specific licensing terms,
but if all of these requirements are met, the software is by definition open source.
Policy Department C: Citizens' Rights and Constitutional Affairs
____________________________________________________________________________________________
66
the public agency can distribute the software, with source code and modifications, to
anyone of its choice and provide recipients with the same abilities to use, study,
modify and redistribute, because the public agency needs to ensure that citizens and
firms and other agencies that access its services using the software or variants of
the software do not need to become customers of the original vendor in order to do
so; for example, a national administration may wish to be able to pass on the
software, without extra costs, to other administrations at the local, regional,
national or European levels.
When supported by an official policy at European, national or local level, such requirements
may not need explicit justification in each tender. Even if there is no official policy, such
criteria need only to be justifiable - i.e. if questions are raised - rather than justified in each
tender. But there is no harm providing explicit justification and references, and it is always
a good practice to (briefly) explain why certain criteria are present. For instance, the
explanation for the Dutch government's preference for open source software is the
"promotion of a level playing field in the software market and promotion of innovation and
the economy".
5.1.4
Open source for redistribution
When procuring software for the purpose of potential redistribution it is important to clarify
specific redistribution conditions for the component being procured, to ensure that the
public authority does not face licensing difficulties combining that component with other,
separately acquired software, for further redistribution.
To address such cases, Spain has adopted Royal Decree 4/2010 implementing the National
Interoperability Framework planned in the eGovernment Law of 11/2007.
100
According to
RD Article 16.1, the licensing conditions of applications owned by Public Administrations
that can be made available for other Public Administrations or for the citizens, must:
allow the free use/reuse of these applications;
exclude the software appropriation by a third party;
protect the administration from liability, support and warranty obligations.
Therefore, if the distribution is decided, it must be under open source conditions (combined
with strong “copyleft” conditions for avoiding the exclusive appropriation that would happen
if the software could become proprietary).
This means that, by default (and by choice, when it is appropriate), the Spanish
administration will distribute its software under the terms of the European Union Public
Licence (the OSI approved licence which has the same value in 22 European languages)
101
.
5.2 Other
requirements
In addition to technical, functional requirements and the non-technical properties of open
source and open standards, calls for tender typically contain also other criteria for awards
and for determining the eligibility of bidders.
One property of open source software that distinguishes it from proprietary software is that
small, innovative companies, limited only by their skills and abilities rather than their
dependence on the software proprietor, can provide it on an equal basis. However, small
companies may have difficulties meeting stringent eligibility criteria with regard to financial
sustainability.
100 The Royal Decree (text in Spanish) is published at:
http://www.csae.mpr.es/csi/pg5e41_ingles.html
. On
ePractice see the presentation and comments from Miguel A. Amutio (in English)
http://www.epractice.eu/en/cases/eni
and comments from P-E. Schmitz on OSOR
http://www.osor.eu/communities/eupl/blog/impact-of-the-spanish-royal-decree-4-2010-of-8-january-2010-1
.
101 Similar provisions can be found in other recent policies in Member States, such as the 1 June 2010 directive of
the Government of Malta enabling, where appropriate, the distribution of its public sector software under the EUPL
- http://ictpolicies.gov.mt/docs/GMICT_D_0097_Open_Source_Software_v1.0.pdf
Dostları ilə paylaş: |