[OSM-dev] Mapping during license change / "safe to edit"

Frederik Ramm frederik at remote.org
Wed Aug 25 12:42:29 BST 2010


Pieren wrote:
> For me, it's more a legal question than a technical question:


There's certainly several sides to this.

There will be objects which are 100% "safe" under the new license 
(clearly, those which have never been touched by anyone who has not 
agreed; and which do not depend on other objects that are unsafe).

There will also be objects which are 100% "unsafe" - only touched by 
people who have not yet signed up to the new license.

Then there will be all the in-between cases, where some contributors 
have agreed and some not, or where an object depends on a not-agreed 
object. In these cases, we will have to establish whether the 
contribution by those who have not agreed is (a) non-trivial and (b) 
still present in the existing object, and if both conditions are met, 
the contribution must be removed. (A trivial contribution would e.g. be 
an automated removal of 100.000 created_by tags; and a contribution that 
is not present and longer, e.g. if someone added a tag and someone else 
removed it again, certainly does not require action either.)

"Removing a contribution", then, does not automaticall mean that the 
object has to be deleted; it may be possible to remove someone's 
contribution to an object by rolling it back to an earlier state, or 
even "filtering out" that contribution.

This is what I think will have to be done when we decide what data to 
keep and what to remove. It may well be partially crowdsourced - I think 
it will be hard to find an algorithm that, for example, decides whether 
a contribution is trivial or not. It would be better to let real people 
do this.

But I was thinking more about the immediate short term; at least the 
100% cases could be easily made visible to users. "This object is 
definitely safe", "this object is not yet safe", "this object may be 
partially safe, click here to inspect the history" would already help a 

Of course the work Peter is doing will already be a big step forward in 
driving analyses. However, having the whole thing somehow integrated 
into the editing process would also be cool.

I'm unsure how to handle this technically since I guess that it is too 
expensive to calculate the current relicensing state of each element o 
the fly whenever it is loaded.


More information about the dev mailing list