Re: [OSM-legal-talk] Updated geocoding community guideline proposal
This is a solid proposal and has my support. As long as the purpose of a geocoder is geocoding, and not reverse engineering OSM, then it sensibly fits within the notions of an ODbL produced work. What I wonder is how we will move to decision making on the proposal? What's the OSMF process? -Mikel * Mikel Maron * +14152835207 @mikel s:mikelmaron On Thursday, July 10, 2014 10:54 PM, Alex Barth a...@mapbox.com wrote: I just updated the Wiki with a proposed community guideline on geocoding. In a nutshell: geocoding with OSM data yields Produced Work, share alike does not apply to Produced Work, other ODbL stipulations such as attribution do apply. The goal is to remove all uncertainties around geocoding to help make OpenStreetMap truly useful for geocoding and to drive important address and admin polygon contributions to OpenStreetMap. This interpretation is based on what we hear from our lawyers at Mapbox. As this is an interpretation of the ODbL, grey areas remain and therefore, seeing this interpretation adopted as a Community Guideline by the OSMF would be hugely helpful to create more certainty about the consensus around geocoding with OpenStreetMap data. Please review: https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline Cheers - Alex [1] https://lists.openstreetmap.org/pipermail/legal-talk/2013-June/007547.html ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Hi, On 07/15/2014 01:26 PM, Mikel Maron wrote: As long as the purpose of a geocoder is geocoding, and not reverse engineering OSM, then it sensibly fits within the notions of an ODbL produced work. What if there are two processes run on a city extract - one is a SELECT * FROM planet_osm_point WHERE shop IS NOT NULL, and the other is a yellow pages operator geocoding all their proprietary shop information with OSM and storing the results in their proprietary database. Let's assume for a moment that both were to result in an almost identical database, give or take a few mismatches. The first would clearly be a derived database - no matter for what purpose the SELECT command was issued. And the second - because it was made with the purpose of geocoding - would not be a derived database but a produced work. Is that what you are saying? Because if it is, it seems to require a *lot* more explanation because it doesn't sound very convincing to me. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On 2014-07-15 4:26 AM, Mikel Maron wrote: As long as the purpose of a geocoder is geocoding, and not reverse engineering OSM, then it sensibly fits within the notions of an ODbL produced work. A geocoder isn't a produced work or a derived database - it's software. Do you mean a geocoding result, or a database of geocoding results? What I wonder is how we will move to decision making on the proposal? What's the OSMF process? First we need to wait for discussion to be settled. After that, it'd be the same process as the other guidelines - to LWG for review, then the board. Also, everyone should remember the guidelines are on the wiki right now, so don't be afraid to edit the body of them, not just add examples. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Mon, Jul 14, 2014 at 12:40 PM, Paul Norman penor...@mac.com wrote: On 2014-07-14 11:26 AM, Alex Barth wrote: Also if we assume geocoding yields Produced Work the definition of Substantial doesn't matter. A database that is based upon the Database, and includes any translation, adaptation, arrangement, modification, or any other alteration of the Database or of a Substantial part of the Contents is a derivative database. This doesn't exclude databases where the items in the database are produced works, e.g. a database of geocoding results. If you are extracting insubstantial parts of the database (keeping in mind that repeated insubstantial can be substantial) than the ODbL imposes no requirements, not share-alike nor attribution. To me it seems that there is a demarcation line between ephemeral geocoding on the one hand, where a singular coordinate pair is extracted from OSM as the result of a geocoding operation for the purpose of immediate use, leading to a Produced Work, and 'permanent geocoding' (as mentioned in the guidelines) on the other hand, where geocoding is used in a systematic way, leading to a Derivative database. Correct? This should be made clearer in the definition part of the guideline then, which now encapsulates both these use cases stating the result of geocoding is 'one or more Geocodes. Geocodes are then stored either permanently or temporarily [...]'. -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Tue, Jul 15, 2014 at 04:26:28AM -0700, Mikel Maron wrote: As long as the purpose of a geocoder is geocoding, and not reverse engineering OSM, then it sensibly fits within the notions of an ODbL produced work. please, read ODbL... produced work is “Produced Work” – a work (such as an image, audiovisual material, text, or sounds) resulting from using the whole or a Substantial part of the Contents (via a search or other query) from this Database, a Derivative Database, or this Database as part of a Collective Database. and 4.4.c. Derivative Databases and Produced Works. A Derivative Database is Publicly Used and so must comply with Section 4.4. if a Produced Work created from the Derivative Database is Publicly Used. so regardless of the licence used for produced work, there has to be You must include a notice associated with the Produced Work reasonably calculated to make any Person that uses, views, accesses, interacts with, or is otherwise exposed to the Produced Work aware that Content was obtained from the Database, Derivative Database, or the Database as part of a Collective Database, and that it is available under this License. (4.3.) and the underlying databases has to be released under an open licence. so the real question is which databases does geocoding create. clearly it creates a derivative database (select only those lat-lon which match some of these addresses) btw, cp planet.osm.bz2 planet.png creates a produced work... -- michal palenik www.freemap.sk www.oma.sk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
2014-07-15 18:01 GMT+02:00 Michal Palenik michal.pale...@freemap.sk: btw, cp planet.osm.bz2 planet.png creates a produced work... LOL I'd doubt this, because an image is likely not to be read like in disk image, and not every file with an png extension will be considered an image... ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Tue, Jul 15, 2014 at 7:26 AM, Mikel Maron mikel.ma...@gmail.com wrote: This is a solid proposal and has my support. +1 This is a great effort to clarify something that causes a lot of confusion, and does so within the context of the current license. Very productive! As long as the purpose of a geocoder is geocoding, and not reverse engineering OSM, then it sensibly fits within the notions of an ODbL produced work. The biggest problem I've seen is companies wanting to geocode their proprietary address databases with Nominatim or similar, but are worried that storing the lat/lng results with trigger the ODbL. Having built a geocoder, I think sufficient art goes into it that the results should be considered a produced work. Of course a reverse engineered OSM is different from geocoding your own address database and should be prevented. Adopting clear guidelines in support of geocoding over OSM data will improve OSM, as a large number of developers would have the incentive to clean up data. There is huge demand for permissive geocoders in the development community. What I wonder is how we will move to decision making on the proposal? What's the OSMF process? Having a decision one way or the other is important, either yes or no. Because this work is certainly going to move forward somewhere, and it would be a shame for it not to improve OSM. -Randy ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Tue, Jul 15, 2014 at 06:22:29PM +0200, Martin Koppenhoefer wrote: 2014-07-15 18:01 GMT+02:00 Michal Palenik michal.pale...@freemap.sk: btw, cp planet.osm.bz2 planet.png creates a produced work... LOL I'd doubt this, because an image is likely not to be read like in disk image, and not every file with an png extension will be considered an image... you can view it on a display, you can print it. it's called modern art. :-) or even better example: bzcat planet.osm.bz2 | lp. what a nice text (xml). pure produced work which i hereby licence as beerware. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk -- michal palenik www.freemap.sk www.oma.sk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On 11 July 2014 03:52, Alex Barth a...@mapbox.com wrote: I just updated the Wiki with a proposed community guideline on geocoding. Please review: https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline The whole point of the share-alike aspect of our licence is to stop people taking OSM, using it to 'improve' their own proprietary geo-data, and then not sharing the results back with the community. Whether you are for or against share-alike, that's what the community has decided to adopt, and that is what is required by the licences under which various source data has been used. So I think share-alike is here to stay. The loop-hole for produced works is to allow people to take proprietary style instructions / algorithms and run the geo-data through them to create something artistic, which they then don't have to share. But the ODbL ensures that the underlying geo-data (and any additions / modifications made to it) does have to be shared. So the way I see it, if there's any (substantial) addition of external geo-data along the way, then that addition creates a derivative database, before the produced work is created. So if you want to publicly use this database (or any produced work based on it) then either the derivative database must be shared-alike, or the algorithm used to produce it and any additional input data must be shared. In the case of any substanitial amount of geocoding, you are clearly having to add additional geographic data to the OSM data in order to do the geocoding. I would therefore argue that the result must be seen as a derivative database, and not as a produced work. (In fact I'd go slightly further, and say that in order to do the geocoding, you have to create a derivative database comprising the relevant data from OSM and the relevant address data you want to match against. You then run a query on that derivative database to produce your geocoded results.) And I think treating substantial amounts of geocoded results as a derivative database is certainly within the spirit of the licence, and something we would want share-alike to apply to. If people are enriching their own geographic data using OSM, we would like to be able to use their data to help improve OSM. I don't see why the specific case of geocoding should be any different to other uses of OSM data with data companies would like to keep private. In any case, even without these arguments, I think it would be impossible to argue that a substantial database of geocoded data that's been generated using OSM data is anything but a derivative database of OSM. So I don't think there's any getting around share-alike if your geocoded results are substantial. So for those wanting to geocode proprietary datasets using OSM, I think there are three main options: 1/ Make sure your geocoding only amounts to insubstantial use of OSM. Then share-alike never kicks in, and it's irrelevant whether the results are produced works or derivative databases. 2/ Make sure your geocoded database (and any produced works or derivatives therefore) is kept internal to the company. Hence it is never publicly used, and share-alike does not apply. 3/ Release the smallest possible derivatve database under the ODbL. As far as I can see this would need to include whatever input data is necessary for you to do the geocoding, as you need to include the address data and the OSM data in the same derivative databse in order to run your query on them to do the geocoding. As an example for 3, if you have a databse of company offices with addresses and other meta-data that you want to obtain lat/lons for, you'd need to release the address data and the lat-lons you've obtained. You needn't release the other meta-data, since that could be kept independently as part of a collective databse, with the two linked by some unique ID field. As an aside, I've yet to actually read a use case where this interpretation would be particularly problematic for a third party (at least no more so than any other proprietary data vs share-alike use case). The only thing I've seen where it might cause difficulties would be where individual user privacy is at risk. But I would have thought that either the users can keep their locations private (so not publicly used) or the locations can be linked to the private meta-data via an opaque key with the meta-data kept private in another part of a collective database. A company could always additionally geocode fictitious points to hide individual users to further increase privacy if they wanted. Given what I've written above, my view on https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline is that those proposing it need to go back to the drawing board. At the very least, it needs to start off with proper definitions / explanations of geocoding, and details included in each example to say whether or not they include substantial use of OSM. It also needs to acknowledge that databases of
