[OSM-talk] How to start to remove non-CT compliant data..

[Mike Dupont]

I would like to make this more complex,
for my edits outside of Kosovo, I dont see any problem letting you
re-license the data, so feel free.
mike

On Tue, Sep 6, 2011 at 6:45 AM, Jo <winfixit at gmail.com> wrote:

> It would indeed be great if we could use an arbitrary version of an object
> to continue to build upon. Now, I have to start all over on each object that
> was touched by somebody who didn't agree (yet) to the CTs, which is
> annoying, as it disrupts the entire history.
>
> Jo
>
> 2011/9/5 Ian Sergeant <isergean at hih.com.au>
>
>>
>> I wrote:
>>
>> > To address your question specifically, what happens to data placed in
>> the
>> > public domain by the author on the wiki, who then specifically declines
>> > the CT?  Well in the first case, if the edits are just a trivial
>> > modification to a fully CT-compliant version - I'd say just hide
>> > them.
>>
>> Russ Nelson <nelson at crynwr.com> wrote on 03/09/2011 01:34:09 PM:
>>
>> > What problem does this solve?
>>
>> If data in this class is accepted as compliant with the CT then it
>> obviously solves no problem.  I think this is your point?
>>
>> Just repeating, like I have in all my emails, that I'm only proposing that
>> the API grants the ability to hide/remove data whose author has specifically
>> rejected the CT, allowing us to better manage the transition to a
>> CT-compliant database.  By allowing CT-compliant editors to modify and save
>> CT-compliant earlier versions rather than CT-non-compliant later versions we
>> avoid the possibility of generating more CT-non-compliant tainted data than
>> we have already.
>>
>> The acceptance or otherwise of this peculiar class of data where the
>> author has on the one hand said that anyone can do anything with their data,
>> but later tried to retract that by declining the contributor terms is an
>> interesting issue of policy.   I can see both sides of the argument.
>>  However, I believe the changes I am suggesting will be of procedural value,
>> regardless of how these policy issues are resolved.
>>
>> Ian.
>> _______________________________________________
>> talk mailing list
>> talk at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk
>>
>>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
>


-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20110907/b55943b6/attachment.html>