[OSM-legal-talk] seeking understanding of usage of geocoding and POI

Karel Mikan karel.mikan at gmail.com
Fri Jun 10 18:53:11 UTC 2016


Dear all,

we are a start-up working on a visit-planning tool and struggle whether our
use of OSM triggers share-alike and to which extent. I read the licence,
user cases, legal facts, trivial transformation, and much more, but am
still not fully confident were we stand with our tool. I apologize for the
long email and the many questions, but it is crucial for us to understand
the impacts of using OSM. We are trying to find the right balance between
ODbL licence, customer rights and business data confidentiality. I would
highly appreciate any input on the below points.




Starting Assumptions:

- We are more than happy to give credit to OSM and to share the data that
fit the OSM purpose, as it is a great tool and we would like to contribute
back by using it.

- We would have legal issues if we were forced to share our customers' data
in any way with anyone (even if they themselves publish something on-line
through our tool). There is a very fine line, what counts as customer data
and public data.


-  OSM based tiles (unsure yet if we will use our own server or a third
party service)

- Nominatim for geocoding

- POIs - for the sake of the below questions, we assume the use of OSM POIs

- users share their visit plans globally through our tool

- assume significant traffic on our tool - this is for the sake of
potential "substantial" geocoding arguments

- there is a legal difference between the customer sharing publicly his
data and us sharing his data (even if the data might legally after some
time belong to us)







The questions we have, are around POIs and geocoding (coded addresses,
expanded POIs and custom POIs) and them triggering a share-alike of our
other customer data.


*Q1.) *if we just use the map tiles (CC-BY-SA) and display purely our OWN
POI data on it, we do not trigger share alike for our own data.


---------------------

If I understood correctly the distinction between tiles and the remaining
data, it will be only ODbL beyond this point.


I am unsure about the interpretation of ODbL specifically because of the
ODbL v1.0 text under:

1.0) "Collective Database - [...]independent databases in themselves[...]"

4.4.b ) "... extraction or re-utilization of the whole or a substantial
part of the contents into a new database is a derivative database" - (I
know substantial is the keyword here..)

4.6.b ) "... containing ALL of the alterations made to the database [..],
including ANY additional contents .."






*Q2.) The user inputs point of his visit*

- as an address text that is then

- converted to coordinates with Nominatim

- and saved under a visit number (primary key) in our DB.

- And based on the location we show POIs in the area



*Q2a)* If we save both, coordinates and address, this becomes a *derivative
database*, because we, in theory, with enough points, could re-engineer the
whole OSM DB(Geocoding Guideline). So it must be shared (address,
coordinates, visit primary key as well). ODbL 4.6.b and 1.0 "collective
database" seems to imply that even the visit number must be shared, because
the key is not independent by itself (it was generated because of the
coordinates)?


*Q2a1)* What if we then, based on the user location, save also the OSM POI
IDs in the area under the same visit number (different DB)?


We assume that the derivative database continues to apply because of ODbL
4.6.b "additional content". We need to share this DB as well (basically all
the information that is saved with this visit- because the starting points
were based on OSM geocoding)? I assume that it is not because we saved OSM
POI ids, as that would be seen as trivial matching or under ODbL 1.0
"independent databases in themselves"?


Or does ODbL 1.0 "collective DB" apply to the whole "visit DB", because the
visits just use the ids (trivial link) to link to the OSM POIs. The visit
database can actually stand alone AND it doesn't matter that the subgroup
of OSM POIs were found *based on the initial geocoding through Nominatim*?



*Q2b - alternative to a)* If we just save coordinates from the address (not
the address itself), does it change anything? We now cannot rebuild the
geocoding DB anymore, but the coordinates still come from Nominatim. Do we
then still have a *derivative DB* because of ODbL 4.4b substantial clause
(with time anyways) and need to share the list of coordinates and visit
primary key (the primary key might be answered by Q2a)? In theory one could
argue that if we pulled ALL coordinates, we pulled a substantial part of
the contents  (no matter that those are just numbers, so it really has no
value at all to anyone, without additional info).

