Open Code Sub-Policy

This is a sub-policy of the University's Open Research Policy which promotes transparency, accessibility, and inclusivity in research by embedding open practices through infrastructure, guidance, and culture.

1. Updates to this policy

1.1 This policy has been updated to align to the new University of Bristol policy management framework. It has also been updated through copy and line edits to enhance clarity and include additional reference to licencing considerations.

Back to top

2. Introduction

2.1 The University of Bristol’s Open Code Sub-Policy supports the institution’s commitment to open research by outlining expectations for researchers to make new source code openly available under appropriate licences, unless specific exemptions apply, and encouraging researchers to responsibly share software developed through publicly funded research, in consideration of statutory requirements such as data protection legislation and export control regulations. By encouraging the publication of reusable code under open licences, the policy supports research practices that maximise public value, collaboration and innovation.

2.2 The term must is used to denote actions that are compulsory or necessary, should denotes best practice and aspiration to lead by example.

Back to top

3. Scope

3.1 The sub-policy applies to all staff and students at the University of Bristol engaged in research activity, or activity in support of research across all disciplines, who develop source code as part of said activities. It is relevant to all new code, regardless of size or programming language, including analysis scripts, compiled programs, configuration data, and documentation. While broadly applicable, it acknowledges that in certain cases – such as where releasing code would compromise unreleased intellectual property, personal or protected data, the security and integrity of research infrastructure, or compliance with export control regulations – it may not be suitable to release code publicly.

Back to top

4. Definitions

4.1 Configuration data: settings, parameters, and information which configures or controls the function of software or systems and shows how it is set up, connected, or secured.

4.2 Database schema: the structure of how data is organised and how data elements (e.g. table names, fields, data types) relate to each other.

4.3 Open Repository: a digital platform that holds and provides free, immediate access to research outputs, including code. Individual materials in an open repository normally hold individual open licences which govern reuse permissions.

4.4 Export Controls, Open access, Open licences, Preprint, Reproducibility, Research output and Transparency  are defined in the University of Bristol Open Research Glossary. The Glossary includes other definitions relevant to Open Research.

Back to top

5. Responsibilities

5.1 Researchers: Responsible, where appropriate, for writing code in the open from the start and publishing it under an open licence in a suitable repository, excluding any sensitive information like secret keys, credentials, personally identifiable data or sensitive data. Detailed responsibilities can be found in Responsibilities of researchers (section 9).

5.2 University of Bristol: Provides guidance and training to support researchers in identifying a suitable repository, determining the appropriate licence(s) for release, and understanding how to publish software using, for example, version control repositories; monitors best practice in this area. Detailed responsibilities can be found in Responsibilities of the University (section 9).

1. Research Support Team (Library Services): In consultation with appropriate institutional colleagues, supports researchers by providing advice on open licences and code repositories, and signposting to appropriate training offerings, which may be internal or external to the University.
2. Research Compliance Team: Advises researchers in regard to research security matters, including steps to meet any applicable legal and regulatory framework requirements; maintains the Research Compliance Initial Assessment tool.
3. Commercialisation Team: Advises researchers on protecting intellectual property before publication, especially where research may have commercial potential.

Back to top

6. Making new source code open

6.1 You should make all new source code open and reusable and publish it under appropriate licences. Or, if this is not possible, provide a convincing explanation of why this cannot be done for specific subsets of the source code.

Back to top

7. What source code should be open?

7.1 All new source code should be open and re-usable, regardless of its size or programming language. Small analysis scripts are just as valuable to the community as large, compiled programs. You should consider any source code you write to be potentially valuable to others, and so worthy of being made open source. This includes:

1. Analysis scripts.
2. Source code for compiled programs.
3. Configuration data for running / managing the program.
4. Database schema.
5. Code to compile, test and/or package your software.
6. Documentation to instruct others how to install, test and use your software.
7. Machine-readable metadata to allow for setting up the environment and dependencies (including their versions) required to run the software.

Back to top

8. Why is it important?

8.1 Publicly funded research depends on public money. So, unless there is a good reason not to do so, the code developed during research should be made available for the public to reuse and build on.

