Vorschlag Regelsatz Lizenzänderung

Es wurde ja schon verschiedentlich über die genau Vorgehensweise der Lizenzumstellung diskutiert. Da aber die LWG sich bis jetzt nicht dazu geäußert hat, ist alles nur Spekulation. Wie Oli-Wan in einem anderen Thread vorgeschlagen hat, wäre es aber unter Umständen sinnvoll, die LWG diesbezüglich zu unterstützen, weshalb ich vorschlage, zunächst hier, eventuell später auch im Wiki, eine geeignete Vorgehensweise zu entwickeln und dann an die LWG weiterzuleiten.

Ich mache mal einen Anfang, damit wir was zum Diskutieren haben (basierend teilweise auf der Bacherlorarbeit von JakobA. Auch FK270673 hat sich schon zum Thema geäußert):


Markiere alle Changesets von Zustimmern (sowie evtl. von Ablehnern mit PD, bekannten Botaccounts, etc.) als "gut"
Markiere alle Changesets mit bot=yes als "gut"
Markiere alle anderen Changesets als "schlecht"

Nodes:
    -> setze aktuellen Stand auf leer (keine Tags, keine Koordinaten)
    -> für jedes Changeset, angefangen beim Ersten in aufsteigender Reihenfolge
        -> Changeset schlecht
            -> behalte bisherigen Tag-Zustand bei
            (-> wende als nicht-schützenswert beurteilte Tag-Änderungen an)*1
            -> Koordinaten geändert
                -> setze neue Koordinaten als schlechte Koordinaten, behalte eventuelle gute Koordinaten bei
        -> Changeset gut
            -> wende alle Tag-Änderungen auf den bisherigen Tag-Zustand an
            -> Koordinaten geändert
                -> keine schlechten Koordinaten vorhanden oder neue Koordinaten weiter als 1m*2 davon entfernt
                    -> lösche eventuell vorhandene schlechte Koordinaten
                    -> setze gute Koordinaten auf neue Koordinaten
                -> ansonsten
                    -> setze schlechte Koordinaten auf neue Koordinaten

    -> keine guten Koordinaten vorhanden
        -> Node löschen
    -> setze Koordinaten auf aktuelle gute Koordinaten

Wege:
    -> erstes Changeset schlecht
        -> Weg löschen
    -> setze aktuellen Stand auf Stand des ersten Changesets
    -> für jedes Changeset, angefangen beim Zweiten, in aufsteigender Reihenfolge
        -> Changeset schlecht
            -> behalte bisherigen Tag-Zustand bei
            (-> wende als nicht-schützenswert beurteilte Tag-Änderungen an)*1
            -> behalte bisherigen Knoten-Zustand bei
        -> Changeset gut
            -> wende alle Tag-Änderungen auf den bisherigen Tag-Zustand an
            -> wende alle Knoten-Änderungen auf den bisherigen Knoten-Zustand an
    -> entferne alle gelöschten Knoten
    -> kein Knoten mehr vorhanden
        -> Weg löschen
    -> nur noch ein Knoten vorhanden
        -> Hinweisattribut setzen

Nodes:
    -> Keine Tags und nicht Mitglied eines Weges
        -> Node löschen

Relationen:
    -> erstes Changeset schlecht
        -> Relation löschen
    -> setze aktuellen Stand auf Stand des ersten Changesets
    -> für jedes Changeset, angefangen beim Zweiten, in aufsteigender Reihenfolge
        -> Changeset schlecht
            -> behalte bisherigen Tag-Zustand bei
            (-> wende als nicht-schützenswert beurteilte Tag-Änderungen an)*1
            -> behalte bisherigen Mitglieder-Zustand bei
        -> Changeset gut
            -> wende alle Tag-Änderungen auf den bisherigen Tag-Zustand an
            -> wende alle Mitglieder-Änderungen auf den bisherigen Mitglieder-Zustand an
    -> entferne alle gelöschten Mitglieder
    -> keine Mitglieder mehr vorhanden
        -> Relation löschen


