Author: pnorman
[Added to the original trac issue at 7.12pm, Tuesday, 19th November 2013]

Pros:

• Has a central list
• Easier updating
• Changes would cover JOSM back to 2011

Cons:

• P2 and iD define their blacklists internally, is there a reason JOSM can't do the same
• Would only effect JOSM
• Adds a new element to the API capabilities document, which is a wider change then just updating JOSM's list

From my point of view, yes, preventing the use of layers commonly used for infringing purposes is part of the job of editing software.

Author: TomH
[Added to the original trac issue at 7.31pm, Tuesday, 19th November 2013]

Well I assume that if we did it we would then encourage P2 and iD to take their lists from the API otherwise it would all be a bit pointless.

Author: woodpeck
[Added to the original trac issue at 12.43am, Wednesday, 20th November 2013]

@pnorman, your reasoning only holds if you assume that the OpenStreetMap API with its current license is the only API against which the editing software will be used. If someone were to use any of the programs to connect to a system that uses the OSM API but is licensed differently, then image sources that are not allowed for OSM might become available or vice versa. So, which imagery is allowed depends not on the editor but on the API (and project) the editor connects to. This might be less of an issue for iD or P2 which would likely have to be embedded into that new system anyway, but JOSM - or any other standalone editor for that matter - doesn't require a code change to be used with different servers.

Author: don-vip
[Added to the original trac issue at 9.35am, Wednesday, 2nd April 2014]

[https://docs.google.com/document/d/1uemhXWKwbu3RNjAWcG0R-nEFaN1FHjZl1McFwjXkNSc/pub some LWG activity from Feb 25th] stating:

Getting JOSMs blacklist update is important for the DWG, be it by modifying the API to return a blacklist or not. The question is, should this be delivered by the OpenStreetMap API? The positive is that it actively helps prevent well meaning map data and editor software contributors from contaminating the OSM database with data from non-allowed sources. The potential negative to this is that it may imply that other source not on the blacklist are OK. After discussion, it was felt that the right balance could be struck by additionally adding a whitelist, which may also be of use in its own right. Therefore:

LWG recommends and supports an API-delivered blacklist AND whitelist. We urge that it be made clear in supporting documentation that if a source is not on the blacklist, that does not imply that it OK and research should be done before adding it.

Potential whitelist https://github.com/osmlab/editor-imagery-index

The next meeting was scheduled on March 25th but I can't find the minutes?

Author: pnorman
[Added to the original trac issue at 8.03pm, Saturday, 3rd May 2014]

The LWG recommends adding the imagery blacklist information to the capabilities API and that once it has been added editor clients shift to using it.

Paul Norman \ For the Legal Working Group

Author: pnorman
[Added to the original trac issue at 3.31am, Saturday, 23rd August 2014]

So, there's a schema question here, how do we best define it?

One idea suggested was

<blacklist>
  <if-match pattern="foo"/>
  <if-match pattern="bar"/>
</blacklist>

It's possible that some clients may not have regular expression capabilities, and there's a number of different regex variants, which means we'd have to specify what we were using. I'm also not sure that we'd actually need regular expressions.

don-vip, as you're the requester for the enhancement, any thoughts?

Author: don-vip
[Added to the original trac issue at 12.51am, Saturday, 30th August 2014]

Thanks for the update.

I think we should stick to the format defined and implemented by Frederik years ago. Implementing it now in the API should result in all JOSM clients honor it, even the oldest ones, even Mac OSX users stuck with Java 6, and so on:

<api>
  ...
</api>
<policy>
  <imagery>
    <blacklist regex=".*\.google\.com/.*" />
    <blacklist regex=".*209\.85\.2\d\d.*" /> 
    <blacklist regex=".*209\.85\.1[3-9]\d.*" />
    <blacklist regex=".*209\.85\.12[89].*" />
  </imagery>
</policy>

We should however test it first against http://api06.dev.openstreetmap.org as this part of JOSM code has never really been used since.

Author: stoecker
[Added to the original trac issue at 8.27pm, Friday, 3rd February 2017]

Hmm, was implemented inbetween it seems.