Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Am 10.03.2015 um 02:10 schrieb Alex Barth: On Thu, Feb 19, 2015 at 11:52 PM, Simon Poole si...@poole.ch mailto:si...@poole.ch wrote: http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#.22Collective_Database.22_alternative 1. Why is the input data part of the Derivative Database? There is an underlying assumption that the input data will match, in the best case exactly, an object in the OSM dataset, and that you are extracting further information about it (aka its geographic location) from the OSM data. Note that in this model we are treating the input data as a key in to the geocoded dataset. Treating the geocoded results plus input data as a derivative DB sidesteps various issues. They have their roots in, on the one hand, the most popular OSM based geocoder not just returning a pair of coordinates and, on the other hand, us having no control over how geocoding is technically implemented. It further makes clear if that you are using more attributes to improve the geocoding that they are subject to the same terms. Not sure I follow here. The geocoded results plus input data in and itself would be in the most common cases not Substantial even by OSM's very aggressive definition of what's Substantial ( 100 features OTOH). A non-Substantial extract would remain non-Substantial. The cases I thought we were discussing here, are the real world requirements of 100'000 if not millions of objects that have to be bulk geo-coded. If these use cases are of no concern or don't actually exist, then it is not quite clear to me why we are having the discussion in the first place, given that: - on the fly geocoding is unproblematic (no database created) - a small number of geocoded results is non-Substantial and doesn't create share alike obligations. So it depends on how you'd store the results returned by the geocoder and whether you'd store the input data with it. The logic is fairly clear. Assume you have a database of restaurant reviews, besides the review related data, every entry has restaurant name and street address. - I create a table with name and street address extracted from my database. - I geocode name and street address with OSM, adding the coordinates (or building polygons or whatever) to above table - I can now use this table (subject to the ODbL) and the original data together as a collective database to for example create a map with the restaurant locations or run a service that calculate routes to the restaurants on the fly. The important bit is not arguing about how the database is arranged and so on, but more that it gives us a model with which we can define precisely which data is subject to being available on ODbL terms. And yes in above example a user could ask you to give out the list of restaurant names, addresses and coordinates, which assuming that, for example, names could be missing in OSM, would actually be useful to the community. Which brings us to point 2: 2. This language is not explicit about Geocoding Results from other databases that are stored in the same database. Would they be part of the Derivative Database? I believe that is a not an issue as formulated. You would need a clear way of keeping the data separate. For lack of a better example: two tables: addresses geocoded with OSM, addresses geocoded with here, but IMHO labelling the geocoding source could be considered enough (given that you may want to provide dynamically displayed attribution you would likely want to do this in any case). Now this interpretation together with the linked data concept of the same Collective Database alternative (below) would mean that only data directly retrieved from OSM would ever be covered by the ODbL. The ODbL would not extend to any data added to the same database. Right? As written in my original mail, the main issue is not so much that you can use similar data from a different source together with your dataset, the question is how do you do so without using information from OSM? Aka the fall back question. Re-visiting the example above: assume that the 2nd point is modified to be: - I geocode name and street address with OSM, adding the coordinates (or building polygons or whatever) to above table, if I don't find a match or the match in OSM doesn't fit my quality requirements, I geocode the name and address with a commercial database and store the results in a separate table. Is the 2nd table free of OSM rights? Not an easy question to answer. Note: http://osmfoundation.org/wiki/License/Community_Guidelines/Horizontal_Map_Layers_-_Guideline currently, on a similar issue, takes the stance that this is not something that is supported. Simon signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Am 20.02.2015 um 08:52 schrieb Simon Poole: ... Treating the geocoded results plus input data as a derivative DB sidesteps various issues. ... I should have mentioned that the single biggest advantage is that it doesn't require us to supply a definition of what geocoding actually is. Trying to nail that down in a general and future proof way has been one of the larger roadblocks. Just imagine when OSM doesn't just have address data for everything, but it is attached to the corresponding entrance of office (indoor mapping). Simon signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Am 03.11.2014 um 00:45 schrieb Alex Barth: I have two questions on the Collective DB alternative: The derivative database consists of the data that has been used as the input data for the geocoding process, as well as the data that has been gained from OpenStreetMap in the process. Any additional data that may be linked to this data, even sitting in the same logical database table, is however not considered to be part of the derivative database (instead it forms a collective database together with the derivative database) and therefore, does not have to be shared under the ODbL. http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#.22Collective_Database.22_alternative 1. Why is the input data part of the Derivative Database? There is an underlying assumption that the input data will match, in the best case exactly, an object in the OSM dataset, and that you are extracting further information about it (aka its geographic location) from the OSM data. Note that in this model we are treating the input data as a key in to the geocoded dataset. Treating the geocoded results plus input data as a derivative DB sidesteps various issues. They have their roots in, on the one hand, the most popular OSM based geocoder not just returning a pair of coordinates and, on the other hand, us having no control over how geocoding is technically implemented. It further makes clear if that you are using more attributes to improve the geocoding that they are subject to the same terms. 2. This language is not explicit about Geocoding Results from other databases that are stored in the same database. Would they be part of the Derivative Database? I believe that is a not an issue as formulated. You would need a clear way of keeping the data separate. For lack of a better example: two tables: addresses geocoded with OSM, addresses geocoded with here, but IMHO labelling the geocoding source could be considered enough (given that you may want to provide dynamically displayed attribution you would likely want to do this in any case). The real underlying issue is the fallback issue: can a set of negative results (no geocoding result from OSM) form a derivative database? On the fly it is IMHO a non-issue, however in the bulk/permament geocoding scenario it is. Simon signature.asc Description: OpenPGP digital signature ___ 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-11-03 0:17 GMT+01:00 Alex Barth a...@mapbox.com: 2014-10-29 20:56 GMT+01:00 Alex Barth a...@mapbox.com: Updated: http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License%2FGeocoding_-_Guidelinediff=1102233oldid=1076215 wouldn't it make more sense to come to a conclusion here before updating the wiki? Hey Martin - the change you link to was to replace the term 'geocode' with the more common 'geocoding result' - do you have a specific concern with it? my bad, sorry for the confusion, my comment was referring to the following edit, which was 4 minutes later: http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guidelinediff=nextoldid=1102233 cheers, Martin ___ 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, Nov 3, 2014 at 6:45 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: my bad, sorry for the confusion, my comment was referring to the following edit, which was 4 minutes later: http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guidelinediff=nextoldid=1102233 Got it, yes. Databases of items of Produced Work aren't Derivative Databases per 4.5b. ___ 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, Nov 3, 2014 at 8:56 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: where in one of the first paragraphs there is this unproven claim: Geocoding Results are a Produced Work by the definition of the ODbL (section 1.): “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. A geocoding result is created via a search or a query. It's a Produced Work. A work can specifically be a database, see http://www.out-law.com/page-5698, Databases are treated as a class of literary works and may therefore receive copyright protection for the selection and/or arrangement of the contents under the terms of the Copyright, Designs and Patents Act 1988. (UK law) This is clearly a possible reading of the ODbL and it would enable geocoding. ___ 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-11-03 15:05 GMT+01:00 Alex Barth a...@mapbox.com: On Mon, Nov 3, 2014 at 8:56 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: where in one of the first paragraphs there is this unproven claim: Geocoding Results are a Produced Work by the definition of the ODbL (section 1.): “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. A geocoding result is created via a search or a query. It's a Produced Work. A work can specifically be a database, see http://www.out-law.com/page-5698, Databases are treated as a class of literary works and may therefore receive copyright protection for the selection and/or arrangement of the contents under the terms of the Copyright, Designs and Patents Act 1988. (UK law) This is clearly a possible reading of the ODbL and it would enable geocoding. Do you really think that a list of addresses can be seen as similar to a literary work? Will there be any protectworthy selection and/or arrangement of the contents? This probably has to be found out based on the individual case and decided by a judge - there will be databases that qualify as works, but maybe this doesn't exclude them from being a database the same time in the context of ODbL? Let's presume we all followed this reading, then when would something actually fall under the definition of derivative database? Why would we still be writing to legal talk instead of using the whole OSM db as a produced work - produced e.g. by performing some operations like wget planet.osm -O osm-produced.work cheers, Martin ___ 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, Nov 3, 2014 at 9:23 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: Let's presume we all followed this reading, then when would something actually fall under the definition of derivative database? Why would we still be writing to legal talk instead of using the whole OSM db as a produced work - produced e.g. by performing some operations like wget planet.osm -O osm-produced.work The command you describe would just be a copy and not actually a query or a search of the database. But extrapolating from what you write, copying the entire db through a geocoder is actually hard. You'll have to know all addresses in advance or query all locations in the world. The latter is expensive and it would always leave you with an inaccurate copy. Either way, if you did this in a systematic way you'd be looking at a Derivative Database again. Just like the example of OCRing an OSM based tiled map and thus rebuilding the OSM database that has come up before. ___ 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 Thu, Oct 30, 2014 at 8:40 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2014-10-29 20:56 GMT+01:00 Alex Barth a...@mapbox.com: Updated: http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License%2FGeocoding_-_Guidelinediff=1102233oldid=1076215 wouldn't it make more sense to come to a conclusion here before updating the wiki? Hey Martin - the change you link to was to replace the term 'geocode' with the more common 'geocoding result' - do you have a specific concern with it? ___ 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 Wed, Oct 29, 2014 at 5:12 PM, Michal Palenik michal.pale...@freemap.sk wrote: 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. which say, that it does not matter whether you declare geocodes produced work or derivative db. if this didn't exist, i could declare anything a produced work (things like any enhanced database) and the whold odbl would not exists. Right, if your geocoding service is Public in the sense of the ODbL and it uses an ODbL Derivative Database to look up geocoding results, the Derivative Database must be disclosed per 4.4. Per 4.4 c this is the case for both current interpretations on the guidelines. The disclosure stipulations set forth in 4.6 apply. Right now, the geocoding guidelines don't talk about the database a geocoder uses to look up results though, they only talk about the database geocoding results are stored in. This could change. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
I have two questions on the Collective DB alternative: The derivative database consists of the data that has been used as the input data for the geocoding process, as well as the data that has been gained from OpenStreetMap in the process. Any additional data that may be linked to this data, even sitting in the same logical database table, is however not considered to be part of the derivative database (instead it forms a collective database together with the derivative database) and therefore, does not have to be shared under the ODbL. http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#.22Collective_Database.22_alternative 1. Why is the input data part of the Derivative Database? 2. This language is not explicit about Geocoding Results from other databases that are stored in the same database. Would they be part of the Derivative Database? An example to clarify my question in (2): Say I have a database of Starbucks locations with addresses. I use OpenStreetMap to geocode all addresses and store geocoding results (lat lon pairs) from OpenStreetMap next to my existing records. A handful of addresses failed to properly geocode so I use a geocoder with proprietary data to backfill the results. What specifically constitutes the Derivative Database here? A) the input data + records I copied from OpenStreetMap B) A + any additions of the same kind of Content, aka the lat lon pairs I added from the proprietary geocoder On Thu, Aug 21, 2014 at 1:26 PM, Frederik Ramm frede...@remote.org wrote: Rob, On 08/21/2014 06:42 PM, Rob Myers wrote: It would be great if people would help fill in the blanks, or correct me where I might have misrepresented the discussion. The page asserts: Geocodes are a Produced Work [...] The rest of the page then silently slips [...] I have tried to present the two different viewpoints in two columns. On the left is Alex' original version which claims what you summarized in your message (that geocodes are produced works etc.); on the right is a version that explicitly claims A database of Geocodes is a derivative database by the definition of the ODbL - which seems to be exactly the statement that you were aiming at, no? The blanks that need filling are the consequences of this different interpreatation for the various use cases. I added one for use case #1, but only an empty column for use cases #2-#4 and #7. I added no extra column for #5 and #6 because those struck me as identical under both interpretations but of course I might be wrong. 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 ___ 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 Sun, Nov 2, 2014 at 6:17 PM, Alex Barth a...@mapbox.com wrote: On Thu, Oct 30, 2014 at 8:40 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: Updated: http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License%2FGeocoding_-_Guidelinediff=1102233oldid=1076215 Hey Martin - the change you link to was to replace the term 'geocode' with the more common 'geocoding result' - do you have a specific concern with it? GEOCODE is a trade mark belonging to a litigious, oh I shouldn't get personal, professor. :-) The background is on the wiki, but I thought this was made clear earlier in the thread? http://wiki.osm.org/wiki/Geocode_Trademark ___ 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-10-29 20:56 GMT+01:00 Alex Barth a...@mapbox.com: Updated: http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License%2FGeocoding_-_Guidelinediff=1102233oldid=1076215 wouldn't it make more sense to come to a conclusion here before updating the wiki? cheers, Martin ___ 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, Oct 27, 2014 at 08:19:10PM -0400, Alex Barth wrote: Good call on geocodes - geocoding results. That's clearer. On Mon, Oct 27, 2014 at 8:06 PM, Paul Norman penor...@mac.com wrote: What do you think the status of a database of geocoding results is under the interpretation in column 1? According to the interpretation in column 1, the ODbL doesn't imply any specific licensing for geocoding results, they are Produced Works. alex, please read 4.6 of odbl, which basically says there is no difference between derivative db and produced work with regards to database rights. michal ___ 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 Mon, Oct 27, 2014 at 8:06 PM, Paul Norman penor...@mac.com wrote: I'm wondering if we should replace geocodes with geocoding results throughout the page. I think it improves clarity as to what is being discussed, and geocodes is not a term in common use for what we are discussing. Thoughts? It shouldn't change the meaning. Updated: http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License%2FGeocoding_-_Guidelinediff=1102233oldid=1076215 ___ 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, Oct 27, 2014 at 8:33 PM, Paul Norman penor...@mac.com wrote: A geocoding result is not the same as a database of geocoding results. Column 1 says the former is a produced work, but is silent on the latter. I updated the guide to be explicit about this case: http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License%2FGeocoding_-_Guidelinediff=1102235oldid=1102233 ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Hey Michal - On Wed, Oct 29, 2014 at 9:38 AM, Michal Palenik michal.pale...@freemap.sk wrote: alex, please read 4.6 of odbl, which basically says there is no difference between derivative db and produced work with regards to database rights. 4.6 talks about disclosure standards in cases where share-alike applies (offer copy of entire database or alteration file). Not sure how this relates? http://opendatacommons.org/licenses/odbl/1-0/ ___ 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 Wed, Oct 29, 2014 at 04:03:03PM -0400, Alex Barth wrote: Hey Michal - On Wed, Oct 29, 2014 at 9:38 AM, Michal Palenik michal.pale...@freemap.sk wrote: alex, please read 4.6 of odbl, which basically says there is no difference between derivative db and produced work with regards to database rights. 4.6 talks about disclosure standards in cases where share-alike applies (offer copy of entire database or alteration file). Not sure how this relates? if you publicly use a produced work (which is the indented case here) 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. which say, that it does not matter whether you declare geocodes produced work or derivative db. if this didn't exist, i could declare anything a produced work (things like any enhanced database) and the whold odbl would not exists. produced work is always based on a derivative db or collective db (if they are used independetly) 4.6. restates this. so the real question is, which part is derivative db (and not whether it's produced work) http://opendatacommons.org/licenses/odbl/1-0/ ___ 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
Picking up on Paul's offer to help along the discussion here [1]. Also copying Steve here as he's renewed his call for better addressing in OpenStreetMap - which I entirely agree with [2]. Feedback from this thread is incorporated on the wiki [2] - thanks particularly to Frederik for this work. However, we have two competing visions for how to interpret geocoding. Column 1 of the wiki page interprets the information queried from OpenStreetMap in a typical geocoding request as Produced Work, thus not extending share alike provisions to geocoded data. Column 2 interprets the content pulled from OpenStreetMap in a geocoding process as a Derivative Database but the database this content is inserted to as a Collective Database. Column 1 entirely enables permanent geocoding with OpenStreetMap data from a legal perspective. Column 2 doesn't enable permanent geocoding by extending share alike provisions to the part of a database that contains OSM derived geocodes. This interpretation would impede the important fall back use case where a geocoder uses OpenStreetMap data - and where OpenStreetMap data is not sufficient - proprietary data as a fallback. In such scenarios both OpenStreetMap data (e. g. lat/lon's) and proprietary data would wind up in the same database to be licensed under the ODbL. It would also impede use cases where data is expected to be relicensed. For making OpenStreetMap viable as a geocoding database, we'll want a permissive reading of our license - no matter what we opine on share alike for the larger database. Of course, enabling permanent geocoding isn't the end-all-be-all strategy for making OpenStreetMap an awesome geocoding database - but it's an important incentive that we can't do without. Having more people use OpenStreetMap as a geocoding database will give us better admin polygons, better place data and better addresses. The opportunity is huge, none of the proprietary data providers provide reasonable terms for _permanent_ geocoding - making everyone look for alternatives. OpenStreetMap should be that alternative. Would love suggestions on how to proceed on taking a decision here. [1] https://lists.openstreetmap.org/pipermail/talk/2014-October/071153.html [2] https://lists.openstreetmap.org/pipermail/talk/2014-October/071135.html [3] http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline On Mon, Aug 25, 2014 at 12:53 AM, Eugene Alvin Villar sea...@gmail.com wrote: On Mon, Aug 25, 2014 at 12:08 PM, Alex Barth a...@mapbox.com wrote: How would the Collective Database approach work if the OSM Database must remain unmodified to be part of a Collective Database? The definition of Collective Database seems to be tailored to use cases where the OpenStreetMap database *in unmodified form* is part of a larger database. I can't quite conjure up a real world example, but the ODbL is pretty clear about this: “Collective Database” – Means this Database in unmodified form as part of a collection of independent databases in themselves that together are assembled into a collective whole. A work that constitutes a Collective Database will not be considered a Derivative Database. - See more at: http://opendatacommons.org/licenses/odbl/1-0/#sthash.mDtnZAPO.dpuf The this Database in unmodified form means the particular database that is licensed under ODbL. It can be the OSM database itself, or any database derived from the OSM database that must in itself be licensed under ODbL. So if you did any transformations on the OSM database (ex., converted it into a form suitable for a geocoder), the transformed database is licensed under the ODbL. You can either publish this transformed database or provide the software used to create the transformed database to comply with the license of the source OSM database. Then, this geocoder database can become part of the collective database. ___ 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
On 10/27/2014 4:47 PM, Alex Barth wrote: Picking up on Paul's offer to help along the discussion here [1]. Also copying Steve here as he's renewed his call for better addressing in OpenStreetMap - which I entirely agree with [2]. Feedback from this thread is incorporated on the wiki [2] - thanks particularly to Frederik for this work. However, we have two competing visions for how to interpret geocoding. Column 1 of the wiki page interprets the information queried from OpenStreetMap in a typical geocoding request as Produced Work, thus not extending share alike provisions to geocoded data. Column 2 interprets the content pulled from OpenStreetMap in a geocoding process as a Derivative Database but the database this content is inserted to as a Collective Database. I'm wondering if we should replace geocodes with geocoding results throughout the page. I think it improves clarity as to what is being discussed, and geocodes is not a term in common use for what we are discussing. Thoughts? It shouldn't change the meaning. Given the lack of mention of a *database* of geocodes, as it stands I don't think column 1 helps with any standard use cases, where you will have many geocodes in a database. What do you think the status of a database of geocoding results is under the interpretation in column 1? Those who I've talked to believe that in principle column 2 supports their use cases - it is just a matter of bringing clarity to it. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Good call on geocodes - geocoding results. That's clearer. On Mon, Oct 27, 2014 at 8:06 PM, Paul Norman penor...@mac.com wrote: What do you think the status of a database of geocoding results is under the interpretation in column 1? According to the interpretation in column 1, the ODbL doesn't imply any specific licensing for geocoding results, they are Produced Works. ___ 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 10/27/2014 5:19 PM, Alex Barth wrote: According to the interpretation in column 1, the ODbL doesn't imply any specific licensing for geocoding results, they are Produced Works. A geocoding result is not the same as a database of geocoding results. Column 1 says the former is a produced work, but is silent on the latter. Under most jurisdictions a geocoding result is likely to be ineligible for any protection, where as a database of them generally is. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
How would the Collective Database approach work if the OSM Database must remain unmodified to be part of a Collective Database? The definition of Collective Database seems to be tailored to use cases where the OpenStreetMap database *in unmodified form* is part of a larger database. I can't quite conjure up a real world example, but the ODbL is pretty clear about this: “Collective Database” – Means this Database in unmodified form as part of a collection of independent databases in themselves that together are assembled into a collective whole. A work that constitutes a Collective Database will not be considered a Derivative Database. - See more at: http://opendatacommons.org/licenses/odbl/1-0/#sthash.mDtnZAPO.dpuf On Thu, Aug 21, 2014 at 1:26 PM, Frederik Ramm frede...@remote.org wrote: Rob, On 08/21/2014 06:42 PM, Rob Myers wrote: It would be great if people would help fill in the blanks, or correct me where I might have misrepresented the discussion. The page asserts: Geocodes are a Produced Work [...] The rest of the page then silently slips [...] I have tried to present the two different viewpoints in two columns. On the left is Alex' original version which claims what you summarized in your message (that geocodes are produced works etc.); on the right is a version that explicitly claims A database of Geocodes is a derivative database by the definition of the ODbL - which seems to be exactly the statement that you were aiming at, no? The blanks that need filling are the consequences of this different interpreatation for the various use cases. I added one for use case #1, but only an empty column for use cases #2-#4 and #7. I added no extra column for #5 and #6 because those struck me as identical under both interpretations but of course I might be wrong. 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 ___ 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, Aug 25, 2014 at 12:08 PM, Alex Barth a...@mapbox.com wrote: How would the Collective Database approach work if the OSM Database must remain unmodified to be part of a Collective Database? The definition of Collective Database seems to be tailored to use cases where the OpenStreetMap database *in unmodified form* is part of a larger database. I can't quite conjure up a real world example, but the ODbL is pretty clear about this: “Collective Database” – Means this Database in unmodified form as part of a collection of independent databases in themselves that together are assembled into a collective whole. A work that constitutes a Collective Database will not be considered a Derivative Database. - See more at: http://opendatacommons.org/licenses/odbl/1-0/#sthash.mDtnZAPO.dpuf The this Database in unmodified form means the particular database that is licensed under ODbL. It can be the OSM database itself, or any database derived from the OSM database that must in itself be licensed under ODbL. So if you did any transformations on the OSM database (ex., converted it into a form suitable for a geocoder), the transformed database is licensed under the ODbL. You can either publish this transformed database or provide the software used to create the transformed database to comply with the license of the source OSM database. Then, this geocoder database can become part of the collective database. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/08/14 01:58 PM, Frederik Ramm wrote: It would be great if people would help fill in the blanks, or correct me where I might have misrepresented the discussion. The page asserts: Geocodes are a Produced Work by the definition of the ODbL (section 1.): “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. The rest of the page then silently slips from the idea that individual geocodes (a term of art for co-ordinates Extracted from the Database) are Produced Works (rather than individually not being Substantial Extracts) to the idea that any number of geocodes are still a Produced Work. But neither the ODbL nor the page explain why a database of geographical co-ordinates is more like an image, text or sound rather than...a database. Or why if that database contains a Substantial portion of the source Database it is not a Derivative Database. The biggest blank on the page is therefore any explanation of why a derivative database becomes a produced work if we call the queries used to produce it geocoding rather than Extraction. :-/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT9iF/AAoJECciMUAZd2dZrAoH/279WkdDxayizW3HTlxTeu1P EdwVdGE3wt/j5hMnPw3aJvHUl3AYNyOlmPlAhwJDHJTw+C3m9q9YldMU2fmx+kkr ZjYntIUfZsnZ1EHFl/Wj8Vx8EUaJjU/qhc1C0PYNpZXS1I9Xeb54BXmLGqwnp988 I1cyq3P1PgoDlzFU2eio6m61lOKPVqXxQCuegpbrkBqcCzCbHmwd/Km39iV4vfu8 icoEzwpgtl4v67HhFZkXtgeQY06xcHjH6641+hVZCYE16ozAsVFevW8a+urUbmkn B921qizR2SsB0yi/O74RRQNehgCTGrcToKzLP5oEKfjopBI2w1p9dM+Uc7ydd1s= =F2f1 -END PGP SIGNATURE- ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Rob, On 08/21/2014 06:42 PM, Rob Myers wrote: It would be great if people would help fill in the blanks, or correct me where I might have misrepresented the discussion. The page asserts: Geocodes are a Produced Work [...] The rest of the page then silently slips [...] I have tried to present the two different viewpoints in two columns. On the left is Alex' original version which claims what you summarized in your message (that geocodes are produced works etc.); on the right is a version that explicitly claims A database of Geocodes is a derivative database by the definition of the ODbL - which seems to be exactly the statement that you were aiming at, no? The blanks that need filling are the consequences of this different interpreatation for the various use cases. I added one for use case #1, but only an empty column for use cases #2-#4 and #7. I added no extra column for #5 and #6 because those struck me as identical under both interpretations but of course I might be wrong. 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
Hi, On 07/25/2014 11:39 AM, Simon Poole wrote: As I've said before, I'm not convinced that trying to better define and clarify the issue by invoking the produced work clauses will lead to a satisfactory result. I would suggest that at least a comparison (for all your use cases) with a model based on the information that is used for geocoding is subject to share alike, but nothing else (which has been suggested in this discussion and previously a number of times). I have made a start on this comparison by adding a second column to https://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guideline outlining the position/results of the stuff used for geocoding makes a derivative database but only that and not the additional info approach. I call it the collective database alternative because the idea is that your proprietary data (store opening times or whatnot) form a collective database with the ODbL-Share-Alike location data. It would be great if people would help fill in the blanks, or correct me where I might have misrepresented the discussion. 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
[OSM-legal-talk] Updated geocoding community guideline proposal
Hello A few days ago I commented But what discussion on legal-talk does not provide is a mechanism for ascertaining a representative community opinion on the spirit of the license; nor a legally qualified opinion on interpretation options; nor a governance mechanism for resolving the proposal ultimately one way or another. I'm not aware if any process is defined for making a decision on this use case. (If one does exist, apologies that I missed it, and I'd appreciate anything that could bring clarity.) I have subsequently read this comment from Simon Poole, which seems to address my comment in some loose form, but not directly. And I must admit, it has only confused me further. From a LWG pov I believe the process we are trying to go through is: looking at some real life use cases, determine how to model best the workings of the ODbL in these and whatthe consequences and effects on third party data are. Staying within the spirit of the licence and hearing arguments from the stakeholders in doing so. That is very different from asking us, or a lawyer: this is the desired outcome, please figure out a way to make some arguments that support it. The former, if you so will, is similar to proceedings of a court, and the result is case law, the later is more a lawyer arguing the case in front of the bench. If it is the understanding of the OSM Foundation, that the Legal Working Group in some ways functions like a Court, then there are several issues to raise about the separation of concerns, checks and balances if you will, in this process as we've witnessed it. * How is the composition of the Legal Working Group formed? * Is anyone on the LWG able to sit in judgement? * Does the LWG itself consult with legal counsel when trying cases? Are there any lawyers on the LWG? * How is the spirit of the license determined? Is this the consensus opinion of the LWG? Voted opinion of the Board? Polled opinion of OSMF members? * How are the broad range of opinions regarding intention of the ODbL balanced within the spirit of the license? * The OSMF itself has repeated asked lawyers to help us reach a desired outcome over the years, the result of which was the ODbL. Why did the OSMF have a desired outcome previously, but no longer has one regarding Geocoding? * Do the OSMF officers in this discussion have a desired outcome regarding Geocoding, and does that prejudice their judgement when trying this use case? * How can we manage conflict of interest in the process of deciding on ODbL use cases? Again, I think the OSMF would best serve the OSM community by considering the governance questions above, and bringing clarity and fairness to the process. Sincerely Mikel ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Am 03.08.2014 16:16, schrieb Mikel Maron: ... If it is the understanding of the OSM Foundation, that the Legal Working Group in some ways functions like a Court, then there are several issues to raise about the separation of concerns, checks and balances if you will, in this process as we've witnessed it. Nobody (outside of yourself) even remotely implied that the LWG is a court. The analogy holds in so far as the LWG doesn't make up new licence terms as it goes along, just as a court doesn't on the fly make new laws. Both simply operate in the legal context as is. * How is the composition of the Legal Working Group formed? * Is anyone on the LWG able to sit in judgement? * Does the LWG itself consult with legal counsel when trying cases? Are there any lawyers on the LWG? * How is the spirit of the license determined? Is this the consensus opinion of the LWG? Voted opinion of the Board? Polled opinion of OSMF members? Mikel given that you know the answers better than anybody else reading this, could you stop asking rhetorical questions just for the effect. * How are the broad range of opinions regarding intention of the ODbL balanced within the spirit of the license? Is there a broad range of opinions on the spirit of the licence? I doubt it, there is a a broad range of opinions on if the specific licence was the right choice, but that is not the same. That said, I don't think there can be any doubt that the ODbL was designed as a replacement for CC by-SA, a licence with very strong share alike provisions, that actually worked for data. Implying that everybody involved at the time (aka you) knew that this meant that share alike would actually work with the ODbL. * The OSMF itself has repeated asked lawyers to help us reach a desired outcome over the years, the result of which was the ODbL. Why did the OSMF have a desired outcome previously, but no longer has one regarding Geocoding? The OSMF is contractually bound to only change the licence on certain terms. You seem be saying (repeatedly) screw the contract and just lets do what will currently get us the best press. But every single contributor clearly has the right to demand that we follow the licence change process and that we don't circumvent it by changing the nature of the licence (see above) outside of clarifying the effects of certain use and edge cases. And just to make it clear: that implies that even if 99.9% of all contributors voted yes in a poll to add a guideline that SA does not apply to extracts of OSM data, it would still not fly. Changes to the licence -have- to be either go through the licence change process or via a revision of the licence itself. * Do the OSMF officers in this discussion have a desired outcome regarding Geocoding, and does that prejudice their judgement when trying this use case? Again you are trying to play rhetoric games. If you are asking me, the answer would be: the desired outcome is a guideline that clarifies what is affected by share alike in typical geocoding use cases and what is not without creating loopholes around our current licence. * How can we manage conflict of interest in the process of deciding on ODbL use cases? Again, a you are beating your wife rhetoric pseudo trick. I don't believe anybody on the board or on the LWG is in a conflict of interest situation. Again, I think the OSMF would best serve the OSM community by considering the governance questions above, and bringing clarity and fairness to the process. And yet another you are beating your wife. it is difficult to imagine a process that is more open and fair than what we going through now. Simon signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Admin note: nominally I'm administrator of the legal-talk@ list. In practice the only international OSM list to ever have been announced as moderated is talk@, and I think locally talk-us@ may be moderated as well. Merely administered is a much more light-touch approach and generally works well enough. However, Mikel's posting raises an important meta issue which as administrator I'd like to clarify: Mikel Maron wrote: * How is the composition of the Legal Working Group formed? * Is anyone on the LWG able to sit in judgement? * Does the LWG itself consult with legal counsel when trying cases? Are there any lawyers on the LWG? * How is the spirit of the license determined? Is this the consensus opinion of the LWG? Voted opinion of the Board? Polled opinion of OSMF members? * How are the broad range of opinions regarding intention of the ODbL balanced within the spirit of the license? * The OSMF itself has repeated asked lawyers to help us reach a desired outcome over the years, the result of which was the ODbL. Why did the OSMF have a desired outcome previously, but no longer has one regarding Geocoding? * Do the OSMF officers in this discussion have a desired outcome regarding Geocoding, and does that prejudice their judgement when trying this use case? * How can we manage conflict of interest in the process of deciding on ODbL use cases? There are 12 questions here, and they appear to be principally addressed to the volunteers who give their time to LWG in particular and the wider OSMF. Mailing lists are open forums. By definition, list messages (unlike private mail) are addressed to all the members of the list, not to a small subset of that. Demanding answers from a small number of people to 12 rather involved questions is not the purpose of a public mailing list. As list admin, I am not very comfortable with the notion of using this public list as a direct communication channel to OSMF rather than a general forum for discussion of legal/licensing issues. If such a list exists then it's osmf-talk; I will leave the discussion of that to whoever might be osmf-talk admin. It is not, however, the purpose of legal-talk, and as admin I certainly didn't volunteer to run a talk to OSMF communication channel (not least because I'm not even an OSMF member these days ;) ). With my list admin hat off, but taking the opportunity to make a wider etiquette point, I would gently remind people that OSM and OSMF are created and run by volunteers; volunteers' time and motivation are finite resources; and it is kinder to be proportionate in your demands on these volunteers. Do question, probe, discuss, but 12 questions at once is a bit Sybil Fawlty: Anything else, dear? I mean, would you like the hotel moved a bit to the left? cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/OSM-legal-talk-Updated-geocoding-community-guideline-proposal-tp5813533p5813560.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
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/07/14 08:46 AM, Martin Koppenhoefer wrote: Il giorno 30/lug/2014, alle ore 16:44, Alex Barth a...@mapbox.com mailto:a...@mapbox.com ha scritto: your lawyers did really say according to their understanding a pair of coordinates is similar to an image or a video, hence a work? Yeah, there's no definition of 'work' in the ODbL, just a non-exclusive list of examples in the definition of Produced Work. The examples have a certain flavour though. yes, but there is also a definition of derivative database, into which geocoding results seem to fit perfectly. In particular a database of geocoding results. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJT2eVAAAoJECciMUAZd2dZV/8IAMkuDERtaSP1BwC0j2N/UMog 8ndzRQ3YHpNsLv/eFrd/5jx/T/S+iAv2kbCe4dEDql1Gagu4Ex5lSZpiPGeicDwF NJ3qS96kQv6Ns4rfHh1tBBLOMLNJTLmjgs5XragDaJ319va4xXoo0oTkamZw5yNn 4aEHeLYcx0VtuySTMZ3oiBwRdn0JvasvHY1m9Lt0DJr+qDQgt5F1D+VmPV6OZ1TJ 5Z14q9r+Tz3G3f9neNUWHJdmDq8BN1mL0Fz14fzuOD6BnDR86RFw7U31/0e2Og4L MhqPz2J7OcSG5xTEtQ1QkrXBjshb69m1BWjS7Y0JOu2mZpYPymIkoVvinzUy6uo= =LPte -END PGP SIGNATURE- ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Hello, Our lawyers' advice is captured in the guideline as shared and posted in this revision: https://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guidelineoldid=1060775 Just to clarify, the above is what your lawyers sent you, except for formatting changes to place it into a Wiki format? 'Geocoding as it pertains to this guideline is a process by which external data is used to construct a query by which an OpenStreetMap database is searched. The result of the Geocoding query is one or more Geocodes. Geocodes are then stored either permanently or temporarily together with the external data used for querying. Geocodes can be latitude/longitude pairs, full or partial addresses and or point of interest names. Geocodes are a Produced Work by the definition of the ODbL' That means that every other mapping project in the world gets that any way he wants, right?:) In example, if I someone wants to add to a project ABC all McDonald's localizations from all over the world, he just queries OSM (query: McDonald), places the result (lat/lon+full addresses) in his database, and adds an attribution I used some OSM data (a cron job would do well). Same with addressing in country X, Y or Z (and the attribution is already there!:). Sounds good. You just need to have some vector data with roads, the rest goes from OSM as a Produced Work. Regards, Tadeusz ___ 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 Wed, Jul 30, 2014 at 12:31 AM, Paul Norman penor...@mac.com wrote: On 7/28/2014 12:07 AM, Alex Barth wrote: On Mon, Jul 28, 2014 at 7:30 AM, Paul Norman penor...@mac.com wrote: Please review: https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline Alex, you mention it was based on what you've gotten from lawyers. Is there anything that can be shared, either publicly, or with the LWG for when they consider the guideline? Our lawyers' advice is captured in the guideline as shared and posted in this revision: https://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guidelineoldid=1060775 Just to clarify, the above is what your lawyers sent you, except for formatting changes to place it into a Wiki format? The above is not what our lawyers sent us, it's the translation into community guidelines of what our lawyers told 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 Mon, Jul 28, 2014 at 12:04 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 28/lug/2014 um 09:07 schrieb Alex Barth a...@mapbox.com: Our lawyers' advice is captured in the guideline as shared and posted in this revision: your lawyers did really say according to their understanding a pair of coordinates is similar to an image or a video, hence a work? Yeah, there's no definition of 'work' in the ODbL, just a non-exclusive list of examples in the definition of Produced Work. “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. - See more at: http://opendatacommons.org/licenses/odbl/1-0/#sthash.JPKZj3yo.dpuf ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Il giorno 30/lug/2014, alle ore 16:44, Alex Barth a...@mapbox.com ha scritto: your lawyers did really say according to their understanding a pair of coordinates is similar to an image or a video, hence a work? Yeah, there's no definition of 'work' in the ODbL, just a non-exclusive list of examples in the definition of Produced Work. yes, but there is also a definition of derivative database, into which geocoding results seem to fit perfectly. cheers, Martin___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Am 27.07.2014 23:52, schrieb Alex Barth: On Fri, Jul 25, 2014 at 11:39 AM, Simon Poole si...@poole.ch mailto:si...@poole.ch wrote: If you apply this to your above example, the addresses would be subject to SA (however no further information), and while potentially one could infer that these are likely the addresses of the store locations, no further information would needed to be disclosed*. So I think I follow: in a database of store locations [1], where coordinates have been added through OSM-based geocoding, only the coordinates (latitude/longitude pairs) from OpenStreetMap are subject to share alike. The store names, street names, house numbers, etc. wouldn't be subject to share alike, they didn't come through the OSM-based geocoder - nor any coordinates that haven't been added through the OSM-based geocoder. Actually in the model what was used to extract the coordinates from OSM -would- be subject to share alike. In the example the resulting address/coordinate dataset. So you would end with a database of geocoded addresses, subject to the ODbL that then could be used to locate your proprietary data. As I've said, the advantage of the model is it only depends on recognizing a couple of principles - the Fairhurst Doctrine (http://wiki.openstreetmap.org/wiki/Open_Data_License/Metadata_Layers_-_Guideline), or whatever you want to call it - and likely allowing https://wiki.openstreetmap.org/wiki/Open_Data_License/Community_Guidelines/Fall_Back and not on making a determination if the way the data is used is still compatible with it being a produced work. A note on the later, the LWG guidance on produced works is deliberately liberal because we wanted to include products delivered to the end user and not primarily intended for further processing and distribution in that category, even if they nominally could be considered databases. While this reading is better than the uncertainty we have now it is not practical beyond well informed users. To appropriately handle geocoding under this practice, a geocoder application would not only have to expose on a granular level where data was sourced from [2] - but a geocoder user would have to store this information in a granular way to be able to release data appropriately. I think you will find that this would be expected even in your model (given that the attribution requirements are essentially the same). If you would differentiate each individual result or just have a blanket statement that is always displayed is likely just a matter of taste. Simon signature.asc Description: OpenPGP digital signature ___ 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 7/28/2014 12:07 AM, Alex Barth wrote: On Mon, Jul 28, 2014 at 7:30 AM, Paul Norman penor...@mac.com mailto:penor...@mac.com wrote: Please review: https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline Alex, you mention it was based on what you've gotten from lawyers. Is there anything that can be shared, either publicly, or with the LWG for when they consider the guideline? Our lawyers' advice is captured in the guideline as shared and posted in this revision: https://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guidelineoldid=1060775 Just to clarify, the above is what your lawyers sent you, except for formatting changes to place it into a Wiki format? ___ 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 Sat, Jul 26, 2014 at 11:02 PM, Frederik Ramm frede...@remote.org wrote: Again and again we hear, make it easier for people to geocode their proprietary databases and OSM can only benefit from it because everyone who saves $$ using OSM somehow magically helps OSM. I'm not convinced of that. One could say the same about the permissive parts of OpenStreetMap today. But there are companies today who're using OpenStreetMap and who are playing an active role to improve the database directly or indirectly (think software, event sponsoring). Interestingly, I have yet to see a company that supports OpenStreetMap as a need of following the letter of the ODbL. There aren't exactly tons of announcements of new ODbL datasets. In addition, even if companies, non profit organizations or governments decide to use but not actively support OpenStreetMap at all, they typically bring OpenStreetMap to broad audiences at a time, and expose OpenStreetMap to more potential individual contributors. What I'm seeing is an attractive OpenStreetMap to participate in, with great reasons to contribute and a growing group of institutional data users with huge opportunities to do so - and already doing so. But right now we're stuck insisting in one very particular way to contribute - and that way isn't defined all too well and it impedes the use of OpenStreetMap for a key use case: geocoding. ___ 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 28, 2014 at 7:30 AM, Paul Norman penor...@mac.com wrote: Please review: https://wiki.openstreetmap.org/wiki/Open_Data_License/ Geocoding_-_Guideline Alex, you mention it was based on what you've gotten from lawyers. Is there anything that can be shared, either publicly, or with the LWG for when they consider the guideline? Our lawyers' advice is captured in the guideline as shared and posted in this revision: https://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guidelineoldid=1060775 ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Am 28/lug/2014 um 09:07 schrieb Alex Barth a...@mapbox.com: Our lawyers' advice is captured in the guideline as shared and posted in this revision: your lawyers did really say according to their understanding a pair of coordinates is similar to an image or a video, hence a work? The whole interpretation in this example turns around this sentence but it isn't quite self explaining: The guideline Geocodes are a Produced Work by the definition of the ODbL (section 1.) cheers, Martin___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Hello, 2014-07-28 7:19 GMT+02:00 Eric Gundersen e...@mapbox.com: Accuracy is what matters, not skimping on a few $. We have dozens of large companies like this that would love to more tightly integrate their internal data with OSM via goecoding, but because of unclear guidelines are blocked. Well, in fact (IMHO) there's no unclear guidelines, as the license is quite clear in terms of Derivative Database licensing. Whether or not is it is subject to change, at this moment (ODbL v1.0) a Derivative Database has to be an ODbL database. What I'm not clear is if community guidelines are strong enough to able to change it without touching the license itself Or, trying to consider a database with geocoding data a Produced Work makes me wonder what type of substantial (I guess we're talking country-wide at least?) extract of the whole database _isn't_ a Produced Work anymore. Regards, Tadeusz ___ 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 28, 2014 at 1:19 AM, Eric Gundersen e...@mapbox.com wrote: Let's not kid ourselves here. The overwhelming number of commercial OSM users are not driven by a motivation to help us, but by a motivation to save money (or perhaps a motivation to escape a monopolist's clutch but that boils down to the same). Frederik, saving money is not the point, it's all about having great data that is supported by a community. Every day I'm talking to commercial companies interested in _paying_ Mapbox because they truly believe we have the best map (power by OpenStreetMap), and the people at these companies believe in a future of open data where the map continues to grow thanks to being open. Mapbox is working with companies from foursquare to Pinterest to the Financial Times to VK.com (https://www.mapbox.com/showcase). These few sites alone are used by hundreds of millions of people looking at beautiful OpenStreetMap data, and location and thus the map, is critical for each app. Accuracy is what matters, not skimping on a few $. We have dozens of large companies like this that would love to more tightly integrate their internal data with OSM via goecoding, but because of unclear guidelines are blocked. +1 Any company I'm aware of interested in OSM is not trying to save money, they're interested in the promise of better quality that you get from a community (of individuals and companies if they're welcome). In fact many companies with plenty of money are hurting for the lack of a truly global geocoder. There is no single source for this, especially outside the US. Try to find one and pay them: you can't. To be clear: OSM is far from ready to provide a high-quality global geocoder. It works pretty well in NYC and I was glad to see how well it worked in Karlsruhe :) but there's a serious lack of address data globally. So the problem is not that it's a great source of geocoding data that we're prevented from using because of licensing. The problem is that there's about to be a lot of resources, effort, and attention focused on this problem, and it would be great to do this within OSM. There are alternatives though such as OpenAddresses. Back to my original comment, if it we're 2010 and I had significant resources to invest in this problem, where would I best do it? Again -- it's fine if it's not OSM, should just come out with a strong statement from the board either way. -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
Hi, On 07/28/2014 12:07 PM, Tadeusz Knapik wrote: What I'm not clear is if community guidelines are strong enough to able to change it without touching the license itself There's a couple sides to this. OSMF is limited to distributing the data under ODbL or CC-By-SA as per the contributor terms; using any other license would require a license change process as outlined in the contributor terms. Now where the ODbL leaves wriggle room, OSMF can to a certain degree interpret the license. Since OSMF are the ones who would have to sue you if you ignore the license, if OSMF say it is our interpretation that so-and-so is ok then you are relatively safe in trusting them. However, if OSMF were to take too many liberties in interpreting the license, and if someone were to make the point that what OSMF distributes the data under is not the ODbL as it was intended, but instead some ODbL with OSMF bells and whistles, then that could nullify the license that OSMF itself has been granted by the mappers. It is quite possible that a lawyer who was asked to assert whether a certain wriggle room exists or not, would not only look at the letter of the license but also at the process that has led to its implementation, or in other words, at the intention that people had when they implemented the license. And that, in turn, is probably why we're talking so much about use cases and do-we-want-this and do-we-want-that... 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 7/28/2014 6:31 AM, Frederik Ramm wrote: Hi, On 07/28/2014 12:07 PM, Tadeusz Knapik wrote: What I'm not clear is if community guidelines are strong enough to able to change it without touching the license itself There's a couple sides to this. OSMF is limited to distributing the data under ODbL or CC-By-SA as per the contributor terms; using any other license would require a license change process as outlined in the contributor terms. It's also important to remember that there is also a significant amount of third-party data in OSM under the ODbL or compatible licenses, and the OSMF's guidelines are of limited influence there. This is one reason why I was particularly concerned when companies were failing to meet ODbL attribution requirements[1], as it wasn't just OSM contributor rights which were being infringed, but also the third party rights. [1]: http://wiki.osmfoundation.org/wiki/Board_Meeting_Minutes_2013-12-10#6._Attribution ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
I would like to add my voice to this discussion. I strongly believe that within the intended spirit of the OSM license, geocoding as defined in this proposal should _not_ trigger share alike. I also believe that the legal interpretation proposed has merit, but if legal advice suggests another means in which to capture this spirit, I would support that as well. As a former OSMF Board member and a member of the OSM community for 9 years, I believe my voice should carry weight in this discussion. Other current and former Board members, and prominent members of the OSM community, have also lent their weighty voices to this discussion. That's excellent, this is the purpose of legal-talk, it has been very enlightening on this issue. But what discussion on legal-talk does not provide is a mechanism for ascertaining a representative community opinion on the spirit of the license; nor a legally qualified opinion on interpretation options; nor a governance mechanism for resolving the proposal ultimately one way or another. I'm not aware if any process is defined for making a decision on this use case. (If one does exist, apologies that I missed it, and I'd appreciate anything that could bring clarity.) The OpenStreetMap Foundation, famously, supports but does not control the OpenStreetMap project. In this situation, I believe this would mean devising a governance structure to help answer such questions, and request that the OSMF in one form or another prioritize this issue. I hope that such can take shape soon, so that the topic of geocoding and other topics can be efficiently and finally resolved. Sincerely Mikel * Mikel Maron * +14152835207 @mikel s:mikelmaron On Thursday, July 24, 2014 5:04 PM, Alex Barth a...@mapbox.com wrote: On Sat, Jul 12, 2014 at 2:30 AM, Paul Norman penor...@mac.com wrote: Consider a chain retailer's database of store locations with store names and addresses (street, house number, ZIP, state/province, country). The addresses are used to search corresponding latitude / longitude coordinates in OpenStreetMap. The coordinates are stored next to the store locations in the store database (forward Geocoding). OpenStreetMap.org's Nominatim based geocoder is used. The store locations are being exposed to the public on a store locator map using Bing maps. The geocoded store locations database remains fully proprietary to the chain retailer. The map carries a notice (c) OpenStreetMap contributors linking to http://www.openstreetmap.org/copyright. In this example, the database powering the geocoder is a derived database. The geocoding results are produced works, which are then collected into what forms a derivative database as part of a collective database. Not following how I can make a Derivative Database from a Produced Work. Once it's a Produced Work it's a Produced Work, right? Sure if I abuse to recreate OSM that's one thing, but at this level? Taking a step back, is the above use case not one we'd like to support without triggering share alike? I'm directing my question to everyone, not just Paul who's taken the time to review my example above. Forward and reverse geocoding existing records is such a huge potential use case for OSM, helping us drive contributions. At the same time it's _the_ use case of OSM where we collide heads on with the realities and messiness of data licensing: Do we really want to make a legal review the hurdle of entry for using OSM for geocoding? Or limit using OSM for geocoding in areas where no one's ever going to sue? How can we get on the same page on how we want geocoding to work and then trace back on how we can fit this into the ODbL? Geocoding should just be possible and frictionless with OSM, no? Shouldn't there be a way to open up OSM to geocoding while maintaining share alike on the whole database? I feel we don't get anywhere by reading the tea leaves of the ODbL - what do we really want for OSM on geocoding? Alex (and yes, when I'm saying geocoding I'm referring to permanent geocoding here, where the geocoding result winds up being stored in someone else's db) ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
I would like to add my voice to this discussion. I strongly believe that within the intended spirit of the OSM license, geocoding as defined in this proposal should _not_ trigger share alike. I also believe that the legal interpretation proposed has merit, but if legal advice suggests another means in which to capture this spirit, I would support that as well. As a former OSMF Board member and a member of the OSM community for 9 years, I believe my voice should carry weight in this discussion. Other current and former Board members, and prominent members of the OSM community, have also lent their weighty voices to this discussion. That's excellent, this is the purpose of legal-talk, it has been very enlightening on this issue. But what discussion on legal-talk does not provide is a mechanism for ascertaining a representative community opinion on the spirit of the license; nor a legally qualified opinion on interpretation options; nor a governance mechanism for resolving the proposal ultimately one way or another. I'm not aware if any process is defined for making a decision on this use case. (If one does exist, apologies that I missed it, and I'd appreciate anything that could bring clarity.) The OpenStreetMap Foundation, famously, supports but does not control the OpenStreetMap project. In this situation, I believe this would mean devising a governance structure to help answer such questions, and request that the OSMF in one form or another prioritize this issue. I hope that such can take shape soon, so that the topic of geocoding and other topics can be efficiently and finally resolved. Sincerely Mikel ___ 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 Fri, Jul 25, 2014 at 11:39 AM, Simon Poole si...@poole.ch wrote: If you apply this to your above example, the addresses would be subject to SA (however no further information), and while potentially one could infer that these are likely the addresses of the store locations, no further information would needed to be disclosed*. So I think I follow: in a database of store locations [1], where coordinates have been added through OSM-based geocoding, only the coordinates (latitude/longitude pairs) from OpenStreetMap are subject to share alike. The store names, street names, house numbers, etc. wouldn't be subject to share alike, they didn't come through the OSM-based geocoder - nor any coordinates that haven't been added through the OSM-based geocoder. While this reading is better than the uncertainty we have now it is not practical beyond well informed users. To appropriately handle geocoding under this practice, a geocoder application would not only have to expose on a granular level where data was sourced from [2] - but a geocoder user would have to store this information in a granular way to be able to release data appropriately. [1] Chain Retailer example (number 1): https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline [2] Assuming a complex geocoder with a fallback to appropriate third party data. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Let's not kid ourselves here. The overwhelming number of commercial OSM users are not driven by a motivation to help us, but by a motivation to save money (or perhaps a motivation to escape a monopolist's clutch but that boils down to the same). Frederik, saving money is not the point, it's all about having great data that is supported by a community. Every day I'm talking to commercial companies interested in _paying_ Mapbox because they truly believe we have the best map (power by OpenStreetMap), and the people at these companies believe in a future of open data where the map continues to grow thanks to being open. Mapbox is working with companies from foursquare to Pinterest to the Financial Times to VK.com (https://www.mapbox.com/showcase). These few sites alone are used by hundreds of millions of people looking at beautiful OpenStreetMap data, and location and thus the map, is critical for each app. Accuracy is what matters, not skimping on a few $. We have dozens of large companies like this that would love to more tightly integrate their internal data with OSM via goecoding, but because of unclear guidelines are blocked. On Sun, Jul 27, 2014 at 2:52 PM, Alex Barth a...@mapbox.com wrote: On Fri, Jul 25, 2014 at 11:39 AM, Simon Poole si...@poole.ch wrote: If you apply this to your above example, the addresses would be subject to SA (however no further information), and while potentially one could infer that these are likely the addresses of the store locations, no further information would needed to be disclosed*. So I think I follow: in a database of store locations [1], where coordinates have been added through OSM-based geocoding, only the coordinates (latitude/longitude pairs) from OpenStreetMap are subject to share alike. The store names, street names, house numbers, etc. wouldn't be subject to share alike, they didn't come through the OSM-based geocoder - nor any coordinates that haven't been added through the OSM-based geocoder. While this reading is better than the uncertainty we have now it is not practical beyond well informed users. To appropriately handle geocoding under this practice, a geocoder application would not only have to expose on a granular level where data was sourced from [2] - but a geocoder user would have to store this information in a granular way to be able to release data appropriately. [1] Chain Retailer example (number 1): https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline [2] Assuming a complex geocoder with a fallback to appropriate third party data. ___ 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
On 7/10/2014 7:52 PM, Alex Barth wrote: Please review: https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline The next step is probably to update this page to represent what there is consensus on out of the discussions and remove what there isn't consensus on. Anyone want to have a go? Alex, you mention it was based on what you've gotten from lawyers. Is there anything that can be shared, either publicly, or with the LWG for when they consider the guideline? ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/07/14 04:38 PM, Jake Wasserman wrote: I agree that geocoded private data must be allowed to stay private. The ODbL goes to great lengths to explain that it only covers publicly released data. At a minimum, we need to find a way to say actively reverse engineering the database can trigger share alike, but the ability to reverse engineer it does not. OK. But we also need to find a way of saying that if that ability leads to that result then there isn't a defence of being surprised. A lot of the responses here just say to not cross the Substantial threshold. That feels like a total cop out - an argument saying OSM and its users should remain small and insubstantial... which doesn't seem to align with our goals. That's something of a conceptual slippage. OSM and its users should become large and substantial (as it were...). Non-free exploitation of the resulting data should not. The fact that we’re scaring away well-intentioned users is sad. Well-intentioned users don't want to circumvent the license in order to recreate substantial sections of it for non-free use. By definition. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJT00kHAAoJECciMUAZd2dZRncH/1R2YvZg8/N+6mCBtEW6HJvw znnCYeYgaK88fRVAvqpZ7bdXQBb9yN0Tbx/Xewoop6dZEp4XSMO4EezciM4kS341 e3mm6XuUiJy+3zYL+qBxjSE/zPmMI/fINM0wR3Tc3w3yT/cU61stSd6ux2bwFNJJ Aa7C0kgkXfV2ItSbBBH6GN0PWkMC4+1fkVe4fEnbgWrT6tF3KlSF4+cKmIALuMc3 ACEyVJUgKCiy4UXXXPF6oRn031gF5GgkXIMnLChLE5HL4DlCWTlLCNPvLIz2N9T6 WKKIp+4hsEs1J5a7Rv5Akl6aE7QVHeA1+YzCYB/dAXe13o0hBa+HY3tPzNaTMzA= =Nqb5 -END PGP SIGNATURE- ___ 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/26/2014 01:38 AM, Jake Wasserman wrote: The fact that we’re scaring away well-intentioned users is sad. Let's not kid ourselves here. The overwhelming number of commercial OSM users are not driven by a motivation to help us, but by a motivation to save money (or perhaps a motivation to escape a monopolist's clutch but that boils down to the same). There is potential for an alignment of interests here - OSM wants more exposure, business wants to save money, win-win - but I wouldn't go so far as to label this as good intentions on the part of the business. There is a very, very small number of businesses who use our data and who go above and beyond what we require of them because they really believe in the idea of OSM. Businesses who come to us and ask how they can help, and who see the good in OSM even beyond their immediate use case which might be hampered by our license. *Those* are the ones for which I would reserve the term well-intentioned. By my definition, if you are scared away from OSM because you can't geocode your proprietary data for free, then your good intentions were maybe a bit too superficial. Also, keep in mind that lowering our requirements will lower them for *everyone*, not only the well-intentioned. Company X runs a restaurant guide that displays star-rated restaurants along your chosen journey. They pay lots of $$$ for geocoding their restaurant database. What we're discussing here is letting them switch to OSM for geocoding and the only thing we might get in return is a mention in an about box somewhere. There is no guarantee that this will do *anything* for OSM's exposure or to improve OSM's data, not even to provide an incentive to improve OSM data. Again and again we hear, make it easier for people to geocode their proprietary databases and OSM can only benefit from it because everyone who saves $$$ using OSM somehow magically helps OSM. I'm not convinced of that. 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 Thu, Jul 24, 2014 at 5:03 PM, Alex Barth a...@mapbox.com wrote: Taking a step back, is the above use case not one we'd like to support without triggering share alike? I'm directing my question to everyone, not just Paul who's taken the time to review my example above. Thanks for taking the time to bring this forward. I agree that geocoded private data must be allowed to stay private. At a minimum, we need to find a way to say actively reverse engineering the database can trigger share alike, but the ability to reverse engineer it does not. A lot of the responses here just say to not cross the Substantial threshold. That feels like a total cop out - an argument saying OSM and its users should remain small and insubstantial... which doesn't seem to align with our goals. The fact that we’re scaring away well-intentioned users is sad. What else can we do to help this cause? -Jake On Fri, Jul 25, 2014 at 5:39 AM, Simon Poole si...@poole.ch wrote: Am 24.07.2014 23:03, schrieb Alex Barth: ... Taking a step back, is the above use case not one we'd like to support without triggering share alike? I'm directing my question to everyone, not just Paul who's taken the time to review my example above. IMHO the example is slightly flawed as to illustrating things that we wouldn't want to be affected by share alike. I expect if you ask a wider audience, the answer is likely to be: yes, we would like (aka it is in the spirit of the ODbL) the store locations to be freely available and potentially to be added to the OSM data, given that this is classical OSM content. Most of the discussions around this issue in the past have revolved around additional meta data present in the geocoded database (for example lets say the list of employees at that location) and if -that- would be effected by share alike. And I expect that you would likely find a majority of the community which would same it is fair game for that to remain unaffected. Naturally this is just my gut feeling on the sentiments of the wider OSM community. Back to the general issue of the proposed guideline. As I've said before, I'm not convinced that trying to better define and clarify the issue by invoking the produced work clauses will lead to a satisfactory result. I would suggest that at least a comparison (for all your use cases) with a model based on the information that is used for geocoding is subject to share alike, but nothing else (which has been suggested in this discussion and previously a number of times). If you apply this to your above example, the addresses would be subject to SA (however no further information), and while potentially one could infer that these are likely the addresses of the store locations, no further information would needed to be disclosed*. Net effect essentially the same in practical terms as in your proposal, but without invoking produced work magic. Such a model has a further advantage that it makes trying to nail down the technicalities of at least forward geocoding less painful. For example the fact that the geocoder that you use in the examples actually returns object geometries aka the actual OSM objects in question. Simon ___ 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
Am 24/lug/2014 um 23:03 schrieb Alex Barth a...@mapbox.com: In this example, the database powering the geocoder is a derived database. The geocoding results are produced works, which are then collected into what forms a derivative database as part of a collective database. Not following how I can make a Derivative Database from a Produced Work. Once it's a Produced Work it's a Produced Work, right? I also see it like this, it would be a database of works (like a database of renderings) and not under ODbL, therefore I think the premise that a geocoding result is a produced work might already be flawed, because it seems natural that a database of results is a derivative database. cheers, Martin___ 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 Thu, Jul 24, 2014 at 5:03 PM, Alex Barth a...@mapbox.com wrote: Forward and reverse geocoding existing records is such a huge potential use case for OSM, helping us drive contributions. At the same time it's _the_ use case of OSM where we collide heads on with the realities and messiness of data licensing: Do we really want to make a legal review the hurdle of entry for using OSM for geocoding? Or limit using OSM for geocoding in areas where no one's ever going to sue? How can we get on the same page on how we want geocoding to work and then trace back on how we can fit this into the ODbL? Geocoding should just be possible and frictionless with OSM, no? Shouldn't there be a way to open up OSM to geocoding while maintaining share alike on the whole database? These are the key questions I support open geocoding with share alike applied to the whole database. How can we get clarity on this either way? Because not clarifying this is effectively saying no which I believe loses high-quality contributions. Clarifying with a no or not clarifying at all will direct a lot of effort elsewhere -- this is a shame. In a previous role I directed a lot of resources specifically toward OSM. With this continued lack of clarity, today I would direct them elsewhere. That's also a shame. (and yes, when I'm saying geocoding I'm referring to permanent geocoding here, where the geocoding result winds up being stored in someone else's db) To not support this is essentially saying that OSM is not to be used for geocoding in the majority of desired cases. But it comes down to what people want for the project, and where address-level effort will go. -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
lawyers are involved. But that shouldn't be more than an absolute minimum, and most importantly, it's something that should stand up against the letter and intent of the licence we all signed up to. Richard -- View this message in context: http://gis.19327.n5.nabble.com/OSM-legal-talk-Updated-geocoding-community-guideline-proposal-tp5811077p5811521.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
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
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
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Robert Whittaker (OSM lists) wrote 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 interpret it as quite the opposite and you are not adding any substantial amount of geographical information. You do query the db with external geo-data. But if the geocoder gives you a result, the information was (in this form) already in the OSM database and so you haven't added anything. If the data was not already in the OSM database, then the geocoder will not spit out any result and thus you haven't created any derived database (or anything else for that matter). So in either case, the result(s) from the geocoding process are pure OpenStreetMap data and there is no additional external geo-data added to the output. Therefore this process then also does not trigger the share-a-like clause in it self. And so as long as you don't use the resultant lat/lon in a way incompatible with the definition of produced work, geocoding itself is fine. -- View this message in context: http://gis.19327.n5.nabble.com/OSM-legal-talk-Updated-geocoding-community-guideline-proposal-tp5811077p5811673.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
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Hi, On 07/17/2014 01:25 AM, Kai Krueger wrote: 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. Indeed. If we were only talking about the enter your address here and we'll zoom the map to your location use case, we'd never be creating any database that contains OSM data in the first place. 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, I guess the most commercially interesting use case is: I have a bunch of POIs or properties or client addresses and I want to be able to compute, at any time, for a given lat/lon, which of these are in the vicinity. The archetypal where's the nearest pizza place application comes to mind. This requires augmenting my proprietary database with lat/lons from OSM, else I would have to on-the-fly geocode half my database every time I want to make a query which would be too expensive. In your own distinction of is this for human consumption or for a computer's, it is clearly for a computer's - since the coordinates form the basis for filtering which items to display to the user. A human wouldn't be able to sift through the list so quickly. 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
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
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Mon, Jul 14, 2014 at 8:44 AM, Alex Barth a...@mapbox.com wrote: On Sun, Jul 13, 2014 at 10:30 AM, Stephan Knauss o...@stephans-server.de wrote: Only when you start to use the process to systematically recreate a database from the process the ODbL kicks in. This is also how I'm reading this. Obviously the sticky point is the definition of what's a database in this sentence: systematically recreate a database from the process. You can't abuse geocoding to recreate OpenStreetMap without triggering share alike. The definition of 'substantial' is key here, isn't it? In one of the examples I added, the result of OSM-based geocoding actions would potentially be stored on a client in a collection of 'favorites' together with other favorites that may be the result of tainted geocoding. There's really two questions here - 1) is this collection of favorites 'substantial' and 2) does this mixed storage trigger share alike in an of itself? -- 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 2014-07-14 8:15 AM, Martijn van Exel wrote: On Mon, Jul 14, 2014 at 8:44 AM, Alex Barth a...@mapbox.com wrote: This is also how I'm reading this. Obviously the sticky point is the definition of what's a database in this sentence: systematically recreate a database from the process. You can't abuse geocoding to recreate OpenStreetMap without triggering share alike. The definition of 'substantial' is key here, isn't it? In one of the examples I added, the result of OSM-based geocoding actions would potentially be stored on a client in a collection of 'favorites' together with other favorites that may be the result of tainted geocoding. There's really two questions here - 1) is this collection of favorites 'substantial' and 2) does this mixed storage trigger share alike in an of itself? Given that any database of geocoding results is going to be clearly based upon the Database [OpenStreetMap], and that any interesting uses of OSM are probably going to substantial, I don't see the definition of it mattering. In most of the cases raised in the wiki page, there's a derivative database of geocoding results and some other non-derivative database of something not taken from OSM, e.g. non-OSM POIs with just an address. You then take this collection of data sources and create a produced work, e.g. a page showing what the user has showed. Once you start taking actual POI information from OSM, not just addresses, then your POI database will also be a derivative of OSM. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Also if we assume geocoding yields Produced Work the definition of Substantial doesn't matter. Taking a step back here. What do we want? From conversations around dropping share alike my impression was that there was a consensus around unlocking geocoding - even among share-alike advocates. Just like how CC-BY-SA created a grey area around the SA implications for the rendered map which wasn't good for OSM, ODbL does the same with permanent geocoding. To make OSM viable for geocoding we can't have its ODbL infecting the datasets it's used on. There are tons of geodatasets out there waiting to be geocoded and we should have clarity around the legal implications of doing that. More use of OSM for geocoding means more incentives to keep and maintain geocoding data (addresses, POIs, admin polygons) in OSM. Alex On Mon, Jul 14, 2014 at 11:34 AM, Paul Norman penor...@mac.com wrote: On 2014-07-14 8:15 AM, Martijn van Exel wrote: On Mon, Jul 14, 2014 at 8:44 AM, Alex Barth a...@mapbox.com wrote: This is also how I'm reading this. Obviously the sticky point is the definition of what's a database in this sentence: systematically recreate a database from the process. You can't abuse geocoding to recreate OpenStreetMap without triggering share alike. The definition of 'substantial' is key here, isn't it? In one of the examples I added, the result of OSM-based geocoding actions would potentially be stored on a client in a collection of 'favorites' together with other favorites that may be the result of tainted geocoding. There's really two questions here - 1) is this collection of favorites 'substantial' and 2) does this mixed storage trigger share alike in an of itself? Given that any database of geocoding results is going to be clearly based upon the Database [OpenStreetMap], and that any interesting uses of OSM are probably going to substantial, I don't see the definition of it mattering. In most of the cases raised in the wiki page, there's a derivative database of geocoding results and some other non-derivative database of something not taken from OSM, e.g. non-OSM POIs with just an address. You then take this collection of data sources and create a produced work, e.g. a page showing what the user has showed. Once you start taking actual POI information from OSM, not just addresses, then your POI database will also be a derivative of OSM. ___ 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
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. ___ 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-14 20:26 GMT+02:00 Alex Barth a...@mapbox.com: Just like how CC-BY-SA created a grey area around the SA implications for the rendered map which wasn't good for OSM, ODbL does the same with permanent geocoding. To make OSM viable for geocoding we can't have its ODbL infecting the datasets it's used on. There are tons of geodatasets out there waiting to be geocoded and we should have clarity around the legal implications of doing that. More use of OSM for geocoding means more incentives to keep and maintain geocoding data (addresses, POIs, admin polygons) in OSM. I think for what you want you should push for a license change, and not for guidelines... I also fail to understand how a database of coordinates could qualify as produced work. cheers, Martin ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/07/14 06:26 PM, Alex Barth wrote: Taking a step back here. What do we want? From conversations around dropping share alike my impression was that there was a consensus around unlocking geocoding - even among share-alike advocates. Just like how CC-BY-SA created a grey area around the SA implications for the rendered map which wasn't good for OSM, Which grey area was that? ODbL does the same with permanent geocoding. To make OSM viable for geocoding we can't have its ODbL infecting the datasets it's used on. Contrary to Microsoft's lovely old FUD, copyleft isn't infectious: it's heritable. ;-) The ODbL represents a major shift away from full-stack copyleft in order to address precisely the concerns that are being raised yet again here. I suspect this is a classic example of a good compromise being something that displeases everyone equally. Luis mentioned that there's case law for the concept of substantial. There's no mention of this on the current Wiki page. I think it would be productive to seek that out next. - - Rob. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTxHL7AAoJECciMUAZd2dZ31UIAK7vPZ5B5j9NVkbgVwYvA8h8 mYPt2l1+7/+sqYMpa8TLYubYaURWa096MLk+FQUcnteUWLy0mKDbVODydhU0WBhL t1sUehJjI0cHYZqE4TG54u8x1O/ADUGnCSJJwsTbuW3njXC2cMcRzkQf680zpBon pJkpoUWkwDE2M8dbbx9vmdoJMR3w847UD57bTINGy6azS/YyUFAL3FhqpyHa2gbZ ExowM2LadTEhQgFFAk5whCuOdzU3HYObfkS6YCKgzoDRMaZmMVCTecxbD4QXtF/C m2XlyLo/h9D/MrhxpPSAsWWHUdHWjWP2S7HqkSmiCQ7/zy17XdyWvug7SLKReTw= =/Vhb -END PGP SIGNATURE- ___ 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 12.07.2014 00:46, Martin Koppenhoefer wrote: Generally what I think about when reading geocoding: you'd take a list of addresses and use the database to localize (translate) them in geo coordinates. This seems to fit perfectly to the derivative db description: “Derivative Database” – Means a database 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. This includes, but is not limited to, Extracting or Re-utilising the whole or a Substantial part of the Contents in a new Database. - See more at: http://opendatacommons.org/licenses/odbl/1.0/#sthash.l1YXFGoW.dpuf So based on this interpretation you could do geocoding without any requirements (in terms of attribution or share-alike) as long as it is insubstantial. As a single geocode run returns only one, maybe a hand full of locations it's certainly insubstantial. So can be freely used. Only when you start to use the process to systematically recreate a database from the process the ODbL kicks in. Refer: 6.2 This License does not affect any rights of lawful users to Extract and Re-utilise insubstantial parts of the Contents, evaluated quantitatively or qualitatively, for any purposes whatsoever, including creating a Derivative Database (subject to other rights over the Contents, see Section 2.4). The repeated and systematic Extraction or Re-utilisation of insubstantial parts of the Contents may however amount to the Extraction or Re-utilisation of a Substantial part of the Contents. - See more at: http://opendatacommons.org/licenses/odbl/1-0/#sthash.zN2GeAfp.ZYQaM1VQ.dpuf Stephan ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
A general note on the examples: using Nominatim as the geocoder muddies the waters a bit too much in my opinion, given that with the default options nominatim returns far more than just coordinates. signature.asc Description: OpenPGP digital signature ___ 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 Fri, Jul 11, 2014 at 5:48 AM, Paul Norman penor...@mac.com wrote: On Jul 10, 2014, at 07:54 PM, Alex Barth a...@mapbox.com wrote: That collective database is then generally used to produce works that are a produced work of the database of geocoding results as part of a collective database. I find the definition of geocoding in the proposed guideline a bit too large: Geocodes can be latitude/longitude pairs, full or partial addresses and or point of interest names.. Wikipedia is more limited: Geocoding is the process of finding associated geographic coordinates (often expressed as latitude and longitude) from other geographic data, such as street addresses, or ZIP codes (postal codes). Or in your definition of geocodes, only the coordinates are coming from OSM ? The risk of course is to create a full extract of all addresses/coordinates /POI's in OSM without the share-alike just because it's done through a geocoding process . How can we prevent this ? Pieren ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Hello Alex, Alex Barth writes: I just updated the Wiki with a proposed community guideline on geocoding. Please review: https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline Thank you for working on these legal guidelines. A task the typical developer is not keen to work on. A while ago there was a discussion about the word geocode which seems to be a trademark in some jurisdictions. So opposed to the general term geocoding the word geocode might need to be used with care. http://wiki.openstreetmap.org/wiki/Geocode_Trademark http://en.wikipedia.org/wiki/Geocoding The document itself describes nicely what use creates a produces work and what a derived database. Is it correct that from a legal point of view the ODbL already protects people from circumventing the share-alike by recreating the database from multiple produced works? I think it did. Still it might be worth mentioning in the guidelines that a large scale geocoding with the purpose to recreate a substantial part of the original database is no longer a produced work but a derived database and triggers ODbL share-alike. Stephan ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Am 11.07.2014 14:40, schrieb Stephan Knauss: .. A while ago there was a discussion about the word geocode which seems to be a trademark in some jurisdictions. So opposed to the general term geocoding the word geocode might need to be used with care. Yes, correct, Alex can you please rephrase your proposal to avoid using the trademark. Thank you. Simon signature.asc Description: OpenPGP digital signature ___ 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/11/2014 04:41 PM, Michal Palenik wrote: so wording As Geocodes are a Produced Work, they do not trigger the share-alike clauses of the ODbL. is totally against section 4.6. This was something that we often discussed during the license change - what if somebody uses produced works to build a database that essentially is a substantial extract of OSM? We agreed (and I believe even had legal counsel on that issue), that no matter what license a produced work is under, making a database from repeatedly produced works *will* trigger ODbL. Else someone could essentially trace a non-ODbL OSM from tiles just because the tiles are produced works. I've added a paragraph to the proposal saying that we should make this explicit when talking about a geocoding guideline, to avoid misunderstandings. I'm not sure but I think some of the use cases quoted on the page are essentially such misunderstandings, unless of course they are not substantial. 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
Am 11/lug/2014 um 16:41 schrieb Michal Palenik michal.pale...@freemap.sk: so wording As Geocodes are a Produced Work, they do not trigger the share-alike clauses of the ODbL. is totally against section 4.6. +1 the data contained in produced works remains ruled by ODbL / share alike, this is stated in 4.3: 4.3 Notice for using output (Contents). Creating and Using a Produced Work does not require the notice in Section 4.2. However, if you Publicly Use a Produced Work, 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. I agree it's hard to believe that geocoding would be considered creating a produced work and not a derivative database (maybe we have a different idea what one is doing when geocoding). the definition for 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 - See more at: http://opendatacommons.org/licenses/odbl/1.0/#sthash.l1YXFGoW.dpuf some use of geocoding might lead to producing a work like an image, audiovisual material, text, or sounds but the data behind it remains ODbL and if you reuse those locations obtained by geocoding you'd have to do it under ODbL IMHO. Generally what I think about when reading geocoding: you'd take a list of addresses and use the database to localize (translate) them in geo coordinates. This seems to fit perfectly to the derivative db description: “Derivative Database” – Means a database 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. This includes, but is not limited to, Extracting or Re-utilising the whole or a Substantial part of the Contents in a new Database. - See more at: http://opendatacommons.org/licenses/odbl/1.0/#sthash.l1YXFGoW.dpuf cheers, Martin ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
We're 100% in grey territory on geocoding and you can keep reading the ODbL in circles. “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. - See more at: http://opendatacommons.org/licenses/odbl/1.0/#sthash.Fuel2Ngv.dpuf This definition does not preclude data to be a work as long as it has been created by a query, and the example in parenthesis are not exhaustive. What I'm looking for a is a clear interpretation by the community, supported OSMF, an interpretation that is a permissive reading of the ODbL on geocoding to unlock use cases. If there's share alike on data coming out of a geocoder you can't use it practically for geocoding. Many data set ups are just too complex. This is about unlocking geocoding on a broader level. More use cases = more incentives to improve data. I'd love to use OSM for geocoding again with more legal certainty at Mapbox and build further on a feedback loop back into OSM address and polygon data and I'd love that to be true for other users of OSM for geocoding too. We need to build up momentum for making OSM viable for geocoding. Clarifying that SA does not apply to results produced by a geocoder would do that. There's a problem with share alike and geocoding, let's make it go away. Alex On Fri, Jul 11, 2014 at 6:46 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 11/lug/2014 um 16:41 schrieb Michal Palenik michal.pale...@freemap.sk: so wording As Geocodes are a Produced Work, they do not trigger the share-alike clauses of the ODbL. is totally against section 4.6. +1 the data contained in produced works remains ruled by ODbL / share alike, this is stated in 4.3: 4.3 Notice for using output (Contents). Creating and Using a Produced Work does not require the notice in Section 4.2. However, if you Publicly Use a Produced Work, 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. I agree it's hard to believe that geocoding would be considered creating a produced work and not a derivative database (maybe we have a different idea what one is doing when geocoding). the definition for 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 - See more at: http://opendatacommons.org/licenses/odbl/1.0/#sthash.l1YXFGoW.dpuf some use of geocoding might lead to producing a work like an image, audiovisual material, text, or sounds but the data behind it remains ODbL and if you reuse those locations obtained by geocoding you'd have to do it under ODbL IMHO. Generally what I think about when reading geocoding: you'd take a list of addresses and use the database to localize (translate) them in geo coordinates. This seems to fit perfectly to the derivative db description: “Derivative Database” – Means a database 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. This includes, but is not limited to, Extracting or Re-utilising the whole or a Substantial part of the Contents in a new Database. - See more at: http://opendatacommons.org/licenses/odbl/1.0/#sthash.l1YXFGoW.dpuf cheers, Martin ___ 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
On Fri, Jul 11, 2014 at 5:09 PM, Alex Barth a...@mapbox.com wrote: We're 100% in grey territory on geocoding and you can keep reading the ODbL in circles. Yes, and thanks a lot Alex for taking the lead in writing up these guidelines. I think a lot of value in this discussion will come from well defined examples. I added a couple more to the list, sourced from discussions we've been having at Telenav. -- Martijn van Exel ___ 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 Jul 11, 2014, at 04:11 PM, Alex Barth a...@mapbox.com wrote: What I'm looking for a is a clear interpretation by the community, supported OSMF, an interpretation that is a permissive reading of the ODbL on geocoding to unlock use cases. Guidelines need to be accurate and supported by the ODbL and shouldn't be advanced to support a particular viewpoint and the process is not a way to weaken share-alike. I'm working my way through the examples. Consider a chain retailer's database of store locations with store names and addresses (street, house number, ZIP, state/province, country). The addresses are used to search corresponding latitude / longitude coordinates in OpenStreetMap. The coordinates are stored next to the store locations in the store database (forward Geocoding). OpenStreetMap.org's Nominatim based geocoder is used. The store locations are being exposed to the public on a store locator map using Bing maps. The geocoded store locations database remains fully proprietary to the chain retailer. The map carries a notice (c) OpenStreetMap contributors linking to http://www.openstreetmap.org/copyright. In this example, the database powering the geocoder is a derived database. The geocoding results are produced works, which are then collected into what forms a derivative database as part of a collective database. This derivative database is then used to create a produced work (the locator map). 4.4.c provides that this database of geocoding results is publicly used and is licensed under the ODbL. 4.6 requires offering the recipients of the produced work the derivative database itself or alterations file. In the specific case of this example, the alterations is trivial - you just say you were using unaltered OpenStreetMap data processed with Nominatim.___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] Updated geocoding community guideline proposal
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
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Jul 10, 2014, at 07: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 That a geocoding result is not a derived database is fairly obvious and not that interesting. It was produced from a derivative database, but isn't a database itself so can't be a derivative database. In my reading of the definitions, a database of geocoding results is a derivative database of the database used to power the geocoder. That database will then frequently be part of a collective database where the other independent databases are typically proprietary databases of some kind. That collective database is then generally used to produce works that are a produced work of the database of geocoding results as part of a collective database.___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
