Re: [OSM-legal-talk] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

> > I mean, nobody cares about a single on-the-fly geocoding result (this > easily falls under the "substantial" guideline) but if you repeatedly > query an ODbL database with the aim of retrieving from it, say, a > million lat-lon pairs to store in your own database, then how in the > world could

Re: [OSM-legal-talk] Geocoding as produced work

Am 23.09.2015 um 15:32 schrieb Tom Lee: > > why wouldn't you want to provide OSM with a list of addresses that > you tried to geo-code (successfully and non-successfully) > > > To use an extreme but hopefully illustrative example, consider the > queries used to create the thematic map on

Re: [OSM-legal-talk] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

> > why wouldn't you want to provide OSM with a list of addresses that you > tried to geo-code (successfully and non-successfully) To use an extreme but hopefully illustrative example, consider the queries used to create the thematic map on this page:

Re: [OSM-legal-talk] Geocoding as produced work

I'm not sure what basis there is for thinking a service provider will necessarily reuse clients' data. Maybe! That's not my experience, but I can imagine how it might be useful. I hope you'll agree that data security and stewardship is a trickier thing to implement within an open project made up

Re: [OSM-legal-talk] When should ODbL apply to geocoding

On Wed, Sep 23, 2015 at 2:01 AM Frederik Ramm wrote: > Hi, > > On 09/23/2015 04:49 AM, Randy Meech wrote: > > I used the MapQuest Nominatim > > service to geocode and/or reverse geocode all the global tide stations > > used in the app. What would the community have me do? >

Re: [OSM-legal-talk] Geocoding as produced work

Am 23.09.2015 um 19:16 schrieb Tom Lee: > I'm not sure what basis there is for thinking a service provider will > necessarily reuse clients' data. Maybe! Not "maybe" but dead certain, see for example geocoder.ca and I hope you don't really believe that google doesn't reuse the data you submit to

Re: [OSM-legal-talk] Geocoding as produced work

I confess that I'm not sure what to say to this. You're asserting that running a geocoding business with ODbL attaching to the results is no big deal, that "all the use cases you can think of" seem fine. Mapbox is _actually running_ a geocoding business and telling you that we would like to use

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

Hi, I'm deliberately taking this out of the geocoding context here to make a point regarding the mixing of OSM and non-OSM data: On 09/23/2015 01:26 AM, Alex Barth wrote: > mixing OSM and non-OSM POIs > should not extend the ODbL to non-OSM POIs and so forth. What we'd like to avoid is

Re: [OSM-legal-talk] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

Hi, On 09/23/2015 01:26 AM, Alex Barth wrote: > This could be well done within the confines of the ODbL by endorsing the > "Geocoding is Produced Work" > guideline > https://lists.openstreetmap.org/pipermail/legal-talk/2014-July/007900.html Frankly, even if I was of the opinion that it would be

Re: [OSM-legal-talk] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

Am 23.09.2015 um 01:26 schrieb Alex Barth: > .. > > The Fairhurst Doctrine won't get us all the way on geocoding. It still > leaves open what happens in scenarios where elements of the same kind > in third party databases are geocoded with OSM data and others with > third party data. This is

Re: [OSM-legal-talk] Geocoding as produced work

Steve Coast http://stevecoast.com/ +14087310937 > On Sep 23, 2015, at 11:22 PM, Simon Poole wrote: > > Now obviously it does limit in some aspects the T an OSM based > geo-coding service can use for its business and it might actually force > such a

Re: [OSM-legal-talk] Geocoding as produced work

I am in complete agreement with Simon. to stress on the topic of geocoding political party donors (example), if you don't plan to publish their individual addresses, you must not geocode their individual specific addresses, but rather a city level address only. michal On Wed, Sep 23, 2015 at

Re: [OSM-legal-talk] Geocoding as produced work

Thanks, Steve, for pushing this in a productive direction; and apologies to you, Simon for letting my frustration through. I should emphasize: I don't think that I'm suggesting a license change at all, and I don't mean to suggest that sharealike is broadly impractical. I'm suggesting that a

Re: [OSM-legal-talk] license test

This strikes me as a fair and useful framework. I'll take a crack at it, with geocodes-as-produced-works in mind: SPIRIT: Surely it's possible to avoid creating a sharealike backdoor by clarifying that geocodes become substantial only when combined to reverse engineer the map. HARM: The evidence

[OSM-legal-talk] license test

A constructive way forward may be to set out some tests that should be met for any license change for any issue. Maybe this exists already and I missed it. I’d suggest three tests below, but maybe someone here has better ones. I’m not sure *who* should judge this. Maybe a vote of some kind.

Re: [OSM-legal-talk] Geocoding as produced work

I don't understand this objection. If a company accidentally publishes something that's a problem with their procedures, not any license (free or proprietary). On 23 September 2015 15:32:06 GMT-07:00, Alex Barth wrote: >On Wed, Sep 23, 2015 at 4:22 PM, Simon Poole

Re: [OSM-legal-talk] Geocoding as produced work

On Wed, Sep 23, 2015 at 4:22 PM, Simon Poole wrote: > it might actually force > such a service provider to differentiate between geo-coding for public > vs in-house use. > This suggestion has come up before and I'd like to flag that this is impractical. No organization would and

Re: [OSM-legal-talk] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

On 9/23/15, Tom Lee wrote: >> >> I mean, nobody cares about a single on-the-fly geocoding result (this >> easily falls under the "substantial" guideline) but if you repeatedly >> query an ODbL database with the aim of retrieving from it, say, a >> million lat-lon pairs to store