[Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3

[Frederik Ramm]

Hallo,

Karsten Merker wrote:
> Die ODBL enthält zwar eine Share-Alike-Klausel, d.h. jemand, der
> einen ODBL-lizensierten Datenbestand "öffentlich" verwendet, muss
> seine Änderungen wieder unter ODBL bereitstellen, er ist jedoch
> nicht verpflichtet, den CT zuzustimmen. In den OSM-Datenbestand
> dürfen mit ODBL+CT aber nur Änderungen aufgenommen werden, an
> denen derjenige, der sie einträgt, _alle_ Rechte hält

Das stimmt so nicht mehr; das war eine Formulierung in alten Entwuerfen, 
aber in der aktuellen Version der Contributor Terms ist das nicht mehr 
der Fall. Wenn Du Daten beitraegst, musst Du nun nur noch versichern, 
dass sie mit der jeweils gerade benutzten Lizenz kompatibel sind, und 
bei einem eventuellen spaeteren Lizenzwechsel muss sich die OSMF damit 
herumschlagen, dass einzelne Daten vielleicht nicht mehr kompatibel sein 
koennten. Das ist eine Aufweichung, die ich persoenlich schade finde, 
weil sie eben einen spaeteren Lizenzwechsel schwieriger macht, wenn das 
viele Leute tun, aber gerade fuer Faelle wie den von Dir geschilderten 
ist das gedacht.

(Contributor Terms Abschnitt 1a: "Indem Sie Inhalte beitragen, 
bestätigen Sie, dass - soweit Sie wissen - Sie das Recht haben, der OSMF 
die Nutzung und Verteilung der Inhalte unter den momentanen 
Lizenzbedingungen zu erlauben...")

> ODBL+CT bieten in dieser Hinsicht also absolut keinen Vorteil
> gegenüber einer Lizensierung unter PD/CC0, sie bringen aber
> aufgrund der komplizierten und in vielen Fällen unklaren Lizenz
> ganz massive Nachteile mit sich. Es ist als normaler Endanwender
> meiner Meinung nach fast unmöglich, festzustellen, was man mit
> den ODBL-lizensierten Daten nun wirklich darf bzw. welche
> Auflagen man in welcher Konstellation beachten muss. Selbst die
> Leute innerhalb des Projektes sind sich ja noch nicht einmal
> einig, wie Teile der ODBL zu verstehen sind, wie soll das dann ein
> normaler Nutzer können?

Da kann ich nur wieder sagen: 1. Das ist bei der CC-BY-SA genauso (dass 
sich Leute uneinig sind und dass keiner weiss, was eigentlich geht), und 
2. bei der ODbL haben wir, weil die OSMF Lizenzgeber ist, wenigstens 
eine Deutungskompetenz, d.h. wenn irgendwas unklar ist, dann sagen wir 
einfach, wie wir es meinen, und so gilt es dann.

> Dazu kommt, dass sich einige der sich
> aus der ODBL ergebenden Auflagen bei der Nutzung der Daten in der
> Praxis teilweise nur schwer oder gar nicht erfüllen lassen

Es waere interessant, zu hoeren, welche Auflagen in der Praxis schwer 
oder gar nicht erfuellbar sind. Mir sind keine bekannt; entweder 
unterliegst Du auch hier einem Missverstaendnis, oder man sollte die 
OSMF schleunigst ueber diesen Fehler aufklaeren, denn eine Lizenz mit 
unerfuellbaren Auflagen waere ja ein ziemlicher Schuss in den Ofen. 
(Evtl. magst Du selbst auf legal-talk schreiben, oder Du erklaerst hier, 
was Du meinst, und ich formuliere das dann dort.)

> Fast alle der komplizierten und unklaren Regelungen der ODBL
> ergeben sich aus dem Share-Alike-Erfordernis, also warum
> verzichten wir nicht einfach darauf - die Share-Alike-Klausel der
> ODBL bringt uns als Projekt wie oben beschrieben ohnehin
> überhaupt nichts, wir bekommen geänderte Daten trotz der
> Share-Alike-Klausel nicht zurück in den OSM-Datenbestand, also
> sparen wir uns und den Nutzern doch den ganzen Ärger und
> lizensieren den Datenbestand gleich unter PD/CC0.

Wenn die OSMF das ernsthaft vorschluege, wuerden wesentlich mehr Leute 
dem Projekt den Ruecken kehren als ohnehin schon. Besser finden taet' 
ich es auch.

> Damit fiele
> auch die Notwendigkeit für die ebenfalls problematischen CT (zu
> denen man auch nochmal seitenweise Bedenken auflisten kann) weg,
> denn eine Rechteübertragung an die OSMF ist bei PD/CC0 gar nicht
> erforderlich.

Bedenken auflisten kann ich zu allem. Die meisten Juristen, die sich im 
Rahmen des Lizenzwechsels mit unserer Situation befasst haben, meinten, 
dass wir sowieso schon immer "implizite" CT hatten, und dass es 
eigentlich fuer die Rechtssicherheit auf allen Seiten besser gewesen 
waere, wir haetten die schon lang vorher explizit gemacht, voellig 
unabhaengig von der Lizenz (und sei es nur, dass der Nutzer versichert, 
nach seiner Kenntnis nicht gegen Rechte Dritter zu verstossen usw.usw.)

> Hier noch eine (mehr oder weniger ;-)) kurze Zusammenstellung der
> meiner Ansicht nach wichtigsten inhaltlichen Kritikpunkte an der
> ODBL (es gibt noch ein paar mehr, aber die Liste wird auch so schon
> zu lang) - vielleicht regt das doch den einen oder anderen dazu an,
> sich Gedanken darüber zu machen, ob die ODBL wirklich die passende
> Lizenz für OSM ist.
> 
> - Die Trennlinie zwischen "produced work" (darf beliebig
>   lizensiert werden) und einer "derivative database" (muss unter
>   ODBL lizensiert werden) ist vollkommen unklar.  Strittig ist
>   beispielsweise, ob eine SVG-Grafik oder ein Vektor-PDF mit der
>   Darstellung einer Karte ein "produced work" oder eine
>   "derivative database" ist, für die gänzlich unterschiedliche
>   Bestimmungen gelten.

Ich weiss nicht, wo Du her hast, dass das "strittig" ist. Meiner Ansicht 
nach wurde darueber zuletzt vor ca. 2 Jahren "gestritten". Die aktuelle 
Haltung der OSMF dazu steht hier:

http://wiki.openstreetmap.org/wiki/Open_Data_License/Produced_Work_-_Guideline

Ich wiederhole mich: Im Gegensatz zur CC-BY-SA, wo der Lizenzgeber der 
Mapper ist und wo man daher nach Belieben und ohne jede rechtliche 
Verbindlichkeit herumdeuteln kann, was der Mapper wohl gemeint haben 
koennte, ist es im aktuellen Szenario so, dass die OSMF der Lizenzgeber 
ist, d.h. wenn die OSMF sich einigt, dass eine bestimmte Definition fuer 
ein "Produced Work" gilt, dann ist das auch verbindlich, und jeder kann 
sich drauf verlassen.

Im konkreten Fall gilt: Eine SVG-Grafik oder ein Vektor-PDF ist ganz 
klar ein "Produced Work". Ausser, wenn Du absichtlich (was ja technisch 
moeglich ist) ein gigantisches SVG aus dem ganzen Planetfile machen 
wuerdest mit dem einzigen Zweck, es dann wieder in eine Datenbank 
einzulesen - wenn Du uns also "austricksen" willst. Dann war es eine 
Datenbank. Das ist ein eleganter Ersatz fuer die "reverse 
engineering"-Klausel, die sich in einer frueheren Version der ODbL fand 
und die nun weggefallen ist.

Im folgenden fuehrst Du das Beispiel weiter aus unterliegst dabei einem 
weiteren Missverstaendnis:

>   Stellt die Vektordarstellung der Karte
>   im PDF eine "derivative database" dar (eine Meinung, die in der
>   Lizenzdiskussion mehrfach vertreten wurde und die sich auch im
>   Wiki findet), müsste der Anwender, um der Lizenz zu genügen, nun
>   auch die OSM-Datenbankdatei, aus der er die Karte erzeugt hat und
>   die im Zweifelsfall hunderte von Megabyte groß sein kann,
>   bereitstellen.  Letzteres entweder, in dem er die zugrundelegende
>   Datenbank allen Empfängern zusammen mit der "derivative
>   database" - d.h. dem PDF - schickt (was wohl kaum
>   realistisch ist), oder er muss sie auf unbegrenzte Zeit
>   bereithalten, um sie auf Anforderung bereitzustellen. 

