FAIR Software: How FAIR4RS Diverges from FAIR for Data, Principle by Principle

Most guidance on “FAIR software” restates the four FAIR letters and swaps the word data for the word software. That is not what the FAIR4RS Principles actually did. The FAIR for Research Software Working Group — convened jointly by the Research Software Alliance (ReSA), FORCE11 and the Research Data Alliance — added two sub-principles, deleted one, promoted one from a third-level clause to a top-level principle, and rewrote another from scratch. The result is 17 numbered guiding principles where FAIR for data has 15, and the differences are exactly where the software-specific work sits.

This page sets the two documents side by side clause by clause, explains why each change was made, and turns the differences into a checklist you can run against a real research codebase. It does not re-explain FAIR for data — if you need that, start with How to Make Your Dataset FAIR and come back.

Two things FAIR4RS is not

It is not a software citation standard. The FORCE11 Software Citation Principles (Smith, Katz & Niemeyer, 2016) are a separate document answering a different question — how software already in existence should be cited in the scholarly record. FAIR4RS asks how software should be made findable, accessible, interoperable and reusable. Well-cited software can be entirely un-FAIR, and FAIR software can go uncited. There is no merged “FAIR4RS Software Citation Principles” document, despite the phrase circulating.

It is not an open-source policy. Principle R1.1 requires a clear and accessible licence; it does not require an open-source one, and A1.2 explicitly preserves authentication and authorisation “where necessary”. FAIR and open are separable in FAIR4RS exactly as they are in FAIR for data.

What counts as “research software” under FAIR4RS

The scope definition is load-bearing and routinely skipped. The Working Group defines research software as including “source code files, algorithms, scripts, computational workflows and executables that were created during the research process or for a research purpose.” It then draws a line most implementers miss:

“Software components (e.g., operating systems, libraries, dependencies, packages, scripts, etc.) that are used for research but were not created during or with a clear research intent should be considered software in research and not Research Software. This differentiation may vary between disciplines.”

So the compiler, the operating system and the third-party statistics library your analysis imports are software in research, not research software. They are not yours to make FAIR — but under R2 they are yours to reference. That distinction determines the scope of your compliance work, and the Working Group itself flags that the boundary shifts between disciplines.

The clause-by-clause cross-walk

Original wording from Wilkinson et al. (2016) on the left, FAIR4RS v1.0 (2022) on the right.

