An environment for sustainable research software in Germany and beyond: current state, open challenges, and call for action

Stakeholder motivations for research software sustainability

While a wide range of stakeholders share interest in sustainable software, we argue that their individual motivation can differ quite significantly:

The general public benefits from research which supports the common good, in other terms: creates a better world, faster. Taxpayers have an interest in economical use of their tax money, to which duplicated or flawed efforts to create research software – in contrast to software reuse – is contrary. A subset of this group may be interested in sustainable, i.e., re-usable and understandable, software as part of citizen science.

Domain researchers benefit from better software to do more, better, and faster research. Sustainable research software supports this through validated functionality (e.g., correct algorithms), the potential for reuse, and general availability. Sustainable software also potentially simplifies building upon previous research results by reusing the involved software to produce additional data or by extending the software’s functionality. In light of recent updates to definitions of good research practice, sustainable research software also allows domain researchers to comply with guidelines and best practices. Additionally, using software that is sustainable enough to establish itself as a standard tool in a field signifies inclusion in a research community. Less directly, researchers may benefit from the existence of sustainable standard tools as they yield standard formats, which in themselves facilitate reuse of research data.

Research software engineers (RSEs) have an intrinsic interest in sustainable research software. They create better software for research, which enables more and better research. RSEs have an inherent interest in developing and working with high quality software, as part of professional ethics as well as good research practice. RSEs build their reputation on high quality software and software citation^20,31, which will open up new career paths. Finally, for RSEs, creating sustainable research software is part of an attractive, intellectually challenging, and satisfying work environment.

Research leaders as well as research performing organizations mainly focus on the economic aspects and management of research, i.e., available funds, people, and time employed to optimize research output. Both need to make sure that their employees continually improve their qualification and generate impact to improve their standing in the various research communities and ensure continued funding. Overseeing and enabling the creation of sustainable research software advances their visibility in the field and makes their research endeavors both more future-proof and more easily traceable, reproducible, and verifiable and thus more likely to attract additional resources (including human resources). Research performing organizations can additionally benefit from sustainable research software if it can be reused in other areas, creating synergies between different research disciplines. These synergies typically free resources that can then be used in areas other than software development and maintenance. Finally, organizations can gain highly competitive positions in terms of funding and hiring opportunities, as well as a reputation for being on the cutting edge of research, through early adoption of research software engineering units, and the implementation of sustainable research software policy and practice.

Research funding organizations have inherent interest in – and directly benefit from – the existence of sustainable research software as it allows them to direct more resources towards actual research (rather than recreation of software) and increase return on investment. At the same time, funding organizations can create incentives for sustainable software by imposing policies that reflect the necessity of research software sustainability and creating respective funding opportunities.

Geopolitical units have a strategic interest to be independent of other geopolitical units to ensure that research can continue seamlessly regardless of geopolitical developments and ensuing embargoes on information flow. Reuse of sustainable software additionally frees up funding for uses other than software development. Well-established, sustainable software systems can also attract researchers and companies in the research and technology sector.

Libraries (also registries, indices) benefit from sustainable research software, as it will undergo a formal publishing process and be properly described in its metadata. Libraries can extend their portfolio beyond text-based research objects and stake claims as organizations harnessing the digitalization of research. In turn, they help to increase visibility and discoverability for research software through their services and advance the competitiveness of their organization or geopolitical unit. In addition, libraries also use research software and would thus benefit directly from a more sustainable research software landscape. Last but not least, by using FLOSS research software, libraries could avoid expensive licenses and often insufficiently adapted commercial software.

Infrastructure units, such as supercomputing facilities and university computing centers, benefit from sustainable software as it makes their daily work in terms of software installation and user support easier. Additionally, they can position themselves at the forefront of research by bundling expertise on the creation and maintenance of sustainable research software and installing research software engineering teams.

Industry benefits from sustainable research software, as the process of creating and maintaining research software produces a highly-skilled workforce. Depending on the employed licensing model, sustainable research software can also be adopted by industry partners to reduce cost in corporate research and development. Helping to sustain research software may also enable positive outreach for companies across industry and into society.

Independent (open source) developers can get involved in research software, even if they are not employed by a research institution. This can help them get in contact with other developers in the field and may potentially lead to collaborations or job opportunities in research based on this extended experience.

