Hi, On 21 December 2011 15:06, Ed Loach <[email protected]> wrote: >> On 13 December 2011 23:03, David Earl >> <[email protected]> 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 _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