FAIR for data (2016)	FAIR4RS (2022)	What changed
F1 — (Meta)data are assigned a globally unique and persistent identifier	F1 — Software is assigned a globally unique and persistent identifier	Substantively carried over. The interesting work moved into two new children.
no equivalent	F1.1 — Components of the software representing levels of granularity are assigned distinct identifiers	New. Software is composite: a suite, a package inside it, a module inside that.
no equivalent	F1.2 — Different versions of the software are assigned distinct identifiers	New. A dataset is normally fixed at deposit; software has a release history.
F2 — Data are described with rich metadata	F2 — Software is described with rich metadata	Carried over.
F3 — Metadata clearly and explicitly include the identifier of the data they describe	F3 — Metadata clearly and explicitly include the identifier of the software they describe	Carried over.
F4 — (Meta)data are registered or indexed in a searchable resource	F4 — Metadata are FAIR, searchable and indexable	Rewritten. The requirement is now on the metadata’s own FAIRness, not merely on the existence of a searchable host.
A1, A1.1, A1.2, A2	A1, A1.1, A1.2, A2	Carried over almost verbatim with software substituted. Accessibility was the least software-specific quarter of the framework.
I1 — (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation	I1 — Software reads, writes and exchanges data in a way that meets domain-relevant community standards	Rewritten entirely. From a description requirement to a behavioural one at the I/O boundary — a requirement only something executable can satisfy.
I2 — (Meta)data use vocabularies that follow FAIR principles	dropped	Removed. No FAIR4RS counterpart.
I3 — (Meta)data include qualified references to other (meta)data	I2 — Software includes qualified references to other objects	Renumbered I3 → I2 following the deletion above.
R1 — (Meta)data are richly described with a plurality of accurate and relevant attributes	R1 — Software is described with a plurality of accurate and relevant attributes	Carried over.
R1.1 — (Meta)data are released with a clear and accessible data usage license	R1.1 — Software is given a clear and accessible license	Same clause, materially different instrument: a data licence is not a software licence.
R1.2 — (Meta)data are associated with detailed provenance	R1.2 — Software is associated with detailed provenance	Identical wording; in practice this means development history, not curation history.
no equivalent	R2 — Software includes qualified references to other software	New. Dependencies. The single most software-specific clause in the document.
R1.3 — (Meta)data meet domain-relevant community standards	R3 — Software meets domain-relevant community standards	Promoted from a third-level clause to a top-level R principle.

The foundational statements changed too, and the R one is the clearest single sentence on why any of this was necessary. FAIR for data treats reusability as a description problem. FAIR4RS states: “Software is both usable (can be executed) and reusable (can be understood, modified, built upon, or incorporated into other software).” Usability-as-executability has no analogue on the data side at all.

The five divergences that actually change your work

1. Versioning is a first-class identifier requirement (F1.2)

A dataset normally gets one DOI at deposit. Software gets a release history, and F1.2 requires each version to be separately identifiable. In practice this is the Zenodo pattern: a concept DOI that always resolves to the latest release plus a distinct version DOI per release, minted automatically when you enable Zenodo’s GitHub integration and cut a tagged release. Cite the version DOI when reproducibility matters and the concept DOI when you mean “the software”; they are not interchangeable.

F1.2 says nothing about how you number versions. Semantic Versioning (semver.org — MAJOR.MINOR.PATCH, where MAJOR signals an incompatible API change) is the dominant convention and makes R2 dependency declarations meaningful, but it is a community convention, not a FAIR4RS requirement. Calendar versioning satisfies F1.2 equally well.

2. Granularity is a decision you now have to make (F1.1)

F1.1 asks for distinct identifiers for “components of the software representing levels of granularity”. Nothing in the principles tells you where those levels stop — whether a monorepo’s individual packages need their own identifiers, or a workflow’s individual steps. The Working Group listed “identification targets” among the areas needing further standardisation, so treat this as genuinely unsettled: record the granularity decision you made and why, rather than claiming compliance.

3. Interoperability became a runtime property (I1)

The data-side I1 is about describing yourself in a shared knowledge-representation language. The software-side I1 is about what your program does when it reads and writes: it must exchange data in formats meeting domain-relevant community standards. This is testable behaviour, not documentation — and it is why the deleted FAIR-vocabularies clause (data I2) had nowhere sensible to land.

4. Dependencies are compliance artefacts (R2)

R2 has no data equivalent because datasets do not have dependencies. “Qualified references to other software” means the reference is machine-readable and states the nature of the relationship — a lockfile, a requirements.txt with pins, a DESCRIPTION file, a CodeMeta softwareRequirements entry, or a container definition. The FAIR4RS paper’s own worked example points at CodeMeta’s softwareRequirements field for exactly this purpose.

Whether a container image alone satisfies R2 is not settled by the principles. A container captures the environment but does not, by itself, produce a machine-readable statement of which software the work depends on and how — see Reproducibility Infrastructure for where containers do and do not help. The defensible position is to ship both a declared dependency manifest and an environment capture.

5. FAIR4RS starts at the first commit, not at deposit

The paper is explicit that this is a process difference, not just a content one: making data FAIR “is typically done when the data is published to an archive”, whereas open-source software “ideally should start working toward satisfying the FAIR4RS Principles when it is initially being developed since it may be used by others directly from its development environment.” A licence file added at submission time is FAIR-for-data thinking applied to software; every clone taken before that point was taken under no licence at all.

Checklist for a research codebase

Grouped by the principle each item satisfies. Nothing here is mandated tooling — the principles are deliberately implementation-neutral — but each row names an artefact that demonstrably discharges the clause.

Findable

• F1 — the archived releases carry a persistent identifier: a DOI (Zenodo, HAL, an institutional repository) or a Software Heritage SWHID, or both. A GitHub URL is not a persistent identifier; the account, the repository name and the history can all change.
• F1.1 — you have written down which components get their own identifiers and which are covered by the parent’s, and why.
• F1.2 — every release is separately resolvable. If you use Zenodo’s GitHub integration, confirm you can distinguish the concept DOI from the version DOI in your own documentation.
• F2 — machine-readable metadata lives in the repository root, not only in a README: a CITATION.cff file, a codemeta.json, or both.
• F3 — that metadata file contains the identifier of the software it describes. A CITATION.cff with no doi or identifiers block fails F3 while looking complete.
• F4 — the software is in at least one registry or catalogue that exposes structured, indexable metadata independently of your repository (a domain catalogue, a language package index, a research software directory).

Accessible

• A1 / A1.1 — retrieval works over an open protocol from the identifier alone, with no account or manual request step.
• A1.2 — where access genuinely must be restricted, the restriction is at the retrieval layer and the metadata remains open.
• A2 — the metadata record survives the code. This is the specific reason to be in an external registry or archive rather than relying on the repository host: if the repository is deleted, the record still resolves.

Interoperable

• I1 — input and output formats are the domain’s standard formats, and the documentation names them explicitly. Where your domain has no agreed format, say so in the documentation rather than implying compliance.
• I2 — references to external objects (datasets, ontologies, specifications, papers) are given as resolvable identifiers with a stated relationship, not as bare URLs in prose.

Reusable

• R1 — the metadata describes authorship, purpose, version, and contact, not just a title.
• R1.1 — a LICENSE file exists in the repository from early in its life, and the licence named in CITATION.cff/codemeta.json matches the file. Mismatched licence declarations are one of the most common findable defects.
• R1.2 — provenance means development provenance here: a real commit history, tagged releases, a changelog, and contributor records. A single squashed “initial commit” containing three years of work satisfies R1.2 poorly.
• R2 — a machine-readable dependency manifest with resolvable versions, plus an environment capture (container definition, lockfile, or environment file) for anything version-sensitive.
• R3 — you can name the domain-relevant community standards you are meeting. If your domain has not agreed any, R3 currently has no determinate content for you — record that rather than asserting compliance.

Where FAIR4RS is genuinely unsettled

These are not gaps in this page; they are open questions the Working Group itself identified as needing “increased standardisation of community practices” — specifically metadata and identifier authority, metadata vocabularies and properties, software identifiers, domain-relevant community standards, and identification targets.

• There is no single required metadata schema. CodeMeta (a schema.org-based crosswalk for software metadata), Citation File Format, .zenodo.json and registry-native records all satisfy F2, and they overlap imperfectly. A practical gotcha worth knowing: where a repository contains both a CITATION.cff and a .zenodo.json, Zenodo uses the .zenodo.json and ignores the CFF file for that deposit.
• R3 is only as concrete as your discipline is. Bioinformatics has mature catalogue and format conventions; many fields have none. R3 is aspirational by design.
• Automated assessment is immature. F-UJI, the best-known automated FAIR scorer, evaluates datasets against the data principles — it is not a FAIR4RS assessment and should not be reported as one. Community checklists exist for software (fair-software.eu sets out five recommendations covering repository, licence, registry, citation and a checklist badge), but they are lightweight community guidance, not an official FAIR4RS conformance test, and a passing badge is not a compliance claim.
• Composite and service-shaped software strain the framework. The principles were written with distributable artefacts in mind; software you can only access as a hosted service raises unresolved questions under F1.2 and A2.

Frequently asked questions

Is FAIR4RS the same as FAIR for data?

No. FAIR4RS adds two sub-principles (F1.1 granularity identifiers, F1.2 version identifiers), adds R2 (qualified references to other software), promotes the data principles’ R1.3 to a top-level R3, drops the data principles’ I2 (FAIR vocabularies) entirely, and rewrites I1 from a knowledge-representation requirement into a data-exchange one. Seventeen numbered principles against fifteen.

Does making my software FAIR mean making it open source?

No. R1.1 requires a clear and accessible licence, not a permissive or OSI-approved one, and A1.2 explicitly allows authentication and authorisation where necessary. Openness helps with several principles in practice but is not what any of them require.

Do I need a DOI, or is a GitHub repository enough?

A repository URL is not a persistent identifier under F1: repositories can be renamed, transferred, force-pushed or deleted. Satisfying F1 and F1.2 means an archival deposit that mints identifiers per release — Zenodo’s GitHub integration is the common route — or Software Heritage’s content-addressed SWHIDs, or both, since they solve different halves of the problem.

What is the difference between FAIR4RS and the FORCE11 Software Citation Principles?

FAIR4RS (2022) governs how software is made findable, accessible, interoperable and reusable. The FORCE11 Software Citation Principles (2016) govern how software is cited — importance, credit and attribution, unique identification, persistence, accessibility and specificity. Related communities, overlapping authors, different questions. For the citing side of the problem see How to Cite Software, Code and R Packages.

Does a CITATION.cff file make my software FAIR?

It contributes to F2 and F3 and supports R1, and Zenodo will read it to populate a deposit’s metadata. It does nothing for F1.2 versioning, I1 data-exchange formats, R2 dependency declaration or R3 community standards. It is one artefact among several, not a compliance shortcut.

Are my third-party libraries in scope?

Not as objects for you to make FAIR. Under the Working Group’s definition they are “software in research” rather than research software, because they were not created with research intent. They are in scope as references: R2 requires your software to declare them.

Is there an official FAIR4RS certification?

No. The principles are explicitly aspirational, there is no conformance test, no certifying body and no authoritative score. Any claim of “FAIR4RS certified” should be read as a self-assessment.

Sources

• Barker, M., Chue Hong, N.P., Katz, D.S., Lamprecht, AL., Martinez-Ortiz, C., Psomopoulos, F., Harrow, J., Castro, L.J., Gruenpeter, M., Martinez, P.A. & Honeyman, T. “Introducing the FAIR Principles for research software.” Scientific Data 9, 622 (2022). doi:10.1038/s41597-022-01710-x — open access; source of the verbatim principle text used above.
• Chue Hong, N.P. et al. “FAIR Principles for Research Software (FAIR4RS Principles), Version 1.0.” Research Data Alliance, 2022. doi:10.15497/RDA00068 — the RDA Recommendation itself.
• Wilkinson, M.D. et al. “The FAIR Guiding Principles for scientific data management and stewardship.” Scientific Data 3, 160018 (2016) — the fifteen data principles, as published at go-fair.org/fair-principles.
• Smith, A.M., Katz, D.S. & Niemeyer, K.E. “Software citation principles.” PeerJ Computer Science 2:e86 (2016).
• CodeMeta (codemeta.github.io), Citation File Format (citation-file-format.github.io), Semantic Versioning (semver.org), Software Heritage (softwareheritage.org), fair-software.eu.

Related CASRAI resources

• FAIR4RS (FAIR Principles for Research Software) — the definitional entry
• FAIR Data Principles and How to Make Your Dataset FAIR — the data-side framework this page diverges from
• Reproducibility Infrastructure: Workflows, Containers, and Code Sharing — the tooling layer under R2 and R1.2
• How to Cite Software, Code and R Packages and Citation File Format (CITATION.cff)
• Software management plan (SMP) — where these requirements get committed to in advance
• RO-Crate — packaging software, data and metadata together
• JOSS and RSE Co-Author or Acknowledged Contributor? — the credit side of research software
• Research Data Management — the full cluster