Self-assessment for FAIR research software

How to use this page

If you are a research software author, please answer the questions below to assess your software's FAIRness. As you go through them, the progress bars at the bottom of the screen will update according to your answers. When you're done with the questions, copy the badge at the bottom of the page and put it in your software's README. Read more.

This way, you

Promote transparency: the badge links back to this page, and contains the required data to check the appropriate answers. This way, users of your software can easily get an idea of the FAIRness state of the project.
Discover best practices: as you go through the questions, you may learn about practices to improve FAIRness that you were not aware of previously.
Become an ambassador of FAIR: By putting the badge in your README, your project will help promote the previous 2 aspects.

The questions are inspired by ARDC's FAIR data self-assessment tool and by the outcomes of the FAIR4RS Working Group (see doi:10.15497/RDA00068). We gratefully acknowledge their contribution. Collapse this section.

Definitions

For the questions that follow, it is helpful to specify what we mean by "the software". Our recommendation is to interpret that phrase as "a specific copy of a specific version of your software-as-a-concept". For many projects,... Read more.

For many projects, the specific copy will be some kind of nested directory tree structure with files and folders, simply what would result from a git clone or svn checkout, or perhaps from uncompressing a zip or a tar file. Some files in the tree will be source files that define the software's functional behavior, these are collectively referred to as the software source files. The other files are metadata files that come bundled with the software:

venn diagram showing the definition of software

The metadata includes files that are meant to be read by humans, such as READMEs, documentation files, source files for documentation, image files, etc. The metadata may additionally include files that are meant to be read by machines, such as package manager files (e.g. package.json, pyproject.toml, DESCRIPTION, CMakeLists.txt, setup.cfg, etc.), citation files (e.g. CITATION.cff, codemeta.json), publishing files (.zenodo.json), etc.

Any additional data that may be gotten from APIs (for example the GitHub, GitLab, Zenodo, PyPI, CRAN, or NPM API) should not be considered metadata for the purposes of this checklist. Collapse this section.

Let's get started!

Findable

The first step in reusing software is to discover that it exists in the first place.

Is information from the metadata consumed by search engines to help rank their results? For the definition of "the metadata", see section above.

(+0)

(+0.3333333333333333)

No, but some of the metadata is machine-readable

E.g. There is a setup.cfg file with keywords, authors, and a description, but the software is not published to PyPI.

(+0.6666666666666666)

No, the software is published on a platform with minimal Search Engine Optimization

E.g. the software is on GitHub or GitLab.

(+1)

Yes, the software is findable via an associated web page which employs Search Engine Optimization.

E.g. the software is published to a package manager (e.g. PyPI, CRAN, NPM) or a dedicated publishing platform (e.g. the Research Software Directory). The associated pages on those platforms can be shown to contain relevant metadata by using Search Engine Optimization tools such as schema.org's validator or OpenLink's Structured Data Sniffer.

Are the software's identifiers globally unique? For the definition of "the software", see section above.

(+0)

E.g. The software is only identified by its name, which is not guaranteed to be or remain unique.

(+1)

Yes for at least some of the identifiers

E.g. The software is identifiable by its URL, or by its DOI.

Accessible

In order to reuse software, one must have access to it.

Can someone else use the software's identifiers to get a copy of the software?

(+0)

(+0.3333333333333333)

No, the identifiers only resolve to a page about the software, not the source files themselves.

E.g. the software is identified by URL or DOI, but the software source files are proprietary, closed-source, or otherwise hidden from public view.

(+0.6666666666666666)

Maybe

E.g. the software is identified by name and version, but there is no information on where to get a copy.

(+1)

Yes for at least some of the identifiers

E.g. the software is identified by its URL or DOI. Or, a copy of the software may be obtained after going through an administrative procedure, e.g. vetting, sending an email, etc.

A few years from now, will the software's identifiers resolve to exactly the same content as they do today?

(+0)

Maybe

E.g. the identifiers include only the name of the software as a concept, but each version of that concept will have a different feature set. Or, the identifiers only include a URL, whose content may be subject to change.

(+0.5)

Yes, at least some of the identifiers are persistent

E.g. The identifiers include a DOI, PURL, Handle, or some other persistent identifier. If the identifier is a concept DOI or collection DOI, the identifiers must also specify a version or version list.

(+1)

Yes, as previous answer, and additionally the metadata will be available for some time after the software itself is no longer available

E.g. The software is a deposition on Zenodo.

Is the software retrievable using a protocol that is open, free, and universally implementable?

(+0)

(+1)

Yes

