Unofficial Response to OSS Policy v2 Redraft

This is an unofficial response to the above document. It is based on the OSSPolicyV2Analysis and is intended to form the basis of an official AFFS response.

OSS Policy v2 Redraft: A Response

The Association For Free Software (AFFS) is a membership organization which promotes and defends Free Software in the UK. Our membership is made up of a broad section of Free Software users, home users, developers and business people alike. More information about the AFFS is available on our website, http://www.affs.org.uk/.

AFFS has responded positively to this proposal in previous versions, last on the 2nd May 2003 on the subject of default exploitation routes for Government-funded research and development, and seeks to further improve this policy going forwards. We are saddened, though, that this latest draft has not been open to public consultation (especially given the number and content of the changes within): even as a former respondent, the AFFS was not involved in the private consultation until we found out that such a consultation existed. As an organisation with a direct interest in the policy, we would want to take part in such a consultation. We also think that it is clear that wider consultation is required - this policy contains simple factual errors which could have easily been corrected earlier in the process.

We hope in the future that the eGovernment Unit will seek to be more inclusive with respondents in the future, especially those with specialist knowledge/interest in the area such as ourselves.

A note on the Introduction

Although the introduction to the policy attempts to define "Open Source Software" for the reader, we feel it doesn't give a very good description; indeed, that you cannot "(redistribute) under a more restrictive license" is factually wrong and more closely describes the concept the community call "copyleft". This is not a definition of open source or free software that any in the community would recognise - while some free software licences contain the idea of "copyleft", many popular ones do not (for example, the BSD licences).

Free software is simply software that is licensed under terms which allow the user to redistribute the software, in either original or modified form, with no strings attached. The Free Software Foundation (FSF) define this with a four-point list of necessary freedoms, the Open Source Initiative (OSI) define it with a ten-point list of necessary attributes. It would be much better to use a standard definition, such as these, rather than attempt to write a new one - especially where the new one is inaccurate and confusing. It is difficult to see how a policy on free software procurement can be properly effective where it uses a faulty definition - and since the definition of such software has legal implications with regards licensing, it is critical that such a mistake be corrected.

We feel it should also use more inclusive terms, such as "Free/Libre and Open Source Software" (or, FLOSS), since only part of the community identifies with the OSI or the term "open source". Indeed, many parts of the community operate under different sets of rules: many developers follow the Free Software definition set out by the Free Software Foundation, others follow the Debian Free Software Guidelines. Followers of both these descriptions (which are, for the most part, similar) constitute a large section of the community, and both documents pre-date the OSI and the open source definition by many years.

The Policy

Procurement on a value-for-money basis

We note that the justification for this policy point includes the reason that this helps "acquiring solutions that deliver value for money over their whole life". We are worried that this specific reasoning, as well as some of the others, are a result of proprietary-think.

What is the definition of "the whole life" of a solution? When considering a proprietary solution, the lifecycle of the solution is likely to be dictated by the supplier; e.g., they have a three-year licensing term. For a free software solution, though, there may well be no such term: free software tends to be upgraded incrementally (as opposed to large product launches), the cost of software licensing tends to be different (there would be no subscription-with-termination type arrangement), among other differences. With this in mind, how can a free software solution be easily compared with a proprietary solution?

The OGC Successful Delivery Toolkit contains evalutation strategy guidance, which has a particularly relevant section on value for money. It says:

1.5.2
VFM can be defined as ‘the optimum combination of whole-life 
cost and quality (or fitness for purpose) to meet the user’s 
requirement’. This is rarely synonymous with lowest price.
As well as cost in simple terms (i.e. as stated in the 
tender), VFM assessment should also take note of other 
quantifiable costs throughout the whole life of the contract,
to arrive at an assessment of ‘whole-life cost’ (also known 
as ‘cost of ownership’) of the contract. This includes costs 
relating to requirements at the end of the contract and 
recompetition.
Non-financial factors such as cultural fit, alignment of 
strategic objectives and the working relationship that the 
parties could create should also form part of VFM assessment.
...
3.3
For large-scale and complex contracts, it can be very 
difficult to balance the financial and non-financial 
elements in order to evaluate bids on a comparable basis. 
However, unless the non-financial elements are fully taken 
into account, the customer will not be able to assess whether
value for money has been achieved, and suppliers and others 
may perceive that the bids were evaluated on ‘lowest price’     
only.
- http://www.ogc.gov.uk/sdtoolkit/reference/ogc_library/procurement/supplier_assessment/evaluatstrategy.htm

There are a number of relevant points within the above notes on considering the value of proposals. In particular, although immediate cost is an extremely important part of the value equation, it is not the only part of the equation. Free software is likely to be competitive in terms of immediate cost, but has strong implications for other elements: future cost elements, and non-financial elements.

In terms of future costs, free software may provide extra benefits that proprietary cannot on grounds such as:

• less cost at the end of contract: there would be no loss of licence for use of software at the end of the contract, for example, so whereas a proprietary solution may have only two end of contract options (renew contract, or replace solution), free software offers a third (continued use).
• more effective recompetition: if the decision is taken to replace either a solution or a vendor, free software provides more recompetition options than proprietary: a vendor may be replaced without requiring that their solution is replaced. This usually isn't possible with proprietary solutions, because the solution is the proprietary property of the vendor.

