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 > [email protected] > http://lists.openstreetmap.org/listinfo/dev > Best Steve _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