Das ist falsch, und ich schreibe jetzt extra langsam und deutlich, in 
der Hoffnung, dass es klar wird.

1. Die Vektordarstellung der Karte ist keine "derivative database", s.o.
2. Nehmen wir trotzdem mal an, sie waere eine; also nehmen wir an, Du 
wuerdest eine "derivative database" verteilen.
3. Dann ist es voellig ausreichend, genau wie jetzt auch, dass Du jedem, 
der diese Datenbank erhaelt, sagst: "Das hier ist aus OSM und steht 
unter ODbL". Fertig. Sonst nichts. Du hast damit alle Deine Pflichten 
erfuellt. Das steht so in Paragraph 4.6 der ODbL.
4. Du musst insbesondere nicht irgendwelche Quellen, aus denen Du Deine 
abgeleitete Datenbank hergestellt hast, herausgeben, oder bereithalten, 
oder sonst irgendwas.

Anders sieht es aus, wenn Du tatsaechlich ein "produced work" (und das 
ist Dein PDF) verteilst. Dann musst Du naemlich tatsaechlich Zugriff auf 
die Datenbank dahinter gewaehren. Dieser Zugriff kann aber auch in der 
Bereitstellung eines "diffs" bestehen (also mal angenommen, Du nimmst 
eine aktuelle OSM-Datenbank und mischst 100 POIs hinein, dann reicht es, 
die 100 POIs bereitzustellen), oder in Form einer algorithmischen 
Beschreibung ("ich habe die OSM-Datenbank genommen und alle Gebaeude 
geloescht" oder sowas).

Zum Thema "Aufbewahrungsfrist" gab es ein paar Diskussionen; klar ist, 
dass man von jemandem, der einen regelmaessig aktualiserten Server 
betreibt, nicht erwarten kann, dass er zwei Jahre spaeter noch den 
Datenstand von damals hervorzaubern kann. Das ist allerdings, und in dem 
Punkt muss ich Dir recht geben, noch nicht richtig formalisiert.

>   Damit sind wir auch schon direkt beim nächsten Problempunkt. Die ODBL
>   definiert im Gegensatz zu beispielsweise der GPL keine zeitliche
>   Begrenzung der Vorhaltungspflicht, d.h. wenn der Betroffene dem
>   Empfänger die zugrundeliegende Datenbank nicht gleich mitschickt
>   (was im vorliegenden Fall wegen bestehender Größenbeschränkungen
>   ggf. technisch gar nicht möglich wäre), ist er nach der ODBL
>   verpflichtet, sie unbegrenzt lange vorzuhalten, weil ja
>   irgendwann jemand kommen könnte, der die Einladung erhalten hat
>   (oder sie in irgendeinem alten Mailinglistenarchiv gefunden hat)
>   und seine Rechte aus der ODBL geltend machen möchte. Kann der
>   Absender der Einladung dann das im Zweifelsfall vor Jahren
>   einmalig für die Erzeugung der Einladung verwendete Datenbankfile
>   nicht zur Verfügung stellen, hat er gegen die Lizenz verstoßen.

Ich finde es gut, dass Du Dir ueber diese Sachen Gedanken machst. Schade 
finde ich, dass Du Dich trotzig hinsetzt und sagst "Nein zu dieser 
Lizenz wegen <Liste von Dingen, die Du nie im Projekt diskutiert hast>"; 
  waere es denn so schwer, diese Sachen auf legal-talk oder in einer 
Mail an die Licese Working Group zur Sprache zu bringen, damit man sie 
fixen kann? Es kann ja wohl in niemandes Interesse sein, dass ploetzlich 
jeder jahrhundertealte Daten vorhalten muss. Meistens, wenn man solche 
Bedenken vorbringt, passiert eine von zwei Sachen - entweder wird ein 
Jurist befragt, der dann sagt "ja, das hoert sich fuer den Laien so an, 
aber ein Gericht wuerde das nicht so sehen, weil <...>", oder es heisst 
"ups, ja, das muessen wir klarstellen", und dann schreibt man eine 
"Community Norm" dazu auf. (Im worst case sagt ein Jurist: "Das ist so 
kaputt, das kann man nicht mit einer Community Norm fixen", und dann 
gehen wir zu den ODC-Leuten hin und sagen denen, sie muessen eine 
Version 1.1 von ihrer Lizenz machen.)

Jochen hat sich auch ein bisschen so in die Richtung ausgedrueckt: Ich 
setz mich hier hin und ich warte, bis die mir eine perfekt ausgedachte 
Lizenz liefern, ansonsten schicke ich sie weg und sage, sie sollen 
spaeter wiederkommen. Denn: "SIE wollen ja was von MIR, da sollen SIE 
auch ihre Hausaufgaben machen!" - das ist zwar menschlich verstaendlich, 
aber SIE sind auch keine Uebermenschen und versuchen den Spagat zwischen 
Juristen und Projekt. Koennte man IHNEN nicht bei der Arbeit helfen, 
statt sich im stillen Kaemmerlein zu denken: "Offenbar wollten die das 
genau so wie es da steht, aber ich finde das doof"?

> - Das nächste Problem betrifft ebenfalls die Definition einer
>   "derivative database". Nach dem Text der ODBL stellt nämlich
>   bereits die Auswahl von Datensätzen aus einer ODBL-lizensierten
>   Datenbank die Herstellung einer "derivative database" dar, selbst
>   wenn dabei kein einziger Datensatz verändert wird ("This
>   includes, but is not limited to, Extracting or Re-utilising the
>   whole or a Substantial part of the Contents in a new Database"). 
>   Dies bedeutet, dass jemand, der JOSM startet, sich eine Region
>   aus der Datenbank herunterlädt - und zwar auch dann, wenn er
>   keine inhaltlichen Änderungen daran vornimmt - bereits eine
>   "derivative database" erzeugt hat.  Erzeugt er nun daraus mit
>   einem Renderer ein Pixelbild, so stellt dieses Pixelbild selbst
>   zwar keine "derivative database" dar, aber ein "produced work
>   created from the derivative database" und damit muss er nach
>   Punkt 4.6 der ODBL genau wie im obigen Fall auch hier zusätzlich
>   zur erzeugten Karte, obwohl sie inhaltlich keinerlei Änderungen
>   gegenüber dem in der OSM-Datenbank befindlichen Datenstand
>   enthält, auch die Datenbankdatei entweder mitschicken oder
>   lebenslang zum Abruf vorhalten. 

Auch hier erlaube mir wieder, Unverstaendnis zu aeussern - Du liest die 
Lizenz, missverstehst sie, entscheidest Dich daher fuer ein "Nein" *und* 
legst Dein Missverstaendnis noch der Welt als Faktum vor, ohne jemals 
mit irgendwem darueber diskutiert zu haben.

Wenn Du zu so einem Schluss kommst, muss doch der erste Reflex sein: 
"Kann das echt sein, dass das so gewollt ist?", und dann muss man 
nachfragen!

Im konkreten Fall: Zunaechst einmal muesstest Du das Pixelbild ja 
verteilen, damit die Lizenz ueberhaupt zum Tragen kommt. Die meisten 
Leute verteilen aber keine aus JOSM hergestellten Pixelbilder. 
Angenommen mal, Du tust es doch, dann koenntest Du Dir der Share 
Alike-Anforderung genuegen, indem Du (4.6b) dokumentierst, in welcher 
Form Du diese abgeleitete Datenbank hergestellt hast. Also mal ganz 
praktisch:

1. Du stellst mit JOSM ein Bild her, indem Du einen bestimmten 
Ausschnitt herunterlaedst und dann einen Screenshot machst. Die 
abgeleitete Datenbank, die diesem Bild zugrundeliegt, ist ein 
heruntergeladener Ausschnitt.

2. Du verteilst dieses Bild, ganz normal, so wie heute auch, und machst 
Dir keine weiteren Gedanken.

3. In dem unwahrscheinlichen Fall, dass irgendwann nach 10 Jahren jemand 
kommt und sagt "aeh, wo ist denn hierzu die abgeleitete Datenbank", 
schaust Du Dir das Bild an, erkennst, welche Gegend das ist, ermittelst 
die Koordinaten dazu und sagst: "Die abgeleitete Datenbank hierzu ist 
ein Ausschnitt mit den Koordinten .... aus OSM". Fertig. Falls Du das 
Bild in einer Publikation benutzt, kannst Du das auch gleich 
drunterschreiben, dann sparst Du Dir sogar das.

>   Wie sich das mit der von den
>   ODBL-Befürwortern propagierten Aussage (sinngemäß) "wenn jemand
>   bloss eine Kartengrafik aus OSM-Daten erzeugt, muss er bei der
>   ODBL nur dazuschreiben, dass es sich um OSM-Daten handelt und
>   sich ansonsten um das ganze Lizenzgeraffel keine Gedanken machen"
>   vertragen soll, erschließt sich mir nicht.

Haettest ja mal frueher eine dieser ominoesen ODbL-Befuerworter fragen 
koennen ;) bei allem, was direkt aus der OSM-Datenbank erstellt ist, ist 
das "diff", das man angeben muss, ja leer (also die in 4.6b erwaehnte 
Beschreibung aller Aenderungen, die Du an der Datenbank vorgenommen 
hast). Oder maximal sagst Du: "Ich hab OSM mit osm2pgsql in eine 
Postgres eingelesen" oder so.

>   Um das Ganze auf die Spitze zu treiben: erstellt die OSMF exakt
>   den gleichen Ausschnitt mit exakt den gleichen Daten wie der
>   Anwender im vorigen Beispiel und stellt ihn genauso wie die
>   Gesamtdatenbank unter ODBL zur Verfügung, der Anwender lädt
>   diesen vorgefertigten Ausschnitt herunter und rendert nun exakt
>   die gleichen Daten in ein Pixelbild, handelt es sich auf einmal
>   nicht mehr um ein "produced work created from the derivative
>   database", sondern nur noch um ein "produced work" und er muss
>   die - inhaltlich exakt gleiche - Datenbankdatei nun nicht
>   mitschicken oder sein Leben lang vorhalten.  Das soll ein
>   normaler Endnutzer verstehen?

Ne, also ehrlich gesagt hab ich den Eindruck, dass wir in dem, was Du 
hier geschrieben hast, den Beweis dafuer haben, dass die ODbL offenbar 
tatsaechlich schwer verstaendlich ist.

Was mich nach wie vor wundert, ist Deine Bereitschaft, ganz 
selbstverstaendlich davon auszugehen, dass die Macher der ODbL eine 
voellig unpraktikable Lizenz auf die Beine gestellt haben ;)

