Angabe von Doppellizenzen

[kulla]

Dies ist ein Follow-Up von #118 : Wenn ich ein Lehrmaterial wie https://www.youtube.com/watch?v=dxqc2sWgiz8 welches unter einer Doppellizenz (Standard Youtube-Lizenz / CC-BY-SA) steht, wie kann / soll ich es angeben? Aktuell ist es im Standard ja nur möglich, eine Lizenz zu wählen.

[acka47]

Wenn ich ein Lehrmaterial wie https://www.youtube.com/watch?v=dxqc2sWgiz8 welches unter einer Doppellizenz (Standard Youtube-Lizenz / CC-BY-SA) steht, wie kann / soll ich es angeben?

In diesem Fall sollte die Angabe der CC-BY-SA-Lizenz ausreichen, weil es ja die offenere ist, oder?

Wir haben uns in #87 bewusst gegen einen Array entschieden. Mit deinem hier und dem von @oellers in #87 gelieferten Beispiel zur Nutzung eines Arrays haben wir auch schon zwei verschiedene Nutzungsarten (duale Lizenzierung vs. komplexe Ressource mit unterschiedlichen Lizenzen für verschiedene Bestandteile), was wir auf jeden Fall vermeiden sollten. Das spricht evtl. für die Objekt-Lösung, verhindert aber natürlich die Doppellizenzierung.

[kulla]

In diesem Fall sollte die Angabe der CC-BY-SA-Lizenz ausreichen, weil es ja die offenere ist, oder?

Ja, in meinem Beispiel resultiert die Doppellizenz daraus, dass YouTube CC-BY-SA nicht als Lizenzangabe ermöglicht (Nur die Standard-Youtubelizenz und CC-BY ist möglich). Die Doppellizenz ist ein Workaround und als Konsument kann man sich dann die Lizenz auswählen, unter der man das Lernmaterial weiterverwendet. Insofern passt es, nur eine Lizenz anzugeben. In der aktuellen Version würde dann aber der Service über den die Metadaten abgefragt werden, diese Entscheidung treffen und nicht der Konsument.

Wobei auch über die Objektlösung eine Doppellizenz realisiert werden könnte. Beispiel:

{
  "license": {
    "id": "https://serlo.org/youtube-and-cc-by-sa",
    "name": "Standard Youtube-Lizenz und CC-BY-SA 4.0",
    "...": "..."
  }
}

Insofern passt es für mich, wenn wir bei einer Lizenz erst einmal bleiben, weil mein Beispiel der Doppellizenz eine große Ausnahme ist und es dafür auch einen Workaround gibt. Passt das?

[acka47]

Wobei auch über die Objektlösung eine Doppellizenz realisiert werden könnte. Beispiel:

{
 "license": {
   "id": "https://serlo.org/youtube-and-cc-by-sa",
   "name": "Standard Youtube-Lizenz und CC-BY-SA 4.0",
   "...": "..."
 }
}

Das ist aber nicht profil-konform, siehe https://dini-ag-kim.github.io/amb/draft/#license, wo es sheißt:

MUSS ein JSON-Objekt enthalten, das eine Property id mit einem URI als Wert enthält, der auf eine Creative Commons-Lizenz, GNU, Apache, MIT oder BSD verlinkt.

Im Schema sieht es entsprechend aus:

amb/draft/schemas/license.json

Lines 8 to 33 in 5ac8253

	"id": {
	"type": "string",
	"format": "uri",
	"oneOf": [
	{
	"description": "Creative Commons License or Public Domain",
	"pattern": "^http[s]?:\/\/creativecommons.org\/(licenses|licences|publicdomain)\/.*"
	},
	{
	"description": "GNU License",
	"pattern": "^http[s]?:\/\/www.gnu.org\/licenses\/.*"
	},
	{
	"description": "Apache License",
	"pattern": "^http[s]?:\/\/www.apache.org\/licenses\/.*"
	},
	{
	"description": "MIT License",
	"pattern": "http[s]?://opensource.org/licenses/MIT"
	},
	{
	"description": "BSD License",
	"pattern": "^http[s]?:\/\/www.opensource.org\/licenses\/BSD.*"
	}
	]
	}

