Developing an open source policy

by Sebastian Rahtz on 1 May 2005

Introduction

Abstract

Using the UK as an example, this paper considers the relevance to an educational institution’s IT strategy of the UK Government’s Open Source Policy, the UK e-Government Interoperability Framework (e-GIF), and the open source policies of the UK Joint Information Systems Committee. It proposes a statement of principles suitable for any educational institution.

Introduction

Most educational institutions do not have a section in their overall IT Strategy which defines their attitude towards open source software. The intention of this paper is to outline the areas such a policy section should cover and what it might say. Although open source per se may not initially seem important, dealing with it properly covers a wide range of subjects of interest to any institution.

An institution’s open source policy will affect, or be affected by,

• institutional or departmental software acquisition
• institutional, national, or international standards for data storage
• research contracts, and exploitation of inventions
• staff employment contracts
• IT training plans All of these areas will naturally be dealt with in the institution’s IT strategy, but the challenge is to ensure that decisions and policies are not dictated by any one model of software development and deployment.

We will first consider the characteristics of open source and why it is of interest to educational communities; then look at the guidance given by the UK government and one of the big IT funding bodies; and conclude with a proposal of what should go into an institutional strategy.

How does open source work?

Open source (http://www.opensource.org/) is computer software for which:

• the source code is available to the end-user;
• the source code can be modified by the end-user;
• there are no restrictions on redistribution or use;
• the licensing conditions are usually intended to _facilitate _ continued re-use and wide availability of the software, in both commercial and non-commercial contexts;
• the cost of acquisition to the end-user is often minimal. The virtue of open source software is that there are no secrets, and the working of the software is available for anyone to inspect, something of great importance for security audits. The fact that the software is generally not privately controlled means that it is likely to promote open rather than proprietary formats; and the model of development by communities often leads to problems being fixed quickly. The fact that open source software is almost always distributed free of charge is in some ways irrelevant, since the cost of deploying software is very often much higher than the simple cost of licence acquisition.¹As with proprietary software, open source requires hardware to run and trained people to customise, install, upgrade, patch, test and maintain it. Many of these tasks are often indirect and a harder cost than the up-front licence fee which is often the most noticeable cost of proprietary software.

Deployment of open source software is, generally speaking, no different from that for proprietary software. It will follow the same pattern of evaluation of needs, testing, acquisition from a supplier and so on. The main differences are additions:

• There can be multiple, independent, primary vendors for open source software to choose between.
• As well as the usual range of support options (relying on a primary vendor, dealing with a large general support company, employing a specialised consultancy, and developing in-house expertise), there is the additional possibility of bringing new feature development in-house and modifying the core source.

Open source can work as a business model for software developers for various reasons. Firstly, only a small proportion of a given piece of software is genuinely original and saleable; the infrastructure around it (storage and communication, for example) might as well consist of an implementation of open standards; if so, it makes sense to share development of this implementation with other companies in a non-competitive manner. Secondly, pyramidal consulting works: making software open makes it easier to devolve support. Lastly, funding small improvements to open source software is economically more efficient than engineering a new solution. Developers work on the things the business cares about and understands. Of course, the revenue margin is likely to be smaller; some estimates are 85% margin on selling licences, and 54% on selling support.

Some open source business work on a dual-licensing model, which allows them to offer a normal open source licence to most customers, and sell support at the same time, but to offer the same software under a closed licence to customers who require the facility to embed the code in their own proprietary systems.

Open source projects (probably the majority) which are not developed as part of a traditional business tend to be classified into two extreme camps:

• A genius programmer creates something which others like. (S)he controls pace and scope of future development. The genius has a complete idea of what the finished software will look like. Changes to the design during the build process are very costly, but the resulting software very polished and uniform.
• A group of people get together to fill a gap and take on different tasks. As time goes by, some drift away and others join in; there is always someone to take over. Design is by consensus, with people working on topics that motivate them. Design changes are relatively cheap but with no over-arching plan the finished program can be patchy. Most projects fall in between. Most of them have a recognised leader, to whom other members defer. A gentle system of leadership challenge and deposition assures the health of the herd is kept up.

The FLOSS study led by Rishab Ghosh (http://flossproject.org/report/) is the best known of a series of studies by economists on how open source works. These studies show that people join an open source project because (in decreasing order of importance):

• it looks technically interesting
• it solves a problem they have
• it looks like an important project

• they know other people involved The desire to learn technical skills by joining an open project is strong. Typical reasons for staying in OSS are:

• improving skills
• ideology
• improving software
• seeking recognition Understanding these motivations is important in the context of educational institutions, because staff and student commitment and interest is regarded as a priority. The fact that working in open source is regarded as a training opportunity is a real consideration.

The perspective of the educational institution

Open source matters to higher and further educational institutions for two main reasons: because it can be cheaper, and because it can be a better match to educational requirements and outlook. As publicly-funded agencies, educational institutions have a legislative responsibility for fiscal responsibility—they have to spend their money wisely. Open source licensing and development methodology may also mean that a piece of open source is better suited for purpose within an education institution than similar proprietary software. Some specific reasons are:

• The ability to tailor the system completely to local needs. Both open and proprietary software are typically both customisable in a shallow sense—institutions can tailor the interface within the bounds given by the programmers. With open source, if an institution needs the software customised in ways not thought of by the programmers, they can have the program changed, either in-house or by a third party.
• Lack of surprises. Open source licences are free and perpetual, so a licence fee increase cannot happen.
• No incentive for theft. Not uncommonly, when proprietary software is used in an educational setting, particularly on the desktop, there is pressure on the students to have the software available at home, and this can lead to theft. With open source software students can download the software free of charge from the internet for their own use.

Apart from these immediate business potentials, how does it benefit an institution if it’s staff are involved in open source? One aspect is potential deep engagement with computer-oriented specialisms. The source code to all open source software is available, so computer-related specialists (computer science, software engineering and hardware engineering) are able to engage very deeply in it. Source code and design discussions can be lifted from the very software that students use every day for use in lectures, assignments, project work and academic research. Even better, students can engage with the communities building that software, both to learn the dynamics of software engineering and to commit their own changes back to the project. On the staff side, we can see advantages in continuing professional development for those who get involved in projects, and good publicity for the institution.

As with evaluating the costs of software, the relative benefits of these will from institution to institution and unit to unit within an institution. In most scenarios open source open source use tends to encourage in-house (or at least local) skills development and spending on human recourses rather than up-front annual fees.

Most institutions are likely to have a dependency of some sort on open source software already. This may be in the form of back-room network systems (DHCP servers, DNS, email relays); of web servers, portal frameworks, and VLE systems; of specialized departments relying on statistical or modelling software; of units doing typesetting using free systems; of staff using web browsers or email clients; or of students studying open source operating systems. While the deployment of proprietary software is often well accounted for, by the counting of licences and auditing of machines, few institutions have seriously looked at either the dependency on, or the cost of, open source.

shows the varying relationships between people and software. In the simplest case, the person deploys the software personally; for more complex software, there is layer of administrators and managers in between; in the most complex case there is an interaction between a content developer, the course administrators, the system administrators and the developers adding new functionality. In all but the first case, the person at the top has no reason to know or care that the software at the bottom is open source; only the intermediate layers of support staff may be concerned with the provenance of the software. In the case of the VLE, the interaction at the top layers relates to data and interoperability standards, not the software itself. Thus from one perspective the dependence on open source is at once both hidden and irrelevant, but it’s existence may underly crucial parts of the institution’s work.

Staff and students in an educational institution sometimes feel that they need not concern themselves with issues of copyright and licensing, and that traditional academic sharing of information will suffice. One of the successes of the open source movement has been to alert particularly computer science professionals about the real importance of properly recording intellectual property rights, and clear licensing rules.

Although free software is sometimes perceived as being anti-capitalist, in fact the reverse is true, and the open source movement is bringing legal rigour to what has sometimes been a poorly-organised area of engineering. This has an important effect on the institution, as it must now provide staff working on open source with clear guidelines about their legal rights. Many academics (staff and students) currently participating in open source projects are not yet aware that they may not be permitted to release institutional intellectual property, by the terms of their contracts.

Open source projects are about more than low-level programming. The usefulness of a system depends not only on its functionality, but also on its user interface, documentation, publicity, error-reporting, and peer-group support. This means that a much wider variety of staff and students than expected may potentially be involved in open source; in some cases without really being aware of it. The casual user of an open source statistical package who maintains a set of usage tips on their home web page is both contributing to the project, and committing institutional resources to it.

Educational institutions have a lot to gain from open source, and must also accept the consequences of their current heavy commitment.

Public policies in the UK

e-GIF

The e-Government Interoperability Framework (e-GIF)[4] is the set of technical policies and specifications mandated for interchange of information between UK Government, its citizens, business, organisations and other governments. It is part of the UK government’s overall e-Government strategy, promoted by the e-Government Unit. The framework uses the web for delivery, and XML-based standards for content and metadata.

e-GIF has four main parts:

• A list of underlying standards, essentially XML as data delivery format, and XSL as transformation language for presentation; specification of XML is more or less universal in initiatives like this. Web services are specified to follow SOAP, UDDI, and WSDL; data modelling is to use UML; data transport is to use Unicode (UTF-8);
• A set of W3C XML Schemas for public sector information; some of these have been defined already, but there is a lot of work remaining to be done;
• A metadata standard, close to the internationally-used Dublin Core;.
• Procedures for keeping the framework up to date with managed change. The standards for information access are conservative. They allow for web browsers back to and including Netscape 4, PDF, Rich Text Format, Word documents and Macromedia Flash. Perhaps surprisingly, Excel spreadsheets and Powerpoint documents are excluded.

Key decisions underlying this list include:

• adoption of XML, and Unicode, as the underlying data standards;
• recognition of the web as the primary delivery format;
• recognition that interoperability is best achieved by use of open standards.

The e-GIF specifications are now at version 6, and work continues on their details and implementation.

UK government open source policy

The policy Open Source Software: Use within UK Government[6] was published by the e-Government Unit of the UK government’s Cabinet Office in October 2004, after research (e.g.[9]), consultation with government agencies, software companies, and open source advocacy groups. The UK Government in this context includes all publicly funded organisations, i.e. central government departments and their agencies, local government, and the education sector. The policy is part of the UK implementation of the EU plan eEurope 2005: An Information Society for all[5], which mandates the governments across Europe to implement interoperability frameworks based on open standards and encouraging the use of open source software.

The policy is quite short, with three key decisions (cited verbatim from the policy) relevant to the discussion in this paper:

• UK Government will consider OSS solutions alongside proprietary ones in IT procurements. Contracts will be awarded on a value for money basis.
• UK Government will only use products for interoperability that support open standards and specifications in all future IT developments.
• Publicly funded R&D projects which aim to produce software outputs shall specify a proposed software exploitation route at the start of the project. At the completion of the project, the software shall be exploited either commercially or within an academic community or as OSS. Unsurprisingly, there is an exemption for the areas of defence, national security and law enforcement. The last one is the most important for us, as it establishes the vital point that all software created with public funds must be exploited in some way, and not left in limbo. The choice is between commercial exploitation, OSS, or within an academic community. Unfortunately, the precise meaning of this last option is not discussed in the policy, and must cast doubt over the useability of the process, since almost any form of restrictive licensing may be covered by this clause.

The e-Government Unit is preparing guidelines on the specific issue of how to choose which licence to use if an OSS route is chosen for exploitation.

Published at the same time as the policy was a report[7] on trials of open source software in government, which concluded that Open Source software is a viable and credible alternative to proprietary software for infrastructure implementations. Note here the word infrastructure, since the report also notes that open source implementations of enterprise-level desktop products are not yet mature enough. The report states that significant cost savings can be achieved by adopting open source (by reducing licensing costs and hardware upgrade requirements), but stresses that planning of migration, consideration of interoperability, training of users, and development of skills for implementation and support will be significant factors in the short term.

The trials report recommended, among other things, that public sector bodies should take the following actions (cited verbatim from the report):

• examine carefully the technical and business case for implementation of Open Source software and the role which OSS could play in current and future projects, …;
• review the potential for server consolidation, comparing the benefits of OSS with proprietary solutions;
• consider the potential costs and benefits of migration to an OSS desktop for transaction users, (potentially in conjunction with use of thin client architecture solutions);
• identify the role of open standards in future IS/IT strategy and policy, in conformance with the e-Government Interoperability Framework (e-GIF);
• consider requirements for the development of skills in Open Source development, deployment and operation within the organisation, and review the availability of such skills in their outsourced IT service providers;
• review their current infrastructure and applications … well in advance of any planned procurement or renewal, and determine whether current technologies and IT policies inhibit future choice; and if so consider what steps may be necessary to prevent future lock in;
• consider the benefits of incremental change by diversifying OSS use beyond the server platform to products like Email, LDAP, Web and internet browser.

There is little in the UK government policy, or the results of its trials, to cause much surprise. They recognise open source as a valid exploitation and deployment method, and note its useful role in giving publicly-funded bodies more choice and potential cost savings; while also stressing the importance of interoperability and open standards for data.

JISC open source policy

The Joint Information Systems Committee (JISC) is tasked with funding an IT infrastructure for UK higher and further education, and its work ranges from supplying the underlying physical network (JANET), directly supporting network services in FE colleges, running advisory services (such as OSS Watch), to funding research into interoperability standards for learning objects. Within this spectrum of work, there has been an increasing recognition that viable long-term software products can emerge from research funding, and that the JISC did not have a coherent policy on how the licensing and exploitation of that should be manged. During 2004, work undertaken by the OSS Watch advisory service on proposing standards for software projects was turned into a coherent policy, which was then submitted to JISC committees for approval in February 2005.[8]

This policy (not yet published) is in three parts: a) guidelines for JISC services and projects in general; b) guidelines for writing calls for funding; and c) detailed guidelines for how to manage the software creation process. The main aim of the first two sections is to establish an environment in which open standards and interoperability are promoted, and avoiding issues regarding digital rights. The third section gives specific rules for the following areas, for which we supply a summary of the policy:

Copyright

It is of paramount importance to establish who owns what, using a formal IPR Register.

Licensing

All software generated by JISC projects should be released under an open source licence, unless an explicit alternative is proposed in the bid.

Trademarks

Use of trademarks to establish reputation and trade on association is up to the project, not the JISC.

Patents

Any patent applications associated with the project should not interfere with free distribution of software.

Dependencies

Projects must record which associated software is needed to make their work run.

Archiving

All documents and software code must have a preservation and archiving strategy.

Testing and quality assurance

All software must have a testing framework in place, and demonstration of standards compliance.

Version control

All software must be developed using version control software, and the history must be preserved by the project.

Sustainability and communities

Projects should, where appropriate, encourage and support user and development communities.

Documentation

Documentation must archive all forms of documentation, including mailing lists and forums.

Software development and maintenance

Software should follow good engineering practice, and be demonstrable to, and testable by, peer communities.

As with the government policy, there is little here which goes beyond common sense and good practice. The most onerous statement is: copyright of software, documentation, design materials, manuals, user interface and source code must be released under an OSI-approved open source licence, unless the bid explicitly argues why this should not be the case and proposes an alternative licence. This puts the burden on a project to consciously reject the open source route at an early stage if it wishes to pursue alternatives. However, the JISC has long maintained a condition that software it has funded must be publicly available, for any use and at no financial cost, throughout UK higher and further education; the simple route of selling licences to peer institutions is ruled out anyway.

The JISC does not make any conditions or suggestions about which open source licence to use, because this is often a contentious area.

Policies for educational institutions

An educational institutional will have a number of strategies relating to IT. This section proposes a series of ideas which are designed to be included in one or more strategy documents.

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 single most important consideration is 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[6].

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 second and third clauses implement the UK government’s policy. The intent of the last clause is to make sure that software developed locally and currently in use is not folded into a proprietary product for which the institution may then have to pay.

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 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.

Conclusions

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.