New guidance on software citation

Encouraging authors to properly reference the software they use in their research

Software (including computational code, scripts, models, notebooks, and libraries) is a highly valuable research object. However, recognition of this fact in journal article references has tended to be highly variable, which has limited the potential impact of the software that’s been produced.

We believe that software should be treated as a first-class object in the digital scholarly ecosystem, consistent with its immense present-day significance.

That’s why we’ve now brought in new guidance for authors about citing the software they use. We’ve also updated our production processes to ensure software is cited as a primary research output, in the same way as other sources of information, such as articles, books, and data.

Our best-practice recommendations are based on the output of a Force11 working group on software citation implementation, which included Taylor & Francis representatives: Katz DS, Chue Hong NP, Clark T et al. Recognizing the value of software: a software citation guide.

What does this new guidance mean for my journal?

You may notice the impact of our software citation guidance in a few ways:

  • Submissions: You’ll hopefully begin to see more authors including formal citations to software in the manuscripts they submit.

  • Copyediting: You may notice some new corrections or questions for authors during the production process, asking them to format their software citations in line with this new best practice.

  • Author queries: You may receive questions yourself from authors asking about this process. If you do, please direct them to our Editorial Policies and the software citation guide.

What does the software citation guidance say?

When authors cite software they have created or used they should include:

  • Creator(s): the authors or project that developed the software.

  • Title: the name of the software.

  • Venue: the publication venue of the software, preferentially, an archive or repository that provides persistent identifiers.

  • Date: when the software was published. This is the date associated with a release or version of the software, or “n.d.” if the date is unknown.

  • Identifier: a resolvable pointer to the software, preferentially, a PID that resolves to a landing page containing descriptive metadata about the software, similar to how a Digital Object Identifier (DOI) for a paper that points to a page about the paper rather than directly to a representation of the paper, such as the PDF. DOIs are preferable, and other examples of PIDs include HandlesRRIDsASCL IDsswMath IDsSoftware Heritage IDsARKs, etc. If there is no PID for the software, a URL to where the software exists may be the best identifier available.

It may also be desirable to include information about two optional properties (as appropriate):

  • Version: the identifier for the version of the software being referenced. If the version is unidentified or unknown, the date of access should be used.

  • Type: some citation styles (e.g., APA), require a bracketed description of the citation (e.g., Computer software) to be included.

For further guidance we recommend Software Citation Checklist for Developers, which includes information on how researchers can obtain a PID or choose a software license for software they’ve developed.