Re: [OSM-talk] Draft Geocoding Guideline

[Michael Steffen]

Hi all -

A few thoughts on the comments. Speaking entirely on my own behalf here, I
have not gotten feedback on this yet from the rest of the LWG.

[from Christoph]

But if you aggregate such results they can become subject to the ODbL. . .
> The difference is that indirect results are significantly *less
> substantial* than direct results because by interpolating you lose a lot of
> substance.  Spelling this out makes sense to me but the formulation cited
> above seems to be misleading and confusing.


[from Martin]

Rather than "contain no osm data" this could be seen as "contain only
> transformations of osm data, no raw osm data".


I think I see the confusion here now. What if we tweaked this language to
something like the following?

*CURRENT DRAFT: Individual Geocoding Results are insubstantial database
extracts if they are based on a Direct Hit. Individual Geocoding Results
that are based on an Indirect Hit contain no OSM data and so are free of
any obligations under the ODbL.*

*PROPOSED REVISION: Individual Geocoding Results are insubstantial database
extracts: Individual Geocoding Results that are based on a Direct Hit
contain an insubstantial amount of raw OSM data; Individual Geocoding
Results that are based on an Indirect Hit contain no raw OSM data at all
and only transformations of or inferences from OSM data.*

[from Martin]

E.g. my algorithm could take a list of all streets, query all house numbers
> from 1 to x (until it doesn't find any more hits for a sequence of
> numbers), but not the numbers 3 and 4 . . .


The hypothetical sounds like a systematic attempt to extract "substantially
all" addresses. It also does sound to me like the intent would likely be to
create a general purpose geodatabase from OSM (for example use of the
results again as a geocoder). So share-alike would apply: “A collection of
Geocoding Results will be considered a systematic attempt to aggregate data
if it is used as a general purpose geodatabase, regardless of how the
original aggregation was accomplished.”

Without attributing to osm


The attribution piece of this is indeed somewhat tricky. We wrote a fairly
detailed explanation of our reasoning in the FAQ section of the wiki. To be
clear: anyone running a geocoder based on OSM would need to attribute OSM.

Yes, individual geocoding results are not substantial, but geocoding is
> typically executed many times (i.e. systematically), and it is the sum of
> the geocoding results that makes the extract substantial.


Yes agreed - a collection of Geocoding Results can have enough data to be a
Substantial Extract of an OSM Database and a Derivative Database. This
applies to both Direct and Indirect Hits.

Hopefully the proposed new wording above would help clarify this.

Thanks again for the feedback.

-Michael


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

Re: [OSM-legal-talk] Vector Tiles: ODbL and non-free data

[Michael Steffen]

Hi Tobias - :) I will get in trouble with my team if I veer into a pricing
discussion, but like I said, shoot me an email with what you're working on,
and I can at least connect you with the right folks to talk to.

On Tue, Sep 6, 2016 at 12:03 PM, Tobias Wendorff <
tobias.wendo...@tu-dortmund.de> wrote:

> Am Di, 6.09.2016, 20:14 schrieb Michael Steffen:
> >
> > We have hundreds of customers hosting their own private data on our
> secure
> > infrastructure. Many customers are also hosting private data that they
> > license from 3rd parties.  Give me a holler if you want to talk. Good
> post
> > about private maps
> > https://www.mapbox.com/blog/private-maps-data-encryption/
>
> That's offtopic, but private maps are available on the $499/month package
> only. Pardon, but that's nothing reasonable for most of the projects.
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>



-- 
This is a private email.  Please check with me before forwarding, as it may
include information that's confidential or protected by the attorney-client
privilege.  If you feel like this email was sent to you by mistake, please
delete it and let me know. Thanks!
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Vector Tiles: ODbL and non-free data

[Michael Steffen]

Hi Tobias - The rendered image is a Produced Work (no different than a
printed map), so the combination is fine. There's no real difference vs
rendering a combined image from raster tiles.

We have hundreds of customers hosting their own private data on our secure
infrastructure. Many customers are also hosting private data that they
license from 3rd parties.  Give me a holler if you want to talk. Good post
about private maps https://www.mapbox.com/blog/private-maps-data-encryption/
.





On Tue, Sep 6, 2016 at 9:27 AM, Tobias Wendorff <
tobias.wendo...@tu-dortmund.de> wrote:

> Am Di, 6.09.2016, 17:33 schrieb Michael Steffen:
> >
> > This should be totally fine. Feel free to reach out directly if you
> > want to talk in more detail.
>
> Yeah, I might contact you in the next days. A problem could be that I
> have to upload the non-free data to Mapbox. This might violate the data's
> copyright.
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>



-- 
This is a private email.  Please check with me before forwarding, as it may
include information that's confidential or protected by the attorney-client
privilege.  If you feel like this email was sent to you by mistake, please
delete it and let me know. Thanks!
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Vector Tiles: ODbL and non-free data

[Michael Steffen]

Hi Tobias -

