Inserting data into OSM which came from a copyrighted source is definitely a no-no (unless that source explicitly gave permission, which has happened in several cases).

If you find some data in OSM which you think looks suspicious, there's a procedure to report it.

Quite often it's down to ignorance, rather than malicious intent, where a new mapper doesn't realise that the map they're copying from is either copyrighted or under a licence which prohibits derivative works.

This has been hashed out endlessly on the OSM mailing lists, and yours is definitely a minority viewpoint.

You've probably just got lucky - commercial data is ahead of OSM in terms of addressing, however you will find errors in pretty much every country (roads that aren't there, roads with the wrong name, roads in the wrong place, etc).

If (when :-) you do find an error, please check it out on OSM and see what it looks like there - if it's wrong in OSM, you can at least fix it. :-)

The map tiles are certainly Apple's own - they have defined their own stylesheet, with their own look.

However the map data those tiles were rendered from appears to be a mix of TIGER in the US and OSM elsewhere. TIGER is a public domain dataset from the US Census Bureau, and OSM is CC-BY-SA.

Looking at the shape of the data is often enough to tell you where it came from. One one level it's modelling the same reality, but in practice mappers tend to make slightly different versions of "the same" object (a road might be smoothly curved, or quite angular, depending on how much effort they went to). As such you can quite easily see when data comes from the same source, even if it's rendered in a different style.

It's pretty conclusively OSM if you look at which small features (footpaths, lanes within a car park, etc) are rendered. This data isn't present in the commercial datasets you can licence from people like TomTom, however it is in OSM (neither Navteq nor TeleAtlas have footpaths, or this kind of micro-mapping of lanes within parking areas).

Based on things like this, typos which appear on both maps, and roads that are in OSM now but aren't in Apple's tiles - it looks pretty clear that they used a snapshot of OSM, specifically one from early April 2010.

GPS devices normally have much worse vertical accuracy than horizontal, unless they have a barometric altimeter.

OSM's database currently just holds latitude and longitude for objects, and you can tag things with a z-level to indicate when something is over or under something else. For 99.99% of objects, that's perfectly fine and sufficient for topological modelling (if you mean topological in the sense of the connections between objects, so that you can calculate a route from A-B-C-D).

For some objects a specific altitude might be worth recording, and since OSM uses an arbitrary key=value store for data you can easily record the altitude for a point if you think it's useful (you might want to record the elevation of a mountain peak, but you probably don't want to record the altitude of a post office or public toilet).

Using a key-value store means OSM has an inclusive data model; you can store whatever data you think might be useful, within reason.

It is not yet under ODbL - the licence changeover is planned for the 1st April 2012 (however Apple appear to be using data from circa 2010, which was definitely under CC-BY-SA).

In practice the problem you see (ambiguities in the endgame) are only really an issue for computer Go. Human players rarely disagree over when a game is "over", as typically the outcome becomes obvious long before each stone is played out to the absolute end.

Perhaps a good analogy is poetry: it is perfectly possible for a poem to convey meaning, even if it does not conform to the rules of the language or have a literal meaning (and yet, people still understand it).

The thick book of "how to interpret patterns" is simply a set of standard plays that people have found empirically to work well (in exactly the same way as opening books are used in chess). Like chess, you are free to ignore those patterns if you like, but typically that leaves you in a weaker position than you would be in otherwise.

These patterns are most commonly used in the opening moves, but local instances of them pop up all the time ("if he moves there, I should move here, then he *has* to move there I'll capture these stones").

The rule is that game is over when both players agree that it is over: if there is a disagreement, the game is played on. Some positions lead to an infinite repeat (A captures B, B captures A, A captures B, etc) but thee plays typically don't determine the final score (if the score was equal, and there was an infinite repeat, then humans would simply call it a draw). Computers can recognise trivial cases of this easily, and do OKish with heuristics for simple cases.

However the real difficulty in computer Go is understanding just why humans make the moves they do, as outside of the standard sequences a move is often made intuitively as a way to steer the other player even though the consequences of that move may be some way off (or may need to be abandoned, or redirected, or reused in some unplanned way).

Go is a truly fascinating game, and also a very human one (computers will play it well one day, but probably about the same time that they get good at writing poems, playing tricks, or asking why).