Archive for March, 2002

Draft Policy on the Use of Open Source Software (OSS) in UK Government Response

Sunday, March 10th, 2002

I recently wrote the following response to the Government’s consultation on the draft policy on the use of open source software:

With regard to the Public Consultation Draft on Open Source Software in Government, I have the following observations and comments to make:

  1. The overall spirit of the Draft (and the QinetiQ report on which it is based), is to be commended. Open source software offers real advantages to society at large and any recognition by the Government, however guarded (as in this report) is to be welcomed.
  2. The definition of OSS within the Public Consultation is not consistent with the Open Source Initiative’s definition at http://www.opensource.org/ . I propose that the OSI definition is used.
  3. Looking at the specific policies outlined by the report, there is potential for a conflict between different criteria laid out in the policies relating to the choice of software. One the one hand, value for money is cited as the basis on which contracts will be awarded. On the other hand, it is stated that UK Government will “seek” to avoid lock-in to proprietary IT products and technologies. However, it is crucial that it is made clear that “value for money” considerations must extend far beyond the superficial and easily-manipulated figures provided by vendors for initial outlay and/or TCO. It is quite possible (in fact, likely) that closed-source vendors will offer solutions which may at first glance appear to offer better value for money as compared to competing OSS alternatives. However, the long term impact of choosing a closed-source solution may be onerous:
    • There may well be considerable future upgrade costs (which may in turn be unavoidable in order to maintain interoperability with other products, organisations or other entities).
    • There may be ‘lock-in’ to proprietary file formats which in turn will mean the Government is forced to purchase other closed-source solutions in order to interoperate, and this effect can easily permeate an entire organisation, creating wide-scale lock-in and very high medium to long term costs.
    • Upgrades or modifications to the software will generally have to be made by the vendor, rather than allowing other companies to bid for such work. A similar argument applies to the provision of support for the software – whilst third parties do sometimes provide support options for closed-source software, the vendor inherently has an advantage over the third parties.

    Furthermore, point 4 states that “UK Government will obtain full rights to bespoke software code…wherever this achieves value for money”. The ‘value for money’ qualification in this policy must be examined carefully in the light of the points raised above. Once again, it may be initially cheaper to choose a closed-source solution without rights to the code but this will almost certainly force vendor lock-in, which may cost more in the long term.

    In summary, if OSS and closed source software are to be compared fairly on a value for money basis, it is crucial that “value for money” should be assessed by an unbiased and independent party and should be calculated as a total cost of ownership over the anticipated lifetime of the product, including all secondary effects on future purchases as discussed above.

  4. Point 2 (relating to interoperability) cannot be overstated. Even if it were to be decided that in a particular situation, a closed source solution should be chosen, it is critical that the solution should not only support completely open and documented standards for data interchange but use them by default. This will avoid lock-in to proprietary formats which in turn will allow uninhibited future interoperability with other software (OSS or otherwise) and ensure that the product may, optionally, be replaced with an alternative solution from another vendor (again, OSS or otherwise) if it is deemed appropriate at some point in the future. A specific reference to the e-GIF may be appropriate here.
  5. I believe that point 5 (using OSS as the default exploitation route for Government funded R&D) should be stated more strongly. OSS should, unequivocally, be the default exploitation route for Government-funded R&D. If society at large is funding software research via central government, then the results of such research should be made available to society in the form of OSS.There are undoubtedly issues to be resolved in certain cases should such a policy be chosen, but these should not deter the Government from implementing such a policy. For example, in the current age of aggressive and often predatory intellectual property rights assertion by large corporations, jointly-funded projects may potentially be threatened by commercial co-funders wishing to aggressively assert IP rights. Whilst an equitable and proportional assignation of IP rights is of course necessary, any joint-funding agreements should, by default, be written to ensure that software resulting from said jointly-funded projects (or at least a fair proportion thereof) is made available as OSS.
  6. There is no stated policy on software patents, yet software/logic patents threaten OSS and therefore impact on this policy. Hence, alongside this policy on the use of OSS, there should be a clear and unequivocal policy statement on software patents, which should state the Government’s support for Article 52(2) (http://www.european-patent-office.org/legal/epc/e/ar52.html) of the European Patent Convention forbidding patents on computer programs. This restriction is currently being unilaterally disregarded by the European Patent Office as well as the UK Patent Office and UK courts (see http://www.patent.gov.uk/patent/notices/practice/computer.htm) – a problem recognised by a recent European Commission Directive on patent harmonisation (http://europa.eu.int/comm/internal_market/en/indprop/com02-92en.pdf). In conjunction with this, the Government needs to ensure that the aforementioned harmonisation resolves any uncertainty in favour of a clear ban on software/logic patents, including guidance on the possible conflict with the “all fields of technology” aspect of TRIPS Article 27(1).
  7. The ‘Justification’ section sums up the spirit of the policies well.

In summary, this Draft contains a generally well-written set of policies which could benefit from some expansion and qualification but which otherwise provide a fair and balanced framework for the use of OSS within Government.

Tim Jackson