@OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

mtb · 2012-01-13 21:13:31

Ich bin doch schon negativ überrascht, dass ein Weg wie dieser http://www.openstreetmap.org/browse/way/26982844 in OSMI rot markiert ist, also als nicht ODBL-kompatibel angesehen wird.
http://tools.geofabrik.de/osmi/?view=wt … ne_created

In der Deep Diff http://osm.mapki.com/history/way.php?id=26982844 sieht man, dass von den 23 Versionen 20 von Zustimmern kommen, nur die Versionen 1, 2 und 19 kommen von Unentschiedenen. Der Ersteller des Weges war insgesamt eine Woche für OSM aktiv - und zwar im September 2008. Der erinnert sich vermutlich kaum noch an OSM - und schon gar nicht an den Namen der Lizenz, die er damals bei der Anmeldung akzeptiert hat.

Man kann bei diesem Beispiel auch nun wirklich nicht mehr davon sprechen, dass der Weg von einem oder mehreren Nicht-Zustimmern 'abstammt', dafür gab es im Laufe der Zeit viel zu viele Änderungen von Zustimmern (auch bzgl. der Knoten)!

Ich würde erwarten - und möchte hiermit von der OSMF fordern - , dass so ein Weg ohne Wenn und Aber nach OSM-ODBL übernommen wird. Es darf nicht wahr sein, dass solche Objekte bei ODBL wegfallen! Lächerlich, anzunehmen, dass sich hier einer der Unetschiedenen zu Recht beschweren könnte oder irgendeine Erfolgsaussicht bei einer Klage gegen die OSMF hätte!

Also: nicht so zögerlich, OSMF! Denkt daran, dass ihr vielen (noch) halbwegs motivierten Zustimmern, von denen ihr ein O.k. zu ODBL/CT gefordert habt, (moralisch) schuldig seid, deren Motivation zu erhalten! Anstatt zu erwarten, dass massenweise Remapping-Aktionen laufen! (ich könnte diesen Weg schnell mit odbl:clean taggen, kenne in der Gegend jeden Trampelpfad. Aber es gibt vermutlich Zigtausende solche und ähnliche Fälle).

Bin jedenfalls der Meinung, dass viel zu viel als Nicht-ODBL-kompatibel angesehen wird. Oder sind die Übernahmeregeln noch gar nicht offiziell und die Rotfärbungen in der OSMI-Karte sind nur ein 'best guess', was denn wegfallen könnte?

Gruß, mtb

scai · 2012-01-13 21:34:50

mtb wrote:

Oder sind die Übernahmeregeln noch gar nicht offiziell und die Rotfärbungen in der OSMI-Karte sind nur ein 'best guess', was denn wegfallen könnte?

Genau so ist es, es gibt noch keine offiziellen Richtlinien. Die Tools (OSMI, Clean-/Badmap etc.) zeigen daher momentan wirklich nur den 'best guess' an.

Ansonsten stimme ich dir jedoch zu, der genannte Beispielweg (und folglich auch viele andere) enthalten vernachlässigbar wenig Daten von Nichtzustimmern, so dass eine Übernahme eigentlich möglich sein sollte.

Mondschein · 2012-01-13 21:45:02

mtb wrote:

Oder sind die Übernahmeregeln noch gar nicht offiziell

Es gibt noch keinen Beschluss und die Regeln sind auch noch nicht fertig ausgearbeitet.
Diese werden, wenn ich die Aussagen der LWG richtig in Erinnerung habe, auch nicht von heute auf morgen einfach beschlossen.
Die LWG hat auf der Mailingliste um Hilfe bei der Ausarbeitung der Regeln gebeten.
Frederik trägt hier derzeit viel dazu bei und fragt auch ab und zu mal die LWG nach ihrer Meinung zu einzelnen Regeln.

mtb wrote:

die Rotfärbungen in der OSMI-Karte sind nur ein 'best guess', was denn wegfallen könnte?

Das ist ein Vorschlag, wie denn die Regeln aussehen könnten, diese werden laufend ergänzt, so dass in der Vergangenheit immer weniger Daten als problematisch eingestuft wurden.
Die LWG kann diese Regeln einfach übernehmen oder abändern/ergänzen (und theoretisch auch komplett neue Regeln erfinden).
Wahrscheinlich wird die LWG sich stark an diesen Vorschlägen orientieren.

Jeder der sinnvolle Algorithmen beitragen kann, darf diese z.B. auf legal-talk (und evtl. rebuild) zur Diskussion stellen.

Gruß,
Mondschein

Last edited by Mondschein (2012-01-13 21:48:15)

aighes · 2012-01-13 21:49:26

Und daher gibt es (wahrscheinlich) für solche Fälle ein odbl=clean. Sowas per Algorithmus herauszufiltern würde ich mal als nahezu unmöglich beschreiben. Als Mapper sollte man sich aber über die Folgen von odbl=clean im Klaren sein.

FK270673 · 2012-01-13 21:55:57

mtb wrote:

Ich bin doch schon negativ überrascht, dass ein Weg wie dieser http://www.openstreetmap.org/browse/way/26982844 in OSMI rot markiert ist, also als nicht ODBL-kompatibel angesehen wird.
http://tools.geofabrik.de/osmi/?view=wt … ne_created

Dasselbe Problem habe ich hier: http://osm.mapki.com/history/way.php?id=4952646
und hier: http://osm.mapki.com/history/way.php?id=10857036

Das ist ein Logikfehler im OSM-Inspektor.

Die Knotenpunkte dieses Weges tragen noch die Nummer, die vom Erstersteller vergeben wurde, befinden sich aber auf der Position, die von einem späteren Bearbeiter festgelegt wurde. Eigentlich ein klarer Fall für odbl=clean, weil kein "schmutziger" Knoten enthalten ist und alle Daten von Zustimmern ergänzt wurden.

Jetzt wird Frederik vielleicht einwenden, dass die Berechnuing des Lizenzstatus bei verschobenen Punkten mehr Rechenzeit benötigt und der Mehrverbrauch an Strom für die zusätzliche Rechenleistung die Versorgungssicherheit in Süddeutschland gefährdet. Da ist es doch einfacher, odbl=clean zu ergänzen, als die Verantwortung für einen Blackout in Süddeutschland zu übernehmen.

Gruß FK270673

aighes · 2012-01-13 22:07:52

Aber wie willst du Fälle rausfiltern, bei denen dei Weginformationen abgeleitet sind?
Bspw. ändert es ja nichts an dem Lizenzstatus, wenn ich einfach alle rote Nodes mit neuen ersetze, da ich die Position ja auf den roten Daten abgeleitet habe. Gleiches gilt ja wohl für den Fall, dass ich sie etwas daneben setze. Jeweils ohne eine andere Quelle zu nutzen, als die vorhandenen Daten.

Mondschein · 2012-01-13 22:14:42

FK270673 wrote:

Die Knotenpunkte dieses Weges tragen noch die Nummer, die vom Erstersteller vergeben wurde, befinden sich aber auf der Position, die von einem späteren Bearbeiter festgelegt wurde.

Richtig, deswegen werden alle Knoten der beiden von dir genannten Wege als "clean" markiert.

FK270673 wrote:

Jetzt wird Frederik vielleicht einwenden, dass die Berechnuing des Lizenzstatus bei verschobenen Punkten mehr Rechenzeit benötigt und der Mehrverbrauch an Strom für die zusätzliche Rechenleistung die Versorgungssicherheit in Süddeutschland gefährdet.

Frederik erkennt diese Knoten schon als "clean" an, siehe deine beiden genanneten Wege:
http://tools.geofabrik.de/osmi/?view=wt … ne_created
http://tools.geofabrik.de/osmi/?view=wt … ne_created

Oder was willst du damit sagen?

Gruß,
Mondschein

mtb · 2012-01-13 22:14:50

aighes wrote:

....Sowas per Algorithmus herauszufiltern würde ich mal als nahezu unmöglich beschreiben.

Ich nicht. Wie wär's mit folgender einfachen (d.h. leicht programmierbaren) Regel:
WENN mehr als 2 Drittel der Versionen eines Weges von Zustimmern stammen UND keine einzige Version des Weges von einem Ablehner editiert wurde UND kein Ablehner an irgendeinem Knoten des Weges beteiligt war => DANN ODBL-kompatibel.

