Model Policy on Sustainable Software at the Helmholtz Centers

Sustainability

In the context of research software, sustainability is essentially aimed at ensuring the transparency, verifiability, and reproducibility of scientific findings and the reusability of the software. The above-mentioned application of the FAIR Principles to research software  contributes to this.

The <Helmholtz Center> undertakes to take aspects of sustainability into account in all stages of the life cycle of research software.

Sustainability shall be included as a factor in decision-making processes, especially in software development and documentation practice; the provision, publication, and archiving of research software; medium- and long-term maintenance; and the provision of corresponding infrastructures.

Development, Use, and Reuse of Research Software

Development and Documentation

The implementation and organization of good software development and documentation practice depends on numerous factors, for example, the scientific domain, the programming technologies employed, and the complexity of the software project. Therefore, the <Helmholtz Center> recommends the developer groups to gradually agree on and define necessary requirements by introducing suitable application classes. Application classes typically reflect the complexity of a software project. Hence, for scripts, for example, different quality requirements may apply depending on their degree of complexity.

The following standards will be established at the <Helmholtz Center > for the different application classes:

1. The developers shall rely on normal standards and state-of-the-art tools during the development, validation, verification, and deployment of the research software.
2. The observance of legal aspects (e.g., the rights of third parties) [→ Legal Aspects] is an integral part of the software development process and requires documentation (e.g., copyright notices).
3. Version control systems shall be used in each application class.
   • The corresponding repository shall contain or reference all components of the research software required for use.
   • A brief, informative description of the purpose of the research software shall be enclosed (e.g., in the form of a README file).
   • Machine-readable metadata shall be enclosed as citation information.⁴ After indexing,
     these metadata will also ensure the findability of research software.
4. Stable (release) versions shall be clearly identified for users, for example, by means of release numbers.⁵
5. For the purpose of citability, the research software shall be assigned a persistent identifier (PID) [→ Provision, Publication, and Citation]. The necessary metadata can be found in the citation information (see above).
6. If the research software is developed by a group, that group shall establish the processes and rules for development and collaboration, which shall be regularly reviewed and documented.
   This relates inter alia to topics such as:
   • Documentation of source text, interfaces, and concepts
   • Test strategies with different types of testing, automation, and times
   • Development methods (agile, iterative, ...)
   • Change management and code reviews
   • Collaborative use of tools and infrastructure
   • Definition of the development cycles
   • Communication channels
7. To facilitate the use of the research software, developers shall provide appropriate installation and user  documentation and designate a contact person.

To support the developers, the <Helmholtz Center> will make corresponding infrastructures and consulting services available [→ Support and Advice Services].

Support and Advice Services

To simplify the development work on research software, the <Helmholtz Center > will provide various support and advice services, as well as suitable state-of-the-art tools that reflect current needs:

1. Version control systems, preferably linked to collaborative functions for communities [→ Development and Documentation]
2. Automation tools and environments for the validation and verification of research software for the purpose of quality assurance
3. Archiving of research software:
   • Primarily for versions in the context of scientific publications
   • Storage of the research software, including accompanying data (e.g., metadata, runtime environment, test data)
   • Observance of retention periods in accordance with the rules of good scientific practice in the respective scientific disciplines
4. Licensing advice and release processes [→ Legal Aspects]

Quality Assurance and Archiving

The <Helmholtz Center> wants to increase the quality of the developed software in the long term in order to generate scientific added-value and visibility in the communities. It will develop compliance level and quality standards for the application classes and checklists for their evaluation.

Developers, developers responsible for the software, and project managers shall jointly ensure that the quality assurance measures will be implemented taking the scientific and economic perspectives into account:

1. Lived practice of the recommendations for the development and documentation of research software
2. Grouping of research software into application classes and its regular evaluation
3. Continuous improvement as a strategic goal
4. Building of a community for users and developers as a strategic goal
5. Compliance with the rules of good scientific practice through repositories that are available in the long term, and, if applicable, (long-term) preservation
6. Introduction of quality control processes

