Versionierung, Lizenzierung, Zitierfähigkeit

6.1. Versionierung, Lizenzierung, Zitierfähigkeit#

Story

../_images/abb_k06_semver_license_pid.png

Fig. 6.2 Versionieren, lizenzieren, zitieren (KI-generiert)#

Die systematische Aufbereitung der Daten ist abgeschlossen und die zu publizierenden Datensätze sowie Metadaten liegen in offenen Formaten vor. Auch die notwendigen Dokumentationsdateien (README.md, Guides, Tutorials usw.) wurden erstellt, um die Daten zu kontextualisieren und die angewandten Methoden nachvollziehbar zu machen. Doch wie geht es anschließend weiter?

Das filmwissenschaftliche Teilprojekt ”C05 Intervenierende Weltentwürfe: Audiovisualität des Klimawandels” hat bereits mehrere Publikationswege evaluiert und sich dazu entschieden, das Datenset in einem ersten Veröffentlichungsschritt auf GitHub/Zenodo zu publizieren. Mehr Informationen zu Repositorien können im Kapitel Publikationswege und -formate abgerufen werden.

Bevor die Daten auf GitHub hochgeladen werden, sollten zunächst Fragen der Versionierung, Lizenzvergabe und Zitierfähigkeit berücksichtigt werden. Die folgenden drei Abschnitte erläutern die dafür relevanten Grundlagen praxisnah und exemplarisch.

Versionierung#

Die Versionierung von Forschungsdaten ermöglicht eine eindeutige Referenzierung und Nachvollziehbarkeit bestimmter Veröffentlichungsstände eines Datensatzes. Sie trägt dazu bei, Änderungen transparent zu dokumentieren und unterschiedliche Versionen digitaler Forschungsartefakte voneinander abzugrenzen.

Für die Versionierung existieren unterschiedliche Ansätze. Ein besonders verbreitetes System zur Versionierung ist Semantic Versioning: kurz “SemVer”. Ursprünglich in der Softwareentwicklung etabliert, wird es heute auch für Forschungsdaten aller Art angewandt. SemVer dokumentiert kleinteilig alle Versionsnummern und Änderungsverläufe publizierter oder publikationsreifer Software und Daten bzw. Datensätze.

Neben SemVer werden auch andere Versionierungsschemata verwendet, beispielsweise fortlaufende Versionsnummern (v1, v2…) oder datumsbasierte Versionierungen (siehe: CalVer). Für GitHub-basierte Workflows hat sich SemVer jedoch als Standard etabliert. Da das vorliegende Projekt die Daten auf GitHub/Zenodo publiziert, soll das Schema hier vorgestellt werden.

Wie funktioniert das Schema?#

Das Schema folgt dem Prinzip eines dreistelligen Nummernsystems:

  1. MAJOR, z. B. 2.0.0 → Es wurden grundlegende bzw. inkompatible Änderungen durchgeführt, bestehende Codes oder andere Programme aus vorigen Versionen funktionieren womöglich nicht mehr

  2. MINOR: z. B. 2.1.0 → Neue Funktionen wurden hinzugefügt, alte Versionen funktionieren aber noch, sie sind also abwärtskompatibel

  3. PATCH: z. B. 2.1.1 → Kleine Bugfixes oder Tippfehler, es wird nichts Strukturelles verändert, alles ist weiterhin abwärtskompatibel

Neben der dreistelligen Versionsnummerierung gibt es zusätzlich noch sogenannte “pre-realease version labels” bzw “pre-release tags”. Sie kennzeichnen Entwicklungsstadien vor der offiziellen Veröffentlichung und signalisieren Nutzenden so, dass eine Version noch nicht vollständig oder stabil ist.

Die Zeitleiste einer Version kann beispielsweise so aussehen:

alpha → beta → release candidate → finale Version

0.1.0-alpha.1 → 0.1.0-beta.1 → 1.0.0-rc.1 → 1.0.0

  • alpha steht für die frühe Entwicklungsphase, die Version ist also noch nicht vollständig bzw. in einem Rohbau und anfällig für Fehler - wird eher für interne Testungen genutzt

  • beta beschreibt eine weitestgehend fertige Entwicklungsstufe, die breiter getestet wird und in denen Fehler weiterhin auftreten können

  • rc ist die Abkürzung für “release candidate” und markiert eine quasi fertige, publikationsreife Version

  • Die finale Version entspricht dann einem MAJOR Release

Schreibweise pre-release labels

Die pre-release labels werden immer mit einem Bindestrich an die Versionsnummer angehängt, wie oben im Beispiel zu sehen ist.

