[OSM-legal-talk] Proposed "Metadata"-Guideline
Simon Poole
simon at poole.ch
Wed Oct 7 10:55:35 UTC 2015
Michael
thanks for the feed back it is very helpful.
Anybody else with input?
IMHO we might do away completely with a negative (as in share alike
invoked) example because of the issues this has caused and undoubtedly
will continue to cause.
Simon
Am 02.10.2015 um 18:31 schrieb 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 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 we 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 an actual one.~~
>
> I recommend striking the paragraph above: This statement doesn't
> clearly flow
> from the ODbL under all circumstances. That would also be in line with
> the the
> stated intent in the opening of the guideline: describe "usage of
> OpenStreetMap
> data that the OSMF and the community views as acceptable without
> invoking the
> share alike clauses of the ODbL" without implying "that this is the
> only legal
> way to do so"
>
> I'd also add something like the following note to the end of the
> guideline,
> as described above:
>
> > __[^1]OSM IDs are not stable identifiers, so this is not a recommended
> > method of linking other data to OSM extracts.__
>
> On Tue, Sep 22, 2015 at 1:55 PM, Simon Poole <simon at poole.ch
> <mailto:simon at poole.ch>> wrote:
>
> I've added a clarification to the example in question as it is causing
> some contention.
>
> Simon
>
> Am 22.09.2015 um 22:39 schrieb Simon Poole:
> >
> > Am 22.09.2015 um 22:14 schrieb alyssa wright:
> >> What does this mean? "uses ratings from OSM "
> >>
> > Again: it is just a hypothetical example.
> >
> > Obviously using a real life use case and declaring that as
> > non-conformant or whatever in a not yet agreed to guideline
> would not be
> > sensible (just imagine the outrage).
> >
> > Not to mention the ability of the OSM community to dig out many
> years
> > stale and obviously out of date wiki pages and to pretend that
> they are
> > meaningful implies that anything that we put in writing is going
> to be
> > quoted for the next couple of decades regardless of what
> guideline we
> > end up with eventually.
> >
> > Simon
> >
>
>
>
> _______________________________________________
> legal-talk mailing list
> legal-talk at openstreetmap.org <mailto:legal-talk at 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20151007/f2be92ea/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20151007/f2be92ea/attachment.sig>
More information about the legal-talk
mailing list