Sustainable research software presupposes that inactive and archived software is also reusable. The short life cycles of the technologies in the area of software development constitute a challenge in terms of the archiving of research software. When planning, implementing, and exploiting research software, developers, project managers, and managers must jointly decide on the basis of the application classes what action is to be taken in each individual case. The allocation of corresponding (long-term) resources shall be taken into consideration when planning.

In order to retain in the long term the existing expertise in developing high-quality software, the <Helmholtz Center> will, in addition, support the creation of sustainable, and where possible long-term, career prospects for roles relating to research software (e.g., RSEs,developers responsible for the software).

Continuing Professional Development, Career Prospects, and Networking

Because the quality of research software depends crucially on the existing knowledge and skills of the developers, continuing professional development (CPD) is of great importance to the <Helmholtz Center> and the Helmholtz Association. In particular, it should increase the motivation for active and sustainable software development in the long term among researchers whose focus lies outside computer science. The widest possible range of CPD and networking offerings at the <Helmholtz Center> will be organized in such a way that they are complementary to the cross-Center offerings of the Helmholtz Association.⁶
The <Helmholtz Center> will support its employees with the following measures:

1. To reward performance in the area of research software development, maintenance, and support, quality assurance, and software publications will be included in scientific reporting.
2. Provision of information offerings and professional support (with different levels of effort):
   • Central, regularly updated and moderated information offering. Examples: best practice guides, collection of tutorials, wikis for knowledge sharing
   • Exchanges in the workplace
   • Examples: community chats, FAQs, informal meetings (hacky hours), consultations (code clinic), communication with developers responsible for the software CPD offerings
   • Examples: software carpentries, training sessions, workshops, hackathons, consulting
   • Consulting provided by internal and/or external research software engineers
3. Facilitation of participation in regular CPD offerings for all employees on programming languages and techniques, methods in the area of software development, and legal aspects and licensing. Where possible, the foundations for sustainable research software management will already be anchored in the <Graduate Schools>.
4. Use of existing training offerings such as software carpentries and online courses as supplementary low-threshold offerings
5. Promotion of the establishment of a network for developers of research software within the <Helmholtz Center> in order to create a forum for community building and the exchange of experiences
6. Introduction of contact points for various matters relating to research software
7. Support for activities for networking developers also outside the Center
8. Support for the collaboration of developers in Helmholtz-wide activities and open source software
9. Support for the networking of developers of research software via various online and offline communication channels (Examples: mailing lists, forum, networking events)
10. Establishment of collaborations with other university and non-university institutions in the area of software development

Provision, Publication, and Citation

To meet the criterion of sustainability in science, the <Helmholtz Center> expects, on the one hand, that research software will be made available, and, on the other hand, that the use of research software by scientists will be indicated through citation, as in the case of research data and scientific publications.

The following framework conditions for provision and publication will apply:

1. Developers, managers, and project managers shall decide jointly and at the earliest possible stage on a strategy for the accessibility of the research software.
   • Accessibility to research software shall be aspired to for the largest possible circle of users as possible – ideally for the general public.
   • From the beginning, the possibility of transparent development in the interests of quality assurance shall be examined.
   • Early consideration of the legal aspects and release processes is indispensable for sharing and publication.
   • Irrespective of the accessibility of the research software as such, metadata on the research software shall be published in the sense of a software publication.
2. The realization of long-term accessibility by using internal and external support and advice services
3. The following shall apply to software publications:
   • Each publication shall be rendered citable by means of a persistent identifier (PID).
   • Publications shall at least include metadata.⁷
   • The publication may be subject to embargo periods (in the sense of withholding and waiting periods).

To increase the visibility of the contribution of research software to scientific results, the software shall be consistently cited in scientific publications.

Irrespective of its public accessibility, research software shall be cited with the following details in scientific publications:^{8, 9} authors, name of the software, PID, date of publication, release number if available. If no PID has been assigned, a revision and the URL of the source text repository can be provided instead.

Legal Aspects