*1 Tag-Änderungen könnten als nicht-schützenswert beurteilt werden, bspw. hghway->highway
*2 Schwelle, um Minimalverschiebungen zur "Rettung" von Objekten auszuschließen, kann auch anders definiert werden

Punkte mit Unterpunkten sind als Bedingungen zu sehen, unter denen die Unterpunkte durchgeführt werden. Die letzte Aktion muss eventuell mehrfach durchgeführt werden, das Relationen ja auch Mitglieder von Relationen sein können. Nicht berücksichtigt werden Splits und Vereinigungen und evtl. weitere komplexe Aktionen, darüber sollte noch genauer diskutiert werden. Wie genau mit Tag-Änderungen sowie Knoten- und Mitgliederänderungen sollte ebenfalls noch genauer diskutiert werden.

Erstmal Danke für die Arbeit.
Wenn sich sonst keiner äußert gebe ich mal meinen Kommentar dazu ab, auch wenn der vielleicht nicht sehr sachkundig ist :wink:

Mir ist der Punkt


-> ansonsten
    -> setze schlechte Koordinaten auf neue Koordinaten

bei Abarbeitung von Nodes nicht klar. Müssten hier nicht die Wörter “schlecht” und “neu” vertauscht werden?

Vielleicht kannst du für die Punkte, bei denen du geschrieben hast, sie müssten genauer diskutiert werden, auch gleich konkrete Vorschläge in deinem Algorithmus machen? Sorry, will nicht die ganze Arbeit auf dich abwälzen, aber du bist gedanklich ja schon sehr stark in der Thematik und kennst vermutlich Fallstricke besser als manch anderer …

Ok, ist vielleicht nicht ganz klar, aber das ist teilweise aus meiner Programmierersicht auf das Problem entstanden: Ich sehe eine Variable “schlechte Koordinaten” die die (im Sinne der Abarbeitung der Changesets) aktuellen nicht für die Relizensierung geeigneten Koordinaten enthält und die in diesem Schritt mit den Koordinaten gefüllt wird, die das aktuelle Changeset vorsieht. Also im Sinne von $schlechte_koordinaten=$neue_koordinaten; Verstanden?^^

Über Splits und Vereinigungen habe ich mir zwar schon Gedanken gemacht, bin mir aber bis jetzt noch nicht darüber klar, wie man das tatsächlich in den Prozess einbauen kann. Ich hoffe da auf jemanden mit einer guten Idee :wink: Bei den Sachen mit den Änderungen und wie genau sie gehandhabt werden sollen, geht es mehr um Implementierungsdetails, die man denke ich zu einem späteren Zeitpunkt präzisieren sollte.

Jo is klar. Hab’s genau andersherum gelesen, deswegen die Verwirrung.

Wie erkennt man die überhaupt in der Datenbank?

Gruß BBO

100%ig kann man sie natürlich nicht erkennen. Folgendes sollte allerdings halbwegs befriedigende Ergebnisse liefern (Beispiel für Split):

In einem Changeset wurde ein Weg angelegt.
In diesem Changeset wurde ein vorher bereits bestehender Weg bearbeitet und dabei wurden Nodes aus ihm entfernt.
Zumindest Teile dieser Nodes befinden sich im neuen Weg.

Je nach dem welche Genauigkeit man an einzelne Teile anlegt (z.B. darf der neue Weg auch neue Nodes erhalten, müssen die alten Nodes in der gleichen Reihenfolge vorliegen, etc.) lässt sich entweder der Fehler 1. oder 2. Art auf Kosten des anderen minimieren.

zu den Nodes müsste es IMHO eine weitere Anweisung geben:
Wenn ein Knoten um mehr als x Meter ( x z.B 10, entspricht einer mittelmäßigen GPS Lokalisierung ) verschoben wurde,
dann entsteht dadurch ein neuer Knoten, die davor liegende Historie bleibt unberücksichtigt.

