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

[Tom Lee]

>
> 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 this new database ever be *not* a derivative? Even if you
> were to define a single geocoding result as a produced work, combining a
> large number of them in a database would still get you a derived
> database again.


Can't the same argument apply to tiles? If you used tiles to recreate the
OSM database (say, by tracing road geometry or by OCRing feature names) and
then republishing under a different license, you would clearly be violating
the ODbL.

It seems as though the same approach can apply to geocoding: locate
features to your heart's content, but if you use the results to create a
general purpose geographic database that substitutes for/competes with OSM,
you'll be in violation of the license.


On Wed, Sep 23, 2015 at 2:18 AM, Frederik Ramm  wrote:

> 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 desirable for the
> ODbL to not apply to geocoding, I don't think that "Geocoding is
> Produced Work" could ever fly, legally, at least in countries that have
> a sui generis database law.
>
> 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 this new database ever be *not* a derivative? Even if you
> were to define a single geocoding result as a produced work, combining a
> large number of them in a database would still get you a derived
> database again.
>
> 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] Geocoding as produced work

[Simon Poole]

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 this page:
>
>
Naturally you fail to mention that

a) whatever service provider did the geo-coding of the above data
undoubtedly used the data for the same purposes as OSM would (and likely
a lot more)

and

b)  in my proposal I specifically address the issue of providing the
geo-coded addresses anonymously

Simon

PS: just to avoid confusion we are talking about addresses without any
attached personal information (names etc), so the data protection issue
is sole the linkage between who is doing the geo-coding and the address.


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] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

[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 this page:

http://www.huffingtonpost.com/2014/10/09/men-killing-women-domesti_n_5927140.html

I'm sure you can imagine similar scenarios related to sales leads,
potential hires, the healthcare industry or other forms of geographic
information that are sensitive for personal or professional reasons.

More generally, geocoding services that produce a product that has ongoing
licensing obligations--e.g. the user must attend to how the result
intermingles with their other data--will always be a hard sell. I realize
that this may not be of much concern to everyone here, but I do think that
more use of OSM for geocoding will spur improvements in various classes of
under-mapped data (addresses, most obviously).

On Wed, Sep 23, 2015 at 4:01 AM, Simon Poole  wrote:

>
>
> 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 a highly relevant scenario as OSM data
> > particularly for geocoding (addresses, POIs) is usually not complete
> > enough. The ability to use OSM for geocoding and "backfill" it with
> > (non-license-compatible) third party data is exactly what would would
> > make a gradual adoption of OSM possible.
> >
> > .
>
> This is obviously off topic as it has little to do with comments and
> input on the proposed guideline (and the proposed guideline has nothing
> directly to do with geo-coding), however I'm curious: why wouldn't you
> want to provide OSM with a list of addresses that you tried to geo-code
> (successfully and non-successfully), for example as proposed in:
>
> http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#The_Failover_Issue_and_Publishing_Derived_Datasets
>
> 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] Geocoding as produced work

[Tom Lee]

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
of volunteers than it is in an organization with contract employees.

To point b: if the addresses remain associated with the entity doing the
geocoding, as I think you're proposing, problematic linkages remain
possible. Consider how Brendan Eich's career ended at Mozilla. That case
involved campaign finance records, but a political organization's geocoded
membership database could easily achieve the same result, even with just
addresses.

Anyway even if the organization->address linkage were to be removed,
organizations who comply with EU Safe Harbour privacy requirements (and, I
assume, the EU privacy provisions from which they're derived) could not
share users' address data with a third party in this manner*.

Put bluntly: expecting data back from geocoding users is not workable and
never has been. Maintaining the hope that someday it will produce useful
contributions merely leads to some noncompliance and lots and lots of
deadweight loss. It's a shame, and is inhibiting useful work being
accomplished both outside of OSM and within it.

Tom

* Partner and vendors can receive data from complying organizations, but
the relationship must be disclosed and users must be given the right to
delete data about them. Partner organizations also have to complete
certification procedures (including things like HR training), and may not
pass the data on further, as OSM presumably would want to under sharealike.



On Wed, Sep 23, 2015 at 10:39 AM, Simon Poole  wrote:

>
>
> 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 this page:
>
>
> Naturally you fail to mention that
>
> a) whatever service provider did the geo-coding of the above data
> undoubtedly used the data for the same purposes as OSM would (and likely a
> lot more)
>
> and
>
> b)  in my proposal I specifically address the issue of providing the
> geo-coded addresses anonymously
>
> Simon
>
> PS: just to avoid confusion we are talking about addresses without any
> attached personal information (names etc), so the data protection issue is
> sole the linkage between who is doing the geo-coding and the address.
>
> ___
> 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] When should ODbL apply to geocoding

[Randy Meech]

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?
>
> As a step one, and before we discuss the potential licensing
> consequences, would you agree that
>
> 1. What you have created to power your app is a database.
>

Yes


> 2. The database you have created is partly derived from a non-OSM source
> (as far as the "there is a tide station at this address" is concerned).
>

Yes, most of the data is from non-OSM sources. Just the results of reverse
geocodes are from Nominatim/OSM.


> 3. The database you have created is partly derived from OSM (as far as
> "this address is at location lon=x, lat=y" is concerned).
>

Actually I mis-spoke a bit (sorry, it was several years ago). The lat/lngs
are actually from state agencies, although I did reverse geocoding with
Nominatim and store the results in the database.


> Is there any doubt about any of these three statements either on your
> side or anyone else's?
>

So again, I don't really care about publishing this under ODbL, but to
argue the point, I'm not sure I agree with the third statement. If I had
taken raw OSM data and derived something from it, I would agree with this.
But -- to Alex's overall point -- the geocoding results seem like a
produced work to me. I believe that I am decorating other open data with
the results of a geocoder that contains sufficient art to make it not
derived, but produced.

Curious about others' thoughts here -- I do think this is an important
topic to figure out and I'm happy to be a guinea pig for this.

-Randy
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Simon Poole]

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
its geo-coding API.

> 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 of volunteers than
> it is in an organization with contract employees.
>
> To point b: if the addresses remain associated with the entity doing
> the geocoding, as I think you're proposing, problematic linkages
> remain possible. Consider how Brendan Eich's career ended at Mozilla.
> That case involved campaign finance records, but a political
> organization's geocoded membership database could easily achieve the
> same result, even with just addresses.
>
> Anyway even if the organization->address linkage were to be removed,
> organizations who comply with EU Safe Harbour privacy requirements
> (and, I assume, the EU privacy provisions from which they're derived)
> could not share users' address data with a third party in this manner*.
>

You are getting slightly carried away: we are talking about SA
obligations for data derived from OSM that is publicly used, which in in
the vast vast majority of cases will not have any relevant
data-protection issues at all. A typical use case would be a company
geo-coding the addresses of its dealerships for display on a map,
4square geo-coding its locations and similar. NOT an insurance
geo-coding the addresses of its customers and publishing them.

The very legislation you are referring to would in general strongly
limit any use of location information associated with individuals in the
first place and it may be that that is actually a rare use case which
will never be possible to cover with OSM.

> Put bluntly: expecting data back from geocoding users is not workable
> and never has been. Maintaining the hope that someday it will produce
> useful contributions merely leads to some noncompliance and lots and
> lots of deadweight loss. It's a shame, and is inhibiting useful work
> being accomplished both outside of OSM and within it.
>
> Tom
>
> * Partner and vendors can receive data from complying organizations,
> but the relationship must be disclosed and users must be given the
> right to delete data about them. Partner organizations also have to
> complete certification procedures (including things like HR training),
> and may not pass the data on further, as OSM presumably would want to
> under sharealike.
>
See above, all the relevant larger scale use cases which I can think of
that touch private data of individuals do not involve publishing the
location information and OSM can be used for that NOW without any fear
at all of share-alike. Matter of fact you are even better of with OSM
than with any service provider, because you can actually do it in house
and don't have to disclose the information to a third party with all the
involved paper work (yes I've actually signed such contracts and they
are a pain).  

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] Geocoding as produced work

[Tom Lee]

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 OSM in it but can't sell a geocoding service that has ODbL attached
to the results.

And no one has yet offered any examples by which ODbL attaching to
geocoding results has led to contributions that improved OSM. Or
contributions at all (the prospect of Randy's tide station data
notwithstanding).

I realize you'll disagree, but I'm left with the same sense of what's
achievable and desirable for a geocoding guidance. Enable more geocoding.
Protect OSM's assets. Abandon the impractical goal of compelling users to
share their results.

On Wed, Sep 23, 2015 at 2:26 PM, Simon Poole  wrote:

>
>
> 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
> its geo-coding API.
>
> > 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 of volunteers than
> > it is in an organization with contract employees.
> >
> > To point b: if the addresses remain associated with the entity doing
> > the geocoding, as I think you're proposing, problematic linkages
> > remain possible. Consider how Brendan Eich's career ended at Mozilla.
> > That case involved campaign finance records, but a political
> > organization's geocoded membership database could easily achieve the
> > same result, even with just addresses.
> >
> > Anyway even if the organization->address linkage were to be removed,
> > organizations who comply with EU Safe Harbour privacy requirements
> > (and, I assume, the EU privacy provisions from which they're derived)
> > could not share users' address data with a third party in this manner*.
> >
>
> You are getting slightly carried away: we are talking about SA
> obligations for data derived from OSM that is publicly used, which in in
> the vast vast majority of cases will not have any relevant
> data-protection issues at all. A typical use case would be a company
> geo-coding the addresses of its dealerships for display on a map,
> 4square geo-coding its locations and similar. NOT an insurance
> geo-coding the addresses of its customers and publishing them.
>
> The very legislation you are referring to would in general strongly
> limit any use of location information associated with individuals in the
> first place and it may be that that is actually a rare use case which
> will never be possible to cover with OSM.
>
> > Put bluntly: expecting data back from geocoding users is not workable
> > and never has been. Maintaining the hope that someday it will produce
> > useful contributions merely leads to some noncompliance and lots and
> > lots of deadweight loss. It's a shame, and is inhibiting useful work
> > being accomplished both outside of OSM and within it.
> >
> > Tom
> >
> > * Partner and vendors can receive data from complying organizations,
> > but the relationship must be disclosed and users must be given the
> > right to delete data about them. Partner organizations also have to
> > complete certification procedures (including things like HR training),
> > and may not pass the data on further, as OSM presumably would want to
> > under sharealike.
> >
> See above, all the relevant larger scale use cases which I can think of
> that touch private data of individuals do not involve publishing the
> location information and OSM can be used for that NOW without any fear
> at all of share-alike. Matter of fact you are even better of with OSM
> than with any service provider, because you can actually do it in house
> and don't have to disclose the information to a third party with all the
> involved paper work (yes I've actually signed such contracts and they
> are a pain).
>
> 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] Proposed "Metadata"-Guideline

[Frederik Ramm]

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 someone making a business of selling "the
better OSM" by adding to our data other, separately curated, proprietary
data, thereby improving OSM without sharing any of the improvements back.

That would enable someone to offer e.g. a "better navigation app" that
was largely based on OSM but had proprietary data improvements, and the
exposure OSM would get from that would be worth nothing as nobody else
could use that same database.

This would be a use case that the license is specifically designed
against and we must take care not to weaken our position here.

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] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

[Frederik Ramm]

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 desirable for the
ODbL to not apply to geocoding, I don't think that "Geocoding is
Produced Work" could ever fly, legally, at least in countries that have
a sui generis database law.

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 this new database ever be *not* a derivative? Even if you
were to define a single geocoding result as a produced work, combining a
large number of them in a database would still get you a derived
database again.

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] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

[Simon Poole]

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 a highly relevant scenario as OSM data
> particularly for geocoding (addresses, POIs) is usually not complete
> enough. The ability to use OSM for geocoding and "backfill" it with
> (non-license-compatible) third party data is exactly what would would
> make a gradual adoption of OSM possible.
>
> .

This is obviously off topic as it has little to do with comments and
input on the proposed guideline (and the proposed guideline has nothing
directly to do with geo-coding), however I'm curious: why wouldn't you
want to provide OSM with a list of addresses that you tried to geo-code
(successfully and non-successfully), for example as proposed in:
http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#The_Failover_Issue_and_Publishing_Derived_Datasets

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] Geocoding as produced work

[Steve Coast]

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 service provider to differentiate between geo-coding for public
> vs in-house use.  But then it isn't as if you are completely free to do
> what you want with a lot of other data sources either. 

Another good point: If the OSM license has some edge case problem, it’s still 
far better than proprietary licenses which are the alternative.

I’m calling it "edge case” if the SNIFF TEST in my prior email is not met, 
maybe it’s just as well to call it the “EDGE CASE TEST”, which is similar if 
not identical to the MANY TEST.

