[Talk-de] Lizenzwechsel ohne Datenverlust + bessere Versionskontrolle + Qualität durch Sichtung

Heiko Jacobs heiko.jacobs at gmx.de
Fr Dez 17 15:04:48 UTC 2010


Am 17.12.2010 13:13, schrieb Frederik Ramm:
> Eine reine Ko-Existenz der Daten kann erreicht werden,
 > indem man beim Rendern auf zwei verschiedene Datenbanken zugreift,
> eine alte und eine neue. Das ist schon vor einem halben
> Jahr als Moeglichkeit auf den Tisch gebracht worden und
> das koennte man mit vergleichsweise geringem Aufwand bauen
 > (vorallem, ohne dass dadurch an Editoren oder zentralen
> Komponenten was geaendert werden muesste).

Ich erinnere mich dunkel. Jedoch wirft eine solche Lösung die
Datenintegrität zwischen den Datenbanken auf. Sobald in der
einen was verschoben oder geändert wird, in der anderen aber
nicht, passt da nix mehr zusammen. Das auseinander fieseln
wäre schon beim Lizenzübergang nach bisheriger Planung ein
ziemlicher Akt, Wiederzusammenführungen wären ein ähnliches
Problem hoch drei.
Ähm, beim Schreiben fiel mir eben schon ein, dass schon alleine
durch das Rausnehmen "unreiner" Daten genug auseinander fallen
wird, dass man das Übereinanderlegen mit brauchbaren Ergebnis
grad vergessen kann. Wenn der letzte Bearbeiter als Nur-CCer
Knoten verschiebt und damit aus ODBL rausfliegt, passen die
Wege ja nicht mehr zusammen, da muss man noch nicht mal nach
dem Lizenzwechsel was editieren, aber es würde ja stetig schlimmer.

> Jede Art des Verbleibens "alter" Daten als Rohdaten in der
> zentralen Datenbank birgt die Gefahr, dass weitere davon in
> irgendeiner Form abgeleitete Daten entstehen und ist daher
> problematisch. Entgegen Heikos Darstellung waere eine solche
> gemischte Datenbank auch nur sehr begrenzt nutzbar - nimm als
 > Beispiel meine Geofabrik-Extrakte: Die duerfte ich
> daraus schon nicht mehr produzieren, denn die ODbL-Anteile
> darin wuerden die Veroeffentlichung des gesamten Extrakts
> unter ODbL erfordern, was wiederum den CC-BY-SA-Anteilen
> unrecht taete.

> Die gemischte Datenbank waere ausschliesslich zur Produktion von
> Werken, die selbst keine Datenbanken sind, geeignet -
> und diese koennten relativ einfach, wie oben skizziert,
> auch ohne eine Durchmischung der Daten produziert werden.

Den genauen Umgang müssen die Lizenzbewanderten noch genauer prüfen.
Gemischte Lizenzierung kommt bspw. in der Wikipedia ständig vor.
Der text scheint zwar einheitlich lizenziert zu sein, aber bei
den Bildern kommen dutzendweise verschiedene Lizenzen zum Zuge
und oft genug steht ein einzelnes Bild auch unter mehreren Lizenzen
(Gnu und CC bspw. beim zweiten auf der bei mir zufällig offenen
Seite zur Rollenden Landstraße).

Es scheint also prinzipiell zu gehen, ein und dasselbe Werk
parallel unter zwei Lizenzen zu halten.
Demnach sollte es schon Erfahrungen damit geben, von denen man
lernen können sollte, was das für Auswirkungen auf Folgeprodukte hat.
Und was das dann für unsere Produkte genau heißt in Abhängigkeit
von der genauen Formulierung, die man dabei findet.

Im Prinzip sind die Daten ja jetzt schon teilweise doppelt lizenziert,
weil alle neuen und zustimmenden der OSMF das Recht geben, unter
beiden zu veröffentlichen, und dieses Recht bleibt auch dauerhaft
drin auch nach CT 1.2 und sobald sich 2/3 finden, kann diese Option
gezogen werden.

Wenn es also eh die Option gibt, jederzeit zu einer (vielleicht
irgendwann besseren Version 47.11 der) CC zurückzukehren,
dann darf die Frage erlaubt sein, ob wir wirklich die CC
spurlos ausmerzen müssen aus der einen wahren Datenbank ...

Davon abgesehen stehe ich ja bekanntermaßen eh auf dem Standpunkt,
dass es gar nicht so einfach ist, die CC loszuwerden, wenn man
die ODBL-Datenbank aus einer CC-Datenbank ableitet und anders
geht das technisch ja m.E. gar nicht ... ;-)
Das Problem hätte man bei einer Doppellizenzierung ja erstmal
auch nicht mehr.

Das Problem, dass planet.osm ja auch die Verwendung von ODBL
fordern würde, sehe ich so nicht direkt, denn das ist ja das,
was wir wollen: ODBL.
Reine ODBL-Daten gibt's als Auszug im planet-odbl.osm
Doppelt lizenzierte unter planet.osm
Wenn's reine CC-Daten (die im planet.osm wären ja 100% CC)
ohne ODBL-"Makel" nicht gibt, ja nu, die CC wollten wir ja
eh loswerden, dann kann's ja nicht so schlimm sein, wenn es
"CC pur" nicht mehr gibt ...

