This Open Source policy is designed to apply to activities funded by Jisc and has two parts. The first related to all Jisc-funded projects and services, the second relates specifically to projects and services which generate software as core output.

Policy on open source software for Jisc projects and services

Policy summary

This open source policy [1] is designed to apply to activities funded by Jisc, and has two parts. The first relates to all Jisc-funded projects and services, the second relates specifically to projects and services which generate software as a core output.

Guidelines for all Jisc services and projects

These points apply to all projects and services funded by Jisc, including both development activities and services providing advice and guidance to the higher and further education communities.

  • Advice and guidance to the communities Jisc serves must be neutral and unbiased, and must not discriminate between open source and closed source software products
  • Documentation, graphics, sound, data and other files must, wherever possible and practicable, use open standards [2]
  • All outputs must be released in a form with no digital rights management (DRM) restrictions [3]
  • All outputs must have clear copyright statements indicating the ownership of the copyright on the output and the licence under which it is being distributed [4]

Guidelines for projects and services involving software development

This part of the policy applies to services and projects which are specifically funded by the Jisc to produce software.

Copyright

Copyright exists on all written texts and performances, including many outputs from Jisc projects and services.

  • Copyright ownership of software, diagrams, schemas, documentation, manuals, user interface and source code must be recorded, and would normally be vested with Jisc [8]
  • Projects must maintain an IPR register, listing all contributors to their software and who owns the copyright on contributions [9]
  • The ownership of code which is to be developed in joint projects would normally rest with Jisc but must be established before work begins[10]
Licensing

Licensing is the action of a copyright owner permitting others to use a work under specified conditions.

  • Software, documentation, design materials, manuals, user interface and source code should be released under an OSI-approved open source licence by the copyright holder, [11], unless the agreement specifies an alternative licence
  • Software should in any case normally be licensed to the Jisc community on the best and most open terms possible [12]
  • The open source licence most appropriate in any given circumstances will depend on the mechanism chosen for exploitation and/or on-going development. It is also likely to depend on the restrictions imposed by pre-existing IPR in the software or any libraries and other components (if any) used in its development. Jisc will issue advice and guidance on best practice in open source software licensing from time to time as circumstances dictate [13]
Dependencies

Dependencies are items of hardware and (usually pre-existing) software which the software in question depends upon [17].

  • Projects must state what build-time and run-time dependencies the developed software has and the licences applicable to these dependencies: dependencies include the operating systems, compilers, development environments, web servers and similar software needed to build and/or run the software [18]
  • Projects should state the licences applicable to these dependencies.
  • Where reasonable alternatives exist, projects must choose OSI-approved licensed dependencies over non OSI-approved licensed dependencies [19]
Archiving

Archiving is the medium to long term preservation of documents, images, source code and software. Archiving is necessary both to meet legal obligations and to preserve valuable software and content for re- use. All electronic outputs must be archived in a repository with a written preservation strategy [20].

Testing and quality assurance

Testing plays a large role in quality assurance of software. It is also pivotal in building trust between distributed development teams and communities of contributors [21].

  • Projects which develop software must have appropriate testing systems in place
  • Software which cannot meaningfully be demonstrated to end users must use automated testing, and include documentation explaining what is being tested and how
  • Software components being developed as part of a larger framework should use automated testing
  • Where software implements specified standards there must be testing for compliance with these standards
Version control

Version control systems [22] allow tracking of who changes files (often source code, but equally documents or images), when they change them, why they changed them and any bugs that may have been fixed by the change. They are used to determine changes between versions of the system; to assist in diagnosis of newly discovered bugs; and also to compile a list of all contributors for IPR issues.

  • Intermediate versions of software must be retained
  • Projects with more than 2 institutions or 3 contributors must use a multi-user version control system
  • The full change history must be retained and it must be archived as above
Sustainability and communities

Many open source projects are supported by community effort, and the Jisc is keen to encourage broad participation and contribution to open source projects.

  • Projects must state in their bid whether they foresee the project continuing beyond the timespan of the funding, and if so whom they see participating in the project
  • Projects should engage with end users and other parties to encourage and build self-sustaining communities
  • Projects should facilitate the use of their software in other UK HE and FE institutions
  • Projects may facilitate the use of their software in the wider community [23]
  • Projects should accept bug reports, patches, translations and feedback from contributors outside the project
Documentation

Documentation is vitally important if software and systems are to be understood by those not intimately involved in its creation.

  • Projects which use internet relay chat, mailing lists, forums or similar media for coordinating software development, reporting bugs or answering user queries must archive these and should store them in a format readably accessible to search engines [24]
  • Projects may remove personal information from documentation before making it publicly accessible
Software development and maintenance

Software development is the process of developing software, and subsequently maintaining it to meet on- going changes in the organisational and computing environment.

  • Projects should release incremental milestone releases of working but incomplete software [25]
  • Projects must demonstrate their software working with third party software, data, documents, processes and/or environments, as appropriate
  • Projects should demonstrate third party software working with their software, data, documents, processes and/or environments, as appropriate [26]
  • During demonstrations projects must make clear which components have been solely developed by the project; which the project has contributed to; which have been written by the project using resources other than those from the Jisc funding; and which are entirely third party [27]
  • Demonstrations must be to independent peers, and should be accessible on the web or be downloadable or be available as live CDs

  • Projects demonstrating software which is challenging to demonstrate to peers and funders may include testimonials from users in the wider community to support their demonstration. Testimonials must be from qualified individuals knowledgeable in the field

