Submitted by “Ars Technica sat down today to talk with KHTML developer and Trolltech employee, Lars Knoll. We talked about his involvement in the project that ultimately became the HTML rendering engine for Apple’s Safari web browser, as well how Apple’s involvement has shaped the future of web browsing for browsers on just about every platform imaginable.”
I salute these guys for trying so hard to keep KHTML clean and pure and fast as it was originally intended to. Apple’s involvement greatly dirtied the code with huge chunks of Apple only code, and they still managed to make KHTML portable.
The interesting part is that these guys are willing to adopt Webkit as the next rendering engine for KDE’s web component. I’ll bet few freedom software fighters will allow that. Yet, this move benefits both camps — users get functionality earlier while Webkit can still remain cross platform due to their exciting work.
ps: now, now, gmail can finally ignore the difference between konqueror and safari if that happens…
I don’t understand why “freedom software fighters” would object to something like this. If the software is GPL, then what is there to complain about? If KDE developers are working with Apple and Apple suddenly turn nasty on them, well, the KDE people can just separate again. However, if the KDE people and the Apple people can work together, then they can both reap the rewards of their cooperation.
If a decision is made in favour of either KHTML or Webkit, I would hope that it is made for technical reasons, not short-sighted politics.
“I don’t understand why “freedom software fighters” would object to something like this. If the software is GPL, then what is there to complain about? If KDE developers are working with Apple and Apple suddenly turn nasty on them, well, the KDE people can just separate again. However, if the KDE people and the Apple people can work together, then they can both reap the rewards of their cooperation.
If a decision is made in favour of either KHTML or Webkit, I would hope that it is made for technical reasons, not short-sighted politics.”
At the time, and I’m working from memory here, the KHTML people were irritated mostly by the disparity between Apple’s PR and Apple’s behaviour. Apple’s PR folks went on, “ye olde leveraging open source synergies and playing nice with the community” rant, and Apple’s developers were doing little more than the bare minimum to meet licence conformance. There’s a bit of a gulf between ‘playing really nice’ and ‘bare minimum monolithic code drops’. I also believe that some of the KHTML folks were concerned that some of Apple’s engineers were overly focused on somewhat hackish make it work type fixes as opposed to more technically correct fixes. (Albeit one man’s hack is anther’s brilliant construct of pure intellect.)
Since then there seems to have been a certain amount of kissing and hugging and loving to go around… Or at least things seems slightly better.
@ Shade
Slightly better?
“Over time, Apple spend significant resources to retool their relationship with KHTML and the open-source community in general by making the Webkit project an open-source one. It was complete with an anonymous CVS repository, a full history of changes from Apple’s very first involvement in the project, a comprehensive web site with Bugzilla bug tracking, blog, mailing lists, IRC channel, and information for developers if they would like to help the project in any capacity.”
I would say that they are now perfect.
Fair enough
That’s what I get for skimming. I was mostly REing in relation to the original KHTML drama. For some reason ‘things are good’ just doesn’t stick in the head as well as, “Yarr!!! They be ebil.”
I think it has to do with this perception (due to some noisy people) about an anti-corporation speeches that are made.
The simple fact is, the vast majority of programmers are pragmatic – those who are noisy tend to make no contributions to or influence in projects. Those who are lead programmers, sure, they’ll make a few nosies, but they will compromise. Give that alot of what is reported is via the press, we don’t always get the full story, but instead a series of sound bites out of context to the larger debate.
Edit: with the move for focus on LVMM and Cling, I’m wondering whether it would be best to make KDE compile with LVMM/Cling to remain compatible with future MacOS X releases.
Edited 2007-06-14 04:29
Apple didn’t “dirty” the code. They forked kHTML so that they could change parts to be Apple specific for the purpose of speed. If they wanted to maintain portability they would have simply used the kHTML trunk as-is, and not bothered forking:- when Safari was first thought of, it was going to be Mac only, with no intention of being on any other platform. Not even iTunes had been ported then.
Webkit mandate that no patch may regress speed – at all. Apple are not shoddy coders.
It has only been recently, that the idea of porting Safari has arisen, for the purposes of providing software for the iPhone.
Webkit is as open source as any other project. Stop tub thumping just because it’s Apple.
Right now, probably.
For quite some time it wasn’t, at least not in the sense that external developers could apply for commit access or that Apple’s developer would notify external developer before changing shared parts.
As far as I understand Apple is improving the way they handle WebKit as a free software project, previously it just had a free software licence.
Don’t forget that XGL was kept closed for several months whilst it was initially being written, too.
yes, and Novell and the “brilliant” people involved with XGL were just are wrong then, too.
there are idiots in the free software world too.
> for the purpose of speed
actually, they picked khtml due to its speed and extensibility. the speed improvements they did make were completely portable. the forking was to (a) allow them to develop in secret at the beginning and (b) avoid having to figure out how to abstract out their macos layer properly. it had nothing (zero) to do with performance.
> they would have simply used the kHTML trunk as-is
well, of course they couldn’t do this as they wanted to port it to mac’s native rendering system.
> Apple are not shoddy coders.
they are good coders, yes. they also aren’t perfect and many of their changes have been questionable. nobody is perfect, so i object to people who try and defend projects (inc kde) as if they were.
> that the idea of porting Safari has arisen
safari, yes. webkit, no. webkit has been ported to various platforms for a few years now.
> Stop tub thumping just because it’s Apple.
that wasn’t why the ‘tub thumping’ happened. it was because it was usual apple “we don’t really understand how this community thing works” showing its ugly.
it has since gotten much better.
giving someone (in this case apple) a get out of jail free card is as bad as putting them in there unjustly in the first place.
but let me guess .. you’re a mac user and apple fan and you’re not overly familiar with the free software roots of the platform you love?
I don’t want to start any flamewar, I just would like to understand. Safari and OS X are proprietary systems, and how are they able to include GPL sofware legally without having to release all the Safari source code, or even all the OS X source code? I think they only release the rendering engine modifications (KHTML) and WebKit. So you can use GPL software in proprietary applications and release as GPL only the code that was changed? You don’t have to open-source your whole application? Please let me know.
Yes it’s somewhat confusing to non software developers.
Basically it’s like this: (many people believe) you can have GPL code and proprietary mixed together as long as they are modularized into libraries with seemingly static boundaries. On windows this would be DLLs.
So you could perhaps have a GPL DLL for handling say, drawing PNGs. And a proprietary DLL for handling BMPs. Your image editing app (like photoshop) which uses both of these could be proprietary or GPL without (as many believe) breaking the law.
Apparently it is somewhat confusing to everyone, because as far as i know that is incorrect. That was the whole reason to create the LGPL license wasn’t it? Which is what KHTML uses, so Apple only had to release the changes they made to it and not the rest of their application.
or even all the OS X source code?
That’s easy – you only have to release the code that is directly linked to the GPL code. Calling a system call in the kernel doesn’t count since that is more like passing a message to another piece of software rather than integrating that software directly into your own. That’s why you can run proprietary apps on Linux and GPL apps on Windows, because they are considered seperate works and not extensions of the other.
Edited 2007-06-13 18:36
From a legal point of view, there is no difference between calling functions in a DLL and using system calls.
Indeed, with the fast system call techniques, where any call to a special memory page (the VDSO) is a jump into kernel code, there is no technical difference either.
The only thing that makes the GPL “contaminate” library users is if the user is a “derived work”. If the program has to use that one and only library, it is probably derived. If it can use different libraries without changes, then it is probably not derived, and doesn’t have to be GPL.
The license is not GPL. It is LGPL. That means that changes to the library itself must be open source. However, the program using the library may be proprietary.
http://websvn.kde.org/trunk/KDE/kdelibs/khtml/khtmldefaults.h?revis…
Exactly. If it were licenced under GPL it wouldn’t be in kdelibs.
See rule #3 of the KDE licence policy http://techbase.kde.org/Policies/Licensing_Policy