Just trying to pull the discussion toward black & white tests which we can 
actually pass or fail, happy to see other suggestions.

Best

Steve___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Michal Palenik]

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 10:22:09PM +0200, Simon Poole wrote:
> 
> 
> Am 23.09.2015 um 21:28 schrieb Tom Lee:
> > 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 OSM in it but can't sell a geocoding service that
> > has ODbL attached to the results.
> 
> No, I'm saying that for a overwhelming majority of use cases in which
> the geo-coding are used publicly the ODbL does not cause the privacy
> problems you were alluring too. Nor does it cause any problem for in
> house use at all.
> 
> 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 service provider to differentiate between geo-coding for public
> vs in-house use.  But then it isn't as if you are completely free to do
> what you want with a lot of other data sources either. 
> 
> >
> > And no one has yet offered any examples by which ODbL attaching to
> > geocoding results has led to contributions that improved OSM. Or
> > contributions at all (the prospect of Randy's tide station data
> > notwithstanding).
> Getting back failed addresses for QA would be a start.
> 
> But the more important point is that we are not at liberty to simply
> declare by fiat that bulk geo-coding does not create a derivative
> database. The underlying problem is that geo-coding is not a clearly
> defined process, it is at best a loose concept. I doubt that anybody
> would have issue classifiying geo-coding addresses in the US to states
> (your initial example)  as a produced work, on the other hand extracting
> building entrances with attached addresses is clearly a one-to-one
> copying out of OSM, both however are "geo-coding".
> 
> Most actual use cases are going to be somewhere in between and the last
> couple of years of discussion on this topic have clearly shown that we
> will not make any progress except if we base a geo-coding guideline on
> principles that are as far as possible independent of the actual mechanics.
> 
> >
> > I realize you'll disagree, but I'm left with the same sense of what's
> > achievable and desirable for a geocoding guidance. Enable more
> > geocoding. Protect OSM's assets. Abandon the impractical goal of
> > compelling users to share their results.
> >
> I don't think there is an election going on any time soon, so please
> tone down the rhetoric. It's simply the case that we have the licence we
> have and at least for the immediate future we have to live with it and
> give our data consumers guidance in the current frame work, not in a
> make believe better world.  
> 
> Simon
> 



> ___
> 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] Geocoding as produced work

[Tom Lee]

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 guidance be issued that clarifies how geocoding
relates to the license. And I'm suggesting that treating geocoding results
as a produced work would not pose risk to OSM; would not cost it data;
would offer advantages to some users; and would create new incentives for
improving the map.

Steve is right to point out that other businesses have decided to take the
risk that ODbL's implications for geocoding results will never be enforced.
Or they're just using the data without worrying about compliance at all. I
think it's unfortunate to dismiss this issue solely because there aren't
more actors willing to work on a clear and ethical path forward.

> however it’s also hard to see who would pay for OSM geocoding in the
first place when there’s almost no data compared to proprietary maps

This speaks to Alex's point about the need to enable iterative uses of the
data, where open data supplements proprietary sources (here's an example:
https://www.mapbox.com/blog/austrian-open-address-data/ ). The name you
chose for this problem is apt. OSM has become a wonderfully powerful tool
for the use cases it's friendly toward, like rendering tiles and routing.
OSM is relatively inflexible toward geocoding, and consequently it is not a
great tool for it. Yet.

At any rate, I can assure you that we have customers today with use cases
that could be served exclusively by OSM data--reverse place-level permanent
geocoding is top of the list. And there are many more who could benefit
from OSM data supplementing the quality of our results.


On Wed, Sep 23, 2015 at 5:33 PM, Steve Coast  wrote:

>
> 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 service provider to differentiate between geo-coding for public
> vs in-house use.  But then it isn't as if you are completely free to do
> what you want with a lot of other data sources either.
>
>
> Another good point: If the OSM license has some edge case problem, it’s
> still far better than proprietary licenses which are the alternative.
>
> I’m calling it "edge case” if the SNIFF TEST in my prior email is not met,
> maybe it’s just as well to call it the “EDGE CASE TEST”, which is similar
> if not identical to the MANY TEST.
>
> Just trying to pull the discussion toward black & white tests which we can
> actually pass or fail, happy to see other suggestions.
>
> Best
>
> Steve
>
> ___
> 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] license test

[Tom Lee]

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 that ODbL has produced useful data contributions from
geocoding users is thin.

