Safari vs. KHTML

Johnny Mnemonic writes "CNET has a story that describes the divergence between the code base of Safari and KHTML. Although there were high hopes that Apple would contribute significantly to the OSS project, that optimism has all but disappeared. Is an unrealized danger of OSS that others may take your project in a direction you didn't intend? Can OSS code and goals harmonize with the goals and needs of corporation designed code? Is it that Apple mismanaged the relationship, or that the KHTML guys expected too much? Interesting warning for other OSS-corporate marriages." We've previously reported on the frustration in the OSS community on this issue.

Comments

Its only the bad things we head about?

[Folmer]

Afaik the relationship between apple and freebsd is fine, and they use eachothers' patches etc. The problem seems to be that apple wanted to develop the browser in another direction than kde, and the communication stopped as they didnt use eachothers patches. As apple are having paid developers working on it, they should develop it their way and kde should maybe look at their methods to see if they are able to work in that way. If not, though luck.. I cant see that apple is the bad guy here.

Re:Its only the bad things we head about?

[Suppafly]

The problem with Apple and KDE is that apple doesn't make patches that are easy to apply to the khtml source. They release one patch that has tons of changes instead of one change per patch.

Re:Its only the bad things we head about?

[IamTheRealMike]

Is it? The last I heard of that relationship, Jordan Hubbard said FreeBSD had got a few minor bugfixes and test suites back. This quote sums up the Apple/FreeBSD relationship quite well, I think:

In his own posting to the FreeBSD mail archives dated June 25, Hubbard stated that his new "day job" would not be the end of his contributions to the FreeBSD and other projects. In his words, "Apple does fully understand the importance of FreeBSD and they don't want me or anyone else to stop working on it. FreeBSD doesn't compete with Apple's product offerings in any way and provides an excellent source of technology for them."

Taken from here.

Re:Its only the bad things we head about?

[Metzli]

That's a problem for KDE, but does Apple not have the right to do what they want with their patches? They wrote the code and they're releasing it to be viewed and used, so shouldn't that be lauded rather than complaining that they're not releasing things the way that the other guys want?

If Apple complained that the KDE guys were releasing code in a manner than didn't work for Apple, then people in the OSS community would say that the Big Bad Corporation (tm) is trying to control OSS and tell the developers what to do. Does Apple not get the same consideration? I thought the point of open sourcing code was to allow people to do what they want with it. Apple is, so either take what they're giving (for free) or shut up and write your own patches. It seems simple enough to me.

Re:Its only the bad things we head about?

[Anonymous Coward]

From the parent: "the problem with Apple and KDE is that apple doesn't make patches that are easy to apply to the khtml source

Noone seems to bitch about X.org changes not getting back into XFree86. Forks are not a bad thing. If Apple can move the software faster than the khtml guys did, they have my blessings. I wouldn't want to slow down Apple's progress by making them jump through hoops for the KHTML guys any more than I'd want to slow down X.org.

Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?

For almost everyone in the world it's a "fully realized feature" not "unrealized danger" of open source that if a new team can advance the software faster than an old team, they're FREE to do so because the software is OPEN.

Re:Its only the bad things we head about?

[JohnFluxx]

"Noone seems to bitch about X.org changes not getting back into XFree86."

True, but the X.org changes are all in some form of vcs unlike the apple changes that they give us.