> - Problematisch wird es auch, wenn jemand eine Slippymap betreiben
>   möchte, die mit Aktualisierungen arbeitet.  Es wird also einmal
>   ein Planet heruntergeladen, damit hat man zunächst die
>   "database".  Die aus diesem Planet erstmalig vollständig
>   erzeugten Tiles sind dann normale "produced works" und noch
>   weitgehend unproblematisch.  In dem Moment, wo eine
>   Aktualisierung über ein Diff aus den aktuellen OSM-Daten erfolgt,
>   wird aus der "database" eine "derivative database" und aus den
>   Tiles ein "produced work from a derivative database".  Damit ist
>   der Betreiber der Slippymap nach der ODBL verpflichtet, jedem,
>   der irgendwann mal ein Tile von diesem Tileserver abgerufen hat,
>   den zum Zeitpunkt der Tile-Erzeugung aktuellen Stand der
>   "derivative database" zum Download zur Verfügung zu stellen, und
>   zwar lebenslang

Total unpraktikabel, laengst abgehakt, haette Dir jeder auf legal-talk 
sofort erklaeren koennen. Steht auch im Wiki in gruen auf 
http://wiki.openstreetmap.org/wiki/Open_Data_License/Closed_Issues, 
gleich der erste Kasten. Wenn in der Lizenz von einer "Datenbank" die 
Rede ist, dann ist das nicht unbedingt eine ganz konkrete Instanz mit 
allen Daten zum Zeitpunkt X. Es reicht, wenn Du sagst: "Das war eine zu 
dem Zeitpunkt aktuelle Version der OpenStreetMap-Datenbank". Du musst 
die nicht vorhalten und auch nicht auf Anfrage eine historische Version 
synthetisieren. Wie sollte das denn gehen? Da waere die Lizenz doch das 
Papier nicht wert, auf dem sie geschrieben ist.

