Es wurde doch ja aber gerade als Vorteil der neuen Lizenz dargestellt, Daten unterschiedlicher Lizenz kombinieren und auch als gedrucktes Werk - nicht nur intern -veröffentlichen zu können? Oder habe ich da was überlesen?
Gruß
Dieter
Hallo juson
Bisher habe ich Garminkarten immer als ein “produced work” gesehen, welches ich nach neuer Lizenz “frei” lizensieren kann. Auf talk-de schreibt Frederik immer häufiger, dass es eine Datenbank ist und somit unter ODbL zu stehen hat. Wenn dem so sein sollte, bringt die neue Lizenz hier überhaupt keine Besserung. Man kann seine Karten auch weiterhin nicht vor komerzieller Verwendung schützen.
Selbst wenn die Garminkarte ein “produced work” ist, das man frei lizensieren kann, hat der Composer unter der neuen Lizenz einen Nachteil, wenn man Karten veröffentlichen will. Man muss die temporären Composerdaten veröffentlichen. Also die *_garmin.osm. Grund ist, dass dort neben den OSM-Daten deine eigenen Küstenlinien und die Höhendaten in eine kombinierte Datenbank geschrieben werden.
Wenn man die Karten “manuell” (per eigenem Skript) macht, kann man die Höhendaten in seperate Kacheln laden und sich somit deren Veröffentlichung unter CC-BY-SA bzw. ODbL ersparen. Evtl. wird der Comopser sich hier noch anpassen.
Ich denke es ist so:
Selbsterstellte, auf OSM basierende Garmin- oder Papierkarten sind “produced work”, welche unter der ODbL-Lizenz frei lizensierbar sind und bleiben und jeder darf sie für sich privat nutzen.
Ob sie aber veröffentlicht werden dürfen, hängt davon ab, wie es sich mit dem zweiten Teil der OBdL, dem “unter die OBdL-Lizenz-Stellen der (zwischenzeitlich) erzielten Datenbank” verhält.
Beispiele:
-
Es werden nur OSM-Daten (Datenbank) genutzt und davon z. B. ein Screenshot gemacht, dieser wird dann mittels “Paint” um einen Anfahrtsweg zur Kneipe ergänzt (eingemalt).
Dann hat man keine neue Datenbank erstellt und kann den Ausdruck der Karte “frei lizenzieren” und veröffentlichen. -
Es werden nur OSM-Daten genutzt und um bestimmte Nodes erweitert (z. B. um die Filialen einer Supermarktkette. Dann dürfen die anschließend ausgedruckten Karten als “produced work” wieder frei lizenziert und die Karte veröffentlicht werden. Es muß aber die, inzwischen erweiterte, Datenbank, inclusive der eingezeichneten Filialnodes, unter die OBdL gestellt werden.
-
Es werden OSM-Daten (Datenbank) plus Fremddaten(-bank) genutzt oder “gemerged” dann kann das Ergebnis, die Karten, wieder “frei” lizensiert werden. Allerdings muß die Lizenz der Fremddaten(bank) berücksichtigt werden. M. a. W. es können die erstellten Karten als “produced work” z.B. unter “non commercial” gestelt werden, wenn die Fremddatenbank dies unter ihrer Lizenz zuläßt.
Bei der Veröffentlichung (Verkauf) kommt es zusätzlich wieder auf die zweiten Bedingung (Datenbank unter die ODbL stellen) an, also, ob die Karten aufgrund einer neuen (gemergten) Datenbank erstellt wurden.
aa.
Ist das der Fall, wurde die Karte also erst zusammen mit den Daten der neuen Datenbank (Zwischenergebnis) möglich, müßte diese neue Gesamt-Datenbank wieder unter die OBdL gestellt werden. Dies dürfte aber nicht möglich sein, da ein Teil der Daten ev. unter der “non commercial” Lizenz steht. Die Folge wäre, m. E., daß damit auch eine Veröffentlichung der Karte nicht erlaubt sein dürfte.
bb.
Bedient man sich eines “Tricks” und argumentiert, die beiden Datenbanken werden nicht gemergt und erst danach eine Karte erstellt, sondern das Ergebnis (die Karten) werden quasi ohne neue Datenbank “on the fly”, z. B. per Script, erstellt, könnte die “freie” Veröffentlichung möglich sein, weil dann die Bedingung “neue Datenbank unter die ODbL stellen” nicht erfüllt werden kann, oder muß.
Wiederum aus meiner Sicht:
Das dürfte aber dem Sinn und Zweck der OBdL widersprechen, weil vermutlich jeder mit diesem Argument die Herausgabe “seiner gewonnenen Datenbank” verhindern wird. Dann kann man OSM eigentlich auch gleich unter eine freie Lizenz stellen, was einem “Verschenken” der Daten gleichkäme. Worin soll dann aber noch der Schutz der OBdL bestehen? Ich gehe mal davon aus, daß die Initiatoren dies auch nicht woll(t)en.
zu 1: Das hängt davon ab, unter welcher Lizenz man den Screenshot stellt/stellen muss (wegen den verwedeten Programmen). Das regelt dann das normale Urheberrecht und hat mit OSM nichts mehr zutun. Der “OSM-Zugriff” endet mit dem Screenshot.
2+3 ist ja der gleiche Fall. Werden zusätzliche Daten mit OSM-Daten verbunden, dann müssen diese unter ODbL veröffentlicht werden.
2+3 kann man umgehen, indem man keine gemeinsame Datenbank erstellt und die Daten getrennt speichert. Bspw. über Layer.
Nochmal zum Composer:
a)
Der Composer bereitet die OSM-Daten auf, erstellt Höhendaten als OSM-Objekte und macht daraus pro Kachel eine gemeinsame Datenbank. Daraus werden dann die Garminkacheln erstellt. → Die gemischte Datenbank muss unter ODbL veröffentlicht werden.
b)
Wenn man sich die Kachen per eingenem Skript erstellt, dann spart man sich das aufwändige mergen der Datenbanken und erstellt transparente Kacheln, die nur die Höhenlinien enthalten. Man hat also zwei getrennte Datenbanken und muss nichts extra veröffentlichen (OSM-Daten sind ja bereits unter ODbL veröffentlicht).
Beides hat Vor- und Nachteile, die jeder für sich abwägen muss. Bei a) braucht man entsprechende Serverkapazitäten, hat dafür weniger Kacheln (Garmingrenze bei ~4000), bei b) spart man Serverkapazitäten, hat dafür mehr Kacheln und ist bei den Höhendaten freier.
Das mit dem Trennen der Datenbanken ist aber nur bei völlig unabhängigen Daten möglich. Wenn man nun bspw. Fußwege aus OSM mit Straßen von Teleatlas nutzen will, geht das nur über eine gemeinsame Datenbank, weil man für ein Routing logischerweise Verknüpfungspunkte braucht.
wobei noch die Frage wäre, ob die nur temporär genutzte Datei, die sich ja problemlos automatisiert nach Beendigung des Renderns löschen lassen würde, wirklich eine Datenbank darstellt. Da wäre erstmal nur eine temporäre Datei, die wie der Name sagt, Daten beinhaltet. Ob die nun eine ‘Datenbank’ darstellt, weiß ich nicht, hört sich zumindest für mich als Laie nicht unbedingt so an. Dann muss man auch irgendwo trennen. Nicht jede Datei, die zusammengeführte Daten enthält, ist eine Datenbank. Sonst könnte man selbst bei getrennten Datenbanken argumentieren, dass in der eventuell vorhandenen Auslagerungsdatei beide Datenquellen zusammen gespeichert werden und diese dann unter ODbL steht.
Dass Frederik jetzt mitten in der Lizenzumstellung seine Meinung ändert, finde ich nicht gerade zielführend und ärgert mich etwas.
was mir da noch einfällt. Gedruckte Karten stellen auch eine Datenbank dar. Zitat Landgericht München:
- Jedes Kartenblatt der topografischen Karten des Kl. stellt für sich genommen eine Datenbank i.S. von § 87a I 1 UrhG dar.
a) Es handelt sich bei jeder TK 25 um die Sammlung einer Vielzahl von Einzeldaten zur Beschaffenheit der Erdoberfläche im jeweiligen Kartengebiet. Dargestellt sind etwa Lage und Ausdehnung von Siedlungsflächen, von Verkehrsflächen, von Gewässern, Vegetationszonen, politischen Grenzen, naturschutzrechtlich bedeutsamen Zonen, das Bodenprofil und Höhenangaben zu einzelnen Bodenpunkten, Gemeinde-, Flur-, Berg- und Gewässernamen und eine Fülle von Hinweisen zu Einzelobjekten wie Kirchendenkmälern, Bergwerken, Schornsteinen, Wegkreuzen, Einzelbäumen etc. Dass auch Datensammlungen in analoger, insbesondere gedruckter Form Datenbankschutz genießen können (vgl. schon Erwägungsgrund 14 der „Datenbankrichtlinie", Richtlinie 96/9/EG vom 11. 3. 1996) wird spätestens seit BGHZ 141, 329 = GRUR 1999, 923 - Tele-Info-CD nicht mehr bestritten und wurde nunmehr durch den EuGH in seiner Entscheidung vom 9. 11. 2004 (GRUR 2005, 254 - Fixtures-Fußballspielpläne II) ausdrücklich bestätigt.
http://de.wikisource.org/wiki/Landgericht_M%C3%BCnchen_I_-_Datenbankschutz_f%C3%BCr_topografische_Landkarten
Damit müssten selbst bei getrennten Datenbanken, gedruckte Karten, die mit OSM Daten erzeugt wurden, unter ODbL stehen. Wenn das auch für gedruckte Karten gilt, sollten doch Garmin Karten auch drunter fallen.
Genau da wollte ich drauf hinaus. Wenn die Garminkarte eine Datenbank darstellen sollte, dann ist dies auch für alle anderen Karten (digital als jpg oder analog auf Papier) der Fall.
Wenn wir schon die Lizenz umstellen, dann sollte das auch genau geregelt werden, was ein produced work ist, dass man frei Lizensieren kann und was eine Datenbank ist, die unter ODbL stehen muss.
damit hier keine Mißverständnisse aufkommen, ich selbst nutze Deine Radkarte auf meinem Garmin und möchte das auch gern weiterhin können. Mir persönlich ist es wichtiger, daß jemand etwas in dieser Form beisteuert, als wenn irgendeine “Pommesbude” ihre Datenbank unter die OBdL stellt.
Also nochmal ein herzliches Dankeschön für Deine Mühen.
Ich will hier auch gar nicht in Anspruch nehmen, daß meine Meinung die einzig wahre ist. Sowohl Deine als auch SunCobalts Ansichten kann ich durchaus nachvollziehen.
Worauf ich hinaus will, man kann wohl letzlich nur Daten miteinander verbinden und veröffentlichen, die entweder unter derselben Lizenz stehen, oder wenn die unter einer wirklich “freien” Lizenz stehenden Daten unter die Lizenz der “einschränkenden” Daten gestellt werden (können).
Anderenfalls hat man genau unsere Diskussion. ==> Wird überhaupt eine Datenbank erstellt, oder ist eine Datei schon eine Datenbank?
Vielleicht sollte das zunächst mal geklärt werden.
Oh, ich sehe gerade:
Was bedeuteten müßte, daß eine Kombination aus OBdL-Daten und vorher anders lizensierten Daten nicht möglich ist, weil z. B. der nächste die Kombination vermarkten könnte, obwohl ein Teil der Daten vorher unter “non-commercial” standen?
Gute Frage, ich hoffe sehr mich zu irren. Wenn selbst Fredrik Ramm keine verläßliche Aussage trifft, wird das wohl keiner mit Sicherheit sagen können.
Wenn das stimmt, hätten die cc-by-sa Befürworter Grund zu Freude. Denn dann gäbe es kein “produced work” sondern nur gemeinsame Datenbanken und damit müssten die “by” und “sa” Bedingungen erfüllt werden, was ja dann genauso wirkt wie eine cc-by-sa
Hallo,
Es gibt verschiedene Definitionen dafuer, was eine Datenbank ist. Die EU-Datenbankdirektive sagt (salopp umschrieben), dass jede Art von sortierter und einzeln zugreifbarer Datensammlung eine Datenbank ist. Darunter faellt so ziemlich jede Datei, die man im Rechner hat (jedes Word-File, jedes PNG) und vielleicht sogar (wurde hier an anderer Stelle gesagt) auch eine gedruckte Karte. Das ist fuer unsere Anwendung natuerlich Quark - wenn alles eine Datenbank ist, braucht man die ganze “produced work”-Regel nicht. Daher schlaegt die OSMF die folgende Definition vor:
http://wiki.openstreetmap.org/wiki/Open_Data_License/Produced_Work_-_Guideline
Also in etwa: “Alles, was gemacht wurde, um die Originaldaten herauszulesen, ist eine Datenbank, alles andere ein Produced Work”. Diese Definition kann aber bei Bedarf noch ueberarbeitet werden.
Dass sowas wie Kartenkacheln - und darauf bezog ich mich mit meinem Beispiel von Nops Karte und den derzeit drei verschiedenen Layern - keine Datenbank sein soll, ist jedem klar, da gab es nie eine Diskussion. Daraus folgt auch, dass Nop seine Karte nach der Lizenzumstellung z.B. als CC-BY-SA-NC publizieren darf.
Mit den Garmin-Karten liegt die Sache aber anders, das sind ja Vektordaten, aus denen man sogar zu einem gewissen Grad die kompletten Ursprungsdaten wieder herauslesen kann (wir hatten schon illegale Importe aus Garminkarten). Eine Garmin-Karte ist meiner Ansicht nach daher eine Datenbank und muss unter der ODbL stehen. Insofern habe ich zu unrecht Felix - der ja, wie ich nun weiss, nur Garmin-Karten macht - gegenueber behauptet, er koenne nach der Lizenzumstellung die gewerbliche Nutzung seiner Karte verbieten; wenn die Garmin-Karte eine Datenbank ist, muss sie unter ODbL veroeffentlicht werden.
Ich will aber gleich mal auf legal-talk nachfragen, wie andere das so sehen.
Bye
Frederik
PS: Ruhig mal direkt anmailen, wenn ich zu irgendwas meinen Senf dazu geben soll, ich les nicht immer alles.
…
Falls es jemanden weiterlesen möchte. Ich habe das mal auf die Mailingliste gestellt.
http://gis.638310.n2.nabble.com/Gibt-es-uberhaupt-Produced-Work-td5496731.html#none
Und auch auf legal-talk: http://gis.638310.n2.nabble.com/OSM-legal-talk-Garmin-Maps-Produced-Works-tp5496944p5496944.html
habs gelesen, aber mich gewundert. Es gibt doch Definitionen in der ODbL, was eine Datenbank ist. Da stehen Definitionen sowohl für Database, Collective Database und Derivative Database
Stimmt, aber die Definition von Database ist mehr als dürftig bzw. sagt mMn nicht das aus, was sie angeblich soll.
Wenn ich es richtig verstanden hab, dann ist eine Datenbank alles, was systematisch oder methodisch angeordnet ist und das einzelne Objekt elektronisch zugänglich ist oder anderweitig unter dieser Lizenz steht.
Elektronisch auslesbar ist auch ein png oder eine Papierkarte. Diese Definition spräche also meiner Meinung nach sehr für “kein produced work mit ODbL möglich”
Stimmt schon, die ODbL hat eine Definition fuer Datenbank und eine fuer Produced Works, aber diese Definitionen sind halt nicht ausreichend praezise. Es ist offensichtlich, dass es sehr viele denkbare Produkte aus einer OSM-Datenbank gibt, die zugleich unter die ODbL-Definition von “Produced Work” als auch unter die ODbL-Definition von “Database” fallen. Die zwei moeglichen Schluesse daraus sind (1) die ODbL-Schreiber und all die Rechtsgelehrten, die dazu was gesagt haben, sind entweder schusselig oder komplette Idioten; (2) es hat alles seinen tieferen Sinn 
Mittlerweile neige ich eher zu (2). Ich denke, diese Unschaerfe wurde bewusst in Kauf genommen, weil die ODbL ja fuer alle Arten von Datenbanken gueltig sein soll, auch fuer Faelle, die ganz anders gelagert sind als das, was wir machen, und die genaue Definition der Abgrenzung Database<->Produced Work ist ohne konkrete Beispiele aus dem jeweiligen Andwendungsbereich kaum zu leisten.
Bye
Frederik
Wenn die ODbL auch nicht der Weisheit letzter Schluß ist, warum wechseln wir dann dahin?
Wenn sich Anwälte austoben können, kommt meist etwas raus, dass unverständlich, praxisfern und ellenlang ist. Ich habe vor einigen Wochen an einem Vertrag mitgearbeitet, bei dem es um einen neunstelligen Betrag ging. Den Vertrag würde jeder verstehen im Gegensatz zu fast allen AGB.
Vorschlag: Wir wäre es bei der Definition der derivaten Datenbank in der ODbL “elektronisch” und “dauerhaft” zu ergänzen? Wenn dauerhaft zu allgemein ist, meinetwegen 72 Stunden oder was halt passt. Und man lässt es unspezifisch und kann allgemein bleiben. Dann muß man halt bei einer Klage den Richter überzeugen, ob etwas dauerhaft ist. Bei einem Webauftritt mit OSM Daten o.ä. durfte das ja nicht schwer sein.
Wenn ich das richtig sehe, hat man damit >90% erschlagen.
Um mal wieder auf das eigentliche Thema dieses Threads zu kommen:
Auf dem Garmin nutze ich OSM-Karten. OSM war sogar der grund warum ich mir ein Garmin gekauft habe. Je nachdem kann ich dann auch schnell mal einen Wegpunkt setzen um etwas nachzutragen.
OSM-Karten selbst im DIN A4 Format zu drucken, finde ich allerdings nicht so ideal.
Im Gepäck habe ich deshalb zusätzlich immer noch eine kommerzielle Radkarte von der jeweiligen Gegend von PublicPress (nein ich bekomme keine Provision 
). Die Karten zeichnen sich dadurch aus, daß sie speziell für Wanderer und Radfahrer erstellt wurden und “wetter- und reißfest” sind. Soll heißen, ein paar Regentropfen machen den Karten nicht s aus. Sie sind im Maßstab 1:100.000 und für “kleines” Geld zu haben. Und da sie nicht so oft aktualisiert werden, hält sich das mit den Kosten auch in Grenzen.
Mir sind bisher keine kommerziell gedruckten OSM-Karten in dieser Form bekannt. Kennt vielleicht jemand sowas? Dann würde ich die mir auch gerne mal ansehen.
Da du ja mit dem Composer arbeitest:
Der kann auch einen Style für den Kosmos-Nachfolger (Name vergesse ich immer wieder) erstellen. Damit kann man sich dann ein Bild rendern lassen und drucken. Mit Laserdrucker geht das deutlich besser, als mit Tinte, daher besser in den Copyshop rennen, wenn man selber keinen hat.
Die Karte dann in eine praktische Kartentasche für eine Lenkertasche.
Mit dem Composer habe ich allerdings das Problem, daß an manchen Stellen nur Höhenlinien abgebildet werden.
Zwischendurch kommen bei der Kartenerstellung immer mal Parse-Errors, sodaß die Karte nicht vollständig ist.
Im Moment ist mir noch nicht klar, ob der Download zu lange dauert, oder ob etwas anderes faul ist.