Practical implications of an open source policy for University researchers

by Sebastian Rahtz on 1 March 2005

Introduction

OSS Watch

I am Sebastian Rahtz:

  • Information Manager for Oxford University Computing Services
  • Manager of JISC’s OSS Watch, the UK national Open Source Advisory Service. JISC (Joint Information Systems Committee) coordinates educational IT structures in the UK. Directly funded by the state at the same level as research councils

sebastian.rahtz@oucs.ox.ac.uk

OSS Watch provides unbiased advice and guidance about free and open source software for UK further and higher education.

Objectives

  • Give an overview of what it means to use open source software
  • Outline some recent UK government work
  • Discuss what a university open source policy might say

Technically, what does Open Source mean?

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.Open Source is a development methodology; Free Software is a social movement.

Virtues of free and open source software

  • It has no secrets: the innards are available for anyone to inspect
  • It is not privately controlled: so likely to promote open rather than proprietary formats
  • It is typically maintained by communities rather than single corporations: so bug fixes and enhancement are often frequent and free
  • It is usually distributed free of charge (developers make their money from support, training, customisation and specialist add-ons; not marketing)

Licensing

The three basic licence models for people writing code:
GPL
If you extend a GPL program, or create a composite with it, you cannot release your work except under the GPL and must offer the source code to the full program to everyone you give the program to
LGPL
If you extend an LGPL program, as with GPL. If you create composites with LGPL code you must offer the source code of the LGPL portion, but may retain the source code to your portions
BSD
You must continue to display the copyright notice on any derived work

If a system is built of two parts eg communicating via SOAP, they are considered separate programs.

What about Creative Commons?

This is not about open source, but about simplifying the licensing of creative work in general, and encouraging the release of artistic works under liberal licences.

The CC range of licences covers areas (eg licensing for non-commercial user) which are incompatible with Open Source.

http://creativecommons.org/

The GNU license question

50-80% of OSS uses the GNU General Public License.

The GPL does not require you to release your modified version.

  • You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
  • If you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL. Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.

GPL urban myths exploded

  • You can sell GPLed programs with no problem
  • You can sell support, training and certification for GPL programs
  • The GPL does not apply to things you create with GPLed tools
  • You can change the programs and keep the changes to yourself; so long as you don’t distribute them
  • GPL software does not have any stamp of approval or follow any special standards
  • The copyright owner is not bound by the licence

The current practical picture for OSS deployment

  • Browser 
  • Desktop OS 
  • Content Management System
  • Digital library services
  • Email 
  • Integrated groupware
  • Library catalogues 
  • Network services 
  • Office suite 
  • Payroll 
  • Scientific workstation 
  • Student records 
  • VLE & portal 

Being possible does not make it best

How we choose software

Functionality | Need ——————– Impact | Reliability Interoperability | Support Future direction | Migration Exit strategy | Cost

Open source is a development methodology

  • Programmer commitment, because the programmer is also the user
  • Rapid change, because programmers want to see results
  • Unconstrained specifications, because there is no external client
  • Collective responsibility for the code
  • Response to change, dictated by (perhaps unexpected) user

Open source is about community

Those who merely deploy open source software are also part of the open source community

Why do people keep working on open source?

The desire to learn technical skills by joining an open project is strong. Typical reasons for staying in OSS are:

  • improving skills: 32%
  • ideology 31%
  • improving software: 24%
  • seeking recognition: 12%

Communities of practice

from the world of learning theory, COPs are:

  • informal networks that emerge from a desire to work more effectively or to understand work more deeply among members of a particular speciality or work group.
  • small groups of people who’ve worked together over a period of time and through extensive communication have developed a common sense of purpose and a desire to share work-related knowledge and experience.
  • communities of apprentices where newcomers learn by gradually going from peripheral participation to full participation in the community. Sound familiar? this is how open source works.

  • Learning is presented as a process of social participation in a community, not as a process of internalisation of knowledge by the learner.
  • Legitimate peripheral participation leads to full participation, and this takes place by sociocultural transformations in the context of the shared community of practice.

How to define communities of practice