Michael at Mapbox here.

Just overlay, no other interaction.


This should be totally fine. Feel free to reach out directly if you want to
talk in more detail.

-Michael

On Tue, Sep 6, 2016 at 8:08 AM, Rory McCann  wrote:

> On 06/09/16 15:13, Tobias Wendorff wrote:
> > Actually, these vector formats are modified SQLite databases
>
> Not really. Vector tiles (*.mvt) are protobuf files, not sqlite files
> (you might be thinking of mbtiles). It doesn't really matter for your
> example, since you could filter a mvt file to split out the different
> layers.
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>


-- 
This is a private email.  Please check with me before forwarding, as it may
include information that's confidential or protected by the attorney-client
privilege.  If you feel like this email was sent to you by mistake, please
delete it and let me know. Thanks!
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Michael Steffen]

Simon et al -

First of all, hello! I started a few months ago as in-house counsel at
Mapbox. I come from the U.S. gov (FCC) where I did a lot of work, among
other things, on opening FCC geodata to the public. I've had to focus on
other things in my first few months, but am looking forward to finally
being able to turn more of my attention to working with this group.

As Tom mentioned, several of us at Mapbox have been digging into the
specifics of the Metadata guideline and I think something like this could
be useful in clarifying and opening up important use cases. (This is true
independently of the broader threads going on around geocoding.)

I've offered specific suggestions below, with explanatory notes.

Thanks for pushing this along Simon (and others),

-Michael


-

> = Metadata Guideline =

> == Background ==

> Many users of OpenStreetMap data are concerned about the share alike
> implications of the ODbL when using OpenStreetMap derived data together
with
> proprietary data, even with such data that is clearly outside the scope of
> the OpenStreetMap project.

> This guideline attempts to better define usage of OpenStreetMap data that
> the OSMF and the community views as acceptable without invoking the share
> alike clauses of the ODbL. This does not imply, as with all community
> guidelines, that this is the only legal way to do so, just legal usage we
> consider in line with the goals of the project.

> The ODbL defines two ways OpenStreetMap data can be utilized with third
> party data: as part of a “Collective Database” or as a “Derivative
> Database”.

> Use in a “Collective Database” does not invoke share alike, the ODbL
> requires that the individual component databases of the collective
database
> are “independent” however does not further define what that means.

> ~~While it would seem to be simple to define “independent” as having no
> ~~reference to OpenStreetMap data, every geographic dataset can be linked
> ~~just by virtue of its location information and further it is a trivial
> ~~exercise to link two datasets isolating OpenStreetMap derived data and
> ~~references to the other dataset in just one of them, so that is likely
not
> ~~a useful criteria.~~

I'd recommend deleting the paragraph above: it's unnecessary
and a bit confusing--the first two grafs amply explain why the guidance
is needed.

> == The Guideline ==

> A database containing one or more datasets derived from OpenStreetMap data
> and other sources is considered an ODbL collective database if one of the
> following conditions are fulfilled by the database elements from other
> sources:

> * the elements do not contain references to OpenStreetMap original or
> derived elements

> * the elements that contain references to OpenStreetMap elements do not
> replace or modify existing attributes or geometry of the referenced
> OpenStreetMap elements.

> For the purpose of this guideline

> * a reference can be a primary or composite database key or any other
method
> of identifying a specific OpenStreetMap derived element.

> * adding additional attributes by means of such a reference is not
> considered modifying the existing attributes of the referenced
> OpenStreetMap element.

> * referring from an OpenStreetMap derived element to an element from
another
> source in the database is considered equivalent to a reference in the
other
> direction.

I'd add an additional bullet akin to the following:

> * technical implementations that are functionally equivalent to a primary
or
> composite key reference but facilitate performance improvements -- for
> example a join of tables by a primary ID for purposes of a production
> database -- are equivalent to a reference.

> == Examples ==

> The following examples will demonstrate this further.

> === Examples of where you DO NOT need to share your non-OpenStreetMap data

> * You collect restaurant reviews and reference the restaurants in your
> database by OSM object id.__[^1]__ ~~(note this is technically
> defective)~~. Your restaurant reviews are not subject to sharealike.

As indicated above, I think it would be clearer to move the technical point
to a footnote, where we'd briefly explain *why* it's technically defective
to use OSM
ID as a database key.

> * You generate traffic data from in-car GPS information and use the
location
> information to identify roads in OSM to weight them differently in your
> routing application.

> ~~=== Examples of where you DO need to share your non-OpenStreetMap data

> ~~* you own a database of restaurant star ratings, you publish a product
> ~~that provides one dataset that uses ratings from OSM when you don’t have
> ~~it in your database and otherwise your data. The data that you publish
> ~~is subject to sharealike. Note: if you don’t use the relevant OSM
> ~~attributes and just your data, your data is not subject to sharealike as
> ~~defined in the “Horizontal Layers” guideline. Note this is a
> ~~hypothetical use case and not