EFFORT: I'm suggesting a guidance clarifying OSMF's opinion on which
part(s) of the current license apply to a class of data use, not a license
change. This is real work, but clearly achievable, since it's been done
before.

MANY: Obviously, geocoding services like Mapbox have an interest in gaining
this flexibility. But everyone will benefit as we & others improve the map
it for the geocoding use case. Nick and I have loaded more than a hundred
million of openly-licensed addresses into OpenAddresses.io in the course of
our work at Mapbox. (I'm not suggesting that large address imports to OSM
are the path forward here; hopefully you can see my point, though.) I love
the OpenAddresses project, but OSM is much more broadly useful, and I would
be glad to direct that energy where it will do more good.

On Wed, Sep 23, 2015 at 5:01 PM, Steve Coast  wrote:

> 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.
>
> SPIRIT - Does the suggested change maintain the spirit of the license?
>
> (Doesn’t require much elaboration I think, maybe I’m wrong)
>
> HARM - Does the suggested change not harm the community or data?
>
> (This is the most squirrely, maybe it can be nailed down. I took it from
> Lawrence Lessig’s supreme court copyright case where the judges asked him
> to show the actual harm the DMCA (would have) caused.)
>
> EFFORT - Does the suggested change merit the effort required?
>
> (The last license change was a monumental effort)
>
> Perhaps we could replace the HARM test with the MANY test:
>
> MANY - Does the suggested change help the many or the few?
>
> Best
>
> Steve Coast http://stevecoast.com/ +14087310937
>
> ___
> 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

[OSM-legal-talk] license test

[Steve Coast]

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.

SPIRIT - Does the suggested change maintain the spirit of the license?

(Doesn’t require much elaboration I think, maybe I’m wrong)

HARM - Does the suggested change not harm the community or data?

(This is the most squirrely, maybe it can be nailed down. I took it 
from Lawrence Lessig’s supreme court copyright case where the judges asked him 
to show the actual harm the DMCA (would have) caused.)

EFFORT - Does the suggested change merit the effort required?

(The last license change was a monumental effort)

Perhaps we could replace the HARM test with the MANY test:

MANY - Does the suggested change help the many or the few?

Best

Steve Coast http://stevecoast.com/  +14087310937___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Rob Myers]

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  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 should take the risk that a
>potential future (accidental) publication of a private OpenStreetMap
>based
>work could jeopardize sensitive data. The risk is significant as even
>the
>publication of a Produced Work can bring the share alike stipulations
>of
>the ODbL to bear.
>
>
>
>
>___
>legal-talk mailing list
>legal-talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/legal-talk

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Alex Barth]

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 should take the risk that a
potential future (accidental) publication of a private OpenStreetMap based
work could jeopardize sensitive data. The risk is significant as even the
publication of a Produced Work can bring the share alike stipulations of
the ODbL to bear.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Eugene Alvin Villar]

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 in your own database, then how in the
>> world could this new database ever be *not* a derivative? Even if you
>> were to define a single geocoding result as a produced work, combining a
>> large number of them in a database would still get you a derived
>> database again.
>
>
> Can't the same argument apply to tiles? If you used tiles to recreate the
> OSM database (say, by tracing road geometry or by OCRing feature names) and
> then republishing under a different license, you would clearly be violating
> the ODbL.
>
> It seems as though the same approach can apply to geocoding: locate
> features to your heart's content, but if you use the results to create a
> general purpose geographic database that substitutes for/competes with OSM,
> you'll be in violation of the license.

A geocoding result is substantially different from a map tile. A
single geocoded result is arguably a single piece of data that is most
probably devoid of any copyright and by itself does not have any
database rights, while a map tile is a creative work that is clearly
copyrighted.

If you have multiple geocoded results, and if those results are
organized in a manner that enabled individual access, then you already
have a database (in the legal sense). I really cannot see how such can
be considered as a Produced Work when it is clearly a Derivative
Database when a source database was used to help produce the results.

Sets of map tiles, on the other hand, are not automatically a database
and because they are primarily creative works are considered Produced
Works. Just like a photo of a storefront may have embedded trademarks
in it, a map tile may have embedded data from a database in it too. It
is only when you extract the trademark from the photo, or the data
from the map tiles that you may possibly infringe on IP rights. Note
that the operative word here is 'extract'. No such extraction occurs
with geocoded results—they are pure data already.

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk