A potted history of WebKit
Since then, WebKit has grown and prospered. It's the engine behind Chrome as well as Safari, for example; it has found its way into their mobile cousins on Android and iOS. It's also used by Nokia in the Symbian Series 60 smartphones, by HP in the Palm smartphones and so on. Many of Apple's competitors have contributed further changes and improvements, which are shared by everyone who uses it. ... until recently.
Apple released iOS 4.3.0 eight and a half weeks ago on March 10, followed by several point releases to take us up to version 4.3.3, where we stand today. We know these versions of the software have seen changes in the WebKit software, but until today, Apple hadn't uploaded any of those changes to the main source repository, although it continued to upload other modifications. Harold Welte of GPL Violations writes that "it cannot be a simple oversight, as multiple inquiries have been made to Apple by interested developers. However, the source code has yet to be released." Prior to today's 60-day delayed release, that is.
Unlike Apple, Google at least did have the courtesy of making an announcement to tell everyone that it wasn't releasing the Honeycomb source code -- whereas Apple was apparently ignoring people who asked for the source while stalling for a full two months. Apple said nothing publicly about why there was a delay and whether we should expect a two-month lag on future releases. Even more importantly, however, unlike Google, Apple doesn't have a choice about prompt and responsive code drops -- the company is legally bound to release the source code.
Why does Apple have to do anything?
Open Source comes in different flavors. There's a whole heap of licenses where, more or less, you can do whatever you want with the source code. Often the only requirement is that you continue to credit the people you took the code from. These include the MIT, BSD and Apache licenses, amongst many others. This means that, theoretically, a bedroom programmer could spend five years working on some amazing bit of code, only to have a major corporation repackage it with a slick makeover and sell it for billions without any comeback.
This bothered the people at the Free Software Foundation, so they wrote a different sort of license that would address these problems: the GNU Public License (GPL) and, a close cousin, the Lesser GNU Public License (LGPL). The details of how these work are very complicated (and often maligned), but the overall principle is actually quite simple: If you give someone a copy of a program licensed under the GPL or the LGPL, you have to also give them a copy of the source code if they ask for it.
Most of Android is under the first type of license, which is why Google could choose to not release the Honeycomb code. The people who wrote KHTML, however -- some of them bedroom programmers working on their own time, remember -- didn't want to get ripped off, so they licensed it under the LGPL. This means that when Apple took the project and built upon it, WebKit was also required to be under the LGPL -- and hence, under the letter of the law, any user of an iOS device should be entitled to a copy of the source code.
Apple's announcement in 2003 that it had adopted KHTML raised some eyebrows at the time, but over the years, Apple's come to be regarded as a good Open Source citizen. Apple engineers have contributed changes to projects they use for OS X quickly and completely. So what prompted this stall on WebKit source releases?
He's right that Mobile Safari does have this unusual new exception to iOS's general security settings, but it seems to me that whatever Safari does to get these special permissions from iOS is part of the operating system itself or the top-level control layers of Safari -- not part of the core WebKit library. Chances are, we'll know soon enough as developers and OSS engineers dive into the new WebKit source.
Considering that the mobile-optimized version of WebKit is used on so many competitive products, it's obviously in Apple's corporate interest to hold back on releasing the new build as long as possible; unfortunately, that particular behavior is incompatible with the LGPL license.
An alternative explanation was suggested by commenter 'Xuzz' on Hacker News -- that, specific to iOS, this is not actually a new Apple policy at all. It took six months for the company to post the source code to the Open Source parts of iOS 4.1 (which are available here). So, it would appear that the iOS team's source code release policy is to do nothing until someone complains (in that case, it was prominent jailbreak coders saurik and comex) and then, some time later, do a manual release. It seems strange Apple wouldn't make this part of its formal release process so that it's done automatically each time, but this way is probably cheaper. Then again, maybe there's a 60-day timer in the Cupertino Open Source Vault, holding out releases until the last possible moment (which is also, technically, an LGPL violation).
It should also be noted that this sort of thing is far from an Apple-exclusive kind of crummy behaviour. For example, HTC is quite slow about releasing source code to shipping Android products, as catalogued by Linux kernel developer Matthew Garrett (warning, NSFW langauge). Matthew also keeps a huge list that spans 165 different Android devices, with the vast majority of them not complying with the GPL -- despite them shipping products where almost every component has a GPL compliance requirement, unlike on iOS where it's a few isolated parts.
I think it's interesting that Google can choose to withhold BSD-licensed Android source code and be widely pilloried in the tech press, whilst Apple has been quietly failing to meet the spirit and possibly the letter of its GPL obligations on iOS releases for years without anyone raising a stink about it. Hopefully, this post will help to redress that balance a little. Pull your socks up, Apple!
UPDATE: John Gruber of Daring Fireball has written an elegant rebuttal to my conclusion.