[Osmf-talk] Draft Attribution Guidelines, possible vote at end of this month & new guidelines.

[Simon Poole]

Am 15.06.2021 um 20:54 schrieb Yves:
> Advertise better OSM => get better data => finally get a pure OSM map 
> content. From our point of view it's a virtuous circle, isn't it?

In theory yes, in practical terms you need to

- get the user/data consumer started with OSM, which implies perhaps a 
small geographical or thematic extract

- be realistic and arrange yourself with the fact that there are regions 
where OSM sucks (at least right now)

- cater for all the the things OSM doesn't do (not saying never, just 
currently things are limited), DEMs, aerial imagery, traffic data, and 
lots of things I can't think of near midnight.

> If other providers have less imperative attribution guidelines than 
> us, then there is no reason to care about equal treatment.
The problem is that the narrative is not about equal treatment, it's 
about "just OSM".
> If concessions have to be made, maybe we could explicitly tolerate a 
> short 'OSM' for multi-source maps when the required attributions is 
> longer than ours alone.

There are lots of ways this could be made to work, matter of fact I'm 
fairly sure a CC BY 2.0esquish "Such credit may be implemented in any 
reasonable manner; provided, however, that in the case of a Derivative 
Work or Collective Work, at a minimum such credit will appear where any 
other comparable authorship credit appears and in a manner at least as 
prominent as such other comparable authorship credit." would make lots 
of OSM contributors quite happy (this would be the equal treatment you 
are referring to), but it is by far not the only avenue that could be taken.

Simon

>
> Yves
>
>
> Le 15 juin 2021 19:59:27 GMT+02:00, Simon Poole <simon at poole.ch> a 
> écrit :
>
>
>     Am 15.06.2021 um 17:12 schrieb Yves:
>>     "they do not cover one of the major bones of contention"
>>     Which one if I may?
>
>     Attribution when OSM is not the dominant source of data and/or
>     potentially just one of many dozen constituent parts of what is
>     being presented.
>
>     In hindsight this is simply an oversight in the ODbL 1.0 which
>     simply doesn't cater for this case (attribution-wise, in other
>     areas it does). To resolve the issue we can either use a lenient
>     interpretation of the licence text, we can revise the current
>     licence or change it completely. The last three years have shown
>     that the 1st is not possible because of a very loud group that is
>     adamant about being very literal, the board refused to even
>     consider the 2nd, even though it would have the advantage of a
>     democratic process to determine the outcome, not to mention that
>     we could have fixed the couple of existing bloopers in the licence
>     at the same time. The last hasn't really ever been discussed in
>     depth, but having a geo-data specific license instead of one that
>     tries to solve the general case could have some advantages.
>
>     Simon
>
>>     Regards, Yves
>>
>>     Le 15 juin 2021 16:55:54 GMT+02:00, Simon Poole <simon at poole.ch>
>>     a écrit :
>>
>>         Am 15.06.2021 um 07:05 schrieb steveaOSM:
>>
>>             ... OSM has let too many, for far too long, get away with
>>             way too much in this regard. It is overdue that we end
>>             this abuse of our requirements to properly attribute OSM
>>             as the copyright holder of the map data being used. No
>>             exceptions. None. None whatsoever. “No matter what." Is
>>             this clear enough? We can’t mess around with this: it is
>>             perhaps THE most serious thing OSMF must protect and
>>             defend. ... 
>>
>>
>>         I've been stocking up on ropes as of late, I would quote you a volume
>>         discount for say a 100 or so.
>>
>>         Seriously the "new" guidelines are no more enforceable as the previous
>>         texts and as they do not cover one of the major bones of contention, and
>>         do not really change the catch 22 situation some users will find
>>         themselves in.
>>
>>         Assuming that the intent is that we want OSM data to be used in the 1st
>>         place, something I now and then doubt.
>>
>>         Simon
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20210615/7fcbc96b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20210615/7fcbc96b/attachment.sig>