Begründung:
das einzig wertvolle an einen Node sind seine Koordinaten, wenn die “signifikant” geändert wurden entsteht quasi ein neuer Knoten.

Hmm, wenn ich recht darüber nachdenke, sollte es möglich sein, den Schritt
→ erstes Changeset schlecht
→ Node nicht Mitglied eines Weges
→ Node löschen
auszulassen, ohne das Probleme entstehen, weil alle möglichen Probleme durch die weiteren Schritte addressiert werden. Kann das jemand verifizieren? Wenn man diesen Schritt auslässt, sollte deiner Anmerkung (die größtenteils richtig ist) genüge getan sein.

EDIT: Ich habe das mal getan. Für an der Diskussion interessierte, die neu dazukommen: Das hier erwähnte war als erster Schritt der Prüfung der Nodes gedacht.

Damit folgt folgendes: Ein Node bleibt genau dann erhalten (aber eventuell mit anderen Informationen als bisher), wenn folgendes gilt: Das Changeset, in dem er angelegt wurde ist gut ODER das Changeset, in dem er angelegt wurde ist schlecht, aber sowohl wurden in guten Changesets seine Koordinaten substanziell verändert (mindestens einmal um mehr als 1m (siehe auch *2) sowie er hat mindestens einen Tag in einem guten Changeset erhalten.

Vieleicht habe ich es übersehen, aber mir ist eine grundlegendes Problem noch nicht klar:
Die meisten Nodes haben nur Koordinaten und keine Tags. Jede Änderung der Koordinaten betrachte ich als neuen Node (auch wenn eine alte ID “wiederverwendet” wird).
Ein Node sollte am Ende die Koordinaten haben, die zuletzt von einem Zustimmer gesetzt wurden. Die restliche History (wer ihn angelegt oder geändert hat) ist in meinen Augen irrelevant.

Bei Tags müsste man einfach alle Änderungen von nicht-Zustimmern ignorieren.

Viele Grüsse

mdk

Mehr oder weniger wird das getan. Nur kann ich dir nicht ganz Recht geben, denn wenn man bei jeder Koordinatenänderung von einem neuen Node ausgeht, würde es genügen, alle Nodes des Planeten jetzt um einen cm nach Westen zu verschieben und schon wären alle Nodes gerettet. Meiner Meinung nach muss die Verschiebung groß genug sein, dass man ernsthaft behaupten kann, dass sie nicht nennenswert durch die vorherige Position beeinflusst ist.

Wenn man Nodes mit neuer ID als sauber betrachtet, dann genügt es, einen Weg mit seinen Nodes zu kopieren und das Original zu löschen, schon sind alle Nodes gerettet. Was ich sagen will: Man kann absichtliche Urheberrechts-Aneignungen nicht zuverlässig automatisch erkennen.

Sollte ein ungetaggter Node im Verlauf einer normalen Bearbeitung (z.B. beim Anpassen des Straßenverlaufs an einen eigenen GPS-Track oder ein Luftbild) verschoben werden, dann ist tatsächlich die ID das Einzige, das vom vorherigen Zustand noch übrig ist. Und da die nicht vom Bearbeiter selbst gewählt wird, kann sie nicht Grundlage eines Urheberrechtsanspruches sein.

Ein häufiges Beispiel sind hier wohl Löschungen von created_by-Tags.

Zur Frage, ob ein verschobener Knoten als neu betrachtet werden kann, gab es auf der Legal-Mailingliste eine längere Diskussion. Solche Grundsatzfragen müssten von der LWG entschieden werden, daher würde ich empfehlen, diese Annahmen getrennt von deinem Algorithmus aufzulisten.

Wenn wir überkorrekt sein wollen, brauchen wir dann überhaupt das komplexe Regelwerk? Wäre es nicht möglich, alle Changesets in gut (Zustimmer + Bots) und schlecht (Nicht-Zustimmer) einzuteilen, mit einer leeren Datenbank zu beginnen und dann in der ursprünglichen Reihenfolge alle guten Changesets einzuspielen? Änderungen, die sich auf nicht vorhandene Objekte beziehen, weil das entsprechende Objekt in einem schlechten Changeset angelegt wurde, werden einfach ignoriert. Bei dieser Methode werden auch Weg-Splits berücksichtigt, da der ursprüngliche Weg gar nicht vorhanden ist, wenn er von einem Nicht-Zustimmer stammt; der Split kann somit nicht durchgeführt werden. Mir ist aber nicht klar, ob das praktikabel ist. Möglicherweise sind alte Changesets aufgrund der späteren API-Änderungen nur mit gewaltigem Aufwand nachzuvollziehen.

@Tordanik: Das ist natürlich korrekt, insofern kann man sich da nur darauf verlassen, das das keiner macht. Trotzdem ist die Frage, ob man einen nur leicht verschobenen Node nicht als abgeleitet betrachten sollte. Aber MetiorErgoSum scheint mir Recht zu haben, das ist eine Grundsatzfrage, die man unabhängig davon klären sollte.

@MetiorErgoSum: Wahrscheinlich könnte man das, ja. Aber es würde auf jeden Fall mehr Verluste bedeuten, wenn man annimmt, dass es möglich ist auch Nodes zu relizensieren, die von einem Nichtzustimmer angelegt wurden. Wie das allerdings mit der Nachvollziehbarkeit der Changesets aussieht, kann ich dir nicht sagen. Für die einzelnen Objekte jedenfalls müsste die Information vorliegen.

Die gleichbleibende ID weisst aber zweifelsfrei nach, dass beim Verschieben auf CC-by-SA-Daten aufgesetzt wurde. Man macht sich also grundsaetzlich angreifbar, wenn man das verschobene Objekt unter einer anderen Lizenz frei gibt.

Ausserdem stammen vom ursprünglichen Ersteller ja nicht nur die Koordinaten, sondern auch die Information, zu welchem Weg der Knoten mit dazu gehoert. (Mir ist die Notation von errt hier nicht ganz klar:) Wuerde das Bedeuten, dass nach deiner Ansicht dann der verschobene Knoten ueberleben sollte aber nicht mehr Teil des Weges waere?

Gruss
Torsten

Ein Knoten hat keine Information, zu welchem Weg er gehört. Knoten würden meinem Vorschlag entsprechend gelöscht, wenn sie zu einem Weg gehören, der gelöscht werden muss und keine Tags, die relizensiert werden können, tragen. Tragen sie solche Tags, bleiben sie erhalten, auch wenn der Weg natürlich nichtmehr da ist. Wird der Weg nicht gelöscht, bleibt der Knoten erhalten und Teil des Weges, wenn das Changeset, das den Knoten zu dem Weg hinzufügt relizensierbar ist oder eben nicht, wenn das entsprechende Changeset schlecht ist (in diesem Fall gilt das oben gesagte: Wenn relizensierbare Tags da sind, bleibt der Knoten erhalten, ansonsten wird er gelöscht).

Und ich glaube nicht, dass man ab einer gewissen Verschiebung vom Aufsetzen (=Ableiten) von CC-by-sa Daten sprechen kann. Wenn ich einen Knoten entsprechend bspw. eines Luftbildes verschiebe, nehme ich ja nur den, weil er gerade da ist und würde einen neuen erstellen, wenn es ihn nicht gäbe. Außer der ID hat der Knoten danach ja nichtsmehr mit dem alten gemein (vorausgesetzt, er hat keine Tags - aber die fallen ja weg, wenn sie nicht relizensierbar sind).

Ich probiere es mal anhand des Beispiels zu sortieren.

In dem angenommenen Fall sieht es wie folgt aus:

  1. ein Nichtzustimmer hat den Knoten ohne weitere Tags erzeugt und einem Weg zugefuegt
  2. ein Zustimmer hat den Wegverlauf korregiert und dabei den Knoten verschoben aber am Knoten keien Tags hinzugefuegt

Wenn ich dich richtig verstehe, geht in so einem Fall der Knoten verloren, unabhaengig davon, wie man die Vershciebung selber bewertet.

Rein faktisch bleibt es aber eine Ableitung. Was jemand selber haette tun koennen, ist dabei doch nicht relevant. Es zaehlt nur, was jemand getan hat (oder genauer: was man nachweisen kann, dass es jemand getan hat).
Darum dreht sich doch auch momentan die Diskussion, ob ein spaeter Uebergang zur Phase 5 nicht schaedlich ist, da man jetzt vielleicht aus Unwissenheit/Unachtsamkeit Aenderungen an CC-by-SA-Daten vornimmt, die nach einem Lizenzwechsel sowieso wieder wegfallen werden.

Gruss
Torsten

Wenn der Knoten zu keinem weiteren Weg gehört, geht der Knoten in diesem Fall verloren, ja. Denn er gehört dem Weg ja hinterher nichtmehr an (weil die Aktion des hinzufügens nicht relizensiert werden kann) und ein Node ohne Tags und Weg macht keinen Sinn. Allerdings macht es vielleicht Sinn, über diesen Fall noch genauer zu diskutieren, denn wenn man annimmt, dass beim Verschieben (mal abgesehen von den Tags) praktisch ein neuer Knoten entsteht, könnte man ihn ja im Weg lassen und behalten.

Ich glaube nicht, dass man da von einer Ableitung ausgehen muss. Sicher ist es der Fall, dass der Node vorher schon da war, aber darum geht es dabei ja nicht. Eine Ableitung liegt ja nur dann vor, wenn jemand geschützte Daten eines anderen verwendet und darauf aufbauend ein Werk erzeugt. Die Existenz des Knotens ist aber ja nicht schützenswert, sondern nur seine Lage und seine Tags. Wenn er keine Tags hat und ich die Lage in einer Weise verändere, die mit der ursprünglichen nichts zu tun hat, dann erzeuge ich ein neues Werk. Das ist wie, wenn ich mir die Noten für eine Bach-Kantate kaufe, die einzelnen Notensymbole ausschneide und in einer Weise auf Notenlinien klebe, die mit dem ursprünglichen Werk nichts zu tun hat. Zumindest ist das meine Meinung, höchstens ein Jurist kann das mit größerer Sicherheit klarstellen. Aber ich denke, das das ausreicht, um keine rechtlichen Probleme fürchten zu müssen.

Was ist, wenn jemand die Position eines Knotens (z.B. ein Berggipfel, eine Telefonzelle oder Ähnliches) selbst nachmisst und anschließend neu lizenziert? Dann wäre nicht einmal eine Verschiebung des Knotens notwendig, sondern lediglich ein Flag mit der Aussage “Ich habe diese Information neu ermittelt und kann bestätigen, dass sie mit der alten Information identisch ist.”.

Du kannst unter CC-BY-SA erstellte Dinge nicht neulizensieren du leitest immer ab. Das ist auch das Hauptproblem bei Verschiebungen. Jeder Knoten der Verschoben wird, jedes Gebäude das nach Sattelitenbildern neu angepassßt wird ist in der Wurzel CC-BY-SA und wird trotz gleichen Aufwandes wie neuanlegen nur das alte Objekt an neuer Position bleiben. Also muss es gelöscht und neuerstellt werden. So auch mit der Telefonzelle. Es reicht nicht zu wissen, dass die Telefonzelle wirklich da ist. Die alte Zelle muss gelöscht werden und die neue eingezeichnet.

@Marqqs: Du kannst den Knoten in diesem Fall problemlos löschen und einen neuen erzeugen.

@viw: Wie ich oben bereits dargelegt habe, bin ich der Meinung, dass bei einer ausreichenden Verschiebung davon ausgegangen werden kann, dass es sich nicht um eine Ableitung handelt. Natürlich nur was die Koordinaten angeht, die Tags müssen unter Umständen trotzdem weg.