PIDs und Zitation

Anerkennung von Forschungssoftware

Zählt Software als Publikation in Bewerbungen und Anträgen?

  • Nein, nicht zwangsläufig. Die Anerkennung von Forschungssoftware hängt von vielen Faktoren ab.
  • Jedes Max-Planck-Institut kann hierzu eigene Regelungen schaffen. In der MPG-GWP steht hierzu kein verbindliches Vorgehen.
  • Je nach Disziplin, Forschungsfragen und Fachkultur kann es aber sinnvoll sein, Forschungssoftware als Publikation zu werten, inkl. der damit verbundenen internen Wertschätzung.
  • Es ist aber sinnvoll, dies schon im Vorfeld den Bewerbenden z.B. in der Stellenanzeige zu kommunizieren.

Beispiel: Helmholtz Open Sciene Policy
“Bis 2024 wird ein Helmholtz-Qualitätsindikator für Forschungssoftware-Publikationen entwickelt und etabliert, der im Rahmen der PoF eingesetzt wird und den Einstiegsindikator ablösen wird.”
Quelle: Helmholtz OS Policy

Beispiel: DFG
Die DFG erlaubt seit September 2022 bei Bewerbungen nur noch maximal zehn Veröffentlichungen in einem Publikationsverzeichnis. Darüber hinaus dürfen aber zehn weitere Leistungen genannt werden. Hier bietet es sich an, relevante Forschungssoftware zu nennen.
Quelle: DFG-Vordruck 1.91 – 09/22

Gibt es MPG-interne Leistungsbewertungen, um Forschungssoftware zu honorieren?

  • Nein, hierzu existieren keine Max-Planck-weiten Vorgaben.
  • Jedes Max-Planck-Institut, jede Abteilung etc. kann sich aber intern auf eine Leistungsbewertung für Forschungssoftware einigen. Es gibt hierzu keine zentralen Vorgaben.
  • Für die transparente Kommunikation hierzu kann es sinnvoll sein, sich als Institut eine eigene Forschungssoftware-Policy zu geben. Hierdurch entsteht für alle Beteiligten Rechtssicherheit. Gleichzeitig wird der Umstand deutlich kommuniziert, dass Forschungssoftware als Ergebnis eine klare Wertschätzung erfährt.

Beispiel: Max-Planck-Institut für Meteorologie
Das MPI-M ist der Meinung, dass Forschungssoftware zum Wohle der Wissenschaft als Open-Source-Software veröffentlicht werden sollte. Quelle: Software Licensing and Copyright Policy for Research SoftwareCODE@MPI-M

Forschungssoftware veröffentlichen

Gibt es Empfehlungen wie und wo Forschungssoftware veröffentlicht werden soll?

  • Laut MPG-GWP muss “[d]er Quellcode von öffentlich zugänglicher Software [..] persistent, zitierbar und dokumentiert sein.”1
  • Diese Punkte können am sinnvollsten durch Repositorien, Journals und sonstige Dienste gewährleistet werden, die sich auf Software spezialisiert haben.
  • Ähnlich wie bei Forschungsdaten werden Dienste nach folgenden Kategorien empfohlen:
  1. Forschungssoftware-spezifische Journals
  2. Software-Repositorien
  3. Institutionelle Publikationsorte
  4. Generische Publikationsorte
    • z.B. Zenodo; siehe auch die FAQ zu Repositorien
    • Abhängig vom Anwendungsfall kann es sinnvoll sein, verschiedene Publikationsorte zu kombinieren
  5. GitHub (für den laufenden Entwicklungsstand) und Zenodo (für genau definierte Versionen/Releases); How-to auf Youtube
  6. Softwarejournal und GitHub

Beispiel: Max-Planck-Institut für Struktur und Dynamik der Materie
“Mit der Software ubermag können Sie Ihre mikromagnetischen Simulationen vom Jupyter-Notebook aus steuern.”
Quelle: Übersetzung von https://ubermag.github.io; siehe auch https://doi.org/10.1109/TMAG.2021.3078896

Wer gilt als Autor_in einer Software?

  • Jede_r, der einen nicht unwesentlichen Teil des Codes geschrieben hat, dabei reichen schon wenige Zeilen, ist Autor_in.
  • Personen, die lediglich Ideen liefern (Vorgesetze, Forschende, die die Software in Auftrag geben), sind nicht Autor_innen. Jedoch sind auch schon Entwurfsmaterialien des Codes durch das UrhG geschützt. Das bedeutet für Autor_innen des Entwurfsmaterials aber nicht die Autorschaft des Codes.

Beispiel: Pull Request
Doktorandin A macht einen Pull Request auf ein git Repositorium. Der Request wird akzeptiert, dadurch wird der von A geschriebene Code zum Bestandteil des nächsten Software Releases. A wird folgerichtig in die Liste der Autoren aufgenommen.

Gegenbeispiel: Issue
PostDoc B findet einen Fehler im Code einer Simulationssoftware. Er öffnet auf github ein Issue, in dem er den Fehler beschreibt. Später wird der Fehler vom Entwicklerteam der Software behoben und ein neuer Release veröffentlicht. B wird nicht in die Autorenliste aufgenommen aber in den Release Notes dankend erwähnt.

Beispiel: RDMO
Auflistung der Mitarbeit an der Software “RDMO” samt Issues im Changelog für 1.4.0-rdmo-1.6.0

  • Bei Unklarheiten bietet es sich an, ähnlich wie bei Forschungsdaten, genau zu spezifizieren, welche Person welche Aspekte bearbeitet hat.
  • Dabei können die weiter gefassten Begriffe “Beitragende” oder “Mitwirkende” (engl.: “Contributors”) verwendet werden, unter welchem auch die obigen Beispiele eingeschlossen sind.
  • Links zu Tools und Initiativen, die das Ziel haben, verschiedenen Arten von Beiträgen Rechnung zu tragen:
    • All Contributors Project: Spezifikation für die Anerkennung von Mitwirkenden an einem Open-Source-Projekt auf eine Weise, die jeden Beitrag belohnen soll
    • All Contributors Emoji Table: Emojis zur Darstellung der Arten von Contributorship
    • CRediT: Rollen-Taxonomie für Mitwirkende
    • Tenzing: App zur Erstellung von Berichten über die Beiträge, basierend auf CRediT

Wie ist Autorschaft von Software kenntlich zu machen?

  • Die Autorenschaft (oder allgemeiner “Mitwirkung”, engl. “Contributorship”) ist klar und deutlich wiederzugeben. Dies geschieht am besten in einem menschen- und machinenenlesbaren Weg.
  • Das Citation File Format (CFF) ist der empfohlene Weg, die Autorenschaft an einer Software kenntlich zu machen. Eine.cff-Datei kann leicht z.B. online erstellt werden und zum Software-Repository gelegt. Gängige Softwarerepositorien wie GitHub, aber auch Zotero oder Zenodo, unterstützen das .cff-Format. Eine Erweiterung auf “contributors” (gegenüber bisher lediglich “authors”) ist für eine künftige cff-Version vorgesehen.
  • Weitere Wege sind Dateien zu erstellen wie “authors.txt” oder “contributors.md”.
  • Umfangreiche Software-Metadaten (auch jenseits der Contributorship) können in einer CodeMeta-Datei hinterlegt werden.
  • Ebenso kann die Autorenangabe im Changelog hinterlegt werden. Dies bietet sich besonders an, wenn Personen spezifische Bestandteile des Releases geliefert haben.
  • Letztendlich ist es auch möglich, die Autorenschaft im Lizenzdokument (falls dies die Lizenz zulässt), in einer Readme Datei oder in einem anderen Textdokument zu vermerken. Dieser Weg hat jedoch den wesentlich Nachteil, dass er kaum machinenlesbar ist.

Beispiel: Max-Planck-Institut für Dynamik komplexer technischer Systeme
pymor.org

Persistente Forschungssoftware

Wie wird Software persistent?

  • Software kann in unterschiedlichen Stadien dauerhaft erhalten – also persistent – werden:
  1. Mit der “Bitstream Preservation” werden ’ledglich’ die binären Information wie beispielsweise Buchstaben, Ziffern etc. erhalten. In diesem Zustand wird der Code als Text konserviert. Diese werden als Daten langzeitarchiviert, sodass sie auch große Zeitabstände überdauern. Die Funktionalität der Software ist in diesem Zustand nicht garantiert. Im Gegenteil, je älter desto wahrscheinlicher werden Fehler. Auch wird es mit der Zeit immer unwahrscheinlicher, dass der Code noch mit den dann gängigen Betriebsystemen, Laufzeitbibliotheken, Dateiformaten etc. kompatibel ist.
  2. Mit der “Migration und Emulation” als weiterer Strategie wird die Software so erhalten, dass sie samt Kontext erhalten und in anderen Systemen abspielbar bleibt. Hierbei könnnen Container wie z.B. Docker und zusätzliche Informationen helfen. Darüber hinaus wird die Software so konzipiert und mit Informationen angereichert, dass in der Zukunft die alte Umgebung der Software emuliert, also technisch nachgestellt werden kann.
  3. Die “inhaltsbezogene Erhaltung” zielt auf den funktionalen Erhalt der Software ab. Die Strategie hierbei ist die kontinuierliche Wartung und ggf. sogar Weiterentwicklung der Software, um die intendierten Funktionen der Software über einen langen Zeitraum zu erhalten. Sie ist mit Abstand die aufwendigste Erhaltungsstrategie, die sie eine kontinuierliche Wartung und Ressourcen benötigt. Es kann auch ein Problem mit der Reproduzierbarkeit geben, wenn sich die Funktionalität im Laufe der Zeit ändert.

Beispiel: Max-Planck-Institut für Innovation und Wettbewerb
Software Go Open Alex auf Software Heritage

Welche PID sollte für Software verwendet werden?

Beispiel DOI Selfservice der MPDL https://doi.mpdl.mpg.de/request-doi/ nur im MPG-IP-Range verfügbar

Wie wird Software zitierfähig?

  • Software wird zitierfähig in dem sie mit genügend Metadaten versehen wird. Minimal sind dies Titel, Autor_innen, Veröffentlichungsdatum. Sinnvoll ist auch Affiliation, vergebene Lizenz und Identifikator anzugeben.
  • Mit einer .cff-Datei können die Metadaten zu einer Software besonders leicht zitierbar gemacht werden. GitHub, Zenodo, Zotero usw. unterstützen dieses Format mittlerweile und vereinfach dadurch die Zitation von Software erheblich.

Beispiel: Max-Planck-Institut für Bildungsforschung
.cff-Datei für das GitHub-Repository “Self-paced Julia Workshop”: https://github.com/formal-methods-mpi/Workshop.jl/blob/main/CITATION.cff

Wie zitiere ich die verwendeten Softwarepakete in einer Publikation?

  • Je nach Publikationsart ist es sinnvoll mehr oder weniger Informationen von einer Software zu erwähnen. Es ist hierbei sinnvoll sich nach den Vorgaben der Software-Autor_innen zu richten.
  • Ansonsten muss laut MPG-GWP “die Herkunft von im Forschungsprozess verwendeten Daten, Organismen, Materialien und Software kenntlich gemacht und die Nachnutzung belegt”1 werden. Die konkrete Umsetzung und welcher Zitationsstil verwendet wird, unterliegt keiner zentraler Vorgabe.
  • Die Software Citation Principles von 2016 geben in Abschnitt 4 einige Beispiele, welche Informationen wann erwähnt werden sollten.

Beispiel: Max-Planck-Institut für Plasmaphysik Greif, R., (2023). HW2D: A reference implementation of the Hasegawa-Wakatani model for plasma turbulence in fusion reactors. Journal of Open Source Software, 8(92), 5959, https://doi.org/10.21105/joss.05959.

Wie kennzeichne ich Programmteile Dritter in meinem Code?

  • Die Nutzung von externen Elementen direkt im Code sollte – zusätzlich zu den Lizenzbedinungen – als direkter Kommentar eingebunden werden.
  • Gleichzeitig ist es sinnvoll, im Hauptverzeichnis eine eigene Sammlung von eingebundenen Bibliotheken zu erstellen, wie requirements.txt, package.json, acknowledgements.txt, environment.yml,pom.xml etc.
  • Im Zweifelsfall sollten alle verwendeten externen Elemente nochmals separat z.B. in einer readme-Datei aufgelistet und korrekt zitiert werden.
  • Software, die mit einer SWHID versehen ist, kann auch in Teilen zitiert werden, also einzelne Dateien oder Codezeilen.

Beispiel: Max-Planck-Institut für Information environment.yml für die Software “Scene-Aware 3D Multi-Human Motion Capture”

  1. Max-Planck-Gesellschaft, Verantwortliches Handeln in der Wissenschaft: Verhaltensregeln für gute wissenschaftliche Praxis – Umgang mit wissenschaftlichem Fehlverhalten, S. 12, https://www.mpg.de/197494/rulesScientificPractice.pdf. ↩︎ ↩︎

FORS  IT4SCIENCE  FAQ  Authorship  PID  Citation  Publication