Written and maintained by CASRAI Editorial Board
Last updated
A software management plan (SMP) is a working document that sets out how a project’s research software — not its datasets — will be developed, licensed, tested, released, and kept usable after the funding ends. It is easy to assume this is now a standard, funder-mandated deliverable the way a Data Management Plan often is. That assumption does not survive a check of the actual policy text. A 2024 peer-reviewed survey of SMP practice, Grossmann et al., “Software Management Plans: Current Concepts, Tools, and Challenges” (Data Science Journal), states plainly that “no funding organization explicitly requires” a document by this name, even as individual programs move toward requiring the underlying content by other routes. This page maps what funders actually ask for, then gives a template built from that reality rather than from a generic “software project best practices” list.
What funders actually require, program by program
Treat the table below as the current state, not a settled convention — this is a fast-moving area and several entries below are “expected to,” not “does.”
| Funder / body | What it actually asks for | Status |
|---|---|---|
| US National Science Foundation | Every NSF proposal must include a Data Management and Sharing Plan (DMSP). Under NSF PAPPG 24-1, Supplement 2 (effective 22 January 2026), the DMSP explicitly names software and algorithms among the materials that must be identified and covered — “samples, physical collections, software, and curriculum materials should be shared as covered by the DMSP.” From 27 April 2026 the DMSP is built in a structured Research.gov webform rather than a 2-page narrative PDF. | Mandatory, folded into the DMSP — not a standalone “SMP” document |
| UK EPSRC / UKRI | EPSRC’s research data policy applies to software only conditionally: software counts as research data when it is necessary to validate or replicate a published result. EPSRC does not currently name a standalone software management plan as a required deliverable; the Software Sustainability Institute’s SMP guide is offered as a recommended planning tool, not a compliance form. | Recommended practice, not a formal deliverable |
| Netherlands: NWO, ZonMw, Netherlands eScience Center | Per The Turing Way’s SMP guidance, these three Dutch funders/institutes are named as bodies that require or recommend an SMP directly, and the eScience Center publishes its own national SMP guidelines and template. | Required or formally recommended, by name |
| Germany: Volkswagen Foundation, Helmholtz Association | The Volkswagen Foundation addresses research software directly in its Open Science Policy. Per Grossmann et al. (2024), Helmholtz Centres will be able to present research-software-management procedures in publicly available policies “from 2025 on.” | Policy-level, still rolling out |
| Horizon Europe / European Commission | Horizon Europe’s deliverable typology includes an “OTHER” category covering software, prototypes and demonstrators, so a project’s Grant Agreement can name a software management plan as a specific, contractual deliverable — but this is set per call/consortium, not mandated EU-wide. Grossmann et al. (2024) state it can be expected that funders including the EU “will follow” the Dutch/German lead, but as of their 2024 review this had not yet happened as a general rule. | Per-project deliverable where specified, not a blanket EU requirement |
The practical takeaway: check your specific funding instrument’s deliverable list and data policy before assuming either extreme — that nobody will ask, or that everybody now does. If your project proposes software as a primary output (not an incidental analysis script), budget the SMP as if it will be asked for, because the direction of travel is toward requiring it even where it is not required yet.
SMP vs. DMP: where software planning genuinely diverges
CASRAI’s Software management plan (SMP) entry covers the operational definition; this section covers where the divergence from a data plan actually shows up in practice, because “just use your DMP template” is where most software planning goes wrong.
- Licensing choice, not a metadata field. A DMP asks what license applies to a dataset, usually a single Creative Commons choice. An SMP has to reason about license compatibility across every dependency the software pulls in — see the dedicated section below.
- Dependency and version management. A dataset does not have a supply chain. Software does: every third-party library is a maintenance liability and a potential license or security problem the SMP has to name and track, not just the software’s own code.
- The sustainability question after grant end. A dataset can simply sit in a repository, static, and still be useful. Software that stops being maintained tends to stop running — dependency drift, OS/runtime deprecation, and broken build chains degrade it even with zero code changes. An SMP has to answer “who does this, if anyone, after the funding stops” in a way a DMP does not need to.
- Contributor and authorship credit for code. Data citation and software citation follow different conventions and different persistent-identifier practices — see How to Cite Software, Code and R Packages and Citation File Format (CITATION.cff) for the mechanics, which this page does not repeat. Where an SMP needs to go further than a DMP is deciding, up front, who counts as a contributor to the codebase versus who counts as an author on any resulting software paper (see JOSS Authorship Criteria) — a decision worth making before the team scatters, not after.
An SMP template, section by section
The template below is assembled from the common ground across the field’s actual working templates and checklists — the Software Sustainability Institute’s SMP guide, The Turing Way’s SMP chapter, and the five-template comparison in Grossmann et al. (2024) — rather than any single institution’s form. Grossmann et al. found the existing templates “differ significantly in coverage, focus, and granularity,” so treat this as a checklist to adapt, not a form to fill in verbatim.
1. Administrative information
Project name, funder and grant reference, the SMP’s own version number and review date. Every source above agrees an SMP is a living document, revisited at defined project milestones — not written once at proposal stage and filed away.
2. Software outputs and scope
What software will exist by project end: standalone applications, libraries/packages, analysis scripts, containers, or a mix. Distinguish code written to produce a paper’s results (which may only need to be adequate for replication) from code intended as a reusable tool for other researchers (which needs a materially higher documentation and testing bar).
3. Development approach and quality assurance
Development methodology, the revision-control system and branching convention in use, code review expectations, and the automated test coverage the team commits to. Name who is accountable for each release — a single named role, not “the team.”
4. Dependencies and external software
List the direct third-party dependencies, their own licenses, and how the project will track them as they update. This is the section most templates in Grossmann et al.’s comparison under-specify, and it is where the licensing section below actually has teeth.
5. Licensing
The license for each software output, checked for compatibility with every dependency license (detailed below) — not just “MIT or GPL,” picked once.
6. Release, citation, and archiving
Where the code will be hosted, the versioning scheme, whether releases get a persistent identifier via an archive such as Software Heritage or a repository like Zenodo, and a CITATION.cff file so the software is citable in the first place. This page does not restate citation mechanics — see How to Cite Software, Code and R Packages for that.
7. Preservation and long-term availability
Where the final state of the code will live once active development stops, in a form that does not depend on the original developer’s own machine, account, or institutional access still being available.
8. Sustainability and handover
The section every template above treats as optional and every real project eventually needs: what happens to this software when the grant, and the people who wrote it, move on. Covered in its own section below, because it is the part most SMP templates leave thinnest.
Licensing: beyond “pick MIT or GPL”
Naming a license is the easy part. Three consequences of that choice are where research teams get into real trouble, and where a generic SMP template stops being useful.
License compatibility with your own dependencies
A permissive license on your own code (MIT, BSD, Apache-2.0) does not override a copyleft license on a dependency you import. If your software links against or incorporates a GPL-licensed library, the GPL’s terms generally require that the combined work also be distributed under the GPL, regardless of what license you intended for your own code. This is the practical meaning of “copyleft” — it propagates outward through the dependency graph, not just downward from your code to derivatives of it. Before adopting a dependency, check its license against your intended license, not just its functionality.
What happens when a dependency’s license changes
Dependency licenses are not fixed for the life of your project. A library maintainer can relicense a future version to more restrictive terms (source-available instead of open source, a new copyleft clause, a usage restriction) — a pattern that has recurred across widely used open-source infrastructure in recent years. Practical mitigation for an SMP to state explicitly: pin dependency versions rather than tracking “latest,” review the license of any dependency before upgrading it (not after), and record, per dependency, whether an unmaintained fork of the last acceptably-licensed version is a viable fallback if relicensing happens mid-project.
The practical consequence of choosing copyleft
If the SMP’s goal is to maximize downstream reuse — other tools embedding your code, including in closed-source or commercial products — a strong copyleft license (GPL family) is a real deterrent: institutions with closed-source products routinely avoid GPL-licensed dependencies specifically to avoid triggering its terms. A permissive license (MIT, BSD, Apache-2.0) removes that barrier but also removes any requirement that downstream users contribute improvements back or keep their derivative open. Neither choice is universally correct; the SMP should state which outcome the project actually wants (maximum embedding, or guaranteed openness of derivatives) and pick accordingly, rather than defaulting to whichever license the team already knows.
The handover point: what happens after the grant ends
This is the question most SMP templates treat as an afterthought and most projects answer badly, by default, through inaction. Grossmann et al. (2024) name it directly among the field’s open challenges: current SMP practice has a limited experience base and thin guidance on what happens once the funded period closes. An SMP should commit, in writing, to one of a small number of honest outcomes rather than leaving the question unanswered:
- Archive as a fixed, final snapshot. Deposit the final release with a persistent identifier (Software Heritage, a Zenodo/institutional-repository DOI), mark it explicitly as unmaintained, and stop implying ongoing support. This is a legitimate, honest outcome — not a failure state — provided it is stated rather than discovered by a user filing an issue nobody answers.
- Transfer to an institutional or community home. Hand the repository, its issue tracker, and maintainer rights to a research-software group, a domain community, or a named continuing team member, with the transfer documented in the SMP itself (who, when, what access they were given).
- Pursue follow-on infrastructure funding — treating continued maintenance as its own fundable activity (the rationale behind funder programs aimed specifically at research software sustainability) rather than assuming the original grant’s leftover time will cover it.
- An explicit, dated sunset. If none of the above is realistic, say so, name the date, and make the final release the one described in the archiving option above — a planned sunset is a materially better outcome for downstream users than software that silently stops working with no notice.
Name the option in the SMP itself, at proposal or kickoff stage, not as a decision deferred to whoever is still around when the grant ends.
Where this fits alongside CASRAI’s other planning content
An SMP is increasingly treated as one component of a broader output management plan, alongside a conventional Data Management Plan, rather than a wholly separate exercise. If your project’s DMP obligations come from NIH or UKRI specifically, see NIH Data Management and Sharing Plan or UKRI Data Management Plan for those requirements in full — this page does not restate general DMP mechanics. For the broader FAIR-for-software landscape the licensing and archiving choices above sit inside, see FAIR Software: How FAIR4RS Diverges from FAIR for Data, and for the infrastructure choices (containers, workflow capture) that make a sustainability plan credible, see Reproducibility Infrastructure: Workflows, Containers, and Code Sharing. For the software-license mechanics behind the compatibility questions above, see Types of Software License Agreements and Software License Agreement: A Worked Example.
Frequently asked questions
Is a software management plan the same thing as a data management plan?
No. They can share a document, but a DMP’s questions are built around datasets (storage volume, metadata schema, retention period) and an SMP’s are built around software-specific concerns — licensing compatibility across dependencies, versioning and release process, and what happens to the software after active development stops — that a data-shaped template does not ask about. See the divergence section above.
Does my funder actually require one?
It depends on the specific program, not the funder’s name in general. See the funder table above: NSF folds software explicitly into its mandatory Data Management and Sharing Plan; EPSRC treats software as conditionally in scope for its general research-data policy but does not mandate a standalone SMP; Dutch funders (NWO, ZonMw, the Netherlands eScience Center) name SMPs directly; Horizon Europe can require one as a named Grant Agreement deliverable on a per-project basis. Check your specific call or award terms rather than assuming.
What license should research software use?
There is no universally correct answer — it depends on whether the goal is maximum downstream embedding (favoring a permissive license like MIT, BSD, or Apache-2.0) or guaranteed openness of any derivative work (favoring a copyleft license like the GPL family). Whichever is chosen, it must also be checked for compatibility against every dependency’s own license — see the licensing section above.
Who is responsible for research software after the grant ends?
Whoever the SMP names — that is the point of writing the handover section explicitly rather than leaving it to be decided by default. The realistic outcomes are archiving the software as a final, clearly-marked-unmaintained snapshot, transferring it to an institutional or community maintainer, seeking dedicated follow-on infrastructure funding, or setting and honoring an explicit sunset date. See the handover section above.
