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 frede...@remote.org ## N49°00'09" E008°23'33"
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
