IMHO/SCNR: OSM schadet (und schafft) Mittelstand

Hallo Forenleser,

Achtung: Das ist ein SCNR-Post! Ich stehe voll hinter OSM.

Irgendwie habe ich jetzt ein schlechtes Gewissen:
http://www.intermap.de/html/deutschlandkarte/plzdeu.html
http://www.intermap.de/html/deutschlandkarte/dbl_1.html

Ich möchte nichts zu den Preisen sagen, bin aber enttäuscht, was man dafür effektiv nur mit den Daten machen darf:
http://www.intermap.de/html/lizenzen.html

OSM ist böse. Wohin soll das noch führen :wink:

SCNR
Tobias

Wann gibts erste “Konkurrenz”-Karten von OSM? Die PLZ’s von Deutschland werden ja gerade importiert. Die Landkreise, Autobahnen und größere Flüsse haben wir auch schon drin. Fehlt noch die Einwohnerzahl bei den Städten, um nur die großen Städte zu rendern.

OSM ist nicht böse. Aber die Welt ändert sich nunmal. Gestern ist man in den Pütt gefahren, heute forscht man an Solarzellen. Ich hoffe ja, dass die Geo-Unternehmen sich geschickter anstellen als die Buchmacher.

Gibt’s doch schon, wir haben viele Dienstleister, wie die Geofabrik, Infra, Wheregroup, Cloudmade oder mich [1].Teilweise werden die Daten aber durch Drittdaten angereichert, damit sie einen Qualitätsstandard erfüllen (z.B. lückenlose Kommunengrenzen). Leider sieht’s dann mit der ODbL bald böse aus, das ist aber anderes Thema!

[1] Ich habe z.B. dem Aachener Verkehrsverbund zu OpenStreetMap Karten verholfen. Die wollten erst ATKIS-Karten einsetzen, was aber mit hohen Folgekosten und Einschränkungen verbunden ist/war/sein wird.

Da, wo man etwas kaputt macht, wächst also wieder Neues. Darum gleicht sich das aus - genau wie Du schon sagtest.

Sehe ich auch so.
Wenn die Jungs von Intermap schlau sind lassen sie sich was einfallen mit OSM-Daten…

@TobWen:
Wie sieht es dann mit der neuen Lizenz bei den angereicherten Karten aus?

Ich glaube, das Problem ist, dass manche Firmen verbindliche Daten wollen. Auch wenn diese Firma in ihren Bedingungen schon schreibt, dass sich Fehler immer einschleichen können, unterliegen unsere Daten einem Fluss, der auch durch Vandalismus beeinträchtigt werden kann. Dieser wird zwar schnell behoben, aber wenn der Export der Daten vor der Korrektur geschehen ist, mag es böse aussehen.

Man muss daher von Anfang an sagen: OSM ist zwar nicht komplett und fehlerfrei, dafür zukunftsträchtig, ständig wachsend, unabhängig und kostenfrei.

Ich muss gestehen, ich habe mir die Endfassung noch nicht durchgelesen. Eine frühere Fassung war etwa so - bitte korrigiert mich: Wenn die OSM-Daten durch Fremddaten direkt angereichert werden, müssen diese Ergänzungen nach OpenStreetMap zurückfließen.

Wenn ich also eine Tabelle mit OSM-Daten habe und diese Daten z.B. direkt mit amtlichen Daten korrigieren würde (allen Gebäuden eine Hausnummer geben), hätten wir einen unlösbaren Konflikt. Die amtlichen Daten dürfen ja nicht zurückfließen. Es war daher damals im Gespräch, die Daten in zwei getrennten Tabellen vorzubehalten, allerdings würden sie ja bei einem Join oder View wieder kombiniert, wenn auch nur temporär.

Wie dieses Dilemma schlussendlich gelöst wurde, kann ich leider nicht sagen :frowning:

In einer “Qualitätsgarantie” (also einer Plausibilitätsprüfung und Durchsicht eines OSM-Extrakts) sähe ich durchaus eine gute Möglichkeit für einen Anbieter, einen Mehrwert zu schaffen. Sein “OSM mit Qualitätsgarantie” wäre dann zwar nicht mehr kostenfrei, dafür hoffentlich weniger fehlerhaft. Und natürlich ist die Qualitätssicherung ein kontinuierlicher Prozess - daher ist es für den Anbieter kein allzu großes Problem, wenn ältere Versionen seiner geprüften Daten frei im Umlauf sind.

Wenn es um die Herstellung von Karten geht, ist natürlich auch ein, möglicherweise manuelles, Nachbessern, Generalisieren und Verbessern der Darstellung gefragt. Unsere automatisierten Renderprozesse haben ihre Grenzen, was die Qualität angeht.

Da fehlt noch ein “und ein Produkt aus diesen Daten veröffentlicht wird”, weil interne Verwendung nicht betroffen ist. Ansonsten stimmt das im Wesentlichen.

Bisher dürfte ich allerdings schon die Daten aus einem veröffentlichten Produkt abkopieren.

Es gibt das Konzept der Sammeldatenbank (war auch schon in früheren Entwürfen, viel hat sich da also wohl nicht geändert) aus OSM-Daten und von OSM unabhängig erfassten Daten. Komplett aushebeln lässt sich das Share-Alike damit aber nicht - wäre auch nicht im Sinne der Lizenzautoren -, aber manche “Anreicherung” fällt durchaus darunter.

Alle Grenzen aus OSM rauswerfen und durch “offizielle” Grenzen ersetzen → wohl eine Sammeldatenbank. Hausnummern nicht nur in die Landschaft setzen, sondern mit in OSM vorhandenen POI oder Gebäuden verknüpfen → sieht m.E. nach abgeleiteter Datenbank aus.

Ja, sorry - natürlich :wink: Sonst wäre es ja ganz witzlos.

Ich dachte gerade durch dieses Verknüpfen der Daten - man verbessert sie ja dadurch - impliziert den Rückfluss (bei Veröffentlichung)?

Man schafft in meinem zweiten Beispiel Datensätze, die eine veränderte (hoffentlich verbesserte ;)) Version von Datensätzen aus der OSM-Datenbank darstellen. Die DB mit diesen Datensätzen ist daher eine abgeleitete Datenbank, und solche abgeleiteten Datenbanken müssen unter ODbL veröffentlicht werden.

Das gilt zumindest, wenn du tatsächlich eine komplette Datenbank erzeugst, die die verknüpften Daten enthält. Ich will aber nicht ausschließen, dass es technische Ansätze gibt, die auf diesen Schritt verzichten und etwa “live” eine Verknüpfung zweier unabhängiger Datenbanken durchzuführen versuchen. Sie dürften aber nur in Spezialfällen praktikabel sein.

Ein solches “live” Beispiel wurde mir mit Nop´s Composer im Thread http://forum.openstreetmap.org/viewtopic.php?id=8888&p=4 (unten) schon genannt. Insofern befürchte ich, daß insgesamt nur wenig zurückfließen wird, weil später jeder sagen wird, das war nur “live”, die (eigentlich unter die ODbL zu stellende) Datenbank wurde (inzwischen) wieder gelöscht, oder es gab nie eine Datenbank.
Das erinnert mich an die Diskussion um den Kopierschutz auf Musik-CD´s. Mit dem richtigen Crack-Programm, fragt man: “Welcher Kopierschutz?”.

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:

  1. 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.

  2. 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.

  3. 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:

  1. 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.

@aighes,

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.