Skip to content

Sharing & licensing

Properly sharing research software involves more than just uploading it somewhere. It involves a series of small decisions: choosing a repository, creating a registry entry, assigning a persistent identifier, adding a citation file, and selecting a license. These decisions make your work findable, retrievable, citable, and legally reusable.

LUMC supports the Open Science principle of being "as open as possible, as closed as necessary". In line with the LUMC strategy 2024-2028, which commits to making research outputs such as datasets, code, and models broadly accessible, openness is the default. Choosing a closed-source approach can be appropriate in cases involving GDPR, intellectual property (IP), medical device regulations, or contractual obligations, but such restrictions require clear justification.

Repository

Any project beyond a quick, one-off script should be kept in version control from the start (e.g., using Git). It should be hosted on a forge—a platform that combines version control with collaboration features (such as GitHub or GitLab). The choice of forge depends on the intended use of the software.

  • LUMC GitLab (gitlab.lumc.nl) is the right home for internal tools, sensitive content, software with patient-data adjacencies, and anything not yet ready for the open world.
  • GitHub is the right home for open-source projects intended for community use. Most of the research-software ecosystem (Zenodo integration, GitHub Actions for CI, well-trodden release workflows) sits there.
  • Public GitLab, Codeberg, or other forges are reasonable when there is a specific governance, license, or platform reason.

What is not an acceptable place for research code:

  • A laptop only (a single disk failure can mean the loss of all code).
  • A shared drive (no history, no diffs, no review).
  • A personal GitHub or GitLab account (when the person leaves, so does the project).

If a repository must be private for legitimate reasons (GDPR, IP, MDR/IVDR, security through obscurity for a small subset of components, contractual obligations), write the reason down in the Software Management Plan (SMP). "Private for now" is fine if there is a plan to open it later; "private indefinitely with no documented reason" is not.

Note also that publishing source code, or describing the method in a paper, is a public disclosure that can foreclose patenting: in Europe (which applies absolute novelty) and most jurisdictions, a disclosure before a patent is filed can permanently bar it. If the software or its underlying method may have patent or commercial value, settle the intention before going public: consult LURIS Legal (lurislegal@lumc.nl) first, and record the IP/patent intention in the SMP. Most research software has no patentable invention and benefits from being open.

In the SMP: record the repository URL, whether it is publicly accessible, and (if not) the specific reason. Plan to revisit the openness decision at every major release.

Registries

A registry is a structured metadata catalog that describes, indexes, and helps discover software. It is distinct from a package repository (PyPI, conda-forge, Docker Hub, CRAN), which hosts installable artifacts. Registry entries primarily support discoverability and citation, while package entries primarily support distribution and installation. You usually want both.

Useful registries depend on the audience:

  • bio.tools - for life-science software; tightly integrated with ELIXIR.
  • Research Software Directory - Dutch-academic-flavoured registry; LUMC and other UMCs have entries here.
  • WorkflowHub - A registry for describing, sharing and publishing scientific computational workflows
  • Zenodo - strictly speaking a deposit/archive, but it issues DOIs and is searchable.
  • Software Heritage - universal archive; assigns a Software Hash Identifier (SWHID) that resolves to a specific commit, even if the original repository disappears.

Using multiple registries is encouraged, as different communities rely on different platforms. Registering in several involves only limited one-time effort.

For a curated, audience-specific overview, see Awesome Research Software Registries, a registry index organized by country, organization, language, and domain.

In the SMP: for each registry, capture the name and the URL or ID of your entry.

Persistent identifiers

A persistent identifier (PID) is a long-lasting, resolvable identifier that remains stable even if the location or metadata of the resource changes. For research software, a common practice is to use a DOI, e.g., minted via Zenodo when archiving a tagged release.

The recommended workflow is short:

  1. Connect your GitHub or GitLab repository to Zenodo.
  2. Tag and push a release in the repository.
  3. Create a GitHub/GitLab Release for that tag.
  4. Zenodo mints a version DOI (specific to that release) and a concept DOI (always resolves to the latest archived version).
  5. Add the DOI badge to your README and the DOI to your CITATION.cff.

The concept DOI is the one you usually want to share in papers and slides - it never goes stale. The version DOI is the one to cite when reproducibility requires exact identity.

For finer-grained provenance, Software Heritage assigns a SWHID to specific commits, trees, or blobs. This is useful when you need to refer to a precise state of the code rather than a release.

Useful resources on identifiers themselves:

  • The DOI System - the canonical reference.
  • DataCite - the registrar behind most research DOIs, including Zenodo's.

In the SMP: record the identifier type (DOI, SWHID, bio.tools ID), the identifier, and which version of the software it corresponds to. For the concept DOI, write concept in the version field.

Citation

A CITATION.cff file in the repository root is the modern way to make software citable. It is plain YAML, machine-readable, and recognized natively by GitHub, GitLab, and Zenodo. When a Zenodo release is created, the CITATION.cff is read automatically and used to populate the deposit's authors and metadata.

