[OSM-legal-talk] ODbL implementation plan - extra phase proposal
flukas.robot+osm at gmail.com
Mon Jan 30 23:41:00 GMT 2012
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
That said there are other ways to ensure the goal of this suggestion -
seamless transition rather than deletions and angry/leaving
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
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.
2012/1/28 Mike N <niceman at 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 at openstreetmap.org
More information about the legal-talk