Workshop: Legal aspects of free and open source software
____________________________________________________________________________________________
63
4.1.3 Repositories
Open source software is actually downloaded from repositories of software, or via
catalogues. Communities of practice can often be found attached to such repositories.
4.2
Identifying and selecting software
When a number of open source software applications appear to meet an organisation's
needs, an evaluation and selection can be performed. This could, first, act as a filter for
general reliability and quality as described above, including by taking into consideration
issues such as maturity, size of the community, availability of commercial support from
various sources, etc. And finally, the selection of the software is based on its matching the
previously defined functional requirements.
Functional requirements can be matched to the software documentation - website, software
manual, etc. Open source software can simply be downloaded and tested - without
deployment, or in pilot deployments - to examine the extent to which it meets functional
requirements
96
.
Finally, an analysis may be performed of the costs of meeting the functional requirements
with the open source software. The solution that is the most cost-effective may be chosen -
considering all the various criteria discussed above. If the solutions identified through this
process are unsuitable, the procedure of acquisition through downloading can be
abandoned, and replaced with a call for tenders for purchasing open source software as
described in the next section.
4.3
Tenders for evaluation, support, customisation, services
Downloading software free of charge does not mean there will be no associated costs.
While in some cases it may be possible for a public agency to provide all the support for a
particular software application in-house, it will often make sense to contract this out. This
will naturally require a call for tenders.
To begin with, the process of identification, evaluation and selection of software to
download does not have to be performed (entirely) in-house at the public agency.
Depending on skills and resources available, it could be useful to have a public contract for
some of these tasks. A condition in such calls for tenders may, if justified, exclude the
winning bidder from further contracts (such as for services, support) related to the software
selected with their assistance, to prevent a conflict of interest and ensure their role as an
honest evaluator of open source download choices
97
. Of course, a new tender is not
required for every case of software selection. This assistance for evaluation and selection
could also be performed by a firm with a pre-existing contract for such on-going
consultancy services.
When a final selection has been made for the choice of software to be downloaded, with or
without the assistance of a contractor, the software has to be installed, maintained, and
supported. Note that downloading software with no contractual arrangements is free of
charge, but also means that the software usually comes with minimal warranties. In fact,
this is true also for much proprietary software, especially "off-the-shelf" software, where,
although many users assume large vendors bear some responsibility for their software, in
fact, software licences typically disclaim warranties. As with proprietary software, entering
into a service or quality assurance contract of some sort is the main method for a public
agency to share some of the responsibility for its use of open source software.
The software may be customised - the ability to be customised extensively is a key
advantage of open source software, and customisation may be one reason why open source
96 Of course, proprietary software can also be included in pilot deployments, although if this involves expenditure
it may require a formal procurement procedures.
97 An automatic exclusion, according to the case law of the European Court of Justice C-21/03 Fabricom,
contravenes the EC Public Procurement directive and such exclusion should be operated only on a case-by-case
basis, with bidders “given the opportunity to prove that, in the circumstances of the case, the experience which he
has acquired [through the execution of a previous contract such as the selection of technologies or software
applications] was not capable of distorting competition”
Policy Department C: Citizens' Rights and Constitutional Affairs
____________________________________________________________________________________________
64
was selected by the public agency in the first place. For customising public sector software,
a paid contractor will usually have to be selected.
For all such additional services, open, competitive calls for tenders should be used to select
suppliers. In order to foster the developer community around the selected software, it may
be useful to introduce as a criterion in such tenders the level of interaction and contribution
the tenderer has within the appropriate community. This can be evaluated through
objective metrics such as: the number of posts the vendor (or employees) makes to
community online forums; the number of software bug reports filed, bug fixes submitted,
or code contributions; the sponsorship and participation of events related to the specific
software community such as conferences, workshops, hackathons, etc.
A key property of open source software is that anyone can provide support or other
services, depending on their skills. The market is thus fully competitive. No proprietary
control or advantage rests with an "owner" or "sponsor", or their dealers and agents. In a
call for tender placed for the purchase of specific proprietary software or related services -
which works against a competitive market and may violate procurement regulations - only
the proprietor itself, or dealers who are necessarily dependent on the proprietor, can bid. In
a call for tenders placed for the purchase of services related to a specific open source
software system, any independent supplier can bid. In fact, this distinction is similar to the
difference that one can find between a tender for the supply of Peugeot cars or services for
Peugeot cars (for which only firms dependent on Peugeot can bid), and a tender for fuel
and tyre service for a car (for which anyone with no ties to a particular car company can
bid).
5 PURCHASING OPEN SOURCE SOFTWARE
Recommended best practice procurement is based on the definition of functional
requirements - which may include properties that are equivalent to the characteristics of
open source software, or the characteristics of open standards.
5.1 Defining
requirements
Calls for tenders for open source software - like all calls for tenders - should be based on
functional requirements, not on specific products or vendors. Properties of open standards
or open source software may be part of these requirements - either as minimum
requirements, or as properties that will be favoured.
5.1.1 Functional
requirements
The author recommends that the tender specify the function of the software in detail, to
ensure transparency and objectivity in the procurement process. The purpose of the
software to be acquired and its essential attributes should be described in a vendor-neutral
manner. This is a general principle of public procurement; the author focuses here on the
additional functional requirements relating to the open source nature of the software, and
open standards.
5.1.2 Open
standards
Provided that this is justifiable due to the interoperability needs of the procuring agency,
open standards can be required just as any standards. Open standards can be required
either by referring to the open standards by name, or by referring to an official list of open
standards. However, if no definition of open standards has been adopted or is applicable to
the procuring public agency, nor any officially approved list of open standards can be cited,
the standard may have to be defined in terms of functional specifications. The functional
properties of “openness”, as described below, could be included among the tender
specifications. This way, the openness of standards can be specified as a preference
(through the weight given to it in the award criteria), or a requirement (by making it a
mandatory in the specifications).
Dostları ilə paylaş: |