Requirements and challenges

The sustained funding of all existing software efforts is not only impossible but would risk overly splintering the community and eventually become counterproductive to the efficiency of the research community. Therefore, it is important to agree on a list of transparent criteria that qualify a software product for sustained funding. We recognize that defining research software engineering criteria for software evaluation will also lead to activities aiming at optimizing scores to achieve these criteria. Hence, the criteria have to be designed such that all score-pushing effort truly advances the value of the software. Criteria that can be manipulated without effectively adding value, i.e., wasting resources, should be excluded. The list of criteria presented in this section could be the basis for a structured review process that facilitates an unbiased evaluation of software tools from various fields. Therefore, this list must be general enough to be applied to research software from various research disciplines while also respecting differences between fields (e.g. citation rates between humanities and life sciences). The challenge to do justice to a wide spectrum is e.g. reflected by suggesting criteria comprising different levels⁵⁷. One of the major challenges in the endeavor to define a selection scheme for sustainable funding of research software is to organize a fair and transparent review process. We believe that it is important that the review process is conducted by experts, or teams of experts, that have a strong background both on software engineering as well as on the domain-specific aspects, the latter because certain criteria often exist on a spectrum that is most likely shaped by the specific demands of the respective research community.

While an assessment based purely on quantitative metrics would allow for seemingly objective comparisons between programs, the definition of valid and robust quantitative metrics that can be evaluated with reasonable effort is a major challenge. On the other hand, a structured qualitative assessment with scores for groups of criteria can provide a middle ground. It is clear that both preparing an application for a review against these criteria from the applicant side as well as the evaluation by the reviewers requires significant effort. We believe that the added value significantly outweighs the investment but appropriate resources need to be factored in. Sustainability of research software should be considered from the beginning for new projects. The criteria listed below, or a subset such as the “good enough” practices proposed by Wilson et al.⁴³ and artifact review approaches^58,59, are valuable throughout the development process (including early phases) for almost all types of research software applications. “Classical” research funding schemes should acknowledge the need to follow best practices during the development of new software and allow factoring in appropriate resources to design and implement for sustainability. In this section, we focus on the question which software to support in dedicated sustainability funding schemes. For such sustained funding, only software in application class 2 or 3 as defined by Schlauch et al.⁶⁰, i.e., with significant use beyond personal or institutional purposes, would likely be considered. Excellence as reflected in funded projects, publications, and software adoption, i.e., backing by a community, should be considered during selection. Nevertheless, we believe a good scheme should strike a balance between consolidating the field to few well-established software packages on one side and stimulating innovation and cooperation promoting diversity in terms of more than one monopolistic package on the other side. Last but not least, there is an inherent conflict between the long-term goals of sustainability funding software and the necessary reevaluation to monitor the state of the software over time.

Selection criteria

Several evaluation schemes for research software have been proposed before and led to the formulation of first recommendations^13,14. Gomez-Diaz & Recio suggested the CDUR scheme based on Citation, Dissemination (including aspects like license, web site, contact point), Use, and Research (output)⁶¹. Lamprecht et al. rephrased the FAIR data principles¹⁰ for research software¹². Hasselbring et al. found that the adoption of FAIR principles is different between fields with an emphasis on reuse in computer science as opposed to a reproducibility focus in computational science¹¹. Fehr et al. collected a set of best practices for the setup and publication of numerical experiments⁶². Jiménez et al. boiled it down to four best practices⁶³: public source code, community registry, license, and governance. Hsu et al.⁶⁴ proposed a framework of seven sustainability influences (outputs modified, code repository used, champion present, workforce stability, support from other organizations, collaboration/partnership, and integration with policy). They found that the various outputs are widely accessible but not necessarily sustained or maintained. Projects with most sustainability influences often became institutionalized and met required needs of the community⁶⁴. In the field of open source software, the CHAOSS (Community Health Analytics Open Source Software) project has developed metrics to evaluate sustainability. One objective of CHAOSS is to automatically generate project health reports based on software that evaluates the metrics, with most of the metrics already covered. The UK Software Sustainability Institute (SSI) suggested both a subjective tutorial-based and a more objective criteria-based software evaluation scheme⁶⁵, the latter being available as an online form. ROpenSci⁶⁶ provides software reviews for R developers, which have been very successful in the community. The review criteria of the Journal of Open Source Software (JOSS) focus on the aspects license, documentation, functionality, and tests. This list of essential items should be fulfilled by all research software that wants to be considered not only for publication but also for sustained funding.