Aber die ganzen Folgewirkungen muss man vielleicht wirklich ma
alle durchdenken, sobald man sich in die Problematik doppelt
lizenzierter Werke a la Wikipedia-Bilder etwas genauer
eingearbeitet hat und vielleicht daher schon eine Idee hat,
auf was man dabei achten muss.

Dass der planet.osm dann ODBL-infiziert wäre, muss ja kein
Schaden sein, weil es ja bisher heißt, unter CC alleine
wäre der Schutz der Daten zu schwach. Sobald sie AUCH unter
ODBL stehen, ist es ja vermutlich nicht mehr so trivial,
sie aufgrund zu schwacher CC zu "klauen".
Insofern kann es von Vorteil sein, die doppelte Lizenzierung
möglichst schnell einzuführen, evtl. auch schon, bevor die
Mechanismen stehen, ODBL-pur-Planeten zu generieren.

>> Jede Lösung, die den Schaden minimiert ist Gold wert.
>
> Jede Loesung, die den Lizenzwechsel *noch* weiter hinauszoegert,
> kostet aber auch Nerven. Das muss man gegeneinander aufwiegen.
> Heikos "Loesung" ist ein grosser Wurf, der alles
> in allem hunderte von Programmierer-Manntagen verschlingen wuerde.
> *Wenn* sich denn jemand findet, der das alles umsetzen will.
> Woran hier zunaechst gearbeitet werden muesste,
> ist, das Konzept klar und einfach darzustellen,
> Mitstreiter zu werben, Prototypen zu basteln und so weiter.

Du vergisst dabei, dass wir die Grundmechanismen sowieso brauchen,
wenn wir eines Tages auf ODBL umsteigen wollen.
Das angesprochene Problem der geteilten und vereinigten Wege
muss man in Angriff nehmen und auch die Beurteilung, welches
Element nun unter welcher Lizenz steht.
Was eventuell anders ist, ist die Stelle, wo das eingebaut werden müsste.
Für einen puren Lizenzwechsel reichen eventuell stand alone Lösungen,
wobei die schon alleine wegen des Wunsches, die Auswirkungen zu sehen,
mehrfach lauffähig sein müssten und somit dem dauerhaften Einsatz
nahe kommen müssten.
Ob man das ganze gar in die API einbauen sollte/müsste/könnte,
da halte ich mich als Feld-, Wald. und Wiesenprogrammierer ohne
wirkliche Ahnung von der Last, die auf der API liegt, lieber
vorerst dezent raus. Ich habe bisher nix an der API rumgeschraubt
oder überhaupt an Systemen unter Last, so dass ich da vermutlich
zu viel kaputt machen könnte. Meine bisherigen C- und Tcl-Programme
sind nicht unbedingt immer wirklich rechenzeitoptimiert ;-)

Die Sichterei ist ja auch zudem eine dauerhaft sinnvolle Sache.

Wenn erstmal Einigkeit hergestellt wäre, dass man den Weg der
Doppellizenzirung gehen möchte, weil die Konsequenzen tragbar sind,
dann wäre die nächste Frage, ob man die nötigen Prozesse auch
schrittweise umsetzen kann. Ich vermute ja und dass das sogar
besser ginge als bei einer puren Lizenzumstellung.
Da müsste nämlich ALLES auf einen Schlag stehen wie eine Eins,
während sich die Qualität der ODBL-pur-Auszüge oder der
Sichtungsmöglichkeiten ja durchaus Schritt für Schritt verbessern dürfte
und man entscheiden kann, ab wann man da einsteigt, die zu nutzen etc.

Es wäre ja vermutlich kein Drama, wenn Potlatcher 3 Wochen vor
den JOSM-Nutzern sichten könnten oder umgekehrt.

Arbeitet überhaupt schon wer an Prototypen für die Module,
die für den Lizenzwechsel nötig sind? Irgendwie habe ich davon
noch nix mitbekommen außer im Rahmen der bacchelor thesis,
wo das ja eigentlich zumind. teilweise vorkommen müsste.
Wenn eh noch niemand dran arbeiten würde und somit auch noch
keiner den Aufwand wirklich abschätzen kann, ist die beurteilung
des Aufwandes für meine Ideen eh ziemlich wackelig und eher
ein Schreckgespenst ... ;-) Wenn schon jemand dran arbeitet,
dann möge derjenige was dazu sagen, wie das gehen soll und wie
man das vielleicht ummünzen kann ;-)

Eher mache ich mir Sorgen, dass der pure Lizenzwechsel sich verzögern
würde, weil eben DA noch niemand dran arbeitet und somit auch noch
keine Vorstellungen hat, was für ein komplexes Auseinandergefiesel
das wird.

Gruß Mueck





Mehr Informationen über die Mailingliste Talk-de