The development, scientific use and reuse – including economic exploitation aspects – of research software must also take the relevant legal context into account. Both the making available of research software in the spirit of open science and its commercial use imperatively require that the necessary rights of disposal are held. The competent specialist departments shall check whether this is the case. As a matter of principle, research software is subject to copyright protection. Section 69a of the German Copyright Act (UrhG) protects software in any form, including drafts, in all forms of expression (QC, C, EXE, modules). By contrast, ideas and principles that underlie the work are not protected.

Although the moral rights of authors are not transferrable, the granting of rights of use and the conclusion of agreements on exploitation rights are permissible. Once the developers are in an employment or service relationship with the <Helmholtz Center>, the rights of use and the exploitation rights automatically lie with the Center (details are regulated in Section 69b of the German Copyright Act, UrhG). Special provisions (e.g., the conclusion of a contribution agreement) will therefore be made if third parties are included who do not have an employment contract or the like with the Center, for example, in the case of spin-offs or commercial use.

In the case of the deployment of external software, rights must also be granted by the author. It is imperative that the licensing conditions of the deployed (open source) software be observed, because non-observance may lead to copyright infringements. This is the case even if only program components or partial sequences are integrated by third parties into the Center’s own research software. In that case, an intensive legal assessment must be conducted to determine the extent to which the various licenses of the integrated third-party software contain contradictory provisions. This may mean that the Center’s own software cannot be published under the intended open source license.

Moreover, the open source license of the deployed software may terminate if the licensing conditions
are not complied with.

It is therefore imperative that, before work begins, the developers’ managers provide guidance on programming measures that prevent this so-called “infection”; that they draw the attention of the employees involved in software development to the possible civil and criminal consequences; and that they issue corresponding codes of behavior. Infringements of copyright can lead to criminal liability (see Section 106 of the German Copyright Act, UrhG).

The same applies to the use of external funding when developing research software. Here, the respective funding regulations and cooperation agreements must be taken into account if, for example, exclusivity for the benefit of the funder of a third party was agreed.

Summary of the main points:

• Allow only persons who have an employment contract or a comparable contract with the Center to work on the development of software.
• Have third parties (e.g., interns, students) who are involved in the development of software and who do not have an employment contract or similar contract transfer their rights to the <Helmholtz Center> by means of a contribution agreement.
• Before licensing, check carefully where the software comes from, who has worked on it, and what components owned by third parties were used for it.
• In the case of conflicts with the rights of third parties, replace or reprogram the research software or its components in such a way that infection is prevented.
• Take programming measures to ensure that the Center’s own software is not infected by copyleft software.
• In the case of different software components, check the compatibility of the licenses.
• Use documentation: version control systems; documentation of the open source software, the license texts, and the authors.
• Check the funding regulations and take them into account.

Aspects of Scientific and Economic Exploitation

This policy explicitly does not exclude downstream economic exploitation. Rather, scientific use and economic exploitation aspects can certainly be common elements of a coordinated exploitation strategy for research software. Economic exploitation aspects do not arise immediately in the course of the development or use of research software. In most cases, exploitation occurs downstream in the context of the contract-related or cooperative acquisition of third-party funding in the technology-driven industrial context.

Therefore, especially with a view to economic exploitation, all necessary commercial rights of use and exploitation rights must be secured at an early stage (e.g., if third parties such as freelancers are involved in the development or research work).

Irrespective of the later use or reuse, it is therefore important to avail of the support and advice services provided and, when the development work begins, to implement the above-described measures for the development, use, and reuse of research software. Only in this way is it sufficiently possible to check in each individual case whether the rights of third parties are infringed, and thus a scientific or economic use or reuse is restricted or even prevented.

The developers and their managers are hereby invited to contact the relevant specialist departments (e.g., legal department, technology transfer, IT) and discuss their respective situations.

Appendix

Glossary

Application classes
Application classes¹⁰ serve to classify research software and set out corresponding rules and recommendations regarding appropriate software development practice and documentation. They facilitate the checking of the rules and communication on the related topics. Further information on the concept can be found in the German Aerospace Center (DLR) document DLR Software Engineering Guidelines (pp. 7 et seq.),¹¹ which provides an exemplary definition of sequential application classes. Application Class 1, for example, specifies minimal recommendations for non-critical research software of limited scope (e.g., data analysis scripts) and is compatible with the minimal development and documentation practice specified in that document.

