Re: [OSM-legal-talk] FYI Collective Database Guideline

[Simon Poole]

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

[Simon Poole]

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

[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?

> - 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

[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



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

[Robert Whittaker (OSM lists)]

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

[Simon Poole]

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

[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.

-- 
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

[Simon Poole]

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