[Osmf-talk] ODbL switchover at SOTM, bad idea

Simon Poole simon at poole.ch
Fri Aug 31 19:44:21 UTC 2012

/storm/ & teacup

Sure, if we want to avoid any inkling of impropriety lets switch the day 
before or after SOTM. In reality it is just coming together such that it 
in all likelihood we will be able to switch rsn.

Am 31.08.2012 15:36, schrieb Frederik Ramm:
> .................................We at DWG have already been
> told in no uncertain terms to "nuke" whatever problematic data remains
> as quickly as possible ("and sort out problems later"), and I believe
> folks at LWG are feeling a similar pressure.

I believe the correct quote is  "nuke the regions in question" (this 
would have involved, among other things, deleting essentially all of 
Germany  and I don't think anybody involved took this at face value, nor 
do I assume the intention was that we should take this literally).

> This doesn't sound good to me.
> If it is true that issues remain to be solved, solve them BEFORE you
> throw the switch. After so many years, diligence in the license change
> must not be dented for a cheap show effect, for a "nice
> opportunity" or just to have something to announce.
Two weeks ago we had no idea if , for example, the UMP cleanup would 
take a week, 10 weeks, or a year. As I wrote in the beginning, it just 
happens that things are coming together nicely (at last!). Once Pauls 
redactions have completed, I'm not aware of further immediate work 
necessary within the realm of current LWG policies. The DCMA stuff is in 
place,  I assume the CWG has stuff prepared. Since, as previously, our 
data consumers will not automatically get updates or a ODBL planet 
without deliberately switching, I don't see anything that isn't in line 
with the OSM courant normale 
(it is no secret that I'm not particularly happy with that, but that is 
a different topic) .

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20120831/dedb492e/attachment.html>

More information about the osmf-talk mailing list