A minimal CITATION.cff includes:

  • the software title;
  • authors with ORCID IDs where possible;
  • the version;
  • the release date;
  • the DOI for that version (or the concept DOI);
  • a preferred-citation message, especially if a method paper exists.

The CFF INIT tool generates a valid file from a web form - useful when you are not yet comfortable with YAML.

If a methods paper exists for the software, be explicit in the citation: cite the paper for the method and cite the software DOI for the exact implementation/version.

A practical reference on the whole workflow: The Turing Way - Software Citation with CITATION.cff. For the full CITATION.cff and codemeta.json field-by-field specification, see Software metadata.

In the SMP: the Publications question captures the paper(s) that describe the method, with their DOI/PMID/PMCID. The software DOI lives under Persistent identifiers. Keeping these separate is intentional. A piece of software can outlive its methods paper, or vice versa.

Software license

Without a license, code is "all rights reserved" by default - even if it is publicly visible on GitHub. "Public on GitHub" is not the same as "open source". Without a license, no one (sometimes not even you, depending on your contract) can legally reuse, fork, modify, or build on your code. Even compiling or running the software can constitute a violation in some jurisdictions.

Choose A License - No License explains the implications.

Which license?

In practice, the Apache License 2.0 is a common and sensible default for research software: it is permissive (compatible with most other open licenses, including commercial use), includes an explicit patent grant (advantage over MIT or BSD-3-Clause for software that might touch patentable methods), and is widely understood. Note that this is guidance as there is no official LUMC-wide software license recommendation. If you are unsure which license fits your project, contact the LUMC Research Support Desk (RSD) (contact form).

If you have a specific reason to prefer something else:

  • MIT or BSD-3-Clause - even simpler permissive licenses; lack the explicit patent grant.
  • GPL-3.0 or AGPL-3.0 - copyleft. Forces downstream users to keep their derivatives open under the same terms. Choose deliberately; copyleft is a real constraint on adopters.
  • CC-BY 4.0 - usually for data and documentation, not code. Avoid licensing code under a Creative Commons license, they were not designed for that.

Always use the Software Package Data Exchange (SPDX) identifier (Apache-2.0, not "Apache 2.0"). It is machine-readable and recognized by package registries, GitHub, and most other tooling.

Useful references:

The repository should contain a LICENSE file (the full license text) at the root. Most forges create one for you when you initialize the repository or run a "Choose a license" wizard.

In the SMP: the License question uses the SPDX identifier list (an integrated search via the SciWiz form). If the software is unreleased and you have not yet chosen a license, write down which license you intend to use.

License compatibility

If your software depends on or includes code under other licenses, your license must be compatible with them. Incompatible licenses can:

  • prevent you from distributing the combined software;
  • require you to adopt a more restrictive license;
  • create real legal risks if your code is widely used downstream.

A few practical guidelines:

  • Permissive licenses (Apache-2.0, MIT, BSD-3-Clause) compose easily with each other and with copyleft licenses, but the result is often constrained by the most restrictive component.
  • GPL in a dependency forces the rest of the distributable combined work to be GPL or compatible.
  • CC-BY-NC (non-commercial) dependencies are usually a problem for shared research software. Avoid them in distributable code.
  • For commercial dependencies, read the license carefully before assuming it allows redistribution.

Tooling can do most of the work:

For Level A, a manual check of direct dependencies before public release is acceptable. For Level B/C, automate it in CI so a problematic license added in a dependency update fails the build.

References:

In the SMP: the question asks whether you check dependency-license compatibility, and how. Automated tooling is preferred; manual checks are acceptable for small projects but fragile.

Cost and access model

Most research software is free of charge, and for anything produced under public funding that is the expected default. The question is still worth answering explicitly, because free and open are different claims and users need to know both.

Three cases:

  • Free of charge. No payment, no registration wall. The norm, and needs no justification.
  • Free with restrictions, or for a select group. Access requires an account, a data-use agreement, a collaboration, or an institutional login. Legitimate - a tool bound to controlled data often cannot be otherwise - but write down who qualifies and how they request access, or the restriction becomes an unanswerable question for anyone outside.
  • Commercial. A licence fee, a subscription, or a paid support tier. Involve LURIS Legal (lurislegal@lumc.nl) early: commercialization constrains licensing, and public disclosure before that conversation can foreclose options.

Cost is independent of the licence. Open-source software can be sold, and free-of-charge software can be closed. Record both, and check they do not contradict each other: an Apache-2.0 tool that users must pay to obtain is possible, but it will surprise people unless you explain why.

In the SMP: the Cost question has three states, with a free-text follow-up for restricted and commercial access. Use the follow-up to say who can get access and how they ask for it.

Publications

If a methods paper, preprint, or application-note exists for your software, link it. Capture the DOI (preferred), and where applicable also PMID and PMCID for PubMed-indexed work. Note which version of the software the paper describes.

In the SMP: the Publications list is open-ended. If one exists, list at least the foundational methods paper cited with the software in CITATION.cff.

Further reading