[josm-dev] License change plugin

[Frederik Ramm]

Hi,

Stephan Knauss wrote:
> For the undecided there is still hope. About 100 user agree each day.
> http://ni.kwsn.net/~toby/OSM/license_count.html

The declined, too, can still redecide, and at least we have a sign of 
life from them whereas for the undecided we don't even know if they 
still read their email.

> Could it be configurable how to treat undecided? A checkbox or expert 
> setting to control "treat undecided as declined"?

I guess...

>> Well: If v1 of an object is done by someone who has agreed to ODbL, then
>> it is absoultely sure that *something* of this object will remain. If v1
>> of an object is done by someone who has not agreed, then it is *not*
>> sure that something will remain. Don't you think that it makes sense to
>> distinguish these cases?

> I'm not that sure something remains or should remain. In case v2 is a 
> deletion, should that be restored?

This is a difficult question but not one that concerns our plugin, 
because if v2 is a deletion then we will not see the object anyway. 
(Unless it was restored in v3...)

> If v1 was completely wrong and v2 fixed it, do we really want some 
> outdated version back? Is this really better?

This is a judgement that an individual mapper can make but not something 
we can do centrally. Maybe I should not have said "... certain that 
something remains" becuase of course this is never certain, of any 
object, because it can always be replaced by something better.

But OSMF is certainly not going to go "oh, the guy who made v2 moved 
this node by 500 metres but he didn't agree to the CT, so in that case 
let's not keep v1 because it seems to have been rubbish anyway!" (not 
least because in doing so, would they not make v1 a derived version of v2 ;)

So, an object where v1 has been created by someone who accepts the ODbL 
is *very unlikely* to be lost in the license change process.

> It sounds easier to start from scratch in these areas (I'm referring to 
> roads in a country in southeast-asia. Could be different in downtown 
> Berlin).

Ideally, mappers would assess the situation before it even comes to the 
license change and associated revert to version 1, delete the whole lot 
and replace it. The plugin is not meant say: "don't touch this object 
since version 1 will remain" - it says "if this object is still here 
when then license change comes then version 1 would likely remain"...

> So the decision of OSMF could be to delete unsafe data completely from 
> the ODbL and to provide some sort of overlay for manually restoring 
> dual-licensed data that is mixed with non-compatible data.

My preferred version is not "first delete, then slowly sort out the 
problem cases", but "first flag and sort out the cases" (what I intended 
the plugin for), and later "nothing left to delete because the community 
has already sorted things out".

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"