https://joinup.ec.europa.eu/sites/default/files/24/ac/83/OSS-procurement-guideline%20-final.pdf
This short annex provides some templates for text that can be used while preparing tenders for the procurement of open source software and software based on open standards. This annex should be read as a source of possible implementation of the recommendations provided in section 2.4 of the main guideline, "Purchasing open source software". Naturally, the texts here may require some adaptation for inclusion in tenders, depending on the precise policies and requirements applicable to each public agency and each tender. The texts are provided following a checkbox approach, allowing the reader to combine texts as appropriate.
Unfortunately, it is not possible to provide ready-to-use texts for functional specifications - the core component of any tender. The authors can only emphasize here how important it is to further good practices and apply the principles of procurement by using clear and precise functional specifications, rather than brand names or product names, although open standards could be cited by name.
Following functional specifications for the software, the authors recommend that open source requirements be placed not in the functional specifications, but as separate requirements in the contract documents (cahier de charges) or contract subject matter description, if they are mandatory, and as weighted award criteria, if the open source requirements are preferential rather than mandatory.
The following text could be included.
The ownership of the supplied software, including all associated intellectual property rights, is to be transferred to the contracting agency with no restrictions on what the contracting agency may do with it 23 ; OR, the software is to be supplied to the contracting agency under the following terms and conditions:
1. the software may be used by the agency for any purpose the agency sees fit
2. the contractor will provide the complete source code and documentation for the software so that the software can be studied by the contracting agency or any third party or parties of its choice
3. the software may be modified by the contracting agency or any third party or parties of its choice
4. the contracting agency may distribute the software, with source code and modifications, to any party of its choice, under terms and conditions allowing such parties the same freedoms retained by the contracting agency, as described above, to use, study, modify and redistribute the software.
The open source requirements as shown above should be included in the contract documents (cahier de charges) or contract subject matter description as mandatory requirements.
The open source requirements should be included as a weighted award criterion. A weighting/scoring system should be used. The weight for the above open source criterion should be set to the level of preference for open source deemed appropriate for the tender, depending on the justifications and requirements. For example, suppose the weight for the open source criterion is set at 20%, and that the winner selection formula is the total quality score divided by the total price at a 1:1 price : quality weighting. In that case, if two competing bids, one for proprietary software and one for open source software, exactly match in terms of quality and other award criteria, the open source bid will be selected unless the proprietary bid has a price that is 20% lower. In this case, the public agency believes the value of the open source properties of the software are worth a 20% premium in the immediate price of the tender (e.g. due to presumed long-term cost advantages that are not included in the tender price)
Along with functional specifcations for the software, the standards must be described in the technical specifcations of the tender. Each standard must be defned by reference (or name), if it is an offcial standard that is permissible to cite this way, or a widely known specifcation that is not a formal standards in the European legal sense, but can be described by name: TCP/IP, HTML, XML, SMTP, etc.
It should already be known at the point of preparing the tender whether or not any given named standards meet the openness requirements of that tender. Thus, standards that do not meet such requirements can simply not be listed in the technical specifcations.
Although it is preferable to name specifc open standards in the technical specifcations, if the technical interfaces, formats or protocols cannot be named – e.g. if no named open standards exist – they must be defned in the technical specifcations. Each standard thus defned must be clearly identifed in the technical specifcations, for example, each defned (unnamed) standard can be numbered, using text such as:
** "This specifcation is referred to in this call for tenders as Open Standard #1" **
Standards which are named in the functional specifcations have presumably been screened for their openness attributes prior to the tender procedure. This may have been done at the European, national, regional or local level, or by the procuring agency itself. Thus, if only named standards are being used, there is no need for the tender to include requirements specifying the openness of standards. The named standards have been assumed to meet any procurement requirements.
If interfaces, protocols or formats are defned in functional terms in the technical specifcations, as described above, openness requirements may need to be included in the tender in order to ensure the openness of any implementation. This may also be required if the technical specifcations of the tender do not detail all the standards that may be included in a procured solution. For example, the call for tenders may require bidders to propose the standards they intend to use, and evaluate each bid on the basis of the openness of the technologies proposed. In this case, the openness could be specifed in award criteria.
There is no universally accepted defnition of open standards; this guide has used the defnition of the European Interoperability Framework version 1.0. However, a defnition of open standards is not required in order to actually have tenders preferring or requiring open standards, if each tender actually includes justifable requirements or award criteria for the openness of standards.
Here the authors provide text consistent with the EIF v1.0 defnition of open standards, but this text stands on its own independent of any external defnitions.
Thus, the following texts could be included as tender requirements or as a weighted award criterion.
If the technical specifcation functionally defines unnamed but numbered protocols, interfaces or formats
The following text could be included as part of the requirements for openness of standards:
The supplied solution must implement the technologies referred to in the Technical Specifcations as Open Standards #1 [#2, #3 etc]. Each of these technologies, as implemented in the supplied solution, must have the following properties:
If the technical specifcations do not include standards, but allow the bidder to propose various technologies and standards in their proposal
The following text could be included as part of the requirements for openness of standards:
The supplied solution may implement a number of standards, interfaces, protocols or formats, each of which, as implemented in the supplied software, must have the following properties:
Openness properties for standards
For either case above, the provided text should be followed by the openness properties for open standards:
1. it is implementable by all potential providers of equivalent technologies 2. its past and future development is open and transparent 3. there is no restriction on its re-use
Note these openness requirements must be justifable due to the interoperability needs of the procuring agency. Moreover, if it is not seen as essential or justifed to be consistent with the EIF v1.0 defnition of open standards, it is possible to use some of these properties alone, or to separate them into individual weighted award criteria rather than combining them into a single one. That way, bids that meet some of the properties of open standards will still get some weighted score, even if they do not meet all the properties.
If the supplied software is required to use open standards
The open standards requirements – or named, open standards, if specifed – should be included in the contract documents (cahier de charges) or contract subject matter description as mandatory requirements.
If the supplied software is preferred but not required to be implementing open standards
The open standards requirements, or named open standards if specifed, should be included as weighted award criterion. A weighting/scoring system should be used. The weight for the open standards requirement should be set to the level of preference for open standards deemed appropriate for the tender, depending on the justifcations and requirements.
Weighting and scoring can also be used if not all the properties of open standards as translated into award criteria are seen as equally important or essential. For instance, if it is seen as essential that the standards is equally implementable by all potential providers of equivalent technologies, and that there is no constraint on re-use, but the transparency of development while preferred is not essential, the openness attributes could be separately listed with #1 and #3 being obligatory and #2 being weighted.
23 - While a transfer of rights to the acquirer is not the same as an open source licence, it fulfils the same procurement requirements; this follows the principle of this guideline that tender terms follow the requirements of the procuring agency, and open source follows from these requirements. Of course, if a procuring agency acquires all rights to the software, it is free to release the software as open source so that other public agencies (among others) share the benefits.