.


*Q2b1)* I assume there is no difference to Q2a1, independent of Q2b answer,
as the POIs are still coming from OSM, so the answer will be equivalent to
whatever it is above.


*Q2c - alternative to a)* What is the situation, if the customer inputs an
address and then has an option to confirm that the coordinates are correct?
If he confirms without changes, we save only the address (NOT the
coordinates from Nominatim). This should be collective DB, as we save no
OSM data. (when we display we than call on Nominatim to give us the
coordinates to display the address, but we never save the coordinates)?

But if the coordinates are wrong and we ask him to correct them and then
save his input in our DB, we would need to share all our addresses and
coordinates, as it is probably ODbL 1.0 "derivative database ...
modification". Correct?

So for not having all data falling under ODbL, would a separate DB of
addresses and coordinates and corrected coordinates allow us to not share
the rest of the visit (in case the visit is above answered as collaborative
DB)?


*Q2d)* If the customer inputs address and coordinate on the map himself by
clicking on the map. that would be pure collective DB (we save nothing from
OSM).


*Q3)* if we were to obscure the starting point for privacy security reasons
and randomly add a few mmm to the coordinate, would we still need to share
the underlying "real point" (might potentially be answered by Q2 answers if
using Nominatim as a start is already a derivative DB)?



*Q4-Q6.) expanded POIs*

- we want to use our own category tagging for POIs, but to develop it, the
original OSM POI tags will be used

- the OSM POIs will be expanded for phone nr., website and proprietary
information (by us or the user) and will in some cases be shared publicly


*Q4) *when developing our own tagging, (linked to OSM POI IDs) is that a
*derivative* because of ODbL 4.4.b (are all tags of POIs a substantial part
of the OSM DB and we look at them prior developing our own) and 4.6b (any
additional content must be shared)?


*Q5a)* if we used OSM phone numbers and web links, and add to OSM POIs that
don't have any, our numbers and links through our user input, this is a
derivative DB and needs to be shared (ODbL 4.4b).


*Q5b**- alternative to a**)* if we didn't use any OSM phone or web links,
but just ours, that would be collective


*Q5b1)* the above is valid as long, as we have names of the POIs from a
different source. If we just pulled the names from OSM and added our own
phone numbers through our users and saved it somewhere else, would ODbL
4.4.b "substantial" pull (even without mixing it with phone nrs from OSM)?



*Q7) custom POIs*
- a customer adds some kind of a point that he feels is important (and
again shares)

*Q7) *if someone adds a church in our DB and tags it as a church (even if
he puts all address and coordinates information in manually), it falls
under share alike, if we also show churches from OSM (horizontal layer
guideline)





*Q8) linking OWN POIs with OSM POIs*

- for this assume we have our own POI database with names, coordinates


*Q8a) *if we just matched through link of names and close coordinates our
POIs with OSM POIs (without correcting our coordinates by using the OSM
data) and then showed OUR POIs with OSM addresses, it would be collective.
This is supported by ODbL 1.0 "collective DB - independent databases in
themselves".


*Q8b)* it becomes a derivative DB, if we chose to show our addresses where
available and OSM addresses when we have nothing) - due to ODbL 4.4.b -
"potential" substantial clause and "horizontal layer guideline".


*Q8c)* In order to protect our customers data when they input new private
points and POIs (of any category), we would have to make the user first
input the POI name and address, without us matching anything to OSM (or
proposing the best match). And once he/she saves it we can have an
algorithm run and see if there is a match in OSM, and ask the user, if that
is the best match.


*Q8c1)* If we would propose a match on the fly, as the customer types, it
might potentially again fall under ODbL 1.0 derivative database "based
upon" and if too many users do it also 4.4.b "substantial".






Thank you very much for you help!

Regards,
Karel Mikan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20160610/d060d472/attachment-0001.html>


More information about the legal-talk mailing list