Nur so als Beispiel. Man muss IMO ganz klar zwischen Ablehnern und Unentschiedenen unterscheiden (was ein vertretbares 'Risiko' aus Sicht der OSMF darstellt), sonst bekommt man mit dem besten Regelwerk "zu viele" nicht-ODBL-kompatible Objekte, behaupte ich.

Last edited by mtb (2012-01-13 22:15:16)

Mondschein · 2012-01-13 22:18:54

FK270673 wrote:

Das ist ein Logikfehler im OSM-Inspektor.

Also fehlt in etwa so eine Regel:
Wenn alle Knoten eines Weges "clean" und alle Tags eines Weges "clean", dann ist der Weg "clean".
(Auch dann wenn der Weg ursprünglich von einem Nicht-Zustimmer erstellt wurde, aber in der aktuellen Version nur noch die Datenbank-Weg-ID übrig ist.)

Gruß,
Mondschein

Last edited by Mondschein (2012-01-13 22:20:25)

aighes · 2012-01-13 22:39:31

mtb wrote:

aighes wrote:
....Sowas per Algorithmus herauszufiltern würde ich mal als nahezu unmöglich beschreiben.
Ich nicht. Wie wär's mit folgender einfachen (d.h. leicht programmierbaren) Regel:
WENN mehr als 2 Drittel der Versionen eines Weges von Zustimmern stammen UND keine einzige Version des Weges von einem Ablehner editiert wurde UND kein Ablehner an irgendeinem Knoten des Weges beteiligt war => DANN ODBL-kompatibel.

cc-by-sa schreibt vor, dass wenn man Werke daraus ableitet, diese auch unter der selben Lizenz wieder veröffentlicht werden müssen. D.h. wenn man ein Objekt übernehmen möchte, dass solche Infos beinhaltet, dann muss man sicherstellen, dass in der aktuellen Version keine Informationen enthalten sind, die von "nur-cc-by-sa-Objekten" abgeleitet worden sind.

Wenn ein Ziel des Prozesses ein mehr an Rechtssicherheit für die Datennutzung ist, kann man in dem Prozess nicht irgendwie durch mogeln und raten, ob ein Objekt sauber ist.

Deinen obigen Algorithmus kann jeder der will "knacken". Lade alle Knoten eines Weges, setze an jede Position eines Knotens einen neuen Knoten, lade jeden Knoten einzeln hoch. Nur mal so als Beispiel. "Eleganter" wäre es, wenn man sich um jeden Knoten einen Kreis vorgibt und den neuen Knoten dann zufällig innerhalb des Kreises setzt.

FK270673 · 2012-01-13 22:48:34

Mondschein wrote:

Also fehlt in etwa so eine Regel:
Wenn alle Knoten eines Weges "clean" und alle Tags eines Weges "clean", dann ist der Weg "clean".
(Auch dann wenn der Weg ursprünglich von einem Nicht-Zustimmer erstellt wurde, aber in der aktuellen Version nur noch die Datenbank-Weg-ID übrig ist.)

Genau!

EvanE · 2012-01-14 03:06:11

Die OSMF und LWG wollen eine saubere ODBL Datenbank aufbauen.
Das heißt insbesondere, dass keine Objekte oder Änderungen in diese neue Datenbank kommen, die nicht ODBL-sauber sind. Aus Sicht der OSMF und LWG sind erst einmal nur die Objekte sauber, die ausschließlich von ODBL-Zustimmern erstellt und bearbeitet wurden.

Es macht für die OSMF und LWG keinen Unterschied, ob jemand sich nicht geäußert hat oder aktiv abgelehnt hat. Nur die explizite Zustimmung zählt. Alles andere wäre eine Zwangszustimmung durch Schweigen. Das jedoch ist rechtlich ein gefährliches Pflaster und damit ein sehr dünnes Eis.

Begreift endlich, dass es keinen Sinn macht für die Übernahme von ein paar wenigen Daten die Integrität der gesamten Datenbank aufs Spiel zu setzen. Selbst wenn das im Einzelfall für den einen oder anderen durchaus schmerzhaft sein kann.

Edbert (EvanE)

errt · 2012-01-14 12:44:31

@Edbert: Meine Zustimmung!

@Rest: Nun macht doch mal nicht so nen Wirbel Theoretisch fällt der Weg, der im ersten Post genannt ist, soweit ich das sehe, unter den Punkt, den ich hier bereits angesprochen habe und dem die LWG ja hier (Punkt 7) schon für Nodes mehr oder weniger zugestimmt hat, weshalb man nicht unbedingt davon ausgehen muss, dass dieser Weg wirklich vollständig verschwindet. Leider ist es aber nicht gerade einfach, sowas automatisch festzustellen. Deshalb wäre es für den Anfang sicher gut, wenn man, wie schon erwähnt, odbl=clean setzt. Außerdem sollte man, wenn man über solche Fälle stolpert, diese auf der von mir genannten Wiki-Seite einstellt, damit bei der Diskussion um die endgültigen Umstellungsregelung diese Fälle berücksichtigt werden können. Denn die Regeln für die Umstellung sind noch garnicht festlegt. Zwar gibt es ein paar Einzelfallentscheidungen, was möglich ist und was nicht, aber der große Plan steht noch nichtmal ansatzweise.

EvanE · 2012-01-14 13:49:19

errt wrote:

@Rest: Nun macht doch mal nicht so nen Wirbel Theoretisch fällt der Weg, der im ersten Post genannt ist, soweit ich das sehe, unter den Punkt, den ich hier bereits angesprochen habe und dem die LWG ja hier (Punkt 7) schon für Nodes mehr oder weniger zugestimmt hat, weshalb man nicht unbedingt davon ausgehen muss, dass dieser Weg wirklich vollständig verschwindet. Leider ist es aber nicht gerade einfach, sowas automatisch festzustellen. ...
Denn die Regeln für die Umstellung sind noch garnicht festlegt. Zwar gibt es ein paar Einzelfallentscheidungen, was möglich ist und was nicht, aber der große Plan steht noch nichtmal ansatzweise.

Der große Plan steht schon.
- Alles was nur von Zustimmern bearbeitet wurde ist ODBL-sauber
und wird in die ODBL Datebank übernommen.
- Löschungen von wem auch immer sind ODBL-sauber.
==> Alte, nicht mehr sichtbare Objekte werden nicht wiederhergestellt.
- Es gibt triviale Edits, die man immer behalten kann.
- Knoten ohne Tags werden als System-Aktion betrachtet.
Version 1 = Nichtzustimmer ==> Knoten entfallen
Version n>1 = Zustimmer ==> Knoten bleibt erhalten
- Für alle Objekte gilt:
Version 1 = Zustimmer + Version n>1 = Nicht-Zustimmer
Objekt bleibt erhalten, die Änderungen der Nichtzustimmer
werden jedoch nicht übernommen.
- Importe und automatisierte Edits begründen in der Regel keinen
Anspruch auf Urheberrecht (fehlende Schöpfungshöhe)

Die Frage was als triviale Edits zu betrachten ist, ist bisher nur für einen Fall (Löschen von created_by Taggs) geklärt. Weitere Möglichkeiten (z.B. Werte-Korrekturen) müssen noch entschieden werden.

Während automatisierte Edits relativ klar sind, ist bei Importen die Lizenz des Daten-Urhebers zu beachten. Nur wenn die Lizenz mit ODBL kompatibel ist oder eine explizite Freigabe vorliegt, dürfen die Daten übernommen werden. Gegebenenfalls ist ein Neu-Import vorzuziehen.

Edbert (EvanE)

Last edited by EvanE (2012-01-14 13:49:37)

usm78-gis · 2012-01-14 15:48:38

EvanE wrote:

- Knoten ohne Tags werden als System-Aktion betrachtet.
Version 1 = Nichtzustimmer ==> Knoten entfallen
Version n>1 = Zustimmer ==> Knoten bleibt erhalten

Das heißt, wenn eine OSMF-Hilfskraft die von mir gezeichnete Waldwege (kaum auf Bing erkennbar)
um 1 mm verschiebt, gehören die sofort der OSMF ?
Ein schönes Geschäftsmodell für Geofabrik GmbH und Konsorten !

SimonPoole · 2012-01-14 16:21:14

Man soll ja Trolle nicht füttern, aber da es die Gefahr gibt, dass jemand dich ernst nimmt: Nein der Weg "gehört" immer noch dir.

usm78-gis wrote:

EvanE wrote:
- Knoten ohne Tags werden als System-Aktion betrachtet.
Version 1 = Nichtzustimmer ==> Knoten entfallen
Version n>1 = Zustimmer ==> Knoten bleibt erhalten
Das heißt, wenn eine OSMF-Hilfskraft die von mir gezeichnete Waldwege (kaum auf Bing erkennbar)
um 1 mm verschiebt, gehören die sofort der OSMF ?
Ein schönes Geschäftsmodell für Geofabrik GmbH und Konsorten !

Bikeman2000 · 2012-01-14 17:26:28

usm78-gis wrote:

EvanE wrote:
- Knoten ohne Tags werden als System-Aktion betrachtet.
Version 1 = Nichtzustimmer ==> Knoten entfallen
Version n>1 = Zustimmer ==> Knoten bleibt erhalten
Das heißt, wenn eine OSMF-Hilfskraft die von mir gezeichnete Waldwege (kaum auf Bing erkennbar)
um 1 mm verschiebt, gehören die sofort der OSMF ?
Ein schönes Geschäftsmodell für Geofabrik GmbH und Konsorten !

http://www.openstreetmap.org/?lat=51.23 … 7&layers=M
In Niederkassel habe ich mich zuerst gewundert so wenig auf der Badmap zu sehen ist obwohl ich dort soviele Gebäude angelegt habe (u.a. Feuerwache, Cecilien-Gymnasium)
http://www.openstreetmap.org/user/Bikem … its?page=1

Ein Blick in die History dieser Gebäude hat mir dann einige Fragen beantwortet. Die von mir angelegten Daten hat jemand gelöscht und die neu angelegten Daten kann ich in der Kartendarstellung nicht von meinen unterscheiden.
Vielleicht sind die ein paar Millimeter verschoben oder verzerrt, das kann ich in der Kartendarstellung nicht beurteilen.
Müsste mir die Daten mal in Ruhe anschauen, mit JOSM kenne ich mich nicht mehr so gut aus.

aighes · 2012-01-14 17:32:10

Denkst du, du bist der einzige, der diese Häuser abmalen darf? Und stell dir vor: Wenn du sie perfekt gemappt hast und der andere auch, dann müssen sie sogar an der gleichen Stelle sein.

EvanE · 2012-01-14 17:56:08

Bikeman2000 wrote:

http://www.openstreetmap.org/?lat=51.23 … 7&layers=M
In Niederkassel habe ich mich zuerst gewundert so wenig auf der Badmap zu sehen ist obwohl ich dort soviele Gebäude angelegt habe (u.a. Feuerwache, Cecilien-Gymnasium)
Ein Blick in die History dieser Gebäude hat mir dann einige Fragen beantwortet. Die von mir angelegten Daten hat jemand gelöscht und die neu angelegten Daten kann ich in der Kartendarstellung nicht von meinen unterscheiden.

Es wird einfach Zeit, dass du zustimmst.
Dann hast du diese Probleme schlicht nicht mehr.

SCNR
Edbert (EvanE)

errt · 2012-01-14 17:56:10

Also, ich hab mir mal Testweise ein Gebäude rausgepickt und angeschaut: Die Knotenzahl hat sich gegenüber deiner Version um eins erhöht, die Knotenpositionen, die ich überprüft habe, waren deinen zwar sehr nahe, aber nicht identisch, die Verschiebungen sind unterschiedlich. Ich würde in dem Falle wirklich von neu abgemalten Daten ausgehen, es sieht alles korrekt aus. Ja, das war nur eine Stichprobe von einem Gebäude und wenigen Knoten, aber grundsätzlich sehe ich keinen besonderen Hinweis auf eine Kopie.

EvanE · 2012-01-14 18:01:53

Wegen dem Verschiebenen von Knoten:
Nein ein paar milli- oder zentimeter werden wohl nicht reichen.
Aber bei einer deutlichen Verschiebung um mehr als ein Meter, wird die Regel wohl greifen.

Und um das auch noch einmal klar zu machen:
Es geht bei dieser Regel nur um Knoten ohne Taggs, also rein mit Koordinaten.
Ein Weg, der solch einen Knoten enthält oder gar nur aus solchen bewegten Knoten besteht, ist davon in seinem ODBL-Status nicht betroffen.

Edbert (EvanE)

quasilotte · 2012-01-14 18:10:50

Bikeman2000 wrote:

Ein Blick in die History dieser Gebäude hat mir dann einige Fragen beantwortet. Die von mir angelegten Daten hat jemand gelöscht und die neu angelegten Daten kann ich in der Kartendarstellung nicht von meinen unterscheiden.

Und das ist gut so!

Mir ist die Lizenz unter dennen die OSM-Daten liegen eigentlich egal, hauptsache es sind möglichst viele und richtige Informationen drin - Verluste durch irgendwelche Lizenzumstellungen sollten möglichst aufgefangen werden.

Von mir aus kann jeder damit machen was es will - vonmiraus auch richtih Kohle machen mit einem properiätren Format...

Einzig was ich benötige ist einen freien Zugang zu den OSM-Rohdaten, Downloadquellen und das recht diese entprechend zu verarbeiten...

Mondschein · 2012-01-19 13:55:39

Das passt hier gut dazu:
http://lists.openstreetmap.org/pipermai … 06869.html

Gruß,
Mondschein

hurdygurdyman · 2012-01-30 08:54:20

EvanE wrote:

...
- Importe und automatisierte Edits begründen in der Regel keinen
Anspruch auf Urheberrecht (fehlende Schöpfungshöhe)
Die Frage was als triviale Edits zu betrachten ist, ist bisher nur für einen Fall (Löschen von created_by Taggs) geklärt. Weitere Möglichkeiten (z.B. Werte-Korrekturen) müssen noch entschieden werden.
...

Zur Schöpfungshöhe:
Ich habe hier eine Menge tracks, bei denen eine Ablehner aus "tracktype=Grade*" lediglich "tracktype=grade*" gemacht hat. In einer derartigen Schreibfehlerberichtigung kann ich keine Schöpfungshöhe erkennen, weshalb ich diese Wege alle zusätzlich mit "odbl=clean" tagge. Wenn irgendwann vor dem 1.4. noch Zeit und Lust vorhanden ist, lege ich die vielleicht auch neu an, um auf Nummer Sicher zu gehen.

Edit:
Ich habe mal die Details geprüft. Die Änderungen stammen aus einem Changeset, in dem 1672 ways innerhalb von dreieinhalb Stunden bearbeitet wurden. Das sieht nach bot aus, wodurch die fehlende Schöpfungshöhe zusätzlich dokumentiert wird.

Last edited by hurdygurdyman (2012-01-30 10:50:23)

errt · 2012-01-30 10:23:22

Ich würde mal davon ausgehen, dass solche Änderungen entsprechend erkannt werden, bei der Umstellung. odbl=clean zu setzen kann aber nicht schaden. Aber selbst wenn nicht, dann steht hinterher halt wieder "Grade" statt "grade" drin, das ist ja kein Informationsverlust.

Announcement

#1 2012-01-13 21:13:31

@OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#2 2012-01-13 21:34:50

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#3 2012-01-13 21:45:02

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#4 2012-01-13 21:49:26

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#5 2012-01-13 21:55:57

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#6 2012-01-13 22:07:52

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#7 2012-01-13 22:14:42

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#8 2012-01-13 22:14:50

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#9 2012-01-13 22:18:54

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#10 2012-01-13 22:39:31

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#11 2012-01-13 22:48:34

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#12 2012-01-14 03:06:11

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#13 2012-01-14 12:44:31

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#14 2012-01-14 13:49:19

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#15 2012-01-14 15:48:38

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#16 2012-01-14 16:21:14

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#17 2012-01-14 17:26:28

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#18 2012-01-14 17:32:10

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#19 2012-01-14 17:56:08

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#20 2012-01-14 17:56:10

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#21 2012-01-14 18:01:53

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#22 2012-01-14 18:10:50

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#23 2012-01-19 13:55:39

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#24 2012-01-30 08:54:20

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

#25 2012-01-30 10:23:22

Re: @OSMF: mehr 'Mut' bei der Umstellung nach ODBL, bitte!

Board footer