We drew inspiration from all these works and suggest a set of criteria on which to base reviews for sustainable funding. This set comprises mandatory, hard criteria that we think have to be fulfilled across domains (highlighted in italics) and additional desirable, soft criteria that can be implemented to different degrees depending on the use case and domain-specific software development requirements. The soft criteria should be evaluated in a structured way by the reviewers with a specific response for each section rather than one running text. The fact that most of these criteria will be considered in any software management plan (SMP) highlights its importance for sustainable research software.

Usage and impact. Requirements qualifying software for sustained funding are (1) its use beyond a single research group, (2) the scientific relevance and validity of the software documented in at least one peer-reviewed scientific publication. Ideally a paper also describes the scope, performance, and design of the software. (3) The use of the software in publications is a measure of impact but quantitative assessment brings about additional challenges²⁷. Therefore, other, potentially domain-specific, impact measures, such as influence on policy and practice as well as use in other software and products should be considered as well to evaluate relevance for academia and society. Considerable attendance at training and networking events can be considered as a proof of use as well. (4) A market analysis needs to show that the software is important to a user base of relevant size and either unique or one of the main players in a field with several existing solutions. Geographical or political aspects can be considered as well, e.g. to support the maintenance of a European solution. A convergence process of (parts of) a research community towards a specific software stack, i.e., documented transition of several research groups to a common software, would be a strong indicator of impact. (5) As community uptake and benefits are a central goal of sustained software funding, outreach and appropriate training material for new users of the software are essential.

Software transparency and quality. As mandatory criteria of software transparency and quality that have to be fulfilled, we consider (6) the public availability of the source code in both a code repository and an archive (for long term availability), developed using (7) version control with meaningful commit messages and linked to an issue tracker (ideally maintained, but at least mirrored on a public platform). (8) Documentation of the software needs to be publicly available comprising both user documentation (requirements, installation, getting started, user manual, release notes) and developer documentation (with a development guide and API documentation within the code, e.g. using Doxygen)⁶⁷. (9) The license under which the software is distributed must be defined. Publicly funded software should be published under a Free/Libre Open Source Software (FLOSS) license by default, although exceptions to this might apply (e.g. excluding commercial use). (10) Dependencies on libraries and technologies must be defined.

We acknowledge that some additional criteria have to be evaluated under consideration of the research domain. These comprise (11) the availability of examples (comprising input data and reference results), (12) mechanisms for extensibility (software modularity) as one aspect of software architecture⁶⁸ and (13) interoperability (APIs / common and open data formats for input and output), (14) a test suite (including at least some of the following: unit tests, regression tests, integration tests, end-to-end tests, performance tests; ideally run in an automated fashion in a continuous integration environment), (15) tagged releases (considering their frequency, and availability for end users in terms of binary packages for major operating systems, or availability via package managers or containers), (16) no large-scale re-implementations for functionality for which good solutions already exist. Many of these aspects require appropriate infrastructure (see page 12).

Maturity. The research software applying for sustained funding must have already reached a certain level of maturity (typically class 2 or 3 as defined by Schlauch et al.⁶⁰). A mandatory requirement is (17) a comprehensive and up--to-date software management plan⁶⁹. The software should (18) be maintainable with an appropriate amount of resources as detailed in a sustainability section of the software management plan. The software has (19) a well maintained website with a clearly defined point of contact and a communication channel to inform users about news regarding the software such as new releases. Besides an active user community, sustainable software requires (20) a group of developers (i.e., definitely more than 1 developer) documented, e.g. by contributions to the code base or participation in documented, public discussions or issue tracking. Another criterion is (21) whether potential contributors are invited to participate in a clearly defined process (e.g., a CONTRIBUTING document). The group of developers should have defined a governance model for their project and easy ways for users to provide input regarding their needs.

Recommendations

Given the diversity in the software technology landscape, and the domain-specific software development cultures⁷⁰, some of the above-mentioned criteria have to be evaluated against domain-specific requirements. Therefore, we highly recommend to base the selection process on a combination of (1) a software quality-based review and (2) a domain-specific scientific review. In particular, the former should be ideally performed by a central institution (e.g. at funding bodies or other independent agencies such as a software sustainability institute). Only criteria for which improvement truly advances the value of the software should be considered in evaluation schemes, i.e. no criteria that can be gamed. After rejecting software not fulfilling the mandatory criteria in a first stage of the review process, the second stage of the selection process should be realized as a transparent procedure ideally allowing the reviewers to interact with the PIs of the software (e.g. remote meetings, forum-like discussions) and put the software quality and development efforts into the domain-specific context. The outcome of this second stage should be a structured review assessing each criterion explicitly and a rating for each of the dimensions Usage and impact, Software quality, and Maturity. For sustained software funding, it is important to audit the performance, relevance, impact, progress, and level of sustainability of funded software after reasonable time frames. Such a reevaluation should revisit the criteria under consideration of evolving software technology and scientific standards, without requiring a completely new proposal being submitted. We envision funding periods of 5 years to provide sufficient security for funded software projects, while allowing for adaptation of the portfolio of funded software to novel research directions and community needs. Failure to meet the reevaluation criteria should lead to the decision to phase-out sustainable funding. The phase-out process may come with a 1-year funding program based on a consolidation plan with clear goals regarding the archiving and preservation of the software, documentation, and all existing resources.

Requirements

Possibly the most important demand is the need for an increase in recognition and awareness of research software as a first class citizen in research^14,71,72. For sustainability of research software, long-term commitments of the respective software leads are crucial, but very few professional RSE profiles currently exist. In consequence, it is essential to create career paths for RSEs that are attractive and include permanency perspectives. While creating permanent positions in the German academic system below the faculty level is an actively discussed topic overall⁷³, we specifically focus on the needs originating from the development and maintenance of research software here.

As already mentioned, research software development not only requires domain expertise, but also software development education, skills, and competence. Currently, most of the domain researchers developing and maintaining domain-specific software technology have not received professional training on software development^3,41. To enhance the productivity and sustainability of computer-based research, it is essential to integrate software development training into the education of domain researchers.

Currently, a significant portion of the existing research software is developed by individuals or in small groups, primarily to serve their own requirements. This situation is unsatisfying in terms of collaboration and inefficient in terms of several groups spending resources on generating similar or even the same functionality. To enable and promote synergies, it is important to allocate resources for research software development and to build communities, as described in 74.

Challenges

We are currently facing a lack of awareness for the importance of research software as discussed above. Moreover, there is little recognition for the efforts put into software development and maintenance. In consequence, software development in academic settings is mostly considered as a means to an end and sustainability is often not considered in project planning and grant proposals and contributes little to progressing research careers⁷⁵. The main challenge here is the continued use of metrics that primarily leverage traditionally published articles and article citation numbers.

In academia, developers of research software are typically domain researchers, and in particular if new areas are explored, the software development process itself has research character. Obviously, developing research software requires not only domain knowledge but also software development skills, and the researchers leading the software development process are often domain experts with substantial software development experience, making them extremely valuable members of the research community. However, the current academic system in Germany does not provide a defined RSE role. Fixed-term positions are, at least currently within the German academic system, often effectively the end of a Research Software Engineer's career path, sometimes even a dead end. The challenge here is the lack of available permanent positions within the non-professorial academic faculty (“Mittelbau”) in Germany, compounded by a lack of access to these few permanent positions for RSEs. This in turn is due to the already mentioned lack of recognition for efforts concerning research software for faculty appointments within domain sciences.

In order to develop sustainable software, researchers need to have the skills and expertise to build software that is easy to maintain and extend⁷⁶. However, most of the researchers are self-taught developers^3,41. Ideally, these skills have to be built into the domain science curricula, which could generally be done in two different ways (or a combination of them). One obvious solution attempt are additional courses that focus on these topics. The main challenge here is to decide which other topic(s) to possibly drop due to the limited volume of any given curriculum. A different approach is to incorporate software-related topics into existing domain science courses. While this would provide the benefit of show-casing the usage of specific software skills directly within the domain science, the challenge here is the amount of work necessary to change existing lecture material, let alone the need of the lecturers to acquire those skills themselves in the first place.

As long as the necessary software skills within domain sciences are not yet wide-spread, building a network from those that have acquired relevant skills is difficult. Community efforts, that concentrate on questions regarding research software, can help to fill this gap. Examples of such efforts include the Software Carpentries, national and international RSE societies (e.g., within Germany deRSE e.V.). However, since research software is such an interdisciplinary topic, it is hard to get recognition and find funding within any specific discipline. As a result, existing communities often have to rely heavily on volunteers. This is challenging because despite benefits to domain science, volunteers hardly receive recognition for their work “back home”, i.e., within their domain, underlining again the importance of our first demand.

Recommendations

Increasing recognition and awareness is a challenge that calls for both immediate action and perseverance. Nevertheless, some measures will likely show positive effects comparatively soon.

Similarly to plans for research data management, funding agencies should request that applicants include considerations about how software developed in a project can be sustained beyond the end of the funded project. A follow up on these plans during and after the project lifetime, i.e., a dedicated software management plan, is crucial.

Another recommendation is aimed at decision makers concerning recruitment for academic positions: broaden the definition of research impact beyond traditional scientific publications to also include other impactful results. Not all researchers that think of themselves as RSEs pursue a faculty position as their main career goal. However, permanent academic non-faculty positions are rare within the German academic system, also due to the lack of a defined RSE role. We recommend research institutions to leverage the benefit of dedicated RSEs by establishing attractive long-term career options in the academic environment. The long-term solution in order to gain sufficient software development skills should be education that is included early in the career path, ideally already at the Bachelor level. For the time being however, efforts involving workshops and seminars that provide easy access to hands-on training on software-related questions should be promoted and supported as much as possible.

It is important to provide an environment where communities can form and flourish by allocating resources for research software development and for building communities around it^63,74,77. The identification with a community of like-minded people and personal action⁷⁸ can lead to a permanent establishment of sustainable research software as a valuable research output. Thus, research institutions as well as funding agencies should not only be open-minded regarding existing volunteer organizations, but should actively promote the creation of such groups.

Requirements

Sustainable funding for research software boils down to funding the four main pillars enabling sustainable software development: (1) Personnel with expertise in research software development; (2) Infrastructure for developing, testing, validating, and benchmarking research software; (3) Training in software design and sustainable software development; and (4) Community management and events for creating synergies between research groups and software efforts.

Challenges

Short-term engagement of (early career) researchers raises the question of how to maintain a constant level of expertise within a developer team and prevent knowledge drain concerning domain knowledge and software engineering skills. Conversely, the permanent engagement of qualified personnel requires to offer career perspectives, especially due to the fact that academia competes with industry for the same people. A challenge specific to Germany is posed by the shortage of permanent positions and by the restrictions for temporary positions due to the German Wissenschaftszeitvertragsgesetz⁷⁹.

Sustainable software development requires hardware technology to develop, test, validate, and benchmark features in a continuous integration cycle. The challenge in this context is the persistent evolution of the hardware landscape. Hence, for creating an environment promoting sustainable software development, it is important to provide access to a wide hardware portfolio and to support a development cycle based on continuous integration.

Expertise in sustainable research software development is a scarce resource, and training is heavily needed as one way of building up more expertise. However, while integrating interdisciplinary software engineering courses into the education curriculum can build up basic skills, some expertise is domain-specific and requires interinstitutional training activities. Furthermore, there exist no financial incentives for creating software-specific documentation and tutorials nor to provide other forms of support.

While the creation of research software communities is one major asset in sustaining research software technology, promoting this process requires the installation of new funding instruments. Traditionally, research grants are limited to rather short time frames and support personnel, material, hardware, and to a limited degree also travel and research visits. Creating a research software community however requires funding for community and training events as well as “virtual hardware” such as webspace, versioning systems, task-managing systems, and compute cycles. These demands can hardly be met without third-party funding^45,80–82.

Recommendation: creation of adequate funding schemes

Funding is a crucial factor for sustaining research software. Currently available sources and instruments are not adequately shaped for the challenges and solutions outlined above. We recommend actions on the individual, organizational, and national level.

Existing project-focused funding instruments on the local, national, and international level need to be complemented with funding instruments specifically designed for research software development and sustained research software maintenance to make research software a first class citizen in the research landscape. For example, software projects enhancing research and fulfilling the sustainability criteria detailed in section How to decide which software to sustain? may be entitled for sustained funding as long as they live up to the standards and remain a central component of the research landscape.

Computing centers and supercomputing facilities for research need to receive earmarked resources for the support of sustainable software development. This funding is necessary to provide continuous integration services, a hardware portfolio for development, testing and benchmarking software, as well as personnel for training domain researchers in software design and the proper usage of the services.

The creation and maintenance of training materials for general research software engineering education and the software-specific documentation and tutorial creation needs to be reflected in funding opportunities. This can either happen by dedicating modules of research or software grants to providing support and the generation of training material, or by opening funding schemes focusing on interdisciplinary software development education. The latter may include research that looks at research software development as a process to analyze which measures, interactions, and team compositions make research software successful. Additionally, funding instruments fostering the formation of research software communities have to be established.

Project management tools

Research software is developed by individual researchers, in small teams within a single institution, or in larger teams distributed across multiple institutions. In particular if software development is distributed across institutions, there exists an urgent need for frameworks and tools enabling collaborative code development, software feature planning, and software management. As research software development typically includes bleeding-edge research and in some cases development that the researchers do not want to disclose for a certain time to preserve intellectual property, distributed research software development also needs a global Authentication and Authorization Infrastructure (AAI). We recommend the development and/or deployment of tools for distributed software development and software management as central research infrastructure. An important aspect in this context is the cataloging of research software to reduce the duplication of development efforts. This can efficiently be realized by promoting the registration of all research software with a unique identifier and developing a tool that allows to explore the research software landscape. Research software contributors should have an ORCID iD to be uniquely identifiable and referable. While some funding for such tools and software repositories is emerging (e.g. the bio.tools catalogue of bioinformatics tools funded as part of the European ELIXIR project⁸³), a standardized extension of such efforts to the RSE community as a whole is necessary. However, as the experiences from ELIXIR demonstrate, this is a non-trivial effort that requires significant dedicated and long-term funding.

Developer training, motivation, and knowledge exchange

As elaborated, training in sustainable software development is key to achieve sustainability in research software. At the same time, it is not clear how such training should be facilitated and institutionalized. Furthermore, for deriving software quality standards, evaluating the quality of software, and providing a code review service, central resources are necessary that individuals and groups in the research software landscape can draw from.

We consider Software Carpentry and similar efforts like the creation of the Data Science Academy HIDA in the Helmholtz Association of German Research Centers helpful solutions to exchange and distribute knowledge. Local chapters of RSE groups and (inter-)national conferences will further foster networking and community building. We strongly recommend the creation of a national Software Sustainability Institute (involving funded positions to establish web platforms and training material) similar to the UK Software Sustainability Institute (SSI), which serves as a national contact for all aspects related to research software. The UK SSI also publishes best practice guidelines for research software engineering.

Research software discovery and publication

Proper software publication and possibilities for the community to find existing software solutions for a given problem are a prerequisite to optimally exploit synergies and avoid redundant development. However, we observe that today, many funding proposals lack a thorough state-of-the-art report of software that could possibly be reused. This is most often caused by insufficient information retrieval strategies, lack of knowledge about relevant repositories, and an abundance of locations where software is collaboratively developed and stored⁸⁴. Discovery requires publication in a globally accessible location with appropriate metadata, e.g. Citation File Format (CFF)⁸⁵ and CodeMeta. Comprehensive metadata (e.g. contributors, contact, keywords, linked publications, etc.) and publishing platforms have to enable persistent citing, which in turn benefits research evaluation. Selection and curation of software (probably by a data/software librarian) for publication and discovery are certainly challenging.

We consider GitLab or GitHub as collaborative working environments and repositories like Zenodo appropriate publication platforms, because the latter mint DOIs, allow versioning and are publicly funded for long-term access. GitHub, Figshare, and Mendeley Data are examples of commercial enterprises with business cases in the background, which leverage research results. Besides the aforementioned metadata standards, it is advisable to document source code, e.g. using MarkDown (with Doxygen tooling). Metadata and citations play a role in beneficial tools like PIDgraph, DataCite.org, CrossRef, which utilize Persistent Identifiers (PIDs) like DOIs. Another solution to discovery are (mostly) disciplinary software indices like swMATH or the Astronomy Source Code Library as well as language focused systems like CRAN for R. Most of them started as national endeavors and became platforms of global importance. For Germany, we assume that the Nationale Forschungsdateninfrastruktur (NFDI) will put effort into creating or supporting discovery platforms at a central point that ease information retrieval. At the same time, all stakeholders should be aware of and counteract potential institutional “fear” of losing “their” data, software, and intellectual property.