Explanatory notes

  1. Text in these notes is not part of the policy but explanatory text, explaining either the justification, practical impacts or intent of the policy.  Much of the policy is derived from relevant legislation, including Government policy on the use of Open Source Software within the UK government.
  2. Open standards are necessary to ensure the durability of archived outputs. Open standards are written descriptions of formats or processes which are maintained by a public body (such as the ISO, the W3C, or the IETF) in the public interest. XML is an open standard issued by the W3C and implemented, for example, by Apache Xerces, Microsoft XML Parser and IBM XML4J. The Microsoft Word file format is not an open standard because it is maintained by Microsoft, who can change it for commercial reasons which may impact on compatibility and interoperability. It is recognised that some use of proprietary formats is inevitable in the short term to ensure widest dissemination of Jisc outputs, but the aim should be to strive for use of open standards for all Jisc outputs in the longer term.  The UK Government's e-GIF guidelines discuss data standards in some detail.
  3. Word, Excel, PDF and similar documents may need to be checked for DRM restrictions.
  4. This enables the Jisc and all involved parties to be clear about their rights to quote from, archive, copy and redistribute documents and other outputs.
  5. This condition is met by the overwhelming number of Jisc calls already.
  6. Allowing the vendors of proprietary software to set the time scale for financial comparisons has historically enabled them to offer low prices in the initial licensing period, and then to increase the licence fees significantly faster than inflation in subsequent periods.
  7. This is required to meet legal obligations for archiving. It also greatly enhances the ability of diverse hardware and software to read, write, modify and distribute documents.
  8. Standard employment contracts transfer most copyrights from creators to their employers. The situation is less clear where outside contractors are used.
  9. Note that this includes external contributors.  It is vitally important that everyone contributing to a project is aware of the copyright in each item of intellectual property made use of in a project, and the licence governing its possible uses.  Project management procedures should not only require an IPR register incorporating this information to be kept (and kept up to date), but should also include measures to make sure that project staff are aware of the register and required to consult it.
  10. Experience suggests that negotiating copyright issues once a project is under way or completed is significantly harder than negotiating them prior to launching the project, particularly when there are several institutions and/or external parties involved.
  11. The OSI website has a list of licences, criteria for new licences and background rationale.
  12. This is the minimum requirement which has always been a condition of Jisc funding.  In cases where commercial exploitation is a possibility projects may wish to explore dual licensing, under which the software is made available under a commercial licence for exploitation in the commercial market but is also available under an open source licence (in this case normally GPL or LGPL) for open source developers.
  13. The e-Government Unit is expected to issue its own guidelines on open source licensing practices within the next few months.  When this has happened it may be appropriate for the Jisc simply to refer to the e-Government Unit's advice.
  14. Trademarks are brand and community building tools and are frequently key to building self-sustaining communities, groups and products.
  15. Software patents are complex and prone to failure when tested in court. Claiming patents on funded work would expose Jisc to considerable legal burden if the patents were challenged.
  16. The intent is to avoid projects using patents to prevent software from being used in the manner intended by its licence.
  17. If a dependency is unavailable (or unreasonably expensive) for licensing reasons, then the software which depends on it effectively also becomes unavailable or unreasonably expensive. Some dependencies are necessarily expensive (telescope control software is typically useless without an expensive telescope), but some are simply unnecessary (there will usually be no need to write software based on expensive graphics packages if much cheaper or free alternatives exist).
  18. This allows parties interested in reusing software to determine which software they must also buy or licence.
  19. Projects should be aware that certain dependencies restrict their choice of OSI-approved licence; in particular, compiling with GPL licensed code ls likely to require that the software is then released under the GPL.
  20. The intent is to ensure that the software Jisc pays to have produced is not lost. SourceForge is a convenient archive service for open source projects' outputs.
  21. Testing includes operations such as: validating generated web pages against an XHTML validator and validating XML inputs and outputs against their DTD or schema, as well as more structured techniques such as unit testing with JUnit or NUnit. The testing approaches used in a project will vary according to the nature of the software being created, its intended uses, and the size of the project.
  22. Applications such as CVS, Subversion and SourceSafe may be used to meet these requirements. Organisations such as SourceForge provide these as a free service for open source software projects.
  23. Facilitation of use could include distribution of an installable or runnable demonstration, running workshops for installers or end users, making a web interface to the software available on the web or allocating person-hours for answering emails on a mailing list.
  24. Making documentation available to search engines allows people to solve their own problems based on previous answers to similar questions.
  25. Early, public, milestones encourage engagement of and buy-in from user and broader development communities, ensuring that requirements have been correctly captured and are being addressed.
  26. Standalone, single install, software is of decreasing use. Software that has not been tested and demonstrated to work in other organisational and computing environments is not very useful.
  27. This is mainly a clarity of attribution issue.

Original authors Stuart Yeates and Sebastian Rahtz (OSS Watch) Subsequently revised by Jisc Last revision (Matthew Dovey) 20 December 2012

Guidelines for projects and services involving software development
This part of the policy applies to services and projects which are specifically funded by the Jisc to produce software.