E.g. The software is retrievable through a URL that uses HTTP, HTTPS, FTP, or SFTP.

Is the software retrievable using a protocol that allows for authentication and authorization?

(+0)

(+1)

Yes, or the software is openly available

Does the metadata include an identifier to reference the associated software?

(+0)

(+0.3333333333333333)

Yes, the metadata includes the software's name

(+0.6666666666666666)

Yes, the metadata includes a unique identifier to reference the software

E.g. The metadata includes a URL that points to the software on GitHub, GitLab, SourceForge, PyPI, NPM or CRAN.

(+1)

Yes, the metadata includes a unique and persistent identifier to reference the software

E.g. The metadata includes a DOI, PURL or Handle that points to an archived copy of the software.

Interoperable

Software must interact with data and other software to maximize its potential.

If the software reads, writes, or exchanges data, what type of formats are being used?

(+0)

Not applicable

(+0.3333333333333333)

The software reads, writes and exchanges data using proprietary formats only

(+0.6666666666666666)

The software uses open formats for at least some of the data it reads, writes, or exchanges

(+1)

As previous answer, and additionally the formats are common for the domain

What approach does the software take to versioning?

(+0)

Different versions of the software are not identified separately

E.g. the software does not make releases. Updates may or may not be available, but when they are, no version or release is indicated.

(+0.5)

Different software versions are identified using some form of increment at every release

E.g. Software versions are labeled according to the release date, the build number, etc.

(+1)

As previous answer, and additionally, the version identifier communicates information about compatibility

E.g. Software versions are labeled according to semantic versioning.

10.

How are the software's dependencies specified?

(+0)

The metadata does not include explicit information about the dependencies

(+0.3333333333333333)

The metadata includes the names of the dependencies

(+0.6666666666666666)

The metadata includes URI links to the software's dependencies

(+1)

As previous answer, and additionally each link points to a specific version or version range of the dependency, and the list of dependencies includes all dependencies needed to get the software running again on a fresh install of the targeted operating systems

11.

How is the software's relationship to related software, other than its dependencies, described?

(+0)

The metadata does not include links to related software

(+0.5)

The metadata includes at least some URI links to related software

(+1)

As previous answer, with at least some of the links qualified and machine-readable

12.

How is the software's relationship to related data described?

(+0)

The metadata does not include links to related data

(+0.5)

The metadata includes at least some URI links to related data

(+1)

As previous answer, with at least some of the links qualified and machine-readable

Reusable

Software should be usable and reusable.

13.

Is the software executable?

(+0)

No, the software is available as-is. No attempt is made to make the software easily executed

E.g. the software's dependency tree or compilation tool chain are insufficiently specified to facilitate reliable recompilation

(+1)

Yes, the software can be compiled using information bundled with the software sources

E.g. the software includes package manager files like package-lock.json, conanfile.txt, pyproject.toml, or requirements.txt that can be used to compile and run the software, or the software includes sufficient documentation to do so.

14.

Is the software made available in a form that allows for it to be understood, modified, built upon, or incorporated into other software?

(+0)

(+0.3333333333333333)

Yes, the software's source files are available

(+0.6666666666666666)

Yes, as previous answer, and additionally the software includes documentation

(+1)

Yes, as previous answer, and additionally the software is available via a package manager

15.

Which of the following best describes the software's usage rights?

(+0)

The software is unlicensed

(+0.3333333333333333)

The software is licensed with a license that is not widely used

E.g. the software's README includes a few lines about how the software may be used, but the legal meaning has not been tested or subjected to an audit.

(+0.6666666666666666)

The software is licensed with a widely used license

E.g. the software is bundled with a license text such as that of the Apache-2.0, MIT, or MPL license.

(+1)

As previous answer, and additionally, the license is machine-readable

E.g. the software specifies its license in a metadata file such as pyproject.toml, package.json, CITATION.cff, .zenodo.json, codemeta.json, or R DESCRIPTION file.

Get the badge

Use the buttons next to the snippets below to copy your badge and paste it into your project's README. The hyperlink in each snippet points back to this page, and includes the necessary data to check the appropriate answers.

Markdown

[![FAIR checklist badge](badge.svg)](?f=00&a=00000&i=00000&r=000)

copied

ReStructured Text

.. image:: badge.svg
   :target: ?f=00&a=00000&i=00000&r=000
   :alt: FAIR checklist badge

copied

HTML

<a href="?f=00&a=00000&i=00000&r=000">
  <img src="badge.svg" alt="FAIR checklist badge">
</a>

copied