Insofern passt es für mich, wenn wir bei einer Lizenz erst einmal bleiben, weil mein Beispiel der Doppellizenz eine große Ausnahme ist und es dafür auch einen Workaround gibt. Passt das?

Wenn das bei dir immer noch passt – auch mit der Einschränkung auf das license.id-Feld – kannst du das Ticket gerne schließen.

[kulla]

Okay, habe übersehen bzw mir war es nicht bewusst, dass dieser Standard explizit sich nur auf OER bezieht. In diesem Fall hat sich auch meine Frage geklärt. In meinem obigen Beispiel ist dann klar, dass die CC-Lizenz angegeben werden soll und dies ist ja auch im Sinne des Videoproduzenten (die Doppellizenz resultiert am Ende aus technischen Limitierungen bei YouTube CC-BY-SA auszuwählen).

Ich schließe dann mal dieses Issue. Sollte es doch Gründe für Doppellizenzen geben, kann gerne dieses Issue wieder geöffnet werden...

[acka47]

habe übersehen bzw mir war es nicht bewusst, dass dieser Standard explizit sich nur auf OER bezieht

Im Prinzip ist dem auch nicht so. Wir haben aus der Beschreibung den Bezug zu OER extra rausgenommen (siehe etwa 915fc9d). Das Profil lässt sich ja auch gut für die Beschreibung urheberrechtlich geschützter Lernressourcen verwenden, wobei mensch dann z.B. einfach die Lizenzangabe weglassen könnte.

[kulla]

Wir haben aus der Beschreibung den Bezug zu OER extra rausgenommen (siehe etwa 915fc9d).

Wenn die Spezifikation sich nicht nur auf OER beziehen soll, dann sollte IMHO der Satz "MUSS ein JSON-Objekt enthalten, das eine Property id mit einem URI als Wert enthält, der auf eine Creative Commons-Lizenz, GNU, Apache, MIT oder BSD verlinkt." geändert werden in "SOLL ein JSON-Objekt enthalten, das eine Property id mit einem URI als Wert enthält, der auf eine Creative Commons-Lizenz, GNU, Apache, MIT oder BSD verlinkt."

[acka47]

Darauf bezieht sich ja die Pflichtfeld-ja/nein-Angabe und license ist eben kein Pflichfeld. Wenn es aber benutzt wird, dann muss es ein Objekt mit id enthalten. Ich denke, dass ist so erstmal ok. Tatsächlich wird das Profil gerade hauptsächlich im Kontext von OER benutzt. Wir sollten das Profil auch weiterhin möglichst Use-Case- statt Hypothesen-getrieben entwickeln, d.h. wir können gerne schauen, ob und wie wir entsprechende Anforderungen erfüllen können, wenn jemand dazu kommt der das Profil ausschließlich für urhebrrechtlich geschützte Ressourcen einsetzen möchte.

[kulla]

Nachdem wir in #199 einen ähnlichen Fall haben, öffne ich dieses Issue wieder, weil ich es für die 1.0 besprechen möchte. Auch hier sehe ich die Gefahr eines breaking changes, wenn in Zukunft Mehrfachlizenzen erlaubt werden sollen. Oben ist ein Beispiel hierfür verlinkt – nicht, dass ich es direkt ändern will, aber ich würde es gerne besprechen.

Anmerkung: Wie in #199 (comment) beschrieben, wäre dies bereits ein breaking change für aktuelle Implementierungen.

[acka47]

Wurde im heutigen Treffen diskutiert mit Tendenz, unverändert bei einer Lizenzangabe zu bleiben, siehe https://pad.gwdg.de/s/2023-05-09-kim-oer#Unklar

[kulla]

@acka47 hat es bereits beschrieben: Wegen der zusätzlichen Komplexität und weil Konsumenten von Metadaten wie WLO oder Sodix Mundo aktuell in ihrem Datenmodell nur eine Lizenz pro Entität speichern, setzen wir es nicht um.