[OSM-dev] data redaction api

SteveC steve at asklater.com
Wed Jun 17 18:58:45 BST 2009


On 13 Jun 2009, at 09:04, Matt Amos wrote:

> unfortunately, sometimes data finds its way into OSM which might be
> copyrighted. the data working group was set up to help the community
> deal with these incidents when usual methods of community arbitration
> fail.
>
> the usual course of action when copyright violation is strongly
> suspected is to revert those changes to the database. however, when
> data is reverted using the normal API the previous versions of
> reverted elements are still available in the history. while this is
> fine for vandalism, it's not so great for copyrighted stuff - it'll
> still be accessible via the API.
>
> one solution would be to delete the old versions from the database by
> hand; but this isn't very scalable as only DB admins can do it.
>
> the solution wikipedia uses is to keep the (potential) copyrighted
> works in its database, but flag them as hidden (or interdicted,
> banned, redacted - whatever your preferred terminology). this means it
> can't be accessed via their web interface by normal users. and has the
> further advantage that, if the data is later shown to have been
> legally imported, the revert can be reverted and the data be made
> visible again.
>
> if this functionality is suitably general-purpose, it could also be
> used during the re-licensing to hide the data of users who haven't
> agreed to the ODbL. leaving arguments about the suitability of the
> ODbL to one side (or legal-talk, as it's otherwise known), this has
> the huge benefit of leaving the door open for users to agree at a
> later point in time (maybe to a later version of the license, or when
> they realise the ODbL is actually good) and to "recover" their data
> without needing to look through old planet files or database backups.
>
> these are just some of the possible use cases for a "data redaction
> api". the question is; what would such an API look like, and how would
> it be implemented without serious performance loss?

I'm not sure, but +1 on the idea! :-)

>
> looking forward to hearing everyone's ideas,
>
> cheers,
>
> matt
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
>

Best

Steve





More information about the dev mailing list