Für Forschungsdaten ist die Verwendung von pre-release version labels je nach Projektkontext abzuwägen. Bei abgeschlossenen Projekten mit gesetztem Laufzeitende liegen die Datensätze zur Publikation meist vollständig vor und können auf Version 1.0.0 publiziert werden, da oft keine wesentlichen Änderungen zu erwarten sind. Die Nutzung von pre-release tags ist insbesondere dann sinnvoll, wenn abzusehen ist, dass wesentliche Entwicklungen oder Änderungen eintreten werden.

Lizenzierung#

Neben der Versionierung, ist weiterer zentraler Schritt der Publikation die Vergabe von Lizenzen. Forschende und Forschungsprojekte sollten sich frühzeitig mit der Frage der Lizenzierung auseinandersetzen, um etwaige lizenzrechtliche Unschlüssigkeiten oder Unsicherheiten bereits im Vorfeld zu klären. Denn Lizenzen legen fest, unter welchen Bedingungen andere Personen die Forschungsdaten nutzen, bearbeiten oder weitergeben dürfen.

Die Creative Commons Lizenzen (CC) im Überblick#

Insbesondere für kreative Werke und Texte, aber auch für Forschungsdaten oder Annotationen haben sich die Creative-Commons-Lizenzen als übergreifender, internationaler Standard etabliert.

Was ist CC?#

Creative Commons (CC) ist eine Non-Profit-Organisation, die in Form vorgefertigter Lizenzverträge eine Hilfestellung für Urheber zur Freigabe rechtlich geschützter Inhalte anbietet.

Es werden sechs Standards-Lizenzverträge angeboten, die für die Publikation und Verbreitung kreativer Inhalte oder Ressourcen genutzt werden können, um die rechtlichen Bedingungen zu definieren. Sie bestehen aus kombinierbaren Modulen, die unterschiedliche Nutzungsrechte festlegen.

Modul Bedeutung
BY – Namensnennung Urheber:in muss genannt werden
SA – Share Alike Weitergabe nur unter gleicher Lizenz
NC – Non-Commercial Nur nicht-kommerzielle Nutzung
ND – No Derivatives Keine Bearbeitungen erlaubt

Daraus ergeben sich sechs Lizenzkombinationen sowie zusätzlich die Lizenz CC0 (= vollständiger Rechteverzicht bzw. Public Domain Dedication):

CC BY · CC BY-SA · CC BY-ND · CC BY-NC · CC BY-NC-SA · CC BY-NC-ND · CC0

Wer im Sinne der FAIR-Prinzipien handelt will, sollte für Forschungsdaten die möglichst offene Lizenz CC BY 4.0 wählen, da sie die Nachnutzung und Zitierbarkeit unter Namensnennung sicherstellt.

Keine Lizenzangabe

Ohne explizite Lizenzangabe gilt automatisch das Urheberrecht, das heißt, dass eine Nachnutzung ohne Rückfrage rechtlich nicht erlaubt ist.

Was ist der Unterschied zwischen 4.0 und 3.0?#

Die CC-Versionen 4.0 sind die aktuellen und überarbeiteten Lizenzverträge, welche ausdrücklich empfohlen werden. Ab Version 4.0 decken die CC-Lizenzen ebenfalls Datenbankrechte ab. Insofern sind die Lizenzen auch explizit für Forschungsdaten geeignet. Forschungsdateninfo weist darauf hin, dass bei früheren Versionen die Schutzwirkung fraglich ist.

Welche Lizenz passt zu meinen Daten?#

Um die Auswahl der Lizenz zu erleichtern, haben Barbara Klute und Jöran Muuß-Merholz für wb-web eine Entscheidungsgrafik erstellt:

../_images/abb_k06_lizenzwahl.jpg

Fig. 6.3 Grafik von Barbara Klute und Jöran Muuß-Merholz für wb-web © CC BY SA 3.0#

Ebenso kann mit dem Creative Commons License Chooser eine passende Lizenzempfehlung durch Ausfüllen des Minimalfragebogens ausgegeben werden.

../_images/abb_k06_cc_chooser.png

Fig. 6.4 Fragebogen des CC License Choosers#

Unwiderruflichkeit von CC-Lizenzen

Eine einmal vergebene Lizenz kann nicht zurückgezogen werden. Ein Werk kann also auch dann noch weiterhin gemäß den ursprünglichen Lizenzbedingungen genutzt werden, wenn der/die Urheber:in die Lizenz nachträglich ändern möchte. Neue Versionen eines Datensatzes können jedoch unter einer anderen Lizenz veröffentlicht werden. Für die Praxis bedeutet dies, dass die Lizenzvergabe vor der Publikation sorgfältig zu prüfen ist. Nachträgliche Änderungen (z. B. von CC BY zu CC BY-NC) gelten dann nur für neue Versionen, nicht für bereits veröffentlichte Stände.

