Open source policies for educational institutions

by Sebastian Rahtz on 1 June 2005

Introduction

An educational institution will have a number of strategies relating to IT. This document proposes a series of ideas which are designed to be included in one or more strategy documents, in order to clarify the institution’s attitude towards open source software.

Open source is neither a threat to, nor a panacea for, the IT needs of educational institutions. It is an opportunity to expand the range of ways they deploy and develop software, and they should take the opportunity to re-examine their IT and IPR strategies.

These policy ideas are designed to complement and expand on the policies of the UK government, and of JISC:

This paper was prepared by OSS Watch, a UK JISC service funded for 2003–2006. OSS Watch (http://www.oss-watch.ac.uk) provides unbiased advice and guidance about free and open source software for UK further and higher education. It is hosted by the Research Technologies Service at the Computing Services, University of Oxford.

Unless directly quoted, ideas and opinions expressed in this paper are those of the author and do not represent the policy or intentions of JISC or of the University of Oxford.

Procurement policy

The primary questions for an educational institution’s IT procurement strategy will relate to demand (that is to say, why do we need the system) and value (what will it cost us). Within that framework, the most important considerations are the preservation of data and the interoperability of systems. Thus:

  • New software acquisitions should demonstrate conformance to relevant open standards and interoperability with open systems. At each point on the procurement and deployment chain, software should be assessed on its merits. Thus:

  • Open source and proprietary software options should be assessed using the same criteria, including total cost of ownership over the expected lifetime of the deployment. These are also the first two points of Open Source Software: Use within UK Government.

Intellectual Property policy

With respect to intellectual property created for the institution by the writing of software, an institutional IPR policy should acknowledge the potentially significant role played by open source methodologies in terms of exploitation routes for the institution’s technology transfer arm. This expands the possible range of material which can be exploited, and it is no longer necessary to regard the bulk of software IPR as un-exploitable. However, the exploitation route must not exclude the developer sharing in derived income. Thus:

  • Software development by staff and students must include maintenance of a register of intellectual property rights (IPR).
  • Publicly-funded software development should include an exploitation plan.
  • Open source must be available as an exploitation method, and should be the default method where no alternative is proposed.
  • Income derived from services and training associated with a software product must be shared with the developers using the same system as that used for patents.
  • When selecting an open source licence, the institution should ensure that it has the right to use all future versions of the software. The first clause is explained in more detail in the JISC policy. The second and third clauses implement the UK government’s policy. The intent of the last clause is to make sure that software developed locally is not folded into a proprietary product for which the institution may then have to pay.

Policy on contributing to open source software

Initiation of entirely original software is less common than adding to an existing product. Participation in, and contribution to, open source software projects should be considered as a normal part of the working life of IT-related staff, and this must be reflected in employment policy and employment contracts. There must be procedures in place so that staff can do work on open source projects in good conscience, without removing the protection afforded to the institution by retention of copyright. Thus:

  • A register of deployed open source software should be maintained.
  • A register of open source software for which staff and students may contribute code, documentation and support must be maintained. It must state whether contributions remain the property of the institution, whether copyright has been assigned to a body maintaining the software, or whether copyright is to be the property of the software developer.
  • Staff and students may not contribute institutional intellectual property to open source projects without explicit permission.