FAIR4RS (FAIR Principles for Research Software)

FAIR4RS (short for FAIR Principles for Research Software) is the 2022 adaptation of the FAIR Data Principles to software, published as an official Research Data Alliance (RDA) Working Group output, developed jointly with FORCE11 and the Research Software Alliance (ReSA), and led by Chue Hong, Katz, Barker and around 70 co-authors (Version 1.0, DOI 10.15497/RDA00068). FAIR4RS answers one specific question: how should research software be made Findable, Accessible, Interoperable and Reusable? It is not a citation standard — see ‘How FAIR4RS differs from the FORCE11 Software Citation Principles’ below.

Operational definition

Software qualifies as FAIR4RS-compliant to the extent it satisfies the four top-level FAIR categories — Findable, Accessible, Interoperable, Reusable — carried over from the original Wilkinson et al. FAIR Data Principles (2016), but with sub-principles rewritten for what makes software different from a static dataset: it is executable (it does something, not just describes something), typically versioned across a release history rather than fixed at one point in time, and dependency-bound (it usually cannot run, or be understood, without a declared stack of other software). Those rewrites are not cosmetic: FAIR4RS adds two sub-principles the data principles have no equivalent for, drops one, promotes another to top level and rewrites a fourth outright — set out clause by clause in how FAIR4RS diverges from FAIR for data. Practically, an assessment of a software package against FAIR4RS looks at whether it has: a persistent identifier and rich, machine-readable metadata (Findable); a documented, ideally standardised access/retrieval protocol, with metadata that persists even if the software itself is removed (Accessible); use of community-standard formats, APIs and controlled vocabularies for interoperation with other software and workflows (Interoperable); and a clear licence, provenance/authorship metadata, and enough documentation of its dependencies and build/run environment to be reused or rerun by someone else (Reusable).

Examples

• A research software package deposited to a registry (e.g. the Software Heritage archive or a language-specific package index) with a DOI, a machine-readable CITATION.cff file, an OSI-approved licence, and a declared dependency manifest (e.g. a lockfile or container definition) is demonstrating FAIR4RS-aligned practice across all four categories at once.
• A lab publishing successive tagged releases of an analysis pipeline (rather than only a single “latest” copy), with each release separately citable, addresses the Findable and Reusable principles’ explicit handling of versioning — a concern the original FAIR data principles did not need to address in the same way.

Counter-example

A script uploaded once to a personal GitHub account with no licence file, no version tags, no dependency list, and no persistent identifier is not FAIR4RS-compliant even if the code itself is technically correct and the repository is public — “publicly accessible” is not equivalent to “Findable, Accessible, Interoperable and Reusable” under the principles; each of the four categories has to be separately addressed.

How FAIR4RS differs from the FORCE11 Software Citation Principles

FAIR4RS and the FORCE11 Software Citation Principles are two distinct documents from overlapping communities that are frequently, and wrongly, treated as one. FAIR4RS (RDA/FORCE11/ReSA, 2022) addresses how software should be made FAIR — its findability, access, interoperability and reusability as an artefact. The FORCE11 Software Citation Principles (Smith, Katz & Niemeyer, 2016, PeerJ Computer Science) address a narrower, different question: how software that already exists should be cited in the scholarly record — what a citation should contain and why software authors deserve credit. Software that is well cited is not automatically FAIR (a citation can point at a poorly documented, unlicensed, unversioned repository), and software that is FAIR is not automatically well cited (good metadata does not by itself guarantee authors get credited in downstream papers). The two efforts are complementary and share contributors and community home (FORCE11’s Research Software Citation Working Group drew directly on FAIR4RS thinking about software’s distinct nature), but they are not the same document, do not have the same authors, and do not answer the same question. Treat any single page or citation that presents “the FAIR4RS Software Citation Principles” as one document with caution — no such merged document exists.

Related terms

• FORCE11 Software Citation Principles — the separate 2016 standard for citing software
• Citation File Format (CITATION.cff) — the machine-readable file format most commonly used to implement software citation metadata
• JOSS (Journal of Open Source Software) — a peer-reviewed venue for publishing research software itself
• FAIR Data Principles — the original 2016 principles FAIR4RS adapts
• FAIR software: the clause-by-clause cross-walk against FAIR for data — plus a practical checklist for a research codebase
• Research Data Alliance (RDA) — the body that hosted the FAIR4RS working group
• FORCE11 — co-developer of FAIR4RS and separate home of the Software Citation Principles

References

• Chue Hong, N.P., Katz, D.S., Barker, M. et al., “FAIR Principles for Research Software (FAIR4RS Principles)”, Version 1.0, Research Data Alliance, 2022. DOI: 10.15497/RDA00068.
• Wilkinson, M.D. et al., “The FAIR Guiding Principles for scientific data management and stewardship”, Scientific Data 3, 2016 (the original data-focused principles FAIR4RS adapts).