8.2 Open-source code can be reused by other researchers, either directly or to inform the development of new code, thereby avoiding duplication of work and reducing costs for everyone. Publishing source code under an open licence encourages collaboration and interdisciplinary working. It helps others build upon your research, which both increases your reputation as a researcher, and the wider societal impact of your research.

Back to top

9. What does it mean in practice?

Responsibilities of researchers

9.1 Researchers should:

1. Write code in the open from the start and publish it in an open repository - minus any sensitive information, like secret keys, credentials, personally identifiable data, or sensitive data.
2. Use a repository which assigns a Persistent Identifier (PID), such as a Digital Object Identifier (DOI) to the code. This can be used to link a manuscript with a specific version of the code, making it easier to cite the code.
3. Retain relevant legal ownership of the intellectual property in new source code that is created and make the source code available for reuse under an open licence. For information on ownership rights in source code you have created, please refer to General terms and conditions of employment for all staff for members of staff or Intellectual Property Policy for Students for UG and PGR students.
4. Consider the licence conditions of any software libraries or dependencies that their code uses.
5. Disclose whether AI tools have been used to assist with production of code. Such code should meet the same standards as code written by hand.

Responsibilities of the university

9.2 The University’s Research Support team (Library Services), in consultation with appropriate institutional colleagues (e.g. Jean Golding Institute), will provide the guidance and resources to help researchers make their software and code open source, including:

1. Providing advice on which code repositories and which open licences would be suitable for their code.
2. Invest in providing institutional access to code repositories.
3. Delivering and/or signposting to internal and external training opportunities on how to publish software, including the use, for example, of version control repositories.
4. Monitoring best practice in this area in this area to ensure guidance and training is current and relevant.

Back to top

10. When code should not be released

10.1 There are certain cases when it may not be appropriate to release code, including under an open licence. Researchers should consider if they work in a sensitive research area(s) where Export Control Regulations could be applicable. Researchers should previously have completed the Research Project Compliance assessment for their research activity and review any guidance provided by the Research Compliance team before releasing code (whether openly or not).

10.2 You must also not release code that could compromise unreleased intellectual property, other dissemination (including publication) of research results, personal or protected data, or the security or integrity of your research infrastructure.

Unreleased intellectual property (IP)/research results

10.3 If the code makes clear details of intellectual property or research results that have not yet been released, you must keep the code closed until the intellectual property and/or research results have been released. For advice on protecting intellectual property, if appropriate, researchers can contact the Commercialisation Team.

10.4 However, you should develop the code as if it is already open and continue to follow good documentation, development and security practices. You should open the code as soon as possible after the intellectual property and/or the research results have been released.

Personal and protected data

10.5 You must remove any personal or protected data from any code that you make public. This includes any data governed via legislation such as GDPR (e.g., personally identifying data), and any data that is not publicly available via other means (e.g. trade secret data, commercially sensitive data etc). Researchers should consult the University’s Data Protection Policy, where relevant.

Security and integrity of research infrastructure

10.6 You must be careful to not share code that reveals details of the security or sensitive configuration aspects of your research infrastructure. This includes sharing login tokens, passwords, or sensitive details of systems used to manage security or detect fraud or system compromises.

Back to top

11. How will being open help your research?

11.1 Openly publishing your code and data from the beginning of your research will encourage:

1. Clearer documentation, making it easier to maintain it and track changes to it, and for others to use.
2. Cleaner and well-structured code that is easier to maintain.
3. Clarity around data that needs to remain protected and how that is achieved.
4. Suggestions about how the code can be improved or where security can be improved.
5. Others to cite and re-use your work.

Back to top

12. References and further information

1. UK Government Service Standard and Open Source Guidance.
2. Software Sustainability Institute Choosing an Open Source Licence
3. UK Reproducibility Network Open Research Primers
4. Introducing the FAIR principles for research software
5. The Turing Way Guide for Reproducible Research
6. University of Bristol Open Research Policies

Back to top

The University of Bristol’s Open Code Sub-Policy is made available under a CC BY 4.0 License.

The PDF version of the Open Code Sub-Policy available at 10.71706/5ea3d0ad-1457-479a-97f0-fa19f75674f3 is the definitive and authoritative version.