Re: [OSM-legal-talk] FYI Collective Database Guideline
Am 09.06.2016 um 17:40 schrieb Christoph Hormann: > On Thursday 09 June 2016, Simon Poole wrote: >> I can understand the desire for a negative example, but: >> >> - this is documentation of use that we are happy with, not of the >> opposite. > But we are happy with uses that invoke share-alike as well, aren't we? Basically the issue is that the guidelines are essentially "safe harbour" statements, "we are ok if you do X", to provide a more secure and stable environment for users of our data. They do not claim to be the only possible interpretation of the ODbL and they do not claim that use that is outside of the guidelines is automatically incompatible with the ODbL. We do however believe that the guidelines can be reasonably assumed to be covered by the ODbL and making these statements or clarifications if you so wish is within our rights as licensor. Giving non-trivial (aka concrete business use cases) negative examples not only has the danger of essentially by fiat declaring something "illegal" were no case has been made and that we've not been able to look at in detail, it further relies on readers understanding the fine difference between "not covered by the guideline" and "not covered by the ODbL" outlined above. Determining the later is something that ultimately would have to be decided by a court and I believe I can safely say the OSMF does not want to tie its hands outside of the context of the guidelines to when it can instantiate legal action and when not. >> - as the preamble says there may be other ODbL compliant ways that to >> not invoke share-alike to combine datasets outside of those detailed >> in the guideline. >> >> - using a contrived non-trivial negative example has the "it is >> definitely going to happen" problem that it will be seen as a ruling >> in use cases which are not on our table and of which we don't know >> the details. > I try to avoid getting again into a discussion on the guideline itself > here (i voiced my concerns previously - no need to do this again at > this point). In any case it would be the first single sided guideline > that does not draw a line between two fields of data use. > > And as i read the text of the guideline it implies certain limits, for > example > > "non-OSM data completely replaces a particular type of geometry or data" > > implies the situation is different in some way if it does not completely > replace and > > "uses either all OSM data or no OSM data for that property" > > implies that a data mixture in properties changes the situation. > > In other words: having precisely formulated points in parameter space > but not having limits defined in relation to these points looks odd. > I already gave the de-duplication example as use that is not covered by the guideline, which in turn is consistent with the already existing guidelines, specifically the "Horizontal Layer Guideline". I like to call it "the all or nothing rule". So yes the guideline says you are only covered by it if you don't intermingle OSM data with 3rd party data of the same type within an extract of suitable size. Simon signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] FYI Collective Database Guideline
Am 09.06.2016 um 17:36 schrieb Simon Poole: > > Am 09.06.2016 um 17:06 schrieb Robert Whittaker (OSM lists): >> Also (and it may be deliberate) this guideline doesn't address the >> question of what filtering / querying you can do with your collective >> database. For instance, under the guideline I can take OSM restaurant >> data, and add third-party ratings data to each entry, and it will be a >> collective database. But what if I then do a query that returns the >> locations of restaurants that have >4* ratings in a certain area and >> just show those to users? Is this filtered dataset -- including the >> ratings used to create it -- subject to share-alike, or is it still a >> collective database of OSM restaurant names and locations, together >> with independent ratings? > I don't quite see the problem: > > - the OSM component of a Collective Database retains its licensing terms > regardless of what you do with it. > - if you don't create a database, you don't create a database. As the > ODbL states you can use a Collective Database to create a Produced Work > without creating an intermediate Derivative Database, typically on the > fly generated results for display purposes will be Produced Works. > - if you created a dataset from the filtered results and publicly used > it, yes, likely you would have to honour a request for the OSM > component (which naturally would implicitly contain the information > where those 4* restaurants are) TANSTAAFL. > > Simon > Small further note: the Collective Database guidelines assumes the same as we do in the "Region Extract" guideline, that the geographic extent of a OSM extract to not invoke share-alike/be a Derivative Database has to be at least country size, that would naturally apply in your example too, so creating smaller extracts would fall afoul of this rule. Simon signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] FYI Collective Database Guideline
On Thursday 09 June 2016, Simon Poole wrote: > I can understand the desire for a negative example, but: > > - this is documentation of use that we are happy with, not of the > opposite. But we are happy with uses that invoke share-alike as well, aren't we? > - as the preamble says there may be other ODbL compliant ways that to > not invoke share-alike to combine datasets outside of those detailed > in the guideline. > > - using a contrived non-trivial negative example has the "it is > definitely going to happen" problem that it will be seen as a ruling > in use cases which are not on our table and of which we don't know > the details. I try to avoid getting again into a discussion on the guideline itself here (i voiced my concerns previously - no need to do this again at this point). In any case it would be the first single sided guideline that does not draw a line between two fields of data use. And as i read the text of the guideline it implies certain limits, for example "non-OSM data completely replaces a particular type of geometry or data" implies the situation is different in some way if it does not completely replace and "uses either all OSM data or no OSM data for that property" implies that a data mixture in properties changes the situation. In other words: having precisely formulated points in parameter space but not having limits defined in relation to these points looks odd. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] FYI Collective Database Guideline
Am 09.06.2016 um 17:06 schrieb Robert Whittaker (OSM lists): > > Also (and it may be deliberate) this guideline doesn't address the > question of what filtering / querying you can do with your collective > database. For instance, under the guideline I can take OSM restaurant > data, and add third-party ratings data to each entry, and it will be a > collective database. But what if I then do a query that returns the > locations of restaurants that have >4* ratings in a certain area and > just show those to users? Is this filtered dataset -- including the > ratings used to create it -- subject to share-alike, or is it still a > collective database of OSM restaurant names and locations, together > with independent ratings? I don't quite see the problem: - the OSM component of a Collective Database retains its licensing terms regardless of what you do with it. - if you don't create a database, you don't create a database. As the ODbL states you can use a Collective Database to create a Produced Work without creating an intermediate Derivative Database, typically on the fly generated results for display purposes will be Produced Works. - if you created a dataset from the filtered results and publicly used it, yes, likely you would have to honour a request for the OSM component (which naturally would implicitly contain the information where those 4* restaurants are) TANSTAAFL. Simon signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] FYI Collective Database Guideline
On 9 June 2016 at 13:08, Christoph Hormann wrote: > On Thursday 09 June 2016, Simon Poole wrote: >> >> The LWG has just forwarded the text of >> http://wiki.openstreetmap.org/wiki/Collective_Database_Guideline to >> the OSMF board for approval and publishing as definite guidance from >> the OSMF. > > IIRC it was already noted by others that the lack of an example where > share-alike applies kind of makes the whole thing appear unbalanced and > endangers meeting the purpose to clarify 'where the line is drawn'. > > Independent of the actual content adding a non-trivial counter-example > would IMO significantly improve practical usefulness and understanding > of the guideline. +1 Also (and it may be deliberate) this guideline doesn't address the question of what filtering / querying you can do with your collective database. For instance, under the guideline I can take OSM restaurant data, and add third-party ratings data to each entry, and it will be a collective database. But what if I then do a query that returns the locations of restaurants that have >4* ratings in a certain area and just show those to users? Is this filtered dataset -- including the ratings used to create it -- subject to share-alike, or is it still a collective database of OSM restaurant names and locations, together with independent ratings? I wonder if we'd be better having a guideline that's based on rule that any data used in a query with OSM data has to be shared. Data that's only used in simple table joins does not. (As in the existing guideline, it would be a question of whether you can achieve the same results using such a method. Technical implementations that do things differently for efficiency reasons don't count against you.) Robert. -- Robert Whittaker ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] FYI Collective Database Guideline
I can understand the desire for a negative example, but: - this is documentation of use that we are happy with, not of the opposite. - as the preamble says there may be other ODbL compliant ways that to not invoke share-alike to combine datasets outside of those detailed in the guideline. - using a contrived non-trivial negative example has the "it is definitely going to happen" problem that it will be seen as a ruling in use cases which are not on our table and of which we don't know the details. A simple trivial example of common use that is not in line with the guideline would be de-duplication of elements in OSM and a third party dataset to generate a common database. in which each object only exists once. Simon Am 09.06.2016 um 14:08 schrieb Christoph Hormann: > On Thursday 09 June 2016, Simon Poole wrote: >> The LWG has just forwarded the text of >> http://wiki.openstreetmap.org/wiki/Collective_Database_Guideline to >> the OSMF board for approval and publishing as definite guidance from >> the OSMF. > IIRC it was already noted by others that the lack of an example where > share-alike applies kind of makes the whole thing appear unbalanced and > endangers meeting the purpose to clarify 'where the line is drawn'. > > Independent of the actual content adding a non-trivial counter-example > would IMO significantly improve practical usefulness and understanding > of the guideline. > signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] FYI Collective Database Guideline
On Thursday 09 June 2016, Simon Poole wrote: > > The LWG has just forwarded the text of > http://wiki.openstreetmap.org/wiki/Collective_Database_Guideline to > the OSMF board for approval and publishing as definite guidance from > the OSMF. IIRC it was already noted by others that the lack of an example where share-alike applies kind of makes the whole thing appear unbalanced and endangers meeting the purpose to clarify 'where the line is drawn'. Independent of the actual content adding a non-trivial counter-example would IMO significantly improve practical usefulness and understanding of the guideline. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] FYI Collective Database Guideline
FYI The LWG has just forwarded the text of http://wiki.openstreetmap.org/wiki/Collective_Database_Guideline to the OSMF board for approval and publishing as definite guidance from the OSMF. Simon signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk