[OSM-talk] Editing of content that will be deleted on April 1st

[andrzej zaborowski]

Hi,

On 21 December 2011 15:06, Ed Loach <ed en loach.me.uk> wrote:
>> On 13 December 2011 23:03, David Earl
>> <david en frankieandshadow.com> wrote:
>> > What are the precise, numeric criteria for proceeding? At the
>> moment even by
>> > a vague definition I don't see how one could describe it as a
>> critical mass.
>>
>> I'm responding to this old thread because now I think whoever
>> made the
>> criteria could have answered the question asked here.  But really
>> there's probably no answer because the date was pulled out of thin
>> air.
>
> Well, I'm not on any committee, but I find it hard how anyone can't
> think there is a critical mass. Over 95% of the data will be
> retained, and this figure is increasing weekly both due to new
> acceptances and of course ongoing mapping by those who have already
> accepted.

I'm not claiming that's a bad date, just trying to find an explanation
to how the decision process works (and why David Earl's question would
never be answered).  I'm seeing the license process has run over most
of the project's normal working rules by now.  For example (but really
these are some of many details):

* the currently proposed "What is clear" criteria based on a
individual object's history.  A couple of months ago [1] Frederik
wrote:
"There are a number of other reasons why IDs could "break". [...]
Relying on numeric IDs is never going to work, and there is no way how
this could be made to work in the future."
And now the whole process which is supposed to be legally sound is
supposed to work based on those IDs.  It's trivial to detect merges,
splits, and tag copy/pasting specially since the changesets have been
introduced and most usual edits happen inside a single changeset.
Considering that first year IT students have to implement pattern
recognition that can read text there's really no technical excuse to
not detect that nodes that belonged to one way now belong to another.

* at the same time proposed is a "meta" tag odbl= that is further from
the on the round rule than perhaps any other tagging devised until
now.  The "don't tag for the render" rule (where renderer refers to
any particular tool using the OSM *map* database) has just gone down
the drain.

* the body who's supposed to "support rather than govern" the project
is on its way to remove map data.  Tangentially, note that the CT
1.2.4 document, which over a hundred thousand people has been made
accept, has been written in such a way that it doesn't disallow
ODbL-incompatible data being contributed, and people have accepted the
terms on that basis [2].  In effect no one can know what is or isn't
incompatible.  But Frederik's and Simon Poole's visualisations in some
ways imply that whatever passes the "What is clean" test is ODbL
compatible and possibly any free-and-open-license-compatible.  As a
result several of my friend mappers are under attack from authors of
CC-By-SA data which now shows as green on those visualisations.  It's
very hard to explain to them that those maps are some person's
viewpoint based on information that is orthogonal to the new license
compatibility, and that their work has not been "stolen".  Which only
makes it harder to convince those authors to agree to the new license
(and shouldn't this, and the remapping going on, really be somebody
else's task?).
Does that mean that LWG needs to ask all of those who agreed to CT
1.2.4 to accept a new version of the contract, if it wants to switch
to ODbL? (incidentally tonight I found that the OpenStreetMap website
has not been displaying the full Contributor Terms document to the
people agreeing for the last perhaps three months, due to a bug --
basically since the introduction of version 1.2.4 [3])  How does that
relate to the < 4 months time left to find out what is or isn't new
license compatible?

Cheers

1. http://gis.638310.n2.nabble.com/Blatant-case-of-tagging-for-the-renderer-tt6633546.html
2. http://www.openstreetmap.org/user/aharvey/diary
3. https://github.com/balrog-kun/openstreetmap-website/commit/fa7e099d840f1214a4a3339873bc39ed52f0a485