Lizenzen für Code und Software#

Für Programmcode oder beispielsweise Pythonskripte und Software jeglicher Art gelten CC-Lizenzen als ungeeignet, da software-spezifische Komponenten wie Kompatibilität oder Abhängigkeiten nicht mit definiert werden. Daher gibt es für Codes, Software und Skripte eigene Lizenzen:

Lizenzierung in der Filmwissenschaft#

Die Lizenzierung von Forschungsdaten und Forschungsmaterial ist durch das geltende Urheberrecht an audiovisuellem Material recht komplex. Primärdaten wie Filme, Filmausschnitte, Screenshots oder Videomaterial sind urheberrechtlich geschützt und können in der Regel nicht offen publiziert werden. Eine Ausnahme ist das Bildzitatrecht, das unter bestimmten Bedingungen greift.

Für die Publikation von Primär- und Sekundärdaten gelten folgende Empfehlungen:

  • Primärdaten (z. B. Film-, Bild- und Videomaterial): Können aufgrund des Urheberrechts in der Regel nicht publiziert werden, es sei denn, die Rechte wurden ausdrücklich eingeholt oder das Material ist Public Domain. In diesem Fall gilt die Ursprungslizenz des Materials.

  • Sekundärdaten (z. B. Annotationen, Metadaten, Analysen, Transkripte, Dokumentationen usw.): Können unter CC-Lizenz publiziert werden, da sie eigenständige wissenschaftliche Werke darstellen.

Sonderfall Moviebarcodes#

Moviebarcodes stellen einen Sonderfall dar und sind nicht lizenzierungspflichtig. Informationen zur konkreten rechtlichen Einordnung gibt es hier. Sofern keine projektspezifischen Anforderungen entgegenstehen, empfiehlt sich die Wahl einer der beiden hier vorgestellten Varianten:

Variante 1: Hinweis in der Lizenz-Dokumentation

Die in diesem Verzeichnis enthaltenen PNG-Dateien ("Moviebarcodes")
sind automatisch erzeugte, rein schematische Darstellungen von Farb-
und Helligkeitsverläufen audiovisueller Werke.

Sie stellen keine eigenständigen kreativen Werke dar und sind daher
nicht von der Hauptlizenz des Datensets erfasst.

An diesen Visualisierungen werden keine Urheberrechte geltend gemacht.

Variante 2: CC0 - Public Domain Dedication

Die in diesem Verzeichnis enthaltenen PNG-Dateien ("Moviebarcodes")
werden unter CC0 1.0 Universal (Public Domain Dedication) 
veröffentlicht: https://creativecommons.org/publicdomain/zero/1.0/

Soweit rechtlich möglich, verzichten die Autor:innen auf alle
urheberrechtlichen und verwandten Schutzrechte an diesen Dateien.

Beide Varianten sind praktikable Möglichkeiten, um die Lizenzierung konkret für die Moviebarcodes zu bestimmen.

Weiterführende Ressourcen

Fallbeispiel: Lizenzierung des Projektdatensatzes#

Wie kann die konkrete Lizenzierung für einen filmwissenschaftlichen Datensatz mit heterogenen Forschungsdaten aussehen? Anhand des Projektdatensatzes Intervening World Projections: Audiovisuality of Climate Change – Dataset kann exemplarisch gezeigt werden, wie eine Mehrfachlizenzierung sinnvoll umgesetzt werden kann.

Ressource Lizenz Begründung
Korpus-Metadatenschema (yml) CC0 1.0 Universal (Public Domain Dedication) Offene Nachnutzung angestrebt, auch für kommerzielle Zwecke nutzbar
Annotationsdaten (azp, json) Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) Eigenständige wissenschaftliche Werke, offene Nachnutzung erwünscht
Metadaten und Dokumentation (verschiedene Formate) Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) Offenheit im Sinne der FAIR-Prinzipien
Moviebarcodes (png) Keine Lizenz Kein urheberrechtlicher Schutz als eigenständige Werke
Primärdaten (mp4, mkv) — Nicht publiziert, da urheberrechtlich geschütztes Filmmaterial

Die vollständige Lizenzdokumentation ist in der LICENSE.md im Repository des Datensatzes hinterlegt.

Was ist eine LICENSE-Datei?

Ähnliche wie die README-Datei, ist eine LICENSE.md eine einfache Textdatei im Markdown-Format, die die rechtlichen Nutzungsbedingungen eines Datensatzes oder Repositoriums definiert. Es wird als Best Practice empfohlen, die Lizenzdatei dem Projektrepository hinzuzufügen.

