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
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
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:
At some point the Open Source ideals which we apply to KHTML and commercial
setup in which you emerge yourself went in two different directions. At
this point we have two completely separate groups developing two different
versions of KHTML. We have absolutely no saying in the way you develop your
version of KHTML and you don't participate at all in the way we develop
Whatever solution we can come up will probably revolve around the following
two: either we'll have some say in the way you develop WebCore's KHTML or
you will start participating in the way we develop KDE's KHTML. It's
basically doing whatever we can to somehow build a bridge between both
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
Porten has also said that collaboration between Apple and KDE is
"still very well possible at this time."
It's just that the patch merging effort became non-trivial. Nothing that
couldn't be overcome by a more frequent patch exchange, though. The issue
of platform dependent API should be solved by appropriate
abstractions. This approach would help both parties as a cleaner design is
usually easier to maintain and more portable to newer versions of the
underlying system in the future.
Both parties are working hard on finding ways to cooperate more closely in
the future. We have to respect each other's needs in terms of release
cycles and policies but I'm sure we'll find a way. After all cooperation
within KDE works as well although the project is made up of hundreds small
but separate entities that all have their different background and
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.
to post comments)