Lizenzwechsel ohne Datenverlust + bessere Versionskontrolle + Sichtung

Moin

Ich möchte noch mal das Thema Lizenzwechsel + Datenverlust aufgreifen,
auch unter neuen Gesichtspunkten und verbunden mit dem Thema
Qualitätssicherung und Versionskontrolle, vielleicht auch
interessant im Zusammenhang mit einer laufenden bacchelor thesis
http://forum.openstreetmap.org/viewtopic.php?id=9817
oder dem groben Ansatz der kartographischen Darstellung des
Lizenzwechselstandes http://osm.informatik.uni-leipzig.de/map/?layers=B0

Zu dem Themenkreis braucht man

  • Entscheidungen zur Vorgehensweise und
  • Tools zur Umsetzung derselben.

Bei letzterem sind es vor allem zwei:

  • Herstellung einer kompletten Objekthistorie und
  • Entscheidung aus dieser heraus, welcher Lizenz ein Objekt aktuell hat.

Arbeitet schon jemand auf der Welt an solchen Tools?
Habe jedenfalls noch nicht von sowas gehört …

Ersteres Tool ist nötig wegen des Teilens und Vereinigens von Wegen.
Beim Teilen entsteht ein way mit “frischer” Historie und “neuem”
Benutzer, auch wenn der außer der Teilung gar nix zu diesem way
beigetragen hat.
Beim Vereinigen geht dagegen die Historie eines ways verloren.

… beides zumind. aus Sicht normaler Nutzer.
Eine komplette Verfolgung der Historie ist bisher nur äußerst
mühsam möglich über die beteiligten nodes, weil die beim Teilen
und Vereinigen meist bestehen bleiben, beim potlatch live Modus
ganz sicher, bei allen anderen Editoren kann auch mit den nodes
zwischendrin genug passieren, dass man es durchaus nicht so recht
nachvollziehen kann …

Nützlich wäre ein solches Tools aber schon bei ganz allgemeinen
Fragestellungen, bspw. wann bestimmte Änderungen eingefügt wurden
und von wem, also für eine bessere Versionskontrolle.
Von daher wäre es sinnvoll, ein solches Tool

  • unabhängig vom Lizenzwechsel zu entwickeln,
  • dieses nicht nur für’s Aufarbeiten vergangener Edits zu verwenden,
  • sondern möglichst dauerhaft einzusetzen auch für künftige Edits.

Für zweiteres würde ein standalone Tool reichen, dass 1x bei der
Umstellung der Lizenz durchläuft. Hätte den Haken, dass man keine
Zwischenstände erzeugen könnte …
Letzteres hieße, dass man entweder der API das beibringt,
oder alle hochladenden Editoren zwingt, Infos einzubauen.
Oder beides. API-Einbau, der meistens (aber nicht immer) nix zu
tun hat, weil die großen Editoren es mundgerecht liefern, denn die
wissen ja am besten, wann split/join geklickt wurde …

Soweit der erste Tool, nun erst mal zum Lizenzwechsel.

Wer braucht die neue Lizenz?

Der reine Mapper eigentlich nicht so dringend, weil der mappt ja
schon die ganze Zeit fröhlich mit der angeblich ungeeigneten Lizenz,
der würde wohl auch weiter fröhlich damit mappen …

Die meisten Datenanwender auch nicht so dringend, denn für die div.
slippy maps online und auf Navis war die alte Lizenz bisher auch
brauchbar.

Es gibt aber einen Kreis, der ganz spezielle Anwendungen mit den
Daten aus OSM bestücken will, vielleicht auch Daten unterschiedlicher
Lizenzen miteinander kreuzen will, ohne dabei in juristische
Schwulitäten zu kommen, was bei der jetzigen Lizenz wohl pasieren kann.

Für letztere ist die neue Lizenz nach allem, was mir bisher begegnete,
vermutlich klar besser. Und auch dem Mapper bietet sie vermutlich mehr
Sicherheit (Unter “Lizenz” verstehe ich jetzt mal zur Vereinfachung
die Gesamtheit aus Daten- und Datenbanklizenz und CT.)
So dass es vermutlich insgesamt betrachtet besser wäre,
die Lizenz zu wechseln. Und je schneller, desto besser.

