Apple releases iOS 4.3.3 WebKit source, but stretches the spirit of the LGPL

Remember when Google said it wouldn't release the source code to Android 3.0 ("Honeycomb") because it "wasn't ready"? Remember the snarky remarks from Apple bloggers about how it was rushed to market and the definition of "open"? And the hopefully thoughtful piece I wrote about what this might mean about what happens next?

Now imagine if it was Apple stalling on releasing source code that it had promised the open-source community. Surprise! It was.

Brian Proffitt wrote a post for IT World, published earlier today, detailing how Apple is refusing to meet its obligations by failing to promptly release the source code to the latest version of WebKit, which makes up most of the guts of the Safari web browser in both mobile and non-mobile flavors. While competent interpretations may differ, most FOSS folk agree that the LGPL license involved requires a simultaneous release of binary and source code.

Eerily, just as Proffitt brought light to bear on the issue, Apple's opensource site released the source for projects included in iOS 4.3.3 (thanks to reader Jan for the heads-up). This code release, while certainly welcome, comes 60 days after iOS 4.3 first became available for download from Apple's consumer-facing servers; this timeline cannot possibly be reconciled with any reasonable definition of 'simultaneous,' unless Apple is in possession of a TARDIS.

Apple's sluggish code drop, in a couple of ways, is notably worse than Google's seemingly similar reticence.

A potted history of WebKit

Modern web browsers are made up of a few big chunks. By far, the biggest is the rendering engine, which is responsible for receiving web pages and images and figuring out how they should be displayed to the user. Writing a new rendering engine from scratch is an enormous undertaking. So, when Apple announced Safari at WWDC in 2003, it also announced it had taken a shortcut -- it started with the open-source KHTML software, which was the core-rendering engine in use by the KDE Linux desktop project. It made a heap of improvements to KHTML, and it was calling the new software WebKit. Safari is made up of WebKit plus the user interface and some other bits and pieces, such as the JavaScript engine Nitro.

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.

Why now?

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?

John Gruber speculates that it has "something to do with the introduction of the Nitro JavaScript engine for MobileSafari [sic], and the security implications of granting MobileSafari -- and only MobileSafari -- an exception to the system-wide ban on marking memory pages as executable." Whilst possible, this doesn't quite ring true for me.

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.

Conclusion

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.

[via Slashdot]