Examples
Worked examples
- Is an instance
'Analysis code is available at github.com/lab/study (commit a1b2c3) and archived at Zenodo DOI 10.5281/zenodo.XXXXXXX, MIT licence.'
- Is an instance
A statement linking to a Snakemake pipeline release tag.
Counter-examples
Looks similar, but isn't
- Not an instance
A statement 'code available on reasonable request' with no archive link.
- Not an instance
Pseudocode in the methods section without an executable counterpart.
Editorial commentary
Best-practice code availability statements link to both a working repository (GitHub) and a permanent archive (Zenodo, Software Heritage) with a version tag or commit hash, and a licence. They complement the data availability statement and are increasingly subject to verification rather than self-attestation.
References
- Nature 'Code and software submissions' policy.
What a code availability statement must say
A complete code availability statement should specify, at minimum: (1) where the code lives — both a working repository (e.g., GitHub/GitLab) and a permanent archive; (2) the exact version used to produce the results in the paper, identified by a release tag or commit hash, since a repository’s default branch changes over time while the article does not; and (3) the license under which the code is released, since without an explicit license, publicly visible code on GitHub remains technically all-rights-reserved and not legally reusable by others.
Where it goes
Most journals place the code availability statement either within the Methods section or in a dedicated “Code availability” section that mirrors the placement of the data availability statement — the two are increasingly treated as companion, parallel requirements rather than one covering the other. See CASRAI’s guide to writing a data availability statement and a sample statement for the equivalent structure on the data side.
“Available on reasonable request” — and why editors increasingly reject it
A statement that code is “available on reasonable request” with no archive link is now widely treated by journals as insufficient. Nature’s own guidelines for code and software submissions state that editors reserve the right to decline a paper if code central to the central claims is not made available, and only permit “on request” language for code that is genuinely peripheral to the results. Other journals have gone further: Cambridge’s Quantitative Plant Biology, for example, explicitly states that it is not acceptable for its data availability statements to say data (or, by the same logic commonly applied to code) are available only “on request” from the authors — the underlying rationale is that a third-party reader should be able to independently verify and access what is described without needing to contact the authors at all. This mirrors a broader shift in editorial policy away from author-mediated access and towards deposit-and-cite as the baseline expectation.
Deposition to Zenodo and Software Heritage, with a DOI
Zenodo‘s GitHub integration mints a DOI automatically for each tagged release of a repository, turning an ordinary GitHub link into a permanently citable, versioned archive — this is the most common way researchers satisfy the “permanent archive with a DOI” expectation. Software Heritage operates a separate, large-scale archive whose purpose is long-term preservation of source code specifically (rather than research outputs generally); as of Zenodo’s October 2024 integration, Zenodo deposits can be cross-referenced with Software Heritage persistent identifiers (SWHIDs), giving code availability statements two complementary, independently-run points of permanence rather than relying on GitHub alone, which offers no long-term preservation guarantee.
Licensing
An open-source license (MIT, Apache-2.0, GPL, BSD, etc.) should be declared explicitly in the repository and referenced in the availability statement — see CASRAI’s coverage of open-source software and software license agreement concepts for the underlying distinctions between license types.
Relation to CITATION.cff and JOSS
A code availability statement and a CITATION.cff file serve related but distinct purposes. CITATION.cff is a standardized YAML file placed at the root of a repository (GitHub renders it automatically as a “Cite this repository” button) that makes the software itself formally citable with structured author, version, and DOI metadata — it lives with the code, not the paper. The code availability statement, by contrast, is text inside the published article that tells a reader where to find and how to cite the code used for that specific study; it commonly points to the archived DOI that a CITATION.cff-equipped repository or a Zenodo deposit provides. The Journal of Open Source Software (JOSS) offers a further option: publishing a short, peer-reviewed paper about the software itself, giving it its own citable DOI that a code availability statement in an unrelated research article can then reference as the canonical citation for the tool used.
References
- Nature ‘Code and software submissions’ policy (Guidelines for authors submitting code & software).
- Zenodo Blog, ‘Zenodo launches integration with Software Heritage’ (October 2024).
- Cambridge University Press, Quantitative Plant Biology research transparency policy.
Also known as
software availability statement
Machine-readable encodings
Use in your systems
<role vocab="credit"
vocab-identifier="https://casrai.org/dictionary/"
vocab-term="Code Availability Statement"
vocab-term-identifier="https://casrai.org/dictionary/term/code-availability-statement" />{
"@context": "https://schema.org",
"@type": "DefinedTerm",
"@id": "https://casrai.org/dictionary/term/code-availability-statement",
"name": "Code Availability Statement",
"identifier": "https://casrai.org/dictionary/term/code-availability-statement",
"description": "A statement in a published article describing where the source code used in the study can be obtained, under what licence, and at what version, typically required by journal policy.",
"inDefinedTermSet": "https://casrai.org/dictionary/domain/reproducibility#set",
"url": "https://casrai.org/dictionary/term/code-availability-statement",
"sameAs": [
"software availability statement"
],
"license": "https://creativecommons.org/licenses/by/4.0/",
"publisher": {
"@id": "https://casrai.org/#organization"
},
"author": {
"@id": "https://casrai.org/#editorial-team"
},
"datePublished": "2026-05-21T02:22:49",
"dateModified": "2026-08-23T06:25:19",
"inLanguage": "en-GB",
"isAccessibleForFree": true
}
