Licensing, credit and quality for research software

A summary of presentations and discussions on software licencing with RSEs.

Licensing, credit and quality for research software – technical notes

STEP-UP organised a community event on 4 September 2025, which was focused on practical guidance for research software engineers (RSEs) on licensing, publishing, and gaining recognition for research software, while navigating institutional policies and open science principles.

The event was organised by Isabella von Holstein (STEP-UP Community Manager) and delivered by Jeremy Cohen (STEP-UP PI) with a team from Imperial Library Scholarly Communications, consisting of Hamid Khan (Open Science), Yusuf Ozkan (Bibliometrics), Irene Barranco Garcia (Copyright) and Camille Regnault (Research Data). Many thanks to the team for their expertise!

This page summarises the presentations, integrated with insight from the RSEs present during discussion. This summary is written for dRTPs. In the session we also worked through a series of scenarios to explore realistic examples of research software licensing decisions - download these here.

Copyright and intellectual property (IP)

• Software and code are protected under UK copyright law (CDPA 1988), including source code, design materials and databases.
• Structured research data (e.g., spreadsheets, transcripts) may also be protected as literary works.
• Additional protections may apply: database rights, patents (in rare cases), and confidentiality/licensing agreements.
• Details of IP ownership vary by institution e.g. all students at Imperial own their IP (with exceptions), but only undergraduate and taught postgraduate students at King’s.
• Legal advice on software licensing is often expensive and not always accessible within institutions, as it has low priority compared to other institutional matters.
• Institutions may treat software as either a public good or a commercial asset, which require very different responses for licensing.

Licensing software and data

• Absence of a licence defaults to restrictive copyright with reuse prohibited.
• Licences define terms for access, modification, redistribution and attribution.
• Licensing supports FAIR principles: Findable, Accessible, Interoperable, Reusable.
• Open source licences (e.g., MIT, Apache, GPL) are suitable for software; Creative Commons is not. Wikipedia comparison of licence types. Guidance on how to choose your licence.
• If software includes a GPL-licensed component, the entire software must comply with GPL.
• Changing licences between software iterations is legally murky as few cases have been tested in court.
• Standard copyright duration is long: 70 years after the author’s death or 50 years for machine-generated works. These are too long for software lifecycles.
• If a licence changes after you’ve downloaded software, your rights depend on the version you accessed.
• Use the first release year for software attribution; updated versions can carry later dates.

Publishing and citing software

• Software can be published via journals like JORS, JOSS, and SoftwareX.
• Zenodo (via GitHub) allows DOI minting and archiving for software releases.
• Visibility can be increased via hosting code on GitHub, GitLab, BitBucket, or institutional directories.
• There’s no standard platform for tracking software impact. Metrics like GitHub stars, forks, and downloads are options but have flaws and can be easily gamed. “Used by” metrics on GitHub (i.e., other repos that depend on your code) are more reliable. Different communities do things differently. Different types of code attract different types of recognition.
• Web apps linked to code may have greater reach but lack clear metrics.
• The Open Access (OA) citation advantage (~50% more citations) may apply to software too.
• Attaching code to research outputs is essential but only a minority of researchers share code despite far more generating it.

Best practices for RSEs

• Document licensing choices clearly (e.g., include a LICENSE file with your code).
• Include metadata to support discoverability and citation (e.g. via a CITATION file).
• Use version control and release tagging for reproducibility.
• Keep dependencies up to date and check their licences.
• Software environments evolve so your software must adapt too.
• FAIR principles support transparency, equity, accessibility and reliability.
• Reusability can be enabled through the use of installers and packaging; containerisation (e.g., Docker, Podman) is one possible way to support the minimum viable principles of FAIRness.
• Compatibility instructions aren’t always required: just describe the environment used.
• Security risks are rising. Some repositories are being infiltrated by malicious packages.
• FAIR and reliability are distinct but complementary concepts; the FAIR for Research Software working group is exploring this further.

Institutional support and challenges

• Many researchers upload code to GitHub without a licence due to lack of awareness.
• RSEs often bridge gaps between academics and research services. Many academics have only partial expertise in metadata and data management, even in areas where data is used extensively. What is the role of the RSE here?
• Institutional Git platforms offer credibility and infrastructure, but portability concerns remain.
• Narrative CVs (e.g., UKRI applications) are helping broaden recognition of software outputs.
• Case studies are increasingly used as indicators of impact (e.g., for REF). What would you need to document in order for your code to be one?

Supporting dRTPs beyond events

In addition to delivering events, STEP-UP has a number of other activities to grow support for current and future dRTPs, as well as growing the awareness and recognition of the vital work that dRTPs do within the research community.

We are advocating for the development of enhanced career pathways and structures, since these will help organisations to recruit and retain dRTPs. We are working with sector stakeholders and partners to understand career challenges and how dRTP roles can be better reflected in institutional structures.

We’re also setting up secondment and mentoring schemes, as well as a Research Technical Champions scheme aimed at PhD students at STEP-UP’s four project team institutions. We are also developing and delivering training.

Keep up to date by joining our mailing list and following us on Linkedin or Bluesky. And feel free to get in touch if you have questions, suggestions or ideas.”