DE:Datenverlust bei Lizenzwechsel
Diese Seite dient der quanitatativen und qualitativen Analyse potentieller Datenverluste bei einem Lizenzwechsel.
Aktuelle Lizenz | CC-by-SA |
bisher geplant | ODBL |
mögliche Alternative | PD/CC0 |
Informationen zum geplanten Lizenzwechsel
- ODbL - Wir wechseln die Lizenz - Übersicht zu den Erfordernissen, Alternativen und zum Ablauf
- FAQ zur geplanten ODBL
- Bedeutung von PD-Daten einzelner OSMer
- Vor- und Nachteile von CC0/PD, BSD, ODBL in Vergleich
Berechnung der Datenverluste
Netto-Datenverlust
Datenverlust = gelöschte Daten - wiederhergestellte Daten verbleibender Datenrest = Grundmenge der Daten - gelöschte Daten + wiederhergestellte Daten
Grundmenge der Daten
Für eine Übersicht über die Grundmenge könnte man repräsentative Kartenausschnitte bestimmen und darin die derzeitige Gesamtmenge der Daten bestimmen. Um repräsentativ zu sein, müsste man wohl unterscheiden: Stadt/Land (viel/wenig kartografiert), DE/US/TR (unerschiedliche Communitys), Luftbild ja/nein, Import ja/nein, etc.
Verlust durch Löschung
Für eine "schnelle Übersicht" könnte man in den repräsentativen Kartenausschnitte für jeden Ausschnitt die beteiligten OSMer listen, und aus diesen eine zufällige Stichprobe nehmen, von der man annimmt, dass sie einer Lizenzänderung nicht zustimmen (sinnvoll wäre natürlich, diese Annahme durch eine Umfrage zu erhärten, bei der auch erfasst wird, wllche OSMer überhaupt erreichbar sind,, und das gleich für verschiedene Lizenzvarianten zu tun). Dann löscht man die von den "Ablehnenden" oder von den "Nicht-Erreichten" eingebrachten Daten - und zählt, was noch übrig bleibt.
Für eine genauere Übersicht müsste man zusätzlich kaskadisch auch die historisch nachfolgenden jüngeren Daten löschen.
Und für eine genaue Übersicht müsste man zusätzlich alle "verbundenen" Daten löschen, also solche, die durch räumliche und/oder logische Verknüpfungen mit gelöschten Daten als Folge des Lizenzwechsels ebenfalls gelöscht werden müssen.
Analyse der Wiederherstellungsmöglichkeiten
Um die vermuteten/behaupteten Wiederherstellungsmöglichkeiten zu verifizieren, müssten für jeden einzelnen Fall Werkzeuge entwickelt werden, die verlorene Daten lizenzgerecht wieder herstellen. Diese Werkzeuge müssten dann an den Test-Kartenausschnitten geprüft werden, in welchem Umfang und in welcher Qualität sie die gelöschten Daten wieder lizenzgerecht retten können.
Kaskadische Verluste bei Nichtzustimmung
Wenn ein OSMer nicht erreichbar ist (keine Lust zum Antworten, Urlaub, Mailadresse nicht vorhanden/geändert, nicht mehr im Projekt), oder wenn ein OSMer einer Neulizenzierung seiner Daten bewusst nicht zustimmt, diese also unter CC-by-SA bleiben, dann sind alle auf dessen Bearbeitungen folgenden Änderungen und/oder Ergänzungen kaskadisch betroffen und können in vielen Fällen ebenfalls nicht umlizenziert werden. Hier einige Beispielfälle:
einzelne Punkte mit Attributen
Restaurant als Punkt
- Fall 1
- A trägt ein Restaurant als Punkt ein
- B ergänzt die Adresse
- C ergänzt die Küchenrichtung
A verweigert Lage, Adresse und Küchenrichtung dürfen nicht umlizenziert werden B verweigert Lage darf umlizenziert werden
Adresse und Küchenrichtung dürfen nicht umlizenziert werdenC verweigert Lage und Adresse dürfen umlizenziert werden
Küchenrichtung darf nicht umlizenziert werden
- Fall 2
- A trägt ein Restaurant als Punkt ein
- B ergänzt die Adresse
- C zeichnet ein Haus und übernimmt die Attribute des Punktes
- D ergänzt die Küchenrichtung
A verweigert Lage, Form, Adresse und Küchenrichtung dürfen nicht umlizenziert werden B verweigert Lage darf umlizenziert werden
Form, Adresse und Küchenrichtung dürfen nicht umlizenziert werdenC verweigert Lage des Punktes darf wiederhergestellt, und zusammen mit Adresse umlizenziert werden
Form und Küchenrichtung dürfen nicht umlizenziert werdenD verweigert Lage, Form und Adresse dürfen umlizenziert werden
Küchenrichtung darf nicht umlizenziert werden
Linien
- Fall 1
- A zeichnet eine Strasse und attributiert sie mit "name"
- B verschiebt die Strasse
- C ändert die Attribute
A verweigert Lage, Form und Attribute der Strasse darf nicht umlizenziert werden B verweigert Lage, Form und Attribute der alten Strasse dürfen dürfen wiederhergestellt und umlizenziert werden
die neue Lage, die neue Form und die neuen Attribute dürfen nicht umlizenziert werdenC verweigert Lage, Form und Attribute der verschobenen Strasse dürfen dürfen umlizenziert werden
die neuen Attribute dürfen nicht umlizenziert werden
- Fall 2
- A zeichnet eine Strasse und attributiert sie mit "name"
- B zeichnet eine Abzweigung und attributiert sie mit "name"
- C zeichnet eine Verbindung zwischen den beiden Strassen und attributiert sie mit "name"
A verweigert Lage, Form und Attribute der drei Strassen dürfen nicht umlizenziert werden B verweigert Lage, Form und Attribute der ersten Strasse dürfen umlizenziert werden
die beiden darauf aufbauenden Strassen dürfen nicht umlizenziert werdenC verweigert Lage, Form und Attribute der ersten beiden Strassen dürfen umlizenziert werden
die darauf aufbauende Strasse darf nicht umlizenziert werden
Flächen
Relationen
als Route
als Multipolygon
- Fall 1
- A zeichnet einen See
- B zeichnet eine Insel als Multipolygon
- C ändert die Lage der Insel
A verweigert Lage, Geometrie, Attribute und Multipolygon von See bzw. Insel dürfen nicht umlizenziert werden B verweigert Lage, Geometrie und Attribute von See dürfen umlizenziert werden
Insel, Lage, Geometrie von Insel und Multipolygon von Insel und See dürfen nicht umlizenziert werdenC verweigert Lage, Geometrie und Attribute von See und Multipolygon von See und Insel dürfen umlizenziert werden
Lage und Geometrie der alten Insel dürfen wiederhergestellt und umlizenziert werden,
Lage und Geometrie der neuen Insel dürfen nicht umlizenziert werden
- Fall 2
- A zeichnet einen See
- B zeichnet eine Insel als Multipolygon
- C ändert die Lage des Sees
A verweigert Lage, Geometrie, Attribute und Multipolygon von See bzw. Insel dürfen nicht umlizenziert werden B verweigert Lage, Geometrie und Attribute von See dürfen umlizenziert werden
Insel, Lage, Geometrie von Insel und Multipolygon von Insel und See dürfen nicht umlizenziert werdenC verweigert Lage, Form und Attribute von Insel und Multipolygon und Multipolygon von Insel und See dürfen umlizenziert werden
Lage und Geometrie des alten Sees dürfen wiederhergestellt und umlizenziert werden
Lage und Form des neuen Sees dürfen nicht umlizenziert werden
Bisherige Datenimporte
Luftbilder aus Bayern
In den Nutzungsbedingungen steht:
Die zeitlich befristete Nutzung der DOP-Daten beinhaltet das Recht, die während der Tesphase erhobenen Vektordaten im OSM-Projekt dauerhaft und frei zu nutzen.
"frei"bedeutet hier "PD" (oder so). Das ist aber nur die Position der Regierung.
Entscheidend ist die Position der einzelnen Mitarbeiter im Projekt. Dei meisten werden unter CC-by-SA lizenziert haben.
Damit ist unklar, wie diese "2 Mannjahre" Arbeit bei einem Lizenzwechsel gerettet werden können.
Künftige Datenimporte
Wie wird eine neue Lizenz die Spendenfreudigkeit potentieller Datenspender beeinflussen?
Juristische Klärung
Bis heute (14.8.) ist nicht geklärt, ob überhaupt bei einem Lizenzwechsel Daten gelöscht werden müssen.
Folglich ist juristisch auch nicht geklärt, welche Daten wann wie warum gelöscht werden müssen und welche Daten in Abhängigkeit von zu löschenden Daten ihrerseits gelöscht werden müssen.
Bei Bearbeitungen durch einen Bot muss geprüft werden, welche Lizenz der Botbetreiber benutzt hat.
Bei Daten-Importen muss geprüft werden, welche Lizenz der Importierer benutzt hat.
Modellrechnung
Voraussetzung für Modellrechnungen sind verlässliche Basisdaten.
wieviele Datenbearbeiter ?
geschätzt | gemessen am ... | Bemerkung | |
---|---|---|---|
bisherge Accounts | 280.000 | ||
erreichbare Accounts | |||
aktuelle Accounts | |||
Veränderung der Accounts | jährlich, monatlich, Verteilung, jeweils Zugang, Abgang, Bestand | ||
abstimmungsberechtigte Accounts | nach den vorgeschlagenen "Terms" | ||
Accounts mit PD | |||
Accounts die Lizenzwechsel verweigern wollen | |||
Accounts die GDbL zustimmenn wollen | |||
Accounts die PD zustimmenn wollen | |||
Accounts die einen Fork wollen | |||
... |
wer bearbeitet was ?
geschätzt | gemessen am ... | Bemerkung | |
---|---|---|---|
Accounts mit Edits im vergangenen Jahr | |||
Accounts mit Edits im vergangenen Monat | |||
Verteilung der Edits pro Account | Streuung, Klumpung, zeitl. Dimension, Pareto | ||
... |
wieviele Einzel-Edits sind betroffen ?
Aus obigen Zahlen könnte man berechnen, wie gross die Menge der direkt betroffenen Edits ist.
Unabhängig davon könnte man Modellrechungen machen, denen bestimmte Annahmen zugrunde liegen i.S.v. "was wäre wenn"...
wieviele Edits sind kaskadisch-vererbend betroffen ?
Durch Analyse der DB und ihrer Historie und der Vernetzung der Objekte könnte man analysieren, wie gross die Menge der indirekt betroffenen Edits ist.
Unabhängig davon könnte man Modellrechungen machen, denen bestimmte Annahmen zugrunde liegen i.S.v. "was wäre wenn"...
Strategien
Wenn man aus der Pareto-Analyse weiss, wer die "wichtigsten" Datenspender sind, dann könnte man diese gezielt nach ihren Wünschen befragen, und deren Antworten entsprechend gewichten.
Bei für die Zukunft von OSM "ungünstigen" Antworten könnte man versuchen, diese "wichtigen" OSMer direkt ansprechen und sie um beispielsweise Doppellizenzierung bitten. Oder man könnte gemeinsam mit diesen OSMern einen Fork planen.