[OSM-legal-talk] Guideline review: Substantial

[Michael Collinson]

On 30/04/2014 06:39, Paul Norman wrote:
> Bringing it back to the guideline, I'd suggest
>
> - Dropping references to villages or areas
>
> - Dropping reference to 100 features; the number doesn't seem in line
>    with quantative
>
> - Reframing in terms of mapper effort, i.e. the cost of "obtaining,
>    verification, or presentation"
>
> - Referring to features and noting that a feature like a building
>    may be formed with multiple OSM elements (i.e. multiple nodes) but
>    is one feature.
>
> I could try writing some text if there's agreement on these points.
Alternatives of course are always welcome, but this has been previously 
exhaustively discussed and has been out there for 5 years almost to the 
day without negative effect.

I'd like to emphasise to all that these are guidelines, reasonable rules 
of thumb rather than a rigorous attempt codify the ODbL with regard to 
geospatial data.  They need to be reasonable short and understandable to 
folks who don't have a legal department, are probably not fully engaged 
with the jargon of OSM and want to do right by us. They need to say 
something about our qualitative intentions as a community,  this being 
useful to commercial entities considering using our data ... for the 
most part they want to do right by us too. [And of course also they 
should not open some loophole for the less good intentioned.]

To that end, I would really like to keep references to real things and 
nice round numbers.

My personal take is that we have been quite clever in defining 
insubstantial rather than substantial, (a question raised by Luis), and 
using low, but defined numbers. We are simply saying that if you 
genuinely doing things with small amounts of data, locations in your 
book for example, hey, no problem, we are happy.  And the cleverness is 
that we are silent on anything bigger. I have, by the way, added a 
comment in the summary that the easiest solution by far is to just 
attribute us and contribute back any data improvements!

Mike