Weiterführende Links und Ressourcen zum Thema Lizenzen

Daten zitierbar machen#

Im letzten Teil dieses Kapitels soll es nun um die Zitierfähigkeit der Daten gehen. Wie Publikationen, so sollten auch Forschungsdaten korrekt angegeben und zitiert werden. Um die eigenen Forschungsdaten zitierbar zu machen, gibt es unterschiedliche Wege. In dem Kapitel zu allgemeinen Metadatenstandards sind wir bereits kurz auf Dublin Core und DataCite eingegangen. Neben diesen Varianten, ist die Nutzung des sogenannten Citation File Format (CFF) für Daten und Software, insbesondere in Git-Repositorien, sehr verbreitet.

Die CITATION.cff ist eine standardisierte Metadatendatei im YAML-Format, die beschreibt, wie ein Datensatz oder eine Software korrekt zitiert werden soll. Sie wird von GitHub und Zenodo direkt unterstützt. Wer das Repo besucht, kann die Zitationsinformationen also mit einem Klick exportieren.

../_images/abb_k06_cff_github.png

Fig. 6.5 Zitieren des Repositoriums über die CITATION.cff#

Ohne explizite Zitierstandards werden Forschungsdaten oder Software entweder inkonsistent oder gar nicht zitiert. Mit Formaten wie der CITATION.cff können diese Probleme minimiert werden, indem maschinenlesbare Zitiermetadaten direkt in den jeweiligen Repositorien hinterlegt werden.

Aufbau einer CITATION.cff#

Wie eine CITATION.cff aufgebaut ist, zeigt folgender Eintrag – übernommen aus der Dokumentation von GitHub:

cff-version: 1.2.0
message: "If you use this software, please cite it as below."
authors:
- family-names: "Lisa"
  given-names: "Mona"
  orcid: "https://orcid.org/0000-0000-0000-0000"
- family-names: "Bot"
  given-names: "Hew"
  orcid: "https://orcid.org/0000-0000-0000-0000"
title: "My Research Software"
version: 2.0.4
doi: 10.5281/zenodo.1234
date-released: 2017-12-18
url: "https://github.com/github-linguist/linguist"

Für die Erstellung einer CITATION.cff kann ein kostenloser Code- und Text-Editor wie VS Code genutzt werden.

Generierung/Validierung

Vor der Publikation sollte die CITATION.cff auf ihre Korrektheit überprüft werden. Dafür steht cffinit (CITATION.cff Generator) zur Verfügung. Der Generator zeigt nicht nur Fehler an, sondern kann auch als interaktives Formular zur Erstellung einer CITATIION.cff genutzt werden und wird ausdrücklich zur Nutzung empfohlen.

Wichtig für die Zitierfähigkeit der Daten ist in jedem Fall ein persistenter Identifikator (kurz: PID). Dies ist für Forschungsdaten häufig eine DOI (Digital Object Identifier), also ein eindeutiger und permanenter Identifikator für digitale Objekte wie beispielsweise wissenschaftliche Aufsätze, Publikationen, Forschungsdaten oder Videos. Ähnlich wie eine ISBN-Nummer, dienen DOI’s dazu, Objekte im Internet dauerhaft auffindbar und zitierbar zu machen. Eine DOI besteht häufig aus einer Aneinanderreihung von Zahlen. Die Kennung beginnt immer mit 10, zum Beispiel: doi:10.1000/199. Die DOI sollte in der CITATION.cff angegeben werden. Viele Repositorien vergeben DOIs bei einer Publikation automatisch. Eine Übersicht für Repositorien mit DOI-Vergabe findet sich hier.

DOI-Vergabe und GitHub

Für die Vergabe von DOIs wird GitHub in der Regel mit einem Repositorium wie Zenodo verknüpft. Das vorliegende Projekt nutzt ebenfalls diese Kombination. Nach der Publikation auf Zenodo wird die DOI für das Repositorium generiert und kann anschließend in der CITATION.cff ergänzt werden. Es empfiehlt sich, im Vorfeld einen Platzhalter (Beispiel-DOI oder Ähnliches) für die DOI einzutragen, um ggf. Fehlermeldungen bei der Validierung der DOI zu vermeiden.

Weiterführende Links und Ressourcen zum Thema Datenzitation

Sind die Grundlagen zur Versionierung, Lizenzierung und Zitierfähigkeit geklärt, rückt die Veröffentlichung einen Schritt näher. Ein Aspekt, der im Vorfeld jedoch häufig unterschätzt wird, ist die Kuratierung und Organisation der Daten. Diesem Thema widmet sich das folgende Kapitel.