> - Die Lizenz enthält keine Definition von "substantial extract".
>   Damit ist vollkommen unklar, welche oder wieviele Bestandteile
>   eines OSM-Datensatzes ohne Lizenzbeschränkung verwendet werden
>   können und ab wann die Beschränkungen der ODBL greifen.  Die als
>   Lösung angeführten "Community Guidelines" helfen hierbei leider
>   überhaupt nicht, denn sie sind a) nicht Bestandteil der Lizenz
>   (und nur die gilt im Verhältnis zum Nutzer) 

Das "substantial" steht genau so in der EU-Datenbankdirektive; auch dort 
ist es nicht genau definiert. Es ist eine Auslegungssache fuer die 
Gerichte. Nach einvernehmlicher Auffassung der Juristen, die die OSMF in 
dieser Sache beraten haben, wird ein Gericht in der Regel davon 
ausgehen, dass die vom Herausgeber publizierten Richtlinien Anwendung 
finden, und genau das sind die "Community Guidelines".

 >   und b) für weitere
>   Bearbeiter, die abgeleitete Datenbanken unter der ODBL
>   bereitstellen, nicht bindend - der Bearbeiter kann ganz andere
>   Vorstellungen von "substantial" haben als das, was in den
>   OSM-Community-Guidelines steht.  Ein Nutzer hat also keine
>   Möglichkeit, festzustellen, was er nun darf und was nicht, denn
>   er muss ja die Lizenzbedingungen gegenüber allen Lizenzgebern
>   erfüllen und nicht nur gegenüber der OSMF.