The only 'hoops' we have asked for is that they give us some form of vcs (version control) logs rather than just a single 60MB dump :(

How on earth are we supposed to do anything with comments like "this fixes 2374924" without being able to view what 2374924 is? Some of the kde developers have offered to sign NDA's just to see the commit messages, but apple refuses to reply to such requests.

Personally I think Apple would gain more from working with us a bit more. Particulary with our new dom changes.

Re:Its only the bad things we head about?

[angst7]

As others will likely point out, they certainly are within their legal rights to do what they like where patches are concerned. But you're missing a crucial distinction between Must and Ought.

It is not required that Apple play nice with the way they release patches. That is to say there is not 'must' apart from the requirement that they make them available. But there's alot of 'ought' that comes into play when you use OSS code. This is basically a niceness test that says, in effect, if you use this code to make money, great, but you 'ought' to give back in such a way that we can make use of as well.

Having said all that I feel a bit bad about even responding to an obvious troll. There's very little 'insight' in your comment.

Re:Its only the bad things we head about?

[MoneyT]

Yes, because running it through the obfuscator is not how you work on code.

But the source files are just that.

If some 3 man team in the middle of nowhere started working on KHTML and just realeased the changed documents back to the public, would there be such a great outcry over the fact that they aren't providing the bug trackers?

Re:Its only the bad things we head about?

[Otter]

Absolutely not. Apple is required to offer source code to their product in the "preferred form". They have absolutely no obligation to make their changes trivially backportable to the original codebase.

Do you think the code to all those Linux-based hardware devices can be instantly patch'ed into the kernel.org source?

Re:Its only the bad things we head about?

[Anonymous Coward]

Let me get this straight...

KDE gives Apple (and everyone else) access to a monolithic block of code that doesn't run on Mac OS X, and that's considered a big favour. Apple gives KDE (and everyone else) access to a monolithic block of code that doesn't run on Linux, and that is the moral equivalent of spitting in their face?

Error, error, does not compute.

Re:Its only the bad things we head about?

[turbidostato]

"Let me get this straight..."

Straigth but wrong.

"KDE gives Apple (and everyone else) access to a monolithic block of code that doesn't run on Mac OS X"

The question is, it is NOT a monolithic block of code: everybody has access to KDE source code repositories and they can be analized checkin by checkin.

"Apple gives KDE (and everyone else) access to a monolithic block of code that doesn't run on Linux, and that is the moral equivalent of spitting in their face?"

Yes.

It is not because it doesn't run in Linux (the problem is not Linux, either, but XWindow). In fact, if Apple would develop its safari port in a way compatible with XWindow it should have been seen as a GREAT FAVOUR, but it wouldn't been asked not taken as an offense if the code itself was exactly what it is now.

The offense comes from Apple not giving (read)access to their source code repositories so you only gain access to a bunch of incompatible inextricable code while it would cost NOTHING to them to allow read access to the repo so that very same code could be analyzed checkin by checkin thus making possible to segregate incompatibilities from useful code in understandable bits.

No one sane would say Apple is not doing what is legally bound to do, nor anyone sane would say Apple's behaviour to be unexpectable (so this news is kind of flamebait), but yes, they could do things much better without them costing nothing and they decided to go for the most difficult and unuseful path for the KDE team, so KDE guys are reasonably feeling insulted.

Re:Its only the bad things we head about?

[IamTheRealMike]

Those aren't the WebCore changes, they're a few minor patches made for the Acid test. The bulk of the changes do not come in that form, and that's what the KDE people are pissed off about (or more accurately, they're pissed off at Apple apologists asking them when they'll merge the changes).

Re:Its only the bad things we head about?

[alienw]

Read The Farking License. It doesn't say "preferred form for the original developer". It says "preferred form of the work for making modifications to it". As in, ASCII source code. What they are saying is that you can't comply with the GPL by, say, releasing code only as a PDF file, or only as a hardcopy, or without the appropriate makefiles. Nowhere does it say you even _have_ to release a patch.

Re:Its only the bad things we head about?

[Anonymous Coward]

The thing is, the KDE guys did Apple a favor, and DID make it easy for them to get at the code.

This is the second time I've seen you post this bullshit. Quit it. It isn't true. The first the KHTML developers heard about it was when the first Safari beta was released, so they couldn't possibly have done anythingto help Apple out. Everybody was expecting a browser based on Gecko because of their hiring decisions.

If you still don't believe me, read the email yourself:

I'm the engineering manager of Safari, Apple Computer's new web browser built upon KHTML and KJS. I'm sending you this email to thank you for making such a great open source project and introduce myself and my development team. I also wish to explain why and how we've used your excellent technology.

Does that sound like the KHTML developers gave Apple any special help?

Again, people, stop modding this up, he's a clueless idiot spreading lies.

Re:Its only the bad things we head about?

[99BottlesOfBeerInMyF]

The thing is, the KDE guys did Apple a favor, and DID make it easy for them to get at the code. Apple just spit on their courtesy by just releasing their monolithic patches.

I'm not sure, what exactly did the KDE guys do to help Apple? Did they help them to incorporate the code into their Webcore fork of Konquerer?

Apple using Konquerer has already helped the KDE team in a number of ways. First they do have those patches to look through, in fact the acid test CSS patches from a previous article were even separately documented for the Konquerer codebase as much as possible given the divergence of the codebases. Next Apple using the Konquerer engine has made a lot of web sites compatible with Konquerer since Web designers are much more likely to test their pages against Safari than Konquerer. Also, they have advanced standardized HTML in general by promoting a browser that does not conform to either Gecko or IE's bugs and quirks.

I think it is unlikely that Apple is going to change versioning systems to make the KDE team's job easier, nor are they likely to implement changes on both browsers (even if they could which they can't since the Konquerer developers do not want to implement all of the same type of changes Apple has and don't use the same development tools or APIs). What they do, however, is provide their changes openly so that the KDE team can look through them and copy whatever fixes, improvements, or changes are useful to them. I'm sure both sets of developers are overworked and neither has enough time and both would like more people to do more for them. Maybe if the KDE developers asked for more granularity with the patches the Safari team would be willing to accommodate them. They would probably also be happy to answer questions and explain particular changes.

I guess I just don't see what anyone is mad about, and I'm not sure that anyone really is mad that is involved with Konquerer. This seems like a lot of people trying to make drama out of very little.

Re:Its only the bad things we head about?

[cuijian]

The article quotes from an email that an Apple engineer sent to the KHTML engineers.

"One thing you may want to consider eventually is back-porting (WebCore) to work on top of (KDE), and merging your changes into that," Apple engineer Maciej Stachowiak wrote in an e-mail dated May 5. "I think the Apple trees have seen a lot more change since the two trees diverged, although both have useful changes. We'd be open to making our tree multi-platform."

It sounds like Apple at least has been communicating with the KHTML guys to see how the situation can be improved. I think Apple deserves a lot of credit for being based on open source and working to see how they can increase cooperation. While they may not be as open as everyone likes they are supporting open source, which is much more than I can say for most big software companies.

I wonder how much of this article represents the view of one KHTML developer instead of the view of the larger KHTML team.

Re:Its only the bad things we head about?

[argent]

The LGPL says that changes have to be returned in the "preferred form" for exactly this reason

OK, I'm trying to figure out a definition of "the preferred form" that means "compatible with a toolkit they're not even using". Because that's a huge problem... the changes Apple's made involve porting what started out as KHTML to a completely different API, and no matter how frequently Apple released the patches, or in what sized chunks they released the patches, they'd still be full of changes related to the fact that Apple's APIs have evolved along a completely separate path from X11 for their entire lives. Carbon's API can be traced all the way back to the original Macintosh, and Cocoa is based on the NeXT ObjectiveC + Adobe Display Postscript code... and there's only one X11 toolkit that either of those APIs have any relationship at all with, and it's neither of the Big Two.

The only way to keep that from being a problem would be to have both projects agree to a common API for the GUI, and stick to it.

Do you honestly see that happening? Especially since the best compromise technically would involve the KDE people switching to GNUstep.

Re:Its only the bad things we head about?

[drakaan]

I'd imagine he (or she) was saying something along the lines of "after Apple rummaged around in KDE's browser code and started building something, they pretty much ignored repeated requests from the original developers to make things easier on them when dealing with patches".

It's not wrong per-se, but it's definitely rude.

It's easy to pick out one comment from a post that has some feeling in it and go sociology-101 on that poster. It's not much harder to try and see what the whole post is trying to get across.

Re:Its only the bad things we head about?

[Carewolf]

Right, and I've already merged those that applied. Now if only we got all patches divided up like that, rather than as the once a year code bomb.

Re:Its only the bad things we head about?

[Thomas Miconi]

That's a problem for KDE, but does Apple not have the right to do what they want with their patches

Of course they bloody do. That's called a fork ! And freedom to fork is the most important aspect of OSS - in fact enforcing and maintaining this freedom to fork is the central aim of the GPL.

Apple quite simply forked Safari. This happens all the time in the OSS world. Hello, does anyone really expect that X.org patches will remain 100% compatible with the XFree86 code structure ad aeternam ?

Could someone please tell me what exactly the problem is in the Apple-Safari case ?

Thomas-

Re:Its only the bad things we head about?

[Pete]

I'm not sure, what exactly did the KDE guys do to help Apple? Did they help them to incorporate the code into their Webcore fork of Konquerer?

The KDE project's CVS (and now Subversion) source control tree is totally open and accessible to anyone (including Apple), has always been that way and will always be that way. Also, the general convention (as I understand it) on large open-source projects like KDE (and especially so on core library components) is that code changes should be made in small, distinct, atomic blocks - with a meaningful commit comment to help comprehend the change (and so the changes can be easily rearranged and merged into, eg. a different branch).

This kind of system makes it relatively easy for the Safari/Webcore team to cherry-pick KHTML changes that they like. Though I have no idea how much they've done this, or even if they've done it at all - for all I know they've taken nothing from KTHML since starting Webcore.

But even so, the existing CVS history helps to understand historical design decisions, and indeed can be helpful in all sorts of subtle ways.

Now, conversely, Apple with Webcore. The KHTML team have no access to the Webcore source control system (it's not being run as a truly open open-source project, even if it is under the LGPL). The KHTML team have (AFAIU) only limited access to the Webcore bugtracking system, with some bugs not visible at all. From the story: "[KHTML] suddenly found themselves dealing with bug reports Apple deemed too sensitive to share, new requirements for auditing code before releasing it, and demands that developers sign nondisclosure agreements before looking at some Apple code."

I think it is unlikely that Apple is going to change versioning systems to make the KDE team's job easier,

Whatever Apple uses for a source control system is utterly and totally irrelevant. What is relevant is that their source control system is not publically accessible. You can't see changes as they're made, you can't track the development trunk. All you can do is take the occasional slabs of code that they release - and the whole point is that that makes it difficult to port interesting code changes into the KHTML codebase.

Added to which, the Safari/Webcore developers have entirely different (ie. commercial) priorities to the KHTML project. The KHTML team are prepared to take more time and do it right. The Webcore team are not - so they're more likely to use kludgy, lower-quality hacks that are simply unacceptable to the KHTML team.

And the Apple developers have done another thing which makes things even more difficult for the KHTML devs to use their changes - they're using significant closed-source functionality from Mac OSX system libraries... thus building in a dependency to a closed library. Which makes it even harder to work out what's happening when Webcore makes a call out to an external library to accomplish some vital task.

Maybe if the KDE developers asked for more granularity with the patches the Safari team would be willing to accommodate them.

Wow, you really haven't read any of the background on this at all, have you? The KDE/KHTML team did ask (many, many times), and the Safari/Webcore team weren't willing to (or weren't allowed to) accomodate them.

They would probably also be happy to answer questions and explain particular changes.

Weren't. :-)

Look, what Apple is doing with Webcore is (AFAIU again) completely legal. It's just that they're following the strict letter of the law and not at all the spirit of the law. They're not running an opensource project with Webcore, they're building a closed-source project (Safari) and making occasional monolithic code releases of the one major open-source component of that app (Webcore).

Re:Its only the bad things we head about?

[farnz]

AIUI, the big problem is that people see that Safari is built on KHTML, and assume that the WebCore codebase and the KHTML codebase are closely related; thus, when KHTML doesn't function as well as Safari, idiots go shouting at the devs, accusing them of being lazy for "not merging Apple's lovely changes quickly enough".

The KHTML devs would like Apple to either make it clear that WebCore and KHTML are now very different, despite the common ancestor, or to help merge things back. Either way, they want something to hit the idiots with that makes sense to a clueless type, rather than stick with the current "Apple says", "KHTML says", "But Apple says!" back and forth.

Re:Its only the bad things we head about?

[MudflapSoftware]

The thing is, the KDE guys did Apple a favor, and DID make it easy for them to get at the code

Ummm... no. The GPL gave apple the access to the code. Apple has been compliant with the GPL by giving the changes back to the community.

The fact that the changes are not in the prefered format is completely irrelevant.

AFAIK, the GPL doesn't dictate what format changes need to be submitted back to the project in. In fact, that would hypocritical, as mandating a specific patch format would be a limitation of our freedoms to use what software we want.

Apple is checkpointing their releases. They start with a block of code, make a buttload of changes and then run diff across it.

Big deal, stop whining.

Re:Its only the bad things we head about?

[99BottlesOfBeerInMyF]

The KHTML team have (AFAIU) only limited access to the Webcore bugtracking system, with some bugs not visible at all. From the story: "[KHTML] suddenly found themselves dealing with bug reports Apple deemed too sensitive to share, new requirements for auditing code before releasing it, and demands that developers sign nondisclosure agreements before looking at some Apple code."

Most commercial companies have to deal with customer information privately and that means restricting access to versioning systems, bug databases, trouble tickets, and code comments. I know I work for a company that uses a lot of open source code in our products. That does not mean we can allow access to privileged information that inevitably finds its way into the aforementioned systems. WebCore is as open as any open source project, but that does not mean the internal workings of the company making it or their customers has to be open to public scrutiny. Apple has to do business in the real world with government agencies and large corporations.

You can't see changes as they're made, you can't track the development trunk. All you can do is take the occasional slabs of code that they release - and the whole point is that that makes it difficult to port interesting code changes into the KHTML codebase.

Even so, Apple has gone out of their way to try and make it easier, above and beyond what is required by law. Changes that are specific to Apple technologies or that effect Apple only interfaces are commented as such.

Added to which, the Safari/Webcore developers have entirely different (ie. commercial) priorities to the KHTML project.

Actually I think this is the major problem. Apple wants a flexible web library, easily accessible using their dev tools and that is usable for the general public. KDE wants a browser for technophiles. Apple needs something that runs on OS X using their own window manager, and runs quickly. KDE needs the same for KDE of course.

And the Apple developers have done another thing which makes things even more difficult for the KHTML devs to use their changes - they're using significant closed-source functionality from Mac OSX system libraries.

Gee, I can't imagine why they would have done that. KDE has used significant KDE only libraries. Both groups want them to run on their own system, that is not a surprise.

Wow, you really haven't read any of the background on this at all, have you? The KDE/KHTML team did ask (many, many times), and the Safari/Webcore team weren't willing to (or weren't allowed to) accomodate them.

That's funny I heard the acid test patches were broken up into small chunks and had comments specifically for the KDE team telling them what applied to what as far as the codebase was still the same. I also heard that the lead Apple developer was soliciting suggestions for how they could make things easier, in fact it is still up on his blog. They can't release the bug reports, nor the versioning system, but Apple is certainly trying to be a good neighbor on this one.

They would probably also be happy to answer questions and explain particular changes.
Weren't. :-)

Got any source to back that up? What particular change was asked about that Apple developers refused to answer?

They're not running an opensource project with Webcore, they're building a closed-source project (Safari) and making occasional monolithic code releases of the one major open-source component of that app (Webcore).

Bullshit. WebCore is an open source web engine and there are even several new open source browsers based upon it as well as at least one other proprietary one (Omniweb which I'm using now). There is nothing wrong with closed source applications using open source ones. It violates neither the law nor the spirit of open source.

Apple marketing trumpet Webcore as a good wholesome example of Apple contributing back to the opensource c

Re:Its only the bad things we head about?

[molnarcs]

You miss the point. The main complain of khtml developers is that clueless users think that once a feature is present in Safari, it would be easyt ot port it to konqi. Quote:

And you know what? Thats their right. They made a conscious decision about not working with KDE developers. All Im asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. Theres absolutely nothing great about it. In fact it doesnt exist. Maybe for Apple - at the very least for their marketing people. Clear?

Also, this is not just "a problem for KDE." One reason for the difficulties is that Apple has different sets of priorities than khtml devs. Apple wants feature X present by a deadline. KHTML devs place equal importance on keeping the code clean and optimized. As a result, the Safari code is not up to KDE's coding standards:

Actually the biggest problem right now is that Apple are not keeping up with code-cleanup. We constantly try to develop more elegant easier to maintain code, where as Apple wants the right features - right now. Safari is basically still KHTML from KDE 3.1 with a ton of bug fixes and features. Many of the features takes time to port because they do not live up to our coding standards.

I think this situation could have been avoided if Apple tried to cooperate with KDE from the very beginning - and kde guys did quite a lot (creating specific mailing lists, giving cvs access, etc) to help apple devs. What KDE guys were asking for would have benefitted everyone: code cleanup could have been easily integrated into safari (some kde devs even offered to sign an NDA's to help!) while features might have been integrated into khtml. This is clearly a win-win situation that Apple missed.

A note on zealotry (not directed to parent post ... it is a general complaint). 1) It is quite funny that when I was discussing this on osnews, a bunch of people jumped on my posts calling kde devs names (whiners, zealots, whatevers) and praising apple for their huge contribution to OSS. And no matter how hard I tried, I couldn't get them understand that the main problem of khtml developers is not that Apple didn't contribute back enough (although that is part of the problem). Their problem was that - the result of Apple's marketing campaign about being first class citizens of the OSS community - users thought that they don't implement features present in Safari because they are lazy or they just don't want to or whatever. In other words, their gripe was with clueless users.
2) Check the asnwers to Carewolf's post. Apology, apology, apology... like "users DO NOT CARE if your code is 'elegant' and 'easier to mantain', users WANT THINGS TO WORK whether or not they are 'elegant' or 'adequate'." (why is he shouting? - and most importantly, why is he modded insightful?). IMHO, this kind of APPLE can't do wrong does disservice to APPLE - one of the keys to do successful business is to recognize the mistakes one makes in order to avoid them in the future. You can love APPLE and be critical at the same time!

Re:Its only the bad things we head about?

[Pete]

Shit it's hard to handle appropriate levels of contextual quoting in slashdot-HTML - at least for this long a post *wry grin*.

Most commercial companies have to deal with customer information privately and that means restricting access to versioning systems, bug databases, trouble tickets, and code comments.

And that's fine - Apple is well within their rights to do that. But doing that makes it a hell of a lot harder to consider Webcore a genuine open source project.

WebCore is as open as any open source project, [...]

As open as a project like KDE, which has a completely open source control system, a wide array of open and searchable development mailing lists, and an open bugtracking system? No, I though not :-). See below.

Bullshit. WebCore is an open source web engine and there are even several new open source browsers based upon it [ ... ]

You misunderstand my point. I didn't say that Webcore wasn't under an open source license, nor did I suggest that Apple was violating the license in any way.

What I did say was that Apple wasn't running Webcore as an open-source project. A serious OS project should first and foremost have the source developed in an open and freely accessible source control system (though this is not an absolute - many less active OS projects can achieve much the same result with infrequent tarball releases, mainly because updates to the project are infrequent). Less important, but also good, are openly accessible development mailing lists (though again there's some degree of variation here - some projects have a closed "core team" list - but the vast majority keep all lists open). An open and freely accessible bugtracker is also a big plus (though again, there's a fair amount of scope for restricting access to important security-related bugs, as does the Mozilla project with Bugzilla).

Regarding the different priorities between Webcore/KHTML:

Actually I think this is the major problem.

Well, it certainly seems to be a big part of the technical problem :).

That's funny I heard the acid test patches were broken up into small chunks and had comments specifically for the KDE team telling them what applied to what as far as the codebase was still the same.

As far as I'd heard, that was a case of too little, too late and I seem to recall another KDE dev suggesting that Hyatt only did it because he (the KDE dev) dared him to (as they'd been asking for lightweight atomic patches for ages with no response). I hope that's wrong and Hyatt is genuinely trying to help the KHTML project - it certainly looks as though he is, going by his blog.

Re: a comment I made about the Apple devs not being willing to answer question or explain changes:

Got any source to back that up?

Actually, no. Dammit. I thought I'd seen a couple of references on the KDE dev blogs regarding the Apple Webcore devs being "unresponsive" to requests for information, but I can't find those references now - I might even have misremembered them. I hereby withdraw that comment.

Well you certainly are opinionated, but I don't think you're as informed as you seem to imply. WebCore is a thriving open source project with numerous new browsers for both OS X and Linux based upon it.

You're dead right on the opinionated count :). And I'm sorry, I didn't mean to imply I was that well informed :).

My main objection to the "Webcore is a genuine open source project" is covered above - the lack of an openly accessible source control server is a bit of a deal-bre

Re:Its only the bad things we head about?

[RodgerDodger]

the changes Apple's made involve porting what started out as KHTML to a completely different API, and no matter how frequently Apple released the patches, or in what sized chunks they released the patches, they'd still be full of changes related to the fact that Apple's APIs have evolved along a completely separate path from X11 for their entire lives.

Yes. That's KHTML's problem. They want changes being written for another platform, but they don't have an application or code-base structure that makes it easy to seperate platform-specific code. Nor have they taken the time or effort to introduce one, _after_ they saw the nature of the Apple patches.

This isn't a hard technical problem: it's a political and organisational problem, for the KHTML project.

IMHO, part of the problem here is that KHTML wasn't designed to be extended in piecemeal fashion. Look at Eclipse: totally plug-in based, and if one port goes in an undesired (by the general community) direction, you simply swap out the affected plugin. Very manageable.

honestly.

[Suppafly]

We've previously reported on the frustration in the OSS community on this issue.

Atleast you're being honest.

Another question

[daveschroeder]

As long as they're abiding by the terms of the license, does Apple, any corporation, or any entity for that matter, have any obligation to contribute anything back to the project? Who gets to decide when someone is contributing "enough"?

Additionally Apple posts all of its open source code; here's the page for WebCore, which states:

WebCore is a framework for Mac OS X that 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. WebCore requires the JavaScriptCore framework.

The current version of WebCore is based on the KHTML library from KDE 3.0.2. Changes that are specific to WebCore are marked with #ifAPPLE_CHANGES. Other changes to improve performance and web page compatibility are intended for integration into future versions of the KHTML library.

Sounds like a case of sour grapes to me. I'm sure the level of cooperation and collaboration that the KDE/KHTML/Konqueror folks had hoped for wasn't there, if only because Apple keeps everything secret before its release (including everything related to Safari 2.0 in Tiger). Another example of a corporate need butting heads with a contrary OSS philosophy. And I'm sure Apple's main priority is not developing an infrastructure to cohesively and voluminously contribute changes back to projects. It's more like, "Ok, here's our stuff..."...it's all there for anyone to see.

Re:Another question

[Spy der Mann]

As long as they're abiding by the terms of the license, does Apple, any corporation, or any entity for that matter, have any obligation to contribute anything back to the project?

If you don't like that people JUST obey the license, then change the license!

i.e. If a company decides to launch a similar product based on this source code, they're obligued to keep a revision history in a previously agreed format (i.e. CVS, SVN, etc) so that the authors can track down their improvements.

Ta-da!

Re:Another question

[Refrag]

...and Objective C++ is a framework Apple has for Objective C code interoperating with C++.

"KDE/KHTML guys did a lot of work to let Apple have usable access to the code for KHTML, more than just a code dump"

What work did they do? When Safari first came out the KHTML team didn't even know about it. Apple just grabbed the code and went to work, they didn't need any hand-holding from the KHTML guys.

Re:Another question

[javaxman]

C++ IS an objective language. Objective C is the abortion of a language that Apple uses

You call Objective-C an 'abortion of a language', and then mention C++ as an 'objective language', and you are moded 'Insightful' ?!?! Wow. Words fail me. I guess we all get to have an opinion, but which language has a cleaner, more object-oriented syntax, Objective-C or C++ ? Both are useful, practical, powerful languages, but I'm going to have to humbly disagree with you- it's C++ that's the messier, less OO-centric language. What did Objective-C ever do to you?!? It's a fine, clean, well-designed, practical OO language.

I guess at least the remainder of your post is actually *somewhat* insightful, although it leaves me with questions. Did the KHTML guys really do 'a lot of work' to let Apple have access to their code? What, how and why? It would seem Apple couldn't need any more access to their code than any other developer. What special effort did they ask for ?

Is doing a diff of Apple's release vs. what they started with to determine new code that difficult? From what I've seen actual KHTML developers aren't complaining about this near as much as you are... sure, it would be nice if Apple could have it's engineers spend more time releasing modular change packages to KHTML, but where do you draw the line? Remember, it's not like those guys at Apple have tons of free time- they're overworked and understaffed for the amount of things they have on their plate ( I mean, have you ever WORKED for Steve Jobs?!? ), and it's not their responsibility to do more than they've done.

Seriously, I just see this as some KHTML developers wanting some respect, and not neccessarily from Apple. They want people ( like, KDE users and other developers ) to understand that *they*, the KHTML developers, are having to do some real work, that it's not all just Apple doing everything for them. And they're right.

hah, that's funny. Sane moderation strikes back. In the time it took me to write this, you've gone from 'insightful' to 'flamebait'. Let me check again. Yep. Still funny.

OS Divergence

[Veinor]

Open Source is designed so that everyone can see the code. If you can see the code, then you should be able to tweak it and make your own version of it, as long as you still give credit where it's due. Indeed, look at all the variations on *nix/Linux:

• Suse
• RedHat
• *BSD
• Knoppix
• Mandrake

And there are definitely more that I haven't included. If Safari diverges form KHTML, it's fine with me.

Safari on Windows?

[promantek]

In the article, Apple engineer Maciej Stachowiak said,
"One thing you may want to consider eventually is back-porting (WebCore) to work on top of (KDE)... We'd be open to making our tree multi-platform."

I wonder if that means they are looking to port Safari to Windows. It would give Windows users another taste of the Mac, and I for one would use it.

Re:Safari on Windows?

[Chucker23N]

Um.

Because
1) It's easy to port.
(It's not. Windows doesn't even have native APIs to support Objective C, let alone Objective C++. Porting this means porting large parts of Cocoa.)
2) Safari is just a little front-end for WebCore.
(It's not. Writing a WebCore front-end using WebKit doesn't require, I shit you not, a single line of code. Safari, on the other hand, has many.)
3) Apple would profit tons from this.
(They wouldn't. Giving away a browser for free for a foreign operating system without any other benefits is a honorary decision at best, not a business one.)

Um

[IamTheRealMike]

Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?

It's not unrealized, lots of projects have forked before. I think anybody who puts their code under a license that allows forking will realize that it can happen.

Can OSS code and goals harmonize with the goals and needs of corporation designed code?

Of course it can, this happens every day. Look at the kernel, GCC, Wine, etc.

Is it that Apple mismanaged the relationship, or that the KHTML guys expected too much?

I don't think expecting documented patches or a shared bug tracker is asking too much - this is the pretty much the minimal level of co-operation most projects would expect from a corporate good citizen. Some companies go even further than that, and hire some of the core developers, sponsor conferences, provide hosting facilities etc. There are plenty of examples in the Linux community of companies doing that.

So did Apple mismanage the relationship? Arguably there is no relationship. They certainly mismanaged expectations - if they'd come straight out and the beginning and said "we're not going to co-operate" a lot of frustration would have been avoided. That would have harmed their (mostly imaginary) pro-open source image though.

I doubt there's some kind of Evil Plan to screw over KDE here, it's more likely that Apple don't care or want to help the open source community, it's just a convenient place to take code from (go see how much FreeBSD has got back from them, for instance). Open source and Linux specifically are primary competitors and they'd be foolish to help the community more than they have to. After all, they're in the business of selling proprietary operating systems.

Re:Um

[danigiri]

"After all, they're in the business of selling proprietary operating systems."

No, really. They don't. They're in the business of selling computers and peripherals.

Having those computers and peripherals work well (or at least up to their expectations) incidentally needs of propietary operating systems.

Dani++

PS: look on the changelog of Bash, recently there has been some significant Apple contributions, reported on /., even.

Re:Um

[bahamat]

If they are going to feel betrayed when the project forks they shouldn't put it under a free license anyway.

Apple publishes changes they make to khtml. They have to because khtml is [L]GPLed. If anybody bothered to check, WebCore is licensed under the LGPL 2.1. There's absolutely nothing preventing KDE (or any other Linux destkop for that matter) from incorporating WebCore into the system.

What if someone wrote a new VM subsystem or scheduler for the Linux kernel, and then published patches and the new vm/scheduler? Would they still be villians? Even if they sold it commercially? Even if Linus didn't use it?

All you KDE developers, quitcherbitchen. Why GPL your code and then get pissed when someone uses or forks it? Don't snivle that Apple's version of khtml links against WebCore. Use WebCore. If you don't know how or don't have time to learn it, that's not Apple's problem, is it?

Here's a quote from Zack Rusin

[Lars T.]

he made after his rant.

Did KHTML become better as a result of Apple using it? Yes of course. KHTML became a lot, lot better as a result of patches we merged from Apple folks.

Re:Here's a quote from Zack Rusin

[Elwood P Dowd]

And even during his rant:

They do the very, very minimum required by LGPL.

And you know what? That's their right. They made a conscious decision about not working with KDE developers. All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is.

So really, the only people they were ever particularly annoyed with were us. Here on Slashdot.

Re:Here's a quote from Zack Rusin

[IamTheRealMike]

You're quoting Zack out of context. Here is the full quote:

Did KHTML become better as a result of Apple using it? Yes of course. KHTML became a lot, lot better as a result of patches we merged from Apple folks. And you know what? We've been quiet for almost two years. No one mentioned anything because we all hoped. We still do and always will. Everytime people complained about KDE developers being lazy and not merging patches from the great Apple guys we just took it. This time I simply refused to sit back and look at another /. discussion on Safari and KHTML cooperation.

Seems people like you are what Zak is pissed off about.

Obviously!

[sammykrupa]

Obviously Apple is not sharing there code! Slashdot looks great in Safari!

This sounds normal

[TimmyDee]

How is this different from any other OSS project? Two groups see the project going in two different directions and it forks. Granted, the Apple side on this one may not be as open as the KHTML people want, but in all honesty, I'm willing to bet that Apple has a much better code base than KDE at this point. The fact that Apple is suggesting a KDE backport of WebCore is pretty amazing. How many corporations do we see telling an OSS group, "Why don't you just take our code and use it for your project whole-hog"? My guess is not many.

Open Source Is A License

[American AC in Paris]

Folks, if you want your code used in a certain way, you put the terms in the damned license. That's what it's there for.

Besides, last I checked, the KHTML folks don't have a beef with Apple. They do have a beef with the fanbois who can't seem to grasp the fact that Apple using KHTML's Open Source code does not immediately mean that they're best buddies.

All it means is that Apple is using Open Source code. Period. Apple isn't violating anybody's trust.

Here's the source for the WebCore from Safari 2.0

[daveschroeder]

WebCore-413

And here's everything from 10.4, posted on the same day 10.4 was released. They even posted full binary PowerPC and x86 installers for Darwin corresponding to Tiger that same day.

This is just stupid

[Otter]

The original story just had Zach Rusin saying that Apple's contributions to KHTML were exaggerated. OK, fine.

This stuff is just stupid. Apple has done absolutely nothing illegal; arguably they've done nothing inappropriate. KDE and KHTML are not in any way any less well-off, and if this story accurately reflects the attitude of the primary KHTML developers, honestly, they're being jackasses.

What all this demonstrates is why using free code (especially GPL/LGPL code) is much more of a minefield than a reading of the license would suggest. You can comply to every last detail, and it doesn't do you any good against the negative publicity when someone decides you "owe something to the community".

Nothing to see here... It's just a fork

[Jarnis]

Apple has followed the obligation of the license.

It's just a fork. Forks happen. Move along. If KDE guys think KHTML sucks compared to WebCore/Safari, they are free to fork THAT and start from there (backporting it to KDE). The source is open. Whine less, code more :)

Childish Spat

[cyberlotnet]

This is nothing but a childish spat between 2 diffrent groups of developers.

Apple published the patches, and changes and KHTML cries about them having to much OSX specific code in them? Thats just crap..

Apple is acting in good faith, they are basically asking Apple to make sure all patches are 100% compatible with the current code base.

The KHTML team might as well just ask Apple to take over the project in full.

Open Source does not mean "Anything you do must conform and work with our project or your not doing it right"

Open Source is "If you make changes please give back to the community with the understanding that your changes might not be compatible with ours, Your code changes may not be what we want, but we can't complain about that"

Re:Childish Spat

[TravisWatkins]

They aren't complaining about Apple at all. They're complaining about Apple fanboys who say Apple is helping KHTML and about KDE users who think the KHTML devs are lazy for not merging the patches from Apple right away.

new here, but...

[greystreets]

Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?

Isn't that point of OSS, hoping that someone will take interest in your project and do something with it you couldn't do yourself?

And what's dangerous about that?

KHTML Developers Assumed Too Much

[mgbaron]

I think Apple made a decision that it needed to switch cores and at that moment has every right to do so and never look back. The fact that they are putting any effort into KHTML at all should be looked at as a mere bonus for the KTHML developers at this point. Apple never claimed to be the white night funding the KHTML project or that they would be the dominant developer for the future. This is not an example of IBM taking over a project. I think some KHTML guys read way too much into this relationship. It was pretty clear from the start that they were being used (but the nature of their license allows for this). It was great that they showed trust and attempted to built a relationship, but they should not have become in anyway dependent. I'm not saying this is the case, but the bitterness of their response seems to suggst this sort of dependence.

Sound like KHTML team doesn't want to play either

[MoneyT]

"One thing you may want to consider eventually is back-porting (WebCore) to work on top of (KDE), and merging your changes into that," Apple engineer Maciej Stachowiak wrote in an e-mail dated May 5. "I think the Apple trees have seen a lot more change since the two trees diverged, although both have useful changes. We'd be open to making our tree multi-platform."

The suggestion, which KHTML developers said they were unlikely to accept,


So Apple is open to making the tree cross platform, and presumeably to them back porting web core (which is nessesary to implement some of the things Apple has done since) and KHTML doesn't want to.

So by choice KHTML has already limited the changes they can use.

"In open source, everything's supposed to be done the right way, but sometimes the less correct way is faster," Rusin said. "In fixing one problem, they were breaking a whole bunch of other things. Apple developers were focused on fixing bugs in such a way that we could not merge them back into KHTML. Those fixes were never an option for us."

Ignoring for a moment the fact that OSS is not done the "right way" many times, Apple has an obligation to turn out code and to do it fast. They have obligations to their customers. The fact that KHTML wants to take their sweet time and Apple wants to get the patches done fast and out the door shows where the divergence is. Apple can't afford to take the open source approach of spending 5 years in beta before releasing the next version.

Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches.

KDE volunteers said they suddenly found themselves dealing with bug reports Apple deemed too sensitive to share, new requirements for auditing code before releasing it, and demands that developers sign nondisclosure agreements before looking at some Apple code.

So you mean once KHTML devs wanted access to code that wasn't part of KHTML, they had to play by Apple's rules? Say it isn't so! Apple plays by their rules for their code, but KHTML doesn't want to play by Apple's rules for Apple code. Again, choices by KHTML to limit their own options.

"As long as they needed us, they used us, but when they gained enough knowledge they had no reason to keep sending us reviews and patches," Rusin said. "At a certain point they decided it was a waste of time for them, and at that point the communication just stopped...We had hopes that they would pour resources into KHTML. But that never happened."

No, it did happen, but they're pouring resources in to the ways that allow them to serve their customers best too, and that means leveraging OS X technologies. KHTML has chosen to be just as uncooperative as Apple.

Free donuts

[flaming-opus]

you can't put donuts on the table in the break room and then complain when someone eats them.

Complaining about it shows a great lack of grace.

Nothing wrong with this...

[Port-0]

Apple hasn't done anything wrong. This is exactly the way OSS is set up to work. If someone made some software and you want to change it, you are free to do so. As long as you publish the changes. There is no rule you have to do it in a way that makes the original author happy, you aren't required to follow their vision. You are free from all that. If the original author likes what you've done, they should be able to take your work and merge it back in.

It's nice when everyone cooperates with each other, and keeps everything syncronized, but all that is frosting on the cake.

Read the article and know what is going on.

[WindBourne]

First off, I do KDE work, not Apple.
KHTML is under LGPL. Apple is doing what they are required. In addition, they have offered to move their code base to be multi-pltform. In the end, I think that the KHTML team will move towards this. It will allow full time developers on an import piece of work.

The article is doing a disservice.

OSS project mantra

[93 Escort Wagon]

How many times have you filed a RFE on an OSS project and gotten this back? "If you don't like how that works, feel free to submit a patch".

Okay, if you don't like how Apple provides its patches back to the KHTML guys, please feel free to write a tool that converts their patches into the form you prefer.

Learning about Apple

[Anonymous Coward]

How on earth are we supposed to do anything with comments like "this fixes 2374924" without being able to view what 2374924 is?

One of the things you learn about Apple as you work with them is that secrecy is paramount. Among other things, that means that NOBODY gets access to their bug database. Developers have been clamoring for a more-open database for years. KDE's not getting special treatment, that's how ALL of Apple works. Love it or leave it.

Re:Learning about Apple

[slipstick]

And the KHTML guys have decided to "leave it" and explain why. If Apple gets a black eye out of it so be it.

Apple could have tried to be a little more community spirited rather than just ignoring the needs of the very people they relied on to save them millions in development cost. How hard would it have been to include real comments in their patches rather than pointing to a bug database number?

Apple should start...

[emil]

...by getting everybody on the same source control software.

AFAIK, KHTML uses CVS, and Apple internally uses Perforce.

Nothing constructive can be done until everything is on the same platform.

Apple, offer to buy licenses of your source control software for the KHTML core. Even if they still spurn you, it will appear to the rest of us that you at least tried. You will look more and more of a villan until you make some effort at a reconciliation.

p.s. The KHTML team will need to be conversant with OSX to the point that they can remove GUI calls to it and replace them with QT. If this is a current problem, then some books might be in order.

It should be noted that...

[billstr78]

Dave Hyatt, one of the lead developers of Safari, has solicited comments and suggestions on his blog about how to better improve coordination between Apple's Safari group and the KDE Konqueror. team. Corporate support from Apple will have to follow, of course. I am sure that they are the main reason this coordination has not occured by now.

No problem here

[booch]

This definitely isn't a GPL violation, and doesn't even violate the spirit of Free/Open Source Software. The Apple developers are making their resulting branch of the code available in compliance with the KDE license. They're even trying to work to contribute their changes back to KHTML. Even if the patches don't apply cleanly, the KHTML developers are more than free to look at Apple's changes and add them by hand. Apple is even offering to give back their entire branch, to make it the new official KHTML, since their branch has advanced faster.

This really seems to be a case of the Apple guys offering their changes (or at the very least, making them available), and the KDE guys not being interested in them, or unable to use them for various reasons. It's really hard to blame Apple for that.

Apple's WebCore ported to gtk

[pb]

Check out gtk-webcore; their browser (osb-browser) is incomplete, but the renderer is great. I was able to load Google Maps with it and zoom in, something I haven't managed to do on konqueror. There's also atlantis, which seems to use gtk-webcore--I haven't tried it yet.

So... if Apple's code is so hard to work with, how did these people get it working? And using gtk, no less! Sorry folks--I'm no Apple fan, but Apple definitely *is* releasing code, and it *isn't* unusable.

This is being blown *way* out of proportion

[Illissius]

What actually happened, was this: KHTML developer Zack Rusin read one too many uninformed comment on the internets about how awesome the cooperation between KHTML and Apple is; being on the recieving end of the very not awesome cooperation, he understandably got a bit pissed off, and blogged about it. The thing to note here is his ire *was not directed at Apple* (recognizing that they were fulfilling their legal obligations, and were required to do no more), but rather at the uninformed idiots. This has now been spun, in part by those same uninformed idiots, into the KHTML devs being whiny Apple-haters, and the whole legality question has also been quite predictably confused into it all as well, which was never a part of it.
So far, I have seen exactly one comment on this thread with some understanding of this. it'd be sad, if it weren't so fucking ironic...

Re:Apple = Closed

[99BottlesOfBeerInMyF]

I can't imagine who modded this insightful. We really need the whole -1 factually incorrect mod.

iPod limited to apple services and formats, functionally a lockin product designed to trap users into the Apple Music Store.

iPods play MP3, AAC, WAV, MP3 VBR, Audible, and AIFF formats in addition to DRM'ed AAC files. Most users never use the iTunes music store. Also, why would Apple want to trap people using a store that they don't make any money on? You have it backwards. The store is a service they operate to make ipods more attractive.

Look and Feel. Apple has always imposed the most limits on the user's ability to customize his computer look and feel of any OS. Conformity is the Mantra at Apple. Individuality be darned.

Conformity eh, you mean like conforming to standards? Try editing the preferences of a program in Windows. What menu are they in? Answer, it depends on the program, they all put it somewhere different. Apple programs (and about 95% of third party programs for OS X) all have their preferences in the program menu and it is called preferences. All of the programs can make PDFs, from the same menu, in the same place. Can you see why that might be desirable? You don't have to hunt for things or remember different keyboard shortcuts, menu locations, menu names, etc. for different programs.

As far as look-and-feel goes, it is easy enough to change with third-party tools if you really want to, but you're right Apple discourages it. They spent a lot of time making things easy to use and don't want their systems getting a reputation for being hard to use because end users set the colors to really stupid things and put crappy bitmaps all over everything. They don't actively try to stop you, but they don't make it easy either.

Open Source. Apple plays lip services to opensource but does not give anything of signifigance back to the community. Darwin in open. Aqua is not. KHTML is open, Safari is not. On and on.

Everything Apple takes that is open source, they give back to. They publish their improvements and changes to WebCore which is what they have done with the Konquerer code. They take a different approach to things and provide a web service that all applications can use rather than just making one browser. You can write a basic browser using WebCore in about 5 minutes because all you need to add is the UI. Since the UI runs on a different window manager and rendering environment than Konquerer, the UI work is useless to them anyway. How about zeroconf? Apple wrote it and even provided a port for windows users. It is open and the protocol has been incorporated into printers, modems, routers, Tivo, etc. How about the new LaunchD daemon? It is a real improvement to a core UNIX service and not so different from the advanced schedulers used in some very expensive proprietary Server OSes. Linux can take the code and use it, or implement their own version using it as a reference. That does not include the patches they have submitted to Apache, MySQL, and dozens of other open source projects. It sounds like they are giving back to me.

Apple's image is ALL marketing spin.

Yeah, because contributing to open source is such a huge marketing fiat. Get real most people neither know or care what Open Source is and Apple sure as hell is not getting many sales by tricking the Open Source community into thinking they are helping the movement. Apple uses open source code because it works and they give back because it is in their own best interests. That is how open source works. Your view is severely myopic. Try reading some mainstream news for a change and seeing what the really real world thinks.

What's with the spin?

[eison]

How is this a 'danger', that other people do other things with a project that you have intentionally given the world the right to work on?

Re:Apple = Closed

[argent]

Apple has always imposed the most limits on the user's ability to customize his computer look and feel of any OS.

Actually, Mac OS X is extremely customizable down to a very low level. Apple doesn't give you a nice GUI for making these changes, because they consider the look and feel a brand, but neither have they made any deliberate effort to prevent people from providing the missing components. In fact, if they didn't hold their developers responsible for maintaining that look and feel it would be harder to go in and modify the GUI.

The company that is currently doing the most to take advantage of and develop the various hooks Apple has provided is Unsanity, and Shapeshifter is the premier tool of this type:

http://www.unsanity.com/haxies/shapeshifter

But there's also an open source project:

http://themechanger.sourceforge.net/

And there have been other applications going all the way back to Kaleidoscope on Mac OS 8. These apps don't just change the window borders, they change every detail of every control in every application... and Kaleidoscope did it first.

Re:I see nothing wrong with it

[argent]

If they would just shut the hell up then we could look at Apple as what they are, a passive OSS user.

You have obviously never looked at how companies that are really passive open source software users behave. Microsoft, for example.

Right now Apple is putting some really interesting code out there for people to pick up. They've provided a framework in darwin for completely changing the way UNIX systems are managed, in nicely packaged tools like launchd, complete with "configure" scripts ready for dropping in peicemeal or packaging for debian or Red Hat.

There's a whole damned revolution waiting on opensource.apple.com and nobody's paying attention to it. Why? because it's from Apple? because nobody knows it's there? Because it's not the Linux Way? I don't know. You tell me.

Re:Sound like KHTML team doesn't want to play eith

[molnarcs]

This is unbelievable (I mean the +5 insightful moderation). How can one claim that KDE developers have been just as uncooperative. They set up a mailing list specifically for Apple devs. They gave CVS access. All they asked was incremental changelogs instead of 60Mb code dumps. They even offered to sign NDAs with apple (and their offer was completely ignored) in order to get them.

"The fact that KHTML wants to take their sweet time and Apple wants to get the patches done fast and out the door shows where the divergence is. Apple can't afford to take the open source approach of spending 5 years in beta before releasing the next version."

This is quite ignorant. There are, admittedly some OSS project that are perpetually at a BETA stage. KDE is not one of them. KDE 3.4 had a few weeks of beta testing, and then it was released as final. Just as Tiger. Yes, there were a few bugs found since RELEASE - just as there were bugs in Tiger, and probably there will be more till the next release.

KDE developers did everything they could to help cooperation - in vain. And they don't even regret that as much as they regret that there are clueless users who overestimate APPLE's contributions.

And this makes hardly any sense:"Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches." Excuse me? What were you trying to say?

Mods: congrats!