Free software can also provide non-financial benefits that proprietary solutions may not:

• free software generally uses standard file formats to store data, but in any case data migration is always possible (since access to the code which reads/writes the files is available) and substantially easier than reverse-engineering a proprietary product. This can reduce later costs of migration, or costs of interoperation, whether those costs are financial or time related.
• free software also generally uses standard network protocols, runs on industry standard hardware, etc. - leading to many of the same potential savings as pointed out above. Use of standard hardware (for example) can also mean that a free software solution could run on hardware a proprietary solution cannot (e.g., the proprietary solution may only run on a certain hardware platform) - re-use of existing capital investment is another benefit that free software has wider scope to offer.
• greater competition. The free software market is one where software is not the proprietary product of one vendor; usually, there are a range of vendors to choose from, as opposed to the proprietary system where many vendors are only available when the proprietary vendor allows resellers (and, consequently, controls the market for their product). Greater competition leads to reduced risks associated with the solution (i.e., if a vendor's business fails, that doesn't mean the solution must be replaced) as well as cheaper prices.

We can see, then, that it is difficult to compare proprietary solutions and free software solutions on an exactly like-for-like basis, even though they are both software-based solutions. The differences in licensing have many far-reaching implications into the overall value equation.

The cost equation is very different for free software, and while it is admirable that the Government should look for the best value solution free software solutions must not be compared to proprietary using unfair cost evaluations, even though they are usually cheaper. In particular, we feel that the expertise to recognise the value of free software solutions is likely to be lacking, and that specific guidance should be drawn up so that comparisons may be made on a fair and equitable basis. We see that point 3 of "Next steps" addresses procurement guidance, we hope the above points are taken into account. This is especially important because those used to procuring proprietary solutions are not likely to be used to procuring free software solutions, or understand the value that they offer.

On a separate point, the policy to "consider OSS solutions alongside proprietary ones in IT procurements" seems rather weak: at best, it is saying nothing, since Government could hardly refuse to consider OSS solutions. It also does nothing to "promote the use of open source software in the public sector" as the eEurope 2005 initiative demands. Although this policy is a useful start, we feel that Government should make more imaginative effort to promote the use of free software in the public sector as opposed to merely noting it may be used.

Interoperability, open standards and lock-in

We applaud the Government to look for ways to avoid lock-in into proprietary data formats and standards; the cost of extricating oneself from such a predicament is high.

For many reasons, there are some published standards which are often not implementable in free software. There may be patents covering a standard, or implementation may be covered by a "Reasonable And Non-Discriminatory" (RAND) licensing system, which often involves fees. While standards covered by such systems are easily available, they are only implementable by certain people, and indeed the licensing terms (RAND especially) often discriminates against free software.

Where a standard is called "open", it should be ensured that it is legally possible to implement the standard using free software - otherwise, proprietary vendors may be able to influence the free software options available to Government by restricting their documentation and standards to proprietary competitors only, and subvert any procurement policy that requires free software solutions to be compared fairly to proprietary. Examples of "open" standards that cannot be implemented by free software (and are therefore not truly open) include Microsoft's published WordML/SpreadsheetML languages, but this is not a problem limited to certain large proprietary vendors - it can occur at all levels of the market.

"Open Source" as a default exploitation route

On the face of it, the new proposal to license publically funded software as free software in absence of other plans seems a sensible one. However, there are a couple of problems.

Firstly, the policy draws a false distinction between commercial software and "open source". Free software is usually also commercial software; there is nothing to stop a free software vendor from charging a fee for the software. The policy ought to reworded, therefore, since one might choose an exploitation route for publically funded software that is both "open source" and commercial - and it should be clear in the guidance issued that such a route is possible.

Secondly, we are concerned that Government will draw up guidance based on the advice and recommendations of those who are not familiar with the licensing of free software. This would lead to poor overall advice, and confusion over the licensing terms (for example, that free software licences cannot be made "more restrictive", or that it is not possible to license free software commercially - both mistakes that are repeated in this draft policy). We believe the best route forward would be to involve both the community and recognised experts in the field to craft this advice: relying on lawyers who will not be familiar with either the terms or the aims of the licensing will not lead to good advice.

Further comments on Next Steps

• We re-iterate our point on involving known free software licensing experts to draw up advice on license; currently, we know of no Government or publically funded body well positioned to give such advice. We would be happy to suggest experts that Government might use.
• Unified access to publically funded R&D: we believe that the community should be involved in the feasibility study for such a scheme. Free software tends to be easily available, it is difficult to see what advantage this access might gain.
• Dissemination of "Proof of Concept" trials: we believe that this information should be made publically available, to both show that work is being done in this field, and to publically validate the methodologies being used.
• Futher activities to support OSS use within Government. As the only UK membership organisation that represents users and developers of Free Software, the AFFS is a stakeholder in the use of free software within Government, and would welcome the opportunity to give further advice and feedback on the use of free software.