Nein, auch da unterliegst Du einem Missverstaendnis, denn jemand, der 
eine derived database herausgibt, ist selbst nicht der Lizenzgeber (4.8 
"you may not sublicense the database") und hat deswegen nicht die 
Deutungshoheit, die die OSMF hat.

>   Der Wortlaut von Punkt 4.3 der ODBL spricht davon, dass die
>   zugrundeliegende "database" unter der angegebenen URL verfügbar
>   ist ("is available").  Reicht es nun aus, dass die "database" zum
>   Zeitpunkt der Linksetzung verfügbar _war_ oder ist der Anbieter
>   des "produced work", in diesem Fall also der Tiles, verpflichtet,
>   für die gesamte Zeit, in der er das "produced work" anbietet,
>   sicherzustellen, dass die "database" garantiert verfügbar _ist_.

Darauf hab ich zwar jetzt keine Antwort sofort parat, das muesste man 
mal auf legal-talk zur Sprache bringen. Wir hatten diese Diskussion mal, 
und zwar war da die Frage: Wenn irgendwo in Afrika jemand mit geringer 
Bandbreite Tiles produziert, kann man von dem ja kaum erwarten, dass 
jeder von ihm einen Planet runterladen kann. Ich bin mir aber gerade 
nicht sicher, was da die Loesung war.

Also, zusammenfassend: Das meiste, was Du kritikwuerdig findest, sind 
einfach nur Missverstaendnisse, die Du besser durch Nachfragen 
aufgeklaert haettest, anstatt Dich hier aufs Pult zu schwingen und Deine 
Irrtuemer als Fakten hinzustellen. Offenbar ist die Lizenz tatsaechlich 
so kompliziert, dass es relativ leicht ist, sie gruendlich falsch zu 
verstehen - wobei ich glaube, dass ein kleiner "reality check" ab und zu 
geholfen haette. Zu den Schluessen, die Du gezogen hast, kann man ja 
eigentlich nur kommen, indem man jedem, der diese Lizenz erarbeitet hat 
oder gut findet, jede Intelligenz abspricht. Da gehoert schon ein sehr 
gesundes Selbstvertrauen dazu ;)

Dein Input waere auf legal-talk willkommen. Die License Working Group 
sucht auch noch nach 1-2 Leuten, die Lust haben, mitzuarbeiten - 
vielleicht kannst Du ja mithelfen, dafuer zu sorgen, dass die Sache fuer 
alle klarer wird?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"