Hi Robin,
Have you had a chance to review the Community Guidelines?
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines
In particular, I would think that the Horizontal Layers Guideline
("Examples of where you DO NOT need to share your non-OpenStreetMap data:
You use OpenStreetMap as a base topographical map for orientation and then
plot your own unrelated data over the top. An simple example of this might
be scientific or highly specialist data such as bird migration paths, tree
species distribution or geological outcrops."), Collective Database
Guidelines ("You collect restaurant names and associated phone numbers.
This data is linked to OSM data by references that associate the OSM
restaurant names to your phone numbers so that your restaurant phone
numbers will appear on an OSM-based map. All the restaurant phone numbers
for the regional cut are provided by you (i.e., the restaurant phone
numbers include no OSM data). Your phone numbers are not subject to
share-alike."), and Geocoding Guideline (particularly
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline#Adding_location_names_to_photos)
would be of interest/help to you.
-Kathleen

On Thu, Feb 20, 2020 at 1:19 PM Robin Hawkes <rob.haw...@gmail.com> wrote:

> Hello,
>
> I'm hoping to get some help to better understand how the ODbL licence
> applies with my use of OSM data. I understand that the discussion here is
> not official — nor a replacement for proper legal advice — however I'm
> hoping you can provide some guidance so I can come to my own conclusion as
> to my obligations.
>
> I'm working on an application for photographers to plan trips, discover
> new locations and save "collections" of markers as inspiration for future
> trips. The application is public (requiring registration and login) and
> most of what users create within this application will be mostly private
> and only view-able by themselves, though some may be shared with other
> users of the application.
>
> Here is a breakdown of relevant functionality:
>
>    - The basemap for this is vector tiles from Mapbox (so OSM)
>    - A user is able to use the basemap as visual reference and manually
>    click on the map and place their own markers under a variety of types (eg.
>    place I want to take a photo at, place I want to park my car, waterfall
>    that I want to visit)
>       - The coordinates for manually-placed markers will come from the
>       mouse position, not from any OSM feature metadata underneath the mouse 
> at
>       the time
>       - Manually-placed markers may have metadata added by the user to
>       help them organise (eg. a title, an icon, etc) and will be persisted to 
> a
>       database
>    - Separately, users will be able to search for OSM POIs near a
>    location and add some of them manually to a personal "collection"
>       - The POI search area will be on a relatively local basis (eg.
>       smaller than a national park)
>       - POI search will be limited to very specific features (parking,
>       toilets, viewpoints, waterfalls, etc) — let's say somewhere between 20 
> and
>       40 feature types
>       - POIs will either come from the vector tiles directly, or from a
>       geocoding API (not yet decided)
>       - A user can click on a POI and add it to a personal collection,
>       which will persist the coordinates and POI name and type in a database 
> as a
>       one-time, one-way operation (nothing else is stored in the database from
>       OSM, not even the node ID) — the node coordinates are the only data of
>       interest
>       - A user can then view their saved POIs on the map (coordinates,
>       name and type) and have the ability to change the position, name or 
> type if
>       they wish due to personal preference (eg. I saved a viewpoint POI from 
> OSM
>       but I later change it to a "place I want to take a photo" marker and 
> rename
>       it to "Cool view of mountain")
>
> I've not yet decided if I want to keep the user-created markers and the
> 'collected' OSM POI-sourced markers on separate map layers and separate
> database tables, but it's possible if it helps reduce ODbL compliance
> complexity.
>
> Ultimately, each collection that a user creates will consist of relatively
> few markers (<200 at the top end, probably more like <30 on average),
> mostly manually added by the user (not from POIs), and will be private to
> that user, unless they decide to make it view-able by other users of the
> application. A user can create multiple collections of markers but
> collections are isolated from each other and they can only view one
> collection at a time on the map.
>
> Regarding ODbL:
>
>    - With the first example (manually clicking map to add markers); am I
>    creating a derivative database, or a collective database? Or neither?
>       - I've been reading up on the definitions and it's confusing
>    - Likewise for the second example (storing coordinates manually chosen
>    from a POI search and a user editing the title or position), would this be
>    a derivative, collective or otherwise?
>    - Should I be required to abide by the share-alike clause, would I
>    need to also share any data added personally by the user while under the
>    assumption that the collection was private and not accessible or visible by
>    other users or the public?
>       - eg. a marker title of "Place I want to camp the night", or a
>       marker they add at their house with the title "My House"
>       - This doesn't seem beneficial for OSM as they wouldn't be adding
>       any useful information that isn't already in OSM (they're arguably 
> making
>       the data less useful by personalising it)
>       - It could also expose confidential and identifiable information
>       about the user if the collection is assumed to be private
>       - It feels legally dubious to be obliged to hand over private data,
>       especially if it can identity users
>    - Are there any other ODbL provisions that might be relevant here?
>
> I appreciate you taking the time to read through this respond, and please
> ask me any questions required to help clarify things.
>
> Regards,
> Robin
> _______________________________________________
> 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

Reply via email to