Großer Haken ist in meinen Augen aber die Behandlung der Altdaten,
die nach bisheriger Lesart zwangsläufig bei einer Umstellung
verschwinden müssten. Dabei verschwinden nicht nur Wege etc., sondern
weiterhin bestehende Objekte werden – fast noch schlimmer – durch
Wegfall von nodes oder tags teilweise grob verfälscht.
Besonders lästig ist, dass sich das unter keinen Umständen verhindern
lässt, selbst wenn man noch so große Werbemaßnahmen startet für
den Wechsel, weil es immer Leute geben wird, die nicht zustimmen können
oder wollen, weil sie tot, verschollen oder verärgert ausgestiegen
sind oder einfach, weil ihre verwendete Datengrundlage nicht kompatibel
mit der neuen Lizenz zu kriegen ist.

Für den Kreis der Spezialanwender ist eine Lizenzumstellung
existentiell wichtig, während für die große Masse die Umstellung
einen eher nur theoretischen Nutzen haben wird, aber rein praktisch
höchst ärgerlich werden wird, wenn sie erstmal (zu spät) merken,
was das für Nebenwirkungen haben wird.

Da stellt sich für mich schon lange die Frage, ob diese Nebenwirkungen
nicht vermeidbar sind. Bisherige Überlegungen stießen aber größtenteils
auf Ablehnung. Vielleicht habe ich mit den neuen ja mehr Glück … :wink:

Ein Tool haben wir ja noch zu diskutieren:
Die Klärung, welches Element unter welcher Lizenz steht.
Da gibt’s einen ganzen Rattenschwanz zu klären:

  • Wie gewichtig ist das Urheberrecht an einer einzelnen Koordinate eines nodes
  • Wenn von 100 nodes eines ways 99 ok sind, was macht man mit dem 100.?
  • ab wann sind edits trivial, Frage nach bots etc.
  • ab wieviel tags unter neuer Lizenz ist ein Element sauber

Da will ich mir gar nicht groß den Kopf drüber zerbrechen, weil

  • Diplomarbeit unterwegs, die da vielleicht Antworten liefert?
  • nicht so wirklich relevant für meine Überlegung.
    Es geht um das Ergebnis, das kann sein:
  • Element sauber OdBL, 100%
  • Element nicht sauber ODbL
    oder auch
  • Element sauber ODbL, 100%
  • Element fast sauber ODbL, 90%
  • Element rein CC, 100%
    oder auch
  • Element 100% PD, das kann man ja auch ankreuzen
    Was genau da rauskäme, muss noch diskutiert werden, gerade vorm
    Hintergrund gemeinsam bearbeiteter Objekte, bisher völlig ungelöst.

Bisher ist vorgesehen, dass daraus dann EIN neuer Datensatz entsteht,
der nur noch ODbL-Daten enthält.

Warum aber nur so “binär” und einmalig?

Im Prinzip wird der Beurteilungsprozess sicher so gestaltet werden,
dass man ihn mehrmals laufen lassen kann, denn das Volk verlangt
nach Zwischenzuständen “bis heute haben 47110815 Mapper zugestimmt,
das führt zu dieser Karte http://… wenn es so bliebe”

Dann sind wir nahe dran, den einmal ermittelten Zustand irgendwo
in den Daten festzuhalten. Dann kriegt ein
, oder was auch immer man alles beurteilen wird,
noch ein l=… (licence=…) dazu
l=o, l=c, l=p oder auch in Variationen l=o50 für 50% ODbL …
vielleicht auch noch Zusätze, die aussagen, warum etwas noch nicht
100% ODbL ist …
Was genau gespeichert werden könnte, kann man vermutlich erst im
laufenden Prozess beurteilen, wenn man sich genauer damit beschäftigt.
Vielleicht bringt die Diplomarbeit da Erkentnisse?

Damit könnte man dann zwei Sachen machen:

A.
Wir lassen einfach alle Daten auf Dauer in OSM drin, auch die CC-Daten.

Wer die Daten für Anwendungen braucht, bei denen es egal ist, ob sie
unter CC oder ODbL stehen, zieht sich einfach ALLE Daten.
Die slippy maps könnten weiterhin alle Daten ziehen, es sei denn,
es sind Spezialkarten, die künftig inniger mit Fremdlizenzdaten
kombinieren wollen als es die CC-Lizenz zulässt.

Wer die Daten sauber nach einer einzigen Lizenz braucht, greift
nicht auf den Original-Planeten zurück, sondern entweder bei großen
Gebieten auf in bestimmten Abständen generierten Auszüge, so wie
es sie ja schon regional ausgeschnitten, Deutschland etc. pp., gibt.
Dann gibt’s halt nicht nur planet.osm, sondern auch noch planet-odbl.osm
und planet-pd.osm (!) oder planet-odbl50.osm.

