gähn Diese §§ habe ich schon MEHRFACH ins Spiel gebracht um auszudrücken, das man in OSM eigentlich (fast) keine Daten löschen DARF beim Lizenzwechsel nur aus Lizenzwechselgründen (und ich habe auch schon den Standpunkt vertreten, dass OSM-Daten immer CCbleiben müssen, weil ja jeder ODBL-Extrakt aus CC abgeleitet ist etc. pp.), wurde aber bisher alles zerrupft.
Aber schön, dass nun auch jemand anderes drauf kommt und diesen Aspekt ins Spiel bringt! 
Einer der Hauptzwecke, die Karte, ob nun zum Angucken, an die Wand nageln, zum Routen, … ist sicher ein Gemeschaftswerk. Und auch ein Extrakt von bestimmten Daten (alle Hydranten auf der Welt) ist sicher ein Gemeinschaftswerk, weil nur durch Mitarbeit vieler sinnvoll.
DAS würde ich auf jeden Fall als unter §8/9 UrhG fallend bezeichnen.
Da wird’s evtl. schwieriger, aber sobald der node in irgendeinem Kontext zu betrachten ist, sind an diesme Kontext sicherlich auch mehrere beteiligt. Wird nicht viele Sachen geben, die völlig solitär betrachtet werden können und wo ein Wegfall eines Single-Mapper-nodes sich absolut nicht auf andere Werke auswirkt.
Und im übrigen: das Hinzufügen von tags zu einem bisherigen single-Mapper-Elements würde ja §8/9 zum Durchbruch verhelfen!
Ich prophezeie, wenn diese Rechtssicht sich hoffentlich durchsetzt, viele tags dummschwatz=Ichwarhier 
Das wäre sicherlich ein schlagendes Argument für eine weiter bestehende und nicht umzudeutende Nichtzustimmung.
Das evtl. weniger, müsse bewiesen werden
und anshcließend abgewogen weren ggü. der Interessen der anderen Mapper an unversehrten Daten.
meiner unwesentlichen Meinung nach wird CC eh an uns haften bleiben, weil der erste ODBL-Planet NUR durch einen Auszug aus einen CC-Planet entstehen kann, weil kein Zustimmer seine Beiträge irgendwo extern hat.
D.h. vielleicht haben einige alte Stände als backup gesichert, wenn sie mit josm arbeiten, aber auch darin sind NIE ausschließlich ihre eigenen Daten drin, immer ein Mischmasch mit anderen, weil nur in Zusammenarbeit ensteht OSM.
Und m.E. könnten NUR bisher CC-extern gehaltene Daten unbefleckt von CC eine ODBL-pur-Datenbank bilden.
Daher oder auch unabhängig von dieser Überlegung (halt schon länger her) hatte ich vor einiger Zeit auch irgendwo den Vorschlag eingeworfen, sich mal über eine Dual-Lizenzierung der Hauptdatenbank Gedanken zu machen, aus der man, wenn man aus Lizenzgründen ODBL pur haben will, einen ODBL-Teilauszug bekommen kann (nach all den noch aufzustellenden Instrumentarien erzeugt) und der Rest arbeitet mit der Dual-Lizenzierung, wo immer es geht. CC-only wird sich, je nachdem, wie man die Regularien aufstellt (was ist wann wieviel CC und ODBL, worüber wir ja bisher viel diskutieren, oder auch weder CC noch ODBL, weil fehlende Schöpfungshöhe etc.) im Laufe der zeit rauswachsen …
Es müssten sich halt mal die Juristen Gedanken machen, ob, sobald OSM auch unter ODBL steht, die Daten durch ja schon recht weit gehende “ODBL-Infizierung” der Einzeldaten schon gut genug vor “Missbrauch” geschützt ist, der sich durch die CC-Lücken ergibt.
Wenn man bspw. aus OSM
- einen ODBL-pur-Auszug,
- einen CC-pur-Auszug und
- einen Dual-Auszug
ziehen könnte und ersterer immer kompletter würde im laufe der Zeit, zweiterer aber ähnlich gerupft aussähe wie es von einem relizenzierten Datenbestand jetzt befürchtet wird, und das immer schlimmer würde im Laufe der Zeit, dann wäre so schon ein rein praktischer Schutz wegen zunehmender Unbrauchbarkeit von CC-pur gegeben und Hauptzweck erfüllt …
Man müsste halt die ganzen Gedanken, die sich derzeit ausschließlich darum drehen, wieviel man rausschmeißen muss, einfach mal umlenken in andere Richtungen, wie man mglichst viele Daten möglichst geschickt retten kann und für wen welche Konsequenzen dual hat …
Durchaus. Aber mit allen §§, auch den ungemütlichen 
Genauso wichtig ist m.E. der Respekt gegenüber der Arbeit vieler Mapper, deren Daten durch nicht erreichbare Mapper gerupft würde.
Insbesondere, wenn die Mapper durch Unglücksfälle nicht mehr erreichbar sind, dann wäre das Tilgen deren Arbeit nur aus Fornaljuristerei besonders respektlos …