So you're saying that you will never support the Free Software Foundation (FSF) and the Apache Software Foundation (ASF) as well, two of the most admired open-source projects in the world?

The ASF forces on all its code contributors the following similar language in their contributor license agreement: "You hereby grant to the [Apache Software] Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works."

In the FSF's case, you don't just share rights, you transfer all your copyright to the code to FSF.

And your concern is the reason why the CT does not *only* contain the section you quoted. The CT *also* includes material that the published OSM database can only be under CC-BY-SA 2.0 or ODbL+DbCL (or another suitably open license that active contributors can vote on).

IANAL, but this means that the OSM database can never be proprietary. In your hypothetical example of OSMF dissolving, the CT is likely to be dissolved as well and nobody gains any rights over the database without also gaining the responsibilities (that is, maintaining the "openness" of the OSM database).

Anyway, the OSMF Strategic Working Group currently is going through the Articles of Association (and presumably, the Memorandum as well) and it might be a simple matter to add a clause or something to make it explicit that the data rights conferred to OSMF via the CT cannot be given as proprietary rights to a successor in case of dissolution.

Hi. I'm really sorry for the bother, but the queue is now up to 445 as of this moment.

I'm not from Portland (nor even the US for that matter), but I would love if local government agencies in my side of the world would do what you are doing with OSM! :-)

Is there a deadlock again? Maybe there should really be a timeout.

Hi Lagpas,

I hope that you can provide updates and corrections as well. Bonifacio Global City is one of the best-mapped areas in Metro Manila in OSM. :-)

The same thing happened in the 2010 Chile earthquake. Parts of Chile moved several feet to the west. I'm not sure if the plate's movement was accounted for in mapping Chile since the earthquake. A problem is that satellite imagery tend to be aligned with respect to older imagery.

How dense.

The OpenStreetMap project is about creating a freely-licensed geodatabase of the world.

We don't talk about migration tips, or tourism suggestions, or advice on new places, or how to interact with locals. There are other websites for that. Try Yahoo Answers.

What has this diary entry got to do with OpenStreetMap?

Welcome to OpenStreetMap! Warning, it could be very addicting. :-)

My personal preference is to make that short segment of Tordesillas a two-way street. As you said in your changeset comment, Velasquez and Sanchez do not exactly meet in an intersection and I've seen this myself.

But this is just my opinion. Not a biggie problem. :-)

If you can update the editor to have smart handling of tags between the relations and ways, then you can also make an editor smart by noticing that adjacent ways have the same name and suggest to the user who is renaming a way if he or she wants to update the names of adjacent ways as well. No need for a relation for this.

Thanks!

It seems to have happened again, though.

There really needs to be a timeout. Maybe an hour? There seems to be something at the head of the queue right now that is taking almost 24 hours long to process. The changeset that I wanted analyzed is at the same queue number as it was almost 24 hours ago.

Alternatively, I could just run an instance of the History Viewer for myself. :-P

Hmmm... It seems that Cambridge Village (as a residential area) is not in OSM in the first place. This is the spot, right? osm.org/go/4zhH6nIk?m

Ah, so that's the story behind the Kiamba edits I've been seeing!

Does the NTC want an OSM workshop or can you handle that on your own? :-)

Interesting. I thought Ortigas was pretty well-mapped already. So maybe there's a temporary rerouting, or there's a new traffic scheme somewhere, or maybe there really was an error in the data. Scary. :-p

Hmmm, not sure where to report this but it seems that since you put the queuing mechanism in the History Viewer, either:

a) some changesets take a really long time to analyze (maybe put a timeout?) leading to a long processing time in the queue, or

b) the queue doesn't "pop" until somebody has viewed (or fetched the HTML output of) the latest processed changeset leading to a possible deadlock?

They indeed look better. :-)

I find the History Viewer an invaluable tool for inspecting changesets. Thanks for developing this!