It's the little things we remember most sometimes.
I remember being really excited back in 2002, for instance, when Apple announced that it would be using KHTML and KJS library code as part of its soon-to-be-released Safari browser. These rendering components, one may recall, are part of the KDE Project's Konqueror browser and were forked by Apple into what would eventually be called the WebKit Project.
At the time of the first beta release of Safari in early 2003, Apple CEO Steve Jobs said that the company would release all of the modifications Apple made to KHTML on the same day as the beta release. This was confirmed by a statement on the Safari Web page at the time:
"For its Web page rendering engine, Safari draws on software from the Konqueror open source project. Weighing in at less than one tenth the size of another open source renderer, Konqueror helps Safari stay lean and responsive. And of course, being a good open source citizen, Apple shares its enhancements with the Konqueror open source community."
Here's what I wrote (oh sweet $Deity, eight years ago?) then:
WebCore, according the Apple's Web site, "takes the cross-platform KHTML library (part of the KDE project) and combines it with an adapter library specific to WebCore called KWQ that makes it work with Mac OS X technologies. KHTML is written in C++ and KWQ is written in Objective C++, but WebCore presents an Objective C programming interface."
According to Apple, the current version of WebCore is based on the KHTML library from KDE 3.0.2.
Yep, so young. So vanilla.
Dry writing aside, it was still pretty exciting. Perhaps even more so when Safari became a key part of Apple's mobile iOS platform strategy, helping the iPhone and later the iPad gain prominence with a really solid browser.
To date, Apple has been very good about keeping up with its open source commitments, pushing all of the open source code it uses and modifies back upstream in a timely manner. But now Harald Welte, of GPL Violations, is reporting that Apple is significantly tardy on releasing the source code from some of the LGPL components of WebKit in iOS 4.3.
"iOS 4.3.0 was released on March 10, 4.3.1 on March 25, 4.3.2 on April 14 and 4.3.3 on May 4. For all of those releases, no source code has been published," Welte blogged last Friday, adding, "It cannot be a simple oversight, as multiple inquiries have been made to Apple by interested developers. However, the source code yet has to be released."
You may note the parallel with Google's recent decision to hold off on the release of the source code for the Honeycomb version of Android. There are significant differences, which are kind of weird.
First, Google made their decision (right or wrong) to keep a better handle on the code to prevent Honeycomb, which some argue is not quite ready for phones yet, from showing up on devices before Google thinks its ready. Such conditions should not affect Apple since, as we all know, Apple controls the entire supply chain for its devices with an iron first (dressed in a black turtleneck).
Second, Google actually made a decision about this, and announced it. No word of any kind has been forthcoming from Apple, just a "coming soon" on the pertinent download page.
Finally, Google was able to make the decision to delay the release of their source code because Android is licensed under the Apache Software License, which doesn't specify when code has to be released. The Apple code in question is dual-licensed under the BSD and the LGPL... the latter license pretty much requiring a simultaneous release of binary and source code. So, this is not a decision Apple can really make.
I would think the developer community around WebKit might be willing to cut Apple some slack, if only Apple would bother to answer repeated inquiries about what's going on. Left with a mystery, people are starting to make assumptions about Apple's intentions--assumptions that are less than friendly.
Given Apple's past attacks on Android not being really open, there is a huge amount of irony in this current situation. Apple needs to be clear about what's going on, or risk damaging its relationship with the WebKit community and all the other open source communities with which Apple works.