Apple and KHTML

Apple's use of KHTML and KJS in WebCore, (part of Safari) was widely hailed at the time as a success story between open source and a commercial software company. That was two years ago. Recently, Apple announced that it had passed the Acid2 Test, which prompted users to start wondering when Konqueror would start being Acid2-compliant.

This, in turn, sparked a few developers to clarify that Apple's changes to KHTML and KJS were not necessarily in a form that was easily digestible by the KHTML and KJS teams -- in fact, Apple's changes in some parts, using OS X API, make the code more or less incompatible with KHTML and KJS. While Apple is complying with the license (LGPL), it would seem that Apple was not going much further than required by the LGPL.

After it became public that the relationship between KHTML and WebCore was not a symbiotic success story between open source and Apple, it quickly turned into a "vs." story in the mainstream IT media, like CNET's "Open-source divorce for Apple's Safari."

While the headline may be catchy, it seriously overstates the situation and misses some of the finer points in the relationship. In order to sort through some of the mess to present a more realistic picture, we tried to get folks from both sides to comment. Apple did not respond to a request for comment, but KDE developer Harri Porten was kind enough to respond to questions from LWN.

The first question we posed to Porten was what Apple could do in order to make collaboration more possible. Porten told us that it would be a big help if Apple could provide "an open JavaScript/WebCore CVS" to make it easier to track changes. At this point, there is no CVS provided. Apple does provide source tarballs, but nothing to make it easier to merge the code into KHTML or KJS.

Porten also pointed us to Zack Rusin's blog and his response to Safari developer Dave Hyatt. Hyatt asked what Apple could do better, and Rusin had plenty of suggestions. Rusin noted that, at this point, Apple and KDE developers had gone in two different directions:

Rusin suggested sharing a bugs database, having Apple hire someone to merge patches between the KDE and Apple source trees in sync, having Apple more involved in KHTML head development, and several other suggestions. Rusin also suggested that the two teams organize a phone conference.

While it's not clear if there's been a phone conference between the two groups, KDE developer Allan Sandfeld reports that there has been an IRC discussion and says that "Apple is being a nice guy for the time being, I will let them announce how things will improve once we have a solution," and asks for "no more 'vs.' stories for the time being."

Porten has also said that collaboration between Apple and KDE is "still very well possible at this time."

We also asked Porten whether Apple, or any other company, had an ethical responsibility to go beyond the terms of the license and actually cooperate with development. Porten said he didn't want to get into a discussion of ethics, but said that it "often simply makes sense to get engaged further than what the license requires."

At this point, it seems that the attention and negative publicity have helped to open the channels of communication between Apple and KDE once again. With any luck, the two groups will be able to find a way to collaborate on KHTML/WebCore in a way that makes sense for Apple and KDE.