The WebKit JavaScript implementation is essentially the one exception to the downloadable code rule. I imagine that you could still be rejected for implementing core functionality in downloadable JavaScript, as that would open up a potential security hole.

The summary states that the character code for the open sarcasm mark is U+0161, but the opensarcasm.org site says that it should be U+00A1, which is graphically identical to the Spanish inverted exclamation point but apparently has a historic Ethiopic precedent as a sarcasm marker. Incedentally, when I first read the summary I opened up the Character Viewer applet in osx to see what the mark looked like. Since I misread the summary, I first looked up U+1610, which looks almost exactly like the proprietary bullshit SarcMark, only lacking the interior dot. The shape of the spiral is almost identical though, and U+1612 has the same spiral shape and does have a dot, though the dot is placed slightly differently than in the SuckMark. If a drop-in replacement for the proprietary mark is ever needed I'd nominate U+1612.

When I first read the new agreement I was mostly just confused as to it's purpose. Obviously there's the competitive angle, as so many have pointed out, but upon reviewing the release notes for OS4, I think it's really much more of a technical decision. Beginning with Snow Leopard and now continuing into the new iPhone OS, the language of choice for development is no longer Objective C, C++, or even plain old vanilla C. These old standbys have been supplanted by what I like to think of as Apple-C, distinguished by its inclusion of a new language feature, blocks.

Blocks (closures, lambdas, etc to lisp and python folks, et al) are essential to both the concurrency engine in Snow Leopard (Grand Central Dispatch) and the multitasking implementation in the new iPhone os (essentially GCD lite). Also, a large number of new APIs are written around blocks, and it's clear that they will play an increasingly important role in the future of Apple's development efforts. Personally, I'm all for it. I've always hated function pointers, and the delegate pattern in objective c leave something to be desired. The inclusion of blocks was, to me, the most exciting feature of Snow Leopard. However, by basing their development platform on a non-standard language feature, Apple is walling themselves off from languages that either lack the concept of closures altogether, or whose implementation is in conflict with Apple's. Given Apple's mad lust for control, that probably didn't seem like much of a trade off.

Now clearly, an intermediary layer that complies into objective c or ARM assembly could maintain compatability somehow, and it seems capricious and arbitrary to forbid such a thing. However, this seems like a natural extension of the position Apple took when they fragmented the language - if you want your code to fit into the Apple ecosystem, you'll use Apple's tools. In a context where resources are extremely limited (like, say, a phone) this position makes even more sense. Now that the door is opening to background processing (with limits, of course), they need to make sure that it is as efficient as possible. Sure, on OSX you can load up a python interpreter for your clever network daemon, but that kind of overhead just isn't going to fly in your pocket.

I realize that for a lot of people, this new agreement still sucks ass and is further evidence of Apple's desire to control our thoughts and take over the world. But for those people there is a simple solution; just jailbreak your damn phone and you can load up as many interpreters as you want, or port gnash over and watch some free tv. Or eschew the iCraze altogether and buy a different phone. Either way there's options aplenty. But if you want to go through Apple, you can have any color you like, as long as it's black.