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 <si...@poole.ch > <mailto:si...@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@openstreetmap.org <mailto: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!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