Copyleft
Further developments of the software must be shared under the same licensing terms as the original software. Strict copyleft: no exceptions! (GPL, AGPL, CPL). All adaptations must be distributed under the same licensing terms as the original software. Limited copyleft: Exceptions from strict copyleft are possible and permissible (MPL, LGPL).

Developers
Developers are persons who develop software for scientific purposes in the course of their work (this term covers both scientists who develop software and software developers who develop software in scientific projects).

Developer group
The developer group comprises the natural persons who participate in the development of research software.

Developer responsible for the software
The developer responsible for the software is the spokesperson of the developer group and acts as a direct contact person for the research software. In the case of research software with a limited scope, the developer responsible for the software is usually the lead developer. The developer responsible for the software plans the further development of the research software taking into account the requirements of users and of various research projects, provides information on the development status, and organizes the development process. They also participate in the coordination and definition of access rights and rights of use.

Life cycle of research software
The life cycle of research software comprises all essential development stages, from the idea and conception, through the development, use, and maintenance, to the archiving and decommissioning.

Non-copyleft
Further developments of the software may be released under different licensing terms than the original software (e.g., BSD, Apache); no obligation to license new or modified code. Licenses with special rights (e.g., NPL, QPL). Users who modify the software must grant the owner of the original software special rights. Licenses with options (Artistic/Perl). Users who modify the software may choose between different licensing options for their modifications.

PID
Persistent Identifier (https://en.wikipedia.org/wiki/Persistent_identifier)

Project manager
In the context of scientific projects, a manager is usually entrusted with the management of the project. Depending on the scope of the research software and its share in the project, the project manager may also be the developer responsible for the software.

Release
A release is the stable version of the research software that is made available to users or that makes a contribution to a scientific publication. Following a scheme,¹² a release number ensures that the release and the content associated with it are clearly labeled.

Research software
The term “research software” refers to all forms of program code (e.g., source code together with accompanying documentation, parameters, and workflows) and programs generated therefrom that are developed and/or (re)used in the context of a science-related activity at Helmholtz Centers.

RSEs
Research software engineers (https://rse.ac.uk/about/; de-rse.org/en/)

Software publication
Analogous to research data and scientific texts, research software is also an outcome of scientific work. Thus, as a scientific publication, it can be made known to a wide audience. Nonetheless, analogous to research data, access to research software from the publication may be restricted. Like research data and text publications, a software publication includes metadata by means of which it is findable and citable.

Version control system
The version control system serves to record changes to data (e.g., documents, program code) by a defined group of persons that are managed in a common repository. Each change is associated with a timestamp and the person who made the change. The resulting history allows changes to be traced and enables a return to earlier stages.

References

¹ Paper: “Recommendations for the Implementation of Guidelines and Policies on Research Software Management at
the Helmholtz Centers”: https://doi.org/10.48440/os.helmholtz.040

² https://os.helmholtz.de/open-science-in-der-helmholtz-gemeinschaft/open-research-software/

³https://www.force11.org/group/fairgroup/fairprinciples; https://www.nature.com/articles/sdata201618

⁴https://research-software.org/citation/developers

⁵ Should be governed by a scheme; see practice document and https://semver.org/.

⁶ For example, the Helmholtz Information & Data Science Academy (HIDA): https://www.helmholtz.de/forschung/information-data-science/helmholtz-information-data-science-academy-hida-research-schools/

⁷https://research-software.org/citation/researchers

⁸ See also recommendations of the FORCE 11 Working Group: Smith AM, Katz DS, Niemeyer KE, FORCE11 Software
CitationWorking Group. (2016) Software citation principles. PeerJ Computer Science 2:e86, https://doi.org/10.7717/peerj-cs.86

⁹https://research-software.org/citation/researchers

¹⁰https://rse.dlr.de/guidelines/00_dlr-se-guidelines_de.html#anwendungsklassen

¹¹https://doi.org/10.5281/zenodo.1344608

¹² See, for example, https://semver.org/