Wer nur kleine Gebiete braucht, kann ja jetzt schon über die XAPI
bspw. highway=residential selektiv abfragen, da käme dann l=o o.ä. hinzu,
wer’s lizenzrein braucht.

So gäbe es keine Datenverluste und die, die ODbL zwingend brauchen,
können im Prinzip ab sofort (sobald es diese Tools gibt) loslegen,
deutlich früher vermutlich, als wenn sie auf die 99%-Umstellung warten
müssten, die vielleicht auch gar nicht kommt, wenn nicht genug mitmachen
(können). Sie können schon bei 75% starten, besser als wenn’s keine
ODbL-sauberen Daten gäbe.

Dass der Bestand an ODbL-Daten innerhalb dieser Mischdatenbank
anteilsmäßig wächst, dafür können zwei Effekte sorgen:
zum einen die wachsende Zahl neuer User, die nur noch ODbL-kompatibel
einsteigen, zum anderen die ohne Datenverlustgespenst stärker steigende
Zahl der Lizenzwechsler.
Wir können (und sollten auch) auch beim bisherigen Plan bleiben, dass ab
einem Zeitpunkt in 2011 nur noch Benutzer erlaubt sind, die zugestimmt haben.

Das ist aber noch nicht alles, kommen wir zu:

B:
Sobald man in den Daten ein l=o o.ä. drin hat, kann man das
natürlich auch anzeigen.
In Potlatch 2 bspw. über einen weiteren Kartenstil.
Darauf kann man was weiteres entwickeln, was sich neben einer besseren
Versionskontrolle im Prinzip auch an die Wikipedia anlehnt:

Sichten!

(Ich nenne es mal so in genau dieser Anlehnung an die Wikipedia)

Wie mappt Otto-Normal-Mapper heute?
Er mappt, was fehlt.

  • fehlende nodes, wenn die runde Straße noch eckig erscheint …
  • fehlende ways komplett
  • fehlende tags
    Kaum ein Mapper käme auf die Idee, schon vorhandenes neu zu machen,
  • außer, das Objekt liegt geometrisch daneben, dann wird’s zurechtgerückt
  • oder die tags sind falsch oder suboptimal

Auch vorhandenes neu zu mappen, die Idee kam ja erst im Zuge des
Lizenzwechsels auf, um Daten ODbL-sauber zu machen.
Das ist aber einfach nur Quark …

Aber im Prinzip haben wir noch ein Problem, dass wir in diesem Zuge
lösen könnten: Ein einmal angelegtes Objekt hat den Zeitstempel des
Anlegezeitpunktes. 5 Jahre später, wenn seitdem niemand anderes was
dran getan hat, stehen wir vor der Frage

  • ist das Objekt wirklich unverändert
  • oder ist der Stand veraltet?

Im Moment gibt es keine Möglichkeit, ein Objekt als noch existent zu
bestätigen.

Wenn wir eine Sichtung einführen in OSM, die Lizenzstatus und
Alter des Objekts anzeigt, könnten wir mit einem Klick auf “sichten”

  • bestätigen, dass ich das Objekt unter neuer Lizenz neu hätte mappen können
    und/oder
  • bestätigen, dass das Objekt immer noch genau so existiert.

Vermutlich müsste man noch unterscheiden, ob man

  • die Geometrie
  • die Eigenschaften
    bestätigen kann. Ersteres aus eigenen GPS-Tracks oder Luftbilder,
    letzteres einfach durch in Augenscheinname.
    Vielleicht auch noch detaillierter unterschieden (ich kann surface
    bestätigen, aber nicht name, …)

Wir werden ja noch in das große Problem reinrutschen, dass die Daten
so aussehen, als wäre alles gemappt. Woran erkennt man denn heute,
dass es in einer Ecke veraltete Daten geben könnte? Gar nicht,
weil man denen ihr Alter absolut nicht ansieht.
Mit Sichtungstools und -anzeigen könnte man das Alter besser erfassen
und so Ecken erkennen, die mal kontrolliert werden sollten …
Irgendwann wird’s uns ja langweilig, wenn alle Blumenzwiebeln im
Garten dank 1-cm-Luftbilder erfasst sind :wink:

Im Prinzip könnte man auch das Gegenteil einführen: Sichtung aufheben,
um auszudrücken, dass Geometrie und/oder Eigenschaften angezweifelt
werden, das wäre sozusagen eine erweiterte Verknüpfung mit OpenStreetBugs
oder so …
Sowas hätte ich mir die Tage gewünscht an einer Stele, von der ich
weiß, dass dort irgendwo irgendwie gerade ein neuens Bahnbetriebswerk
gebaut wurde.

Außerdem müsste auch das Tool, dass den Lizenzstatus erfasst, ob nun
einmalig oder mehrfach für Zwischenzustände, dauerhaft installieren, damit

  • diese Sichtungen am l=… angebracht werden
  • oder die ganz normalen Änderungen, die den Status ändern,
    letzteres durch das ganz normale Verschieben von nodes oder ändern
    von tags, die ja auch eine Sichtung mit anderen Mitteln ist …

Damit hätte ich glaub alle Tools und Schritte beisammen …

Vorteile:

  • Datenverlust vermieden
  • Lizenzübergang gleitend
  • Problem gemeinsam bearbeiter Daten nicht mehr so schwerwiegend für viele
  • schneller ODbL-Datensätze für Spezialanwender verfügbar
  • aber auch schneller besserer Schutz, weil schneller von CC-only-DB weg
  • eventuell migriert OSM so irgendwann auch langsam gleitend zu PD
  • überhaupt ist es die einzige Möglichkeit für PD-Fans PD zu extrahieren?
    Und:
  • langfristig durch Sichtung und Versionskontrolle bessere Qualität

Nachteile:

  • ODbL-only-Datenbank dauert länger
  • mehr Aufwand im laufenden Betrieb

Mit Sichtung wird der Nachteil, dass noch CC-Daten da sind, aber vielleicht
schneller ausgeglichen, als wenn CC-Daten gelöscht und neu gemappt werden
müssten. Ich habe zwei große Waldgebiete bearbeitet, fehlende Wege erfasst
und ALLE Wege frisch klassifiziert.
ALLE nicht ODbL-sauberen tags, die schon vorher da waren, also
urheberrechtlich nicht von eingebracht sind, könnte ich in einem
Rutsch sichten, denn wären sie nicht da gewesen, hätte ich sie ja
drangehängt.
Bei den Geometrien müsste ich etwas genauer hinschauen, ob meine
GPS-Tracks auch eine Sichtung der Geometrie hergeben, weil ich meinen
alten Empfänger mit wenig Speicher oft abgeschaltet habe, wenn ich
über alte Wege fuhr. Aber aus Extrapolation meiner GPS-trcks und
Vergleich mit Luftbildern könnte ich wohl vieles doch geometrisch sichten.
Fehlendes wird irgendwann nachermittelt, Waldwege ändern sich ja
gelegentlich und irgendwann muss ich wieder raus, nachgucken, ob grade4
noch immer grade4 ist oder inzwischen impassable, grade5, grade3, grade2, …

Im Prinzip läuft ja gerade ein riesengroßer “Sichtungsprozess” an:
Mit Freigabe der Bing-Luftbilder wird verstärkt abgemalt.
Aber nicht nur neues wie bei mir gleistreue Bahnanlagen, Wenn
die Geometrie nicht passt und es nicht am verschobenen Luftbild
liegt, dann rückt man ja auch die nähere Umgebung zurecht (ich jedenfalls),
damit die Bahnbrücke zur Straße drunter passt und nicht alles krumm
und schief aussieht.
Diese Daten sind damit zumindestens “geometrisch frisch gesichtet”.
Aber mit der derzeitigen Technik eben nur, wenn der node dabei wenigstens
ein bisschen verschoben wurde. Passt das drumrum dagegen gut, dann
habe ich das für mich zwar festgestellt, konnte diese Erkenntnis an den
Daten aber nicht anbringen.

Inwieweit der laufende Betrieb ein Flaschenhals sein kann,
muss noch ein Fachmann bzgl. API beurteilen.
Sprich ob das Einarbeiten des Lizenzstatus und der Version aus den
Changesets mit und ohne Sichtung, mit Splits/Joins, … mit oder
ohne Tipps durch den Editor (“habe Weg x geesplittet in …”)
kontinuierlich beim Hochladen erfolgen kann oder ob da ein Prozess
nachgeschaltet werden muss (ähnlich wie das neurendern von
Mapnik-Kacheln ja auch abgetrennt vom Hochladen läuft)
und ob das lizenzgenaue Abrufen möglich ist und wenn ja,
in welcher Detailliertheit bzgl. der Lizenz und evtl. Graduierungen.

Werde einen Crosspost über die div. Kommunikationskanäle machen:
talk-de, Forum und Wiki in meiner Sprache deutsch, mindestens
talk-legal und Wiki auch mit dem Versuch einer leicht gerupften
englischen Version. Möge es so die richtigen Leute erreichen,
ggfs. durch weiterreichen an die richtigen Stellen.

http://lists.openstreetmap.org/pipermail/legal-talk/2010-December/005542.html legal-talk
http://lists.openstreetmap.org/pipermail/talk-de/2010-December/080718.html talk-de
http://wiki.openstreetmap.org/wiki/Talk:ODbL/Upcoming#licence_change_without_data_loss_.2B_better_version_control_.2B_flagged_revisions Wiki

Chapeau Mueck, das war mal ein wirklich konstruktiver Beitrag, möge er viele OSMler erreichen, die an einer vorwärtsweisenden Lösung arbeiten

Michelwald

An sich sehr konstruktiver Beitrag, ich sehe da nur ein Problem: Du schlägst vor, CC und Odbl-Daten in einer Datenbank weiter zu halten. Zumindest die Odbl erfordert aber, dass in so einem Fall die gesamte Datenbank unter Odbl veröffentlicht werden muss. Das ist aber ja mit der CC nicht vereinbar. Auch bin ich eher skeptisch, ob juristisch diese 90%-Odbl Geschichten standhalten können.

Darin sehe ich eigentlich kein Problem. Die Daten sollten vorerst solange einfach alle noch die alte Lizenz haben, genau so wie es jetzt auch ist. Die Zusatzinformation bezüglich der neuen Lizenz wäre dann in der Datenbank selber das Signal, ob das Objekt schon bereit wäre für eine löschungsfreie Umstellung. Zusätzlich könnte man wohl auch schon aus den 100% Odbl- Daten einen eigenen Extrakt erzeugen, der auch schon zwischenzeitlich in der neuen Lizenz zur Verfügung gestellt werden kann.

Es würde damit hoffentlich recht bald umfangreiche Gebiete als 100% Odbl-ready vorliegen, bzw. im Odbl-Extrakt vollständig aufgenommen sein.

Irgendwann mal würde dann doch noch den Schritt der endgültigen Umstellung machen, ab dem nur noch 100%Odbl in der Datenbank belassen wird und mit der Odbl Lizenz relizenziert wird. Das würde dann aber Otto Normalmapper kaum merken, da sich (beinahe) nichts an den Daten ändert.

Mir erscheint für einen erfolgreichen Lizenzwechsel wichtig, dass relativ schnell edits nur noch als Odbl-ready durchgeführt werden dürfen. (Der OSM-Vorstand dürfte das wohl mit dem vorgegebenen Datum wohl auch so sehen) Ab dem Punkt weg wird man sich nur noch in Richtung 100% Odbl bewegen können. Ab dem Punkt weg hoffe ich aber auf einen möglichst lange Übergangszeit bis zum endgültigen Schnitt der Umstellung von allem auf Odbl. Wirkliche Eile ab dem Punkt würde ich nur dann geboten sehen wenn wirklich jemand die Schwächen der CC Lizenz ausnützen würde und die Daten “stehlen” würde. Das ist aber bisher nicht geschehen und wird hoffentlich auch zukünftig nicht geschehen.

Markus

PS: Als Wunsch ans Christkind würde ich mir dann noch eine geregelte Informationspolitik über die Vorgehensweisen der Lizenzumstellung wünschen.

Gute und wohlüberlegte Vorschläge. Besonders das Sichten fand ich sehr gut und realisierbar.

Hoffe, dass sich das durchsetzt. Vielleicht kommt jetzt bald die Ankündigung: „Das hatten wir doch eh so vor, waren aber über die Details noch nicht ganz einig."

Interessanter Einwurf, nicht in erster Linie wegen des Inhalts des Einwurfs, sondern weil es mihc daran erinnert hat, dass ja WIR die ODBL geschaffen haben (genauer die von der OSMF (als vertreter der communitiy) beauftragten Experten).
Auch wenn die ODBL womöglich durchaus ein gewisses Eigenleben entwickelte …
WIR könnten daher solche eventuellen Probleme auch umschreiben, wenn es wirklich relvante Probleme wären …

Die Frage, ab wann ein Ex-CC-Datensatz ein ODBL-Datensatz hat, wenn mehrere dran rumwerkelten, die unterschiedlichen Lizenzstatus haben, wird uns sowieso begegnen, auch beim absoluten switch, wie bisher geplant. Auch da muss eine Grenze gesetzt werden, damit nicht ein einzelner node von 1000 zum Problem wird für den ganzen way …

An vorderster Front findet ja zumindestens Frederik schon reihenweise Haare in der Suppe in der Mailingliste talk-de …

Nun diese Haare kann er ja, falls derart störend, über Lizenzanpassungen herausfischen; Ich sehe keine Konflikte mit den anvisierten Zielen.

i++

Wäre es nicht einfacher, eine zweite Datenbank aufzusetzen, in der nur die ODbL-Daten enthalten wären?
Stand heute würden alle Daten weiter in die alte (CC-) Datenbank gemappt und dort verbleiben und nur die ODbL-Daten auch in die neue Datenbank übertragen. Man könnte dann einen transparenten Vergleich wie bei http://sautter.com/map/ einführen. Jeder könnte das Wachstum der Lizenwechsel-Datenbank verfolgen und zum Umstellungszeitpunkt wüßte man, was neu zu erfassen wäre. Bis dahin läßt sich vielleicht der ein oder andere doch noch umstimmen. Ich sehe die Lizenzvereinbarung als einen Vertrag zwischen mir und der OSMF. Wenn diese den Vertrag kündigt (Lizenzwechsel) kann ich mich auch nicht mehr beschwerden, wenn die CC-Daten nicht mehr veröffentlicht werden. Nach der Umstellung könnte die OSMF wiederum den Ablehnern eine gewisse Zeit für die Zustimmung geben und bei Zustimmung eine Übertragung der Daten aus der CC-Datenbank in die ODbL-Datenbank vornehmen. Wird diese Frist nicht eingehalten, könnten die Daten (in der ODbL-Datenbank) neu erfasst werden.

Aber auch typische “Oppositions-Politiker-Vorschläge” in meinen Augen. Klingen sehr gut, weil sie sich nicht um die Umsetzbarkeit kümmern müssen.

Die vorliegenden Vorschläge beruhen auf zwei sehr wackeligen Standbeinen:

  • Dass es genug Entwickler-Ressourcen gibt, um die beschriebenen Tools (die unbestritten gut wären, wenn man sie hätte) zu schreiben.
  • Dass eine Rechte-Aneignung per “hätte ich auch so gemacht” - das sogenannte Sichten - tragfähig ist.
    Ich habe an beidem Zweifel.

Ansonsten gibt es noch ein paar Detailprobleme, die ich für sich genommen nicht mal so schwerwiegend fände. Beispielsweise stimmt der behauptete Vorteil “schneller besserer Schutz” nicht. Denn jeglicher besserer Schutz durch die ODbL tritt nicht etwa schon mit Beginn einer Doppellizenzierung ein, sondern erst dann, wenn die Veröffentlichung nur noch ausschließlich unter ODbL stattfindet - also erst dann, wenn der ganze Lizenzwechsel erledigt ist. Und dass sich der Lizenzwechsel mit seinem Vorschlag noch länger hinziehen wird, hat Mueck ja selber zugegeben.

Ich denke über so einen “History Viewer” nach, habe aber noch nichts programmiert. Mir geht es zwar nicht um die Lizenz, aber Ziele und Funktionsweise sind sonst recht ähnlich. Wenn also jemand was in der Art plant oder schon daran arbeitet, dann wäre auch ich über eine Info erfreut.

BTW, beim nächsten Endlospost wäre eine Zusammenfassung ganz hilfreich :slight_smile:

Du hast Recht, eigentlich erwartet die Community von der “Regierung” einen solchen Vorschlag, bzw. eine Konkretisierung hinschtlich der Umsetzung. Von deren Mitgliedern läßt sich aber leider niemand blicken, bzw. hüllen sich in Schweigen. Es fragt auch niemand um Hilfe. Also scheint das Vorgehen klar zu sein. Die ganze Diskussion erfolgt hier nur innerhalb der gespaltenen Community und beruht wohl mehr oder weniger auf Mutmaßungen. Wenn an konstruktiven Lösungen kein Bedarf besteht, sollen sie nur sagen, zum xx.xx.xxxx wird umgestellt und alle Daten derer, die bis dahin nicht zugestimmt haben, werden gelöscht. Dann wäre mir und vielleicht einigen anderen schon geholfen und man bräuchte sich keine Gedanken mehr darum zu machen.