joint enterprise:
the collective understanding of the community by its members and the accountability to each other
mutuality:
the norms and relationships of members’ mutual engagement
shared repertoire:
the languages, tools, artifacts, etc, produced by the community.

Lave, J. and Wenger, E. (1991), Situated Learning, Legitimate Peripheral Participation, Cambridge, Cambridge University Press.

Open source is about conflict and change

Our industry has an almost totally monopolistic provider:

.NET Single framework No room for choice
Office It does everything It has insufficient security barriers
Windows A smooth upgrade path No room for innovation

It is not easy to decide whether this is good or bad

Open Source Software: UK Government policy

Version 2, 28 October 2004:

  • UK Government will only use products for interoperability that support open standards and specifications in all future IT developments.
  • UK Government will seek to avoid lock-in to proprietary IT products and services.
  • UK Government will consider obtaining full rights to bespoke software code or customisations of COTS (Commercial Off the Shelf) software it procures wherever this achieves best value for money.
  • 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.

Open Source Software Trials in Government

Final Report, 28 October 2004:

On the basis of the empirical evidence and experience reported from the trials and elsewhere, the current study has concluded that: Open Source software is a viable and credible alternative to proprietary software for infrastructure implementations, and for meeting the requirements of the majority of desktop user

The JISC open source policy (draft)

Three parts:

  • Policy guidelines for JISC when writing calls for proposals, ITTs etc
  • Policy guidelines for JISC services (and JISC projects generally)
  • Policy guidelines for JISC-funded software development activities specifically
  • Copyright owner ship of software, diagrams, schemas, documentation, manuals, user interface and source code must be recorded,and may be vested with a JISC-appointed body
  • Projects must maintain an IPR register,listing all contributors to their software and who owns the copyright on contributions
  • The ownership of code which is to be developed in joint projects must be established before work begins

JISC policy and licensing

  • 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.
  • Software must in any case be licensed and publicly available, for any use and at no financial cost, throughout UK higher and further education
  • The open source licence most appropriate in any given circumstances will depend on the mechanism chosen for exploitation and/or on-going development.

A university problem?

We need to deal with:

  • individuals contributing to open source software
  • staff creating software which they want to open source
  • teachers making online resources
  • research projects collaborating with industry
  • partnerships with other academic institutions
  • any act of creation generates copyright—it does not have to be claimed
  • most academic contracts specify that all creations are property of the employer
  • usually, there are specific exclusions for books and articles
  • copyright in learning materials is usually claimed by the university
  • the employee has a duty to assist the university in exploiting any created material
  • software is hard (but not impossible) to patent

Difficulties arising

  • the university’s exploitation system for software only knows about selling licenses
  • the university does not have a revenue-sharing arrangement for consultancy-based exploitation
  • the lawyers are reluctant to sanction open source exploitation because they see it as liability without revenue
  • if the university relinguishes copyright, it is at the risk of having to buy back a later release of the product

Examples of (e-learning) open source exploitation in academia

uPortal
portal framework, development by top American universities (stone soup group) to meet their specific needs
Bodington
Small UK open source VLE, developed by Leeds, Oxford, UHI; community based on shared problems
Moodle
Simple but very effective VLE, distinguished by its exemplary open source community
LAMS
innovative e-learning mediating framework from Australia, new work being funded under an open source model

Towards a university open source policy?

  • Open source release is a viable method of exploiting a software invention
  • Staff involved in software development must allowed to share in the income from consultancy- and training-based exploitation
  • All IPR generated by the University staff must be recorded in a central register
  • IPR in non-exploitable software (including patches to existing projects) will be assigned to an independent body controlled by the university which will release it using an open source licence

Depending on your viewpoint

The current excitement and debate about free/libre/open source software is:

  • Just politics relating to the current Microsoft monopoly, it’ll go away
  • A legal and cultural sea change, which will take years to follow through
  • A technical matter of software engineering
  • Just trivia for sandal-wearing bigots to worry about

Conclusions

  • Embracing open source software is an attitude, not a binary choice
  • Can you define the costs of flexibility of choice versus a single unified vision?
  • Standards for your data are as important as current ease of use
  • There is no stasis. Things will always change