Especially in interdisciplinary environments, it would be helpful to have access to a meta software repository index, similar to what re3data⁸⁶ does for research data repositories. We recommend the creation of such a meta index covering important (disciplinary) software indexes in order to ease discovery of relevant software locations. Evaluation of discovered software is an unsolved problem. Here, anonymous telemetry of usage may provide information for the selection of relevant software. Publishing software, their dependencies, and environment in containers may also ease evaluation and further reuse. These suggestions require significant investment in longterm infrastructure. When publishing research software it is recommended to make use of integration schemes like GitHub with Zenodo or local GitLab instances with publication platforms. Such indices and publication outlets may benefit national federated research indexing & archiving systems, similar to the hierarchy of library catalogs⁸⁷.

Archiving

Software preservation aims to extend the lifetime of software that is no longer actively maintained. There are different approaches, which vary in the effort required and the likelihood of success. Software archiving is one important aspect of software preservation: the process of storing a copy of a software package so that it may be referred to in the future. The publication of a certain software version for reference in research articles requires simple ways to archive research software on a long-term basis. Furthermore, its integration with collaborative software development environments such as GitLab or GitHub and with publication repositories is needed to facilitate archiving of referenced software versions based on sustainable frameworks (e.g. Invenio for GitHub to Zenodo integration).

A challenge for software archiving is the need to (ideally) preserve the runtime environment and all dependencies of the software. This could improve reproducibility, especially when running the software in its original state. If research data are needed to reproduce results, they should also be archived with the software or the publication. Specialized and unique hardware like high performance computing resources can be part of the runtime environment, which may not be accessible in the future. To overcome this, an emulation of hardware may be a (challenging) solution. Emulation involves the encapsulation and distribution of the complete hardware and software stacks, including the operating system and driver interdependencies. This can result in intellectual property issues when offered as a service.

There are both local and global approaches to software conservation. One solution to keep the software in an executable state by preserving its context and runtime environment is to use containers such as Docker. However, to archive the Docker containers, additional metadata should be added and stored with the software in an archive container format that allows exchange between repositories and exit strategies, such as the BagIt container format⁸⁸. Application or platform conservation is also achieved by conservational efforts where unmaintainable (virtual) machines are sandboxed to keep the platform in a secure but running state. Other notable efforts in this direction include for example Singularity and Guix HPC. Another threat is losing project repositories on global platforms like Github or BitBucket. Here, global platforms like Software Heritage harvest those repositories and prevent loss by long-term archiving.

Challenges and clarifications

Clarification of rights. Software development is a creative activity. The main relevant law governing legal aspects is therefore the copyright law. It regulates the rights and obligations of the parties involved. Chapter 8 of the German Act on Copyright and Related Rights (UrhG) contains specific provisions applicable to computer programs and is based on the EU computer programs directive. Copyright law protecting the creator of software in similar ways exist in nearly all legal systems. It is important for the identification of rights that software, in the sense of (German) law, includes not only the source code but also the design materials⁸⁹. The challenge in the use, distribution, and commercialization of software is to determine the chain of rights and to identify all right holders. The owner of the copyright is not necessarily the owner of the right of use. For Germany, the Copyright Act regulates the rights for employment relationships⁹⁰. In such cases, the right of use is automatically transferred to the employer. This means that in most cases of employed software developers and research staff, the institution holds the rights of use for the software work. This is not automatically the case for students, freelancers, and individual external cooperation partners. Employment and service contracts with contributors could contain regulations regarding the transfer of rights of use. For researchers who conduct free research not subject to directives, in Germany the constitution guarantees freedom of research so that the rights of use for their work remains initially with the natural person. In addition to the rights of the people directly involved, other rights of third parties may also be relevant. Existing source code (e.g., other Free/Libre Open Source Software (FLOSS)), external libraries, and contributions from institutional cooperation partners are published and provided under certain licenses and their conditions must be observed (which, due to incompatibilities even among FLOSS licenses, may well mean that individually reusable pieces of software cannot be reused together or in a new context). The nature of research careers often brings additional complications to the chain of rights. It happens that researchers take their software with them when they change institutions and develop it further during their career. Here, the former employer may be entitled to some rights of use. In third-party funded projects, in particular with industry but also with public funding, rules regarding rights of use are often defined. Last but not least, the software can also be affected by other (intellectual) property rights such as patents or trademarks. Software itself is usually not patentable but it may implement a technical invention covered by patents. When using or distributing such software, an additional matching patent license may be necessary. Licenses exist (for example: GNU GPL v3) which automatically grant related patent licenses while using the software license. That should be considered when exploitation of the patent is planned.

