Since I am mentioned in the first post, I should probably react too: It was not a deeply thought through proposal, just a general idea. And I still believe a good one. I can imagine that changing the API itself is a lot of work. Much worse, it serves as a public interface that unknown number of clients might use. Still I would not rule that out. Who knows when the next licence change comes (maybe in favour of compatibility with other licence) or some other event when substantial portion of data becomes problematic (eg. because some older import is found licence incompatible).
That said there are other ways to ensure the goal of this suggestion - seamless transition rather than deletions and angry/leaving contributors. One that comes to my mind and does not require any drastic changes would utilise filtering feature of JOSM (and required Potlatch to implement equivalent). Every night/week (depending on how demanding task it would be) each incompatible object would be tagged odbl=incompatible (server side). Editors would then make these objects non-editable/less visible... If API is not changed to serve the cleaned version of data, it would be good to have at least some editor-side tool to revert selected object to the clean state and then repair/edit it as it should be. In my original suggestion I said that this period (remapping what has to be deleted while still serving data under CC-BY-SA) should take a year or two - as long as needed till all the field in http://odbl.poole.ch/ show 99% or more. The time pressure is a false one, there has not really been any argument why it is important to change the licence fast. Lukáš Matějka (LM_1) 2012/1/28 Mike N <nice...@att.net>: > On 1/28/2012 8:30 AM, Frederik Ramm wrote: >> >> >> There is nothing fundamentally wrong or impossible about that. >> >> But it does introduce more work for us (because we would have to >> implement a way for the API to reject changes to tainted objects). > > > A notice could originate in the 2 most popular editors, and not require an > API change. The user would at least be aware of the problem before > continuing the edit. > > > _______________________________________________ > legal-talk mailing list > legal-talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/legal-talk _______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
