I thought I'd throw in my $0.02 into the discussion as well. First of all, I think it is good that we are having this discussion and I hope that eventually we can come to a OSMF sanction conclusion (set of community guidelines) one way or another.
Overall, I think the route via produced works is the correct way to go here. For reverse geocoding I think declaring things as produced work is pretty well justified. The process is to take a geographic coordinate as input. This input is then turned, with the help of a bunch of complex algorithms(e.g. nominatum), into a (textual) rendering of an extract of the openstreetmap data. This textual rendering is then stored and eventually displayed to a human observer. This is nearly exactly equivalent to the process of rendering map tiles. I.e. you take four geographic coordinates (bounding box) as input. This input is then turned, with the help of a bunch of complex algorithms (e.g. mapnik), into a (bitmap) rendering of an extract of the openstreetmap data. This bitmap rendering is then stored and eventually displayed to a human observer. Given that map tiles are universally considered as produced works, so should imho be the result of reverse geocoding. As such, this should then also not trigger share-a-like. Just like one could take a proprietary database, use the stored lat/lon values in that database and render a 256x256 pixel image of the map for each entry of the database and store it back into the proprietary database without "infecting" the database with the ODbL share-a-like, one should be able to do the same with reverse geocoding. Imho anything that is intended for (more or less) direct consumption by humans is a produced work. For forward geocoding, the picture gets a bit more murky though, as the distinction between what is for human consumption and what is data, and thus a derived database, is much less clear cut. If you geocode an address and then all you do with the the resulting lat/lon is to display it in some form, then that is imho clearly also a produced work and thus shields things from the ODbL share-a-like requirement. However, once you start manipulating and computing with those lat/lon values. E.g. to calculate the average distance between all of the POIs in your proprietary db, the definition of produced work probably starts breaking down, because the output of the geocoding process is no longer the end product. Where exactly that line is though between produced work and derived database, I am not sure is obvious, and thus the intention of making the license clearer would unfortunately not really be achieved. Generally, I would consider my self as a proponent of share-a-like, but at least to me personally, I would consider all of the use cases presented in the proposed community guidelines as acceptable and within the spirit of share-a-like requirement for the OSM database. But it probably needs a bit more explanation of what you can and cannot do with the derived lat/lon values of the geocoding process. Kai -- View this message in context: http://gis.19327.n5.nabble.com/OSM-legal-talk-Updated-geocoding-community-guideline-proposal-tp5811077p5811672.html Sent from the Legal Talk mailing list archive at Nabble.com. _______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