Liability. Issues of warranty and liability for faulty software must be taken into account. We consider the possibilities of contractual limitation of liability in licenses. Full exclusions of liability are generally invalid in the German law. Limitations of liability usually depend on the form of distribution: The limitation options are larger if the rights of use are granted free of charge, e.g. provision “as is” as defined, e.g. in the BSD 3-clause license.

Ideas for solutions

In order to meet the legal challenges mentioned, it is absolutely necessary for the software developer (team) to document the rights chain comprehensively during the software development (one possible solution is presented in the accompanying report⁹¹). Contributions of individual persons must be traceable and their (labor law) status must be named. At best, contracts with rules on the transfer of rights of use should be concluded before work begins. Declarations of assignment of rights can be made for existing works. License conditions for external contributions must be evaluated with regard to further rights of use and possible sub-licensing. Contracts and funding conditions must be conscientiously documented and analyzed with regard to rules on rights of use. In case that different parts of the software are based on different conditions and rights of third parties, individual modules of the new software could be published under different licenses and merged accordingly.

A national research software sustainability institute could be established. This institute supports local research software task forces and thereby respective researchers and research teams in the licensing of research software and related legal issues. For this purpose, a legal help desk will be set up, to which all members of their respective research performing organization can apply. Such a legal help desk should be seen as an infrastructural investment to avoid any uncertainty about re-use of existing research software and to support research-friendly licensing. If researchers want to publish the research software under a Free/Libre Open Source Software (FLOSS) license, the organization could bundle the necessary rights beforehand. This is particularly useful when teams of researchers, often international, write software. In addition, the sustainability institute may serve as a one-stop-shop for the licensing of research software.

Recommendations

We see it as an essential part of the sustainability of research to enable the free distribution of research software. There are a variety of open source software licensing models (ranging from permissive to copyleft; for further information, see tldrlegal, the ifrOSS Lizenz-Center, or Morin et al., 2012⁴⁸). The use of an FSF- or OSI-approved FLOSS license for example would enable a truly free model and also reduce legal issues. We recommend that research funding organizations such as the DFG discuss if they expect publishing all funded software under these licenses, following the paradigm of “public money, public code”. If licenses such as Apache or MIT are applied, the research institutions may later still commercialize the software if appropriate. Such open source licensing is also beneficial for start-ups that intend to provide professional services for the software.

Also for legal aspects, we believe it is important that all (German) research performing organizations install a research software task force, especially in light of the new DFG Code of Conduct. Besides organization and bundling of technical and infrastructural support for local RSEs and researchers (see previous sections), this group should organize a local legal help desk, organize educational offers e.g. for the legal topics presented, and (if not implemented yet) develop the software policy of the research performing organization. As an example, with the help of on-boarding processes performed by the research software task force, RSEs should be able to keep the clearance of rights as simple as possible right from the start. This helps to avoid that - out of uncertainty and fear to make a legal mistake - some research groups end up not choosing any license at all, which may hinder reuse of the software. We suggest that the local task forces build a network with the other research performing organizations for exchange of ideas but also for generating a bottom-up strategy to organize RSE standards for Germany and beyond and possibly be the origin of the aforementioned software sustainability institute.

Underlying data

No underlying data are associated with this article.

Extended data

Decision trees and documentation templates for the legal topics are available on Zenodo⁹¹: doi: 10.5281/zenodo.4327147