In an effort to stem the tide of misinformation that has swirled around this topic since the initial blog post was picked up several weeks ago, Kurt Pfeifle has authored an 18 point article [mirror], which clarifies the KHTML/Webcore relationship in hopes that the confusion will stop. Comments on this story on
Hopefully this whole mess and flaming will lead to a better working relationship between the KHTML devs and Apple.
If this really happened, everybody involved, including Apple, would benefit from it, so let’s hope for the best and cut the flames.
…they already have, what was it, #16 or #17, about Apple and KDE developers meeting to discuss how to better manage the sharing/branch management stuff.
I’d like to see them both “profit” from this.
> Hopefully this whole mess and flaming will lead to a better working relationship
It would be sad if all those flames *of users* would have an influence. That would encourage them to continue to do so…
“It would be sad if all those flames *of users* would have an influence. That would encourage them to continue to do so…”
Let’s put it more neutral then:
Hopefully this whole mess and the sometimes heated public debate over this matter will lead to a better working relationship
Looks like a 12 point, or maybe 14 point, article to me — but it could just be the font settings in my browser…
🙂
How a link to something created partially by the nature of things linked/”discussed” on OSNews to get hits to clarify things is now yet another link to discuss/get hits on OSNews… Wash, Rinse, Repeat!
No, I’m not saying OSNews is fully responsible: the posters that respond accordingly are responsible. Just goes to show that regardless of whether something is open or closed source with more than one person involved, people will be people, and outside politics will always creep into the situation, regardless of what the people involved in that project want or do.
Because KHTML is licenced under the LGPL, is Apple even required to “give back” to the KHTML team? Couldn’t they just totally take a copy of the code and run without even talking to KDE people?
In either event, KHTML is great and I hope to see some collaboration on getting some of the more prominent features/fixes in WebCore back into KHTML.
-Eric
the trouble is really a community misunderstanding rather than anything directly versus apple. <p>
This is exactly why RMS is such a hard ass about the GPL! from the article, Apple basically took the code and “gave back” just before launch to prevent bad press.. not to play fair. Bascially they gave back “junk” so there wouldn’t be “offical” KDE fallout, but they never made an attempt to work with the developers… that was never their intention. Apple picked LGPL because they can use a great code base and hide all their improvements in proprietary stuff.<p>
The stuff should rightfully hit the fan when apple benifited from the publicity of using OSS friendly KHTML… but had been stuffing them all along. So what the KHTML devs knew they were being screwed… at least Apple was polite about it? True, apple didn’t break an “rules” but they benifited from allowing us to believe they were being a little more friendly then they were.<p>
This is the whole problem is that apple has a great OSS thing going and it’s sort of a “wet dream” that they would support such a cool project as KHTML. I mean we all want to see MS done in, and we all know iTunes uses the “safari” engine so I think we were all hoping for apple to sneak this in “under the radar” perhaps in iTunes or by proxy via Konquerer… I’d venture the community had their hopes a little too high… perhaps we understand the “game” a little better than the suits do.
Because KHTML is licenced under the LGPL, is Apple even required to “give back” to the KHTML team? Couldn’t they just totally take a copy of the code and run without even talking to KDE people?
Correct. There seems to be a lot of people claiming Apple is doing the bare minimum in discusions surrounding this issue, when in fact they are doing more. The GPL & LGPL only require that you distribute (or make available) machine readable source code to the people who you distribute binarys to. If Apple didn’t really want to embrace open source they could simply only distribute the source code to paying customers of Mac OS X.
There is certainly no prevision that changes you make must be given back to the original author in the format of their preference. Most projects which fork (as Apple has done with KHTML & KJS) don’t send any patches back to the original project/author. While I hope that Apple and the KDE project do find common ground and a way both projects can benefit from a better relationship Apple is certainly doing more then the minimum requirements of the LGPL.
> Hopefully this whole mess and flaming will lead to a better working relationship
It would be sad if all those flames *of users* would have an influence. That would encourage them to continue to do so…
It *is* sad that only such a negative publicity will drive Apple to even reconsider their unidirectional relationship with KDE. Even though I dislike flaming, I must admit they did make an difference, as compared to nice talking and willingness to sign NDA.
Sad the world is not so ideal as you imagined…
thats what its boiling down to. what apple is doing is following the lgpl to the letter. but some parts of the open source community have become used to a spiritual wrapping of their pet licences that isnt supported by the licences.
and when those belifes are questioned they react like many other belivers i have encounterd, pitchforks and torches.
in fact this reminds me of how some mystical texts warn that you must be very carefull about how you word your request to a demon. it will look for any way to twist it for its own amusement and benifit. come to think of it, that fits for lawyers and licences to.
What a thoughtful and well reasoned post. Don’t see many of those. Apple forked KHTML. Their code dumps, while not worthless to the KDE community, aren’t instant drop-ins either. Apple has fulfilled their obligations, but it would be nice if they did more – like give the KDE folks access to their versioning logs. Maybe Apple will do so after this realizing that if KDE people can get the stuff into KHTML from WebCore faster, then the KHTML people can work on other enhancements to KHTML that Apple can then integrate into WebCore.
Nothing is perfect and there is no zero-work code dump. Let’s all just hope that progress keeps getting made.
Apple picked LGPL because they can use a great code base and hide all their improvements in proprietary stuff
Oh really? http://developer.apple.com/darwin/projects/webcore/
For starters KDE picked the LGPL when creating KHTML/KJS not Apple, Apple picked the LGPL because that’s what the code was released under. Seconldy it would be very hard to hide improvements to the rendering engine in a seperate library. Reguardless the rendering engine is all there, under the LGPL.
i’m wondering how many of you actually start flamming wars on here…who use windows on firefox.
people hear the bad sensationalism and miss the retractions and corrections.
As Tantalic noted above, Apple have no obligations of any kind to the KHTML developers – even the GPL doesn’t require anything to be supplied to anyone other than the users of the product. For them to cooperate at all is more than they’re required to do.
Anyway, this whole issue is a waste of time, given the KHTML developers themselves aren’t actually complaining about Apple.
Well, see, the original “news” story has a bit more of a gripping power to it. There are people who want to root for the underdog, who want to see Apple be big and bad, and who would like to have a chance to stake out the line between Corporations and Open Source (especially in a case where the corporation is a “nice” company like Apple who might actually do something).
If they pay attention to the retractions, who can they be mad at?
No, Apple cannot do that. The LGPL requires they release their source code to any KHTML-derived product (ie: webcore), but not to Safari. So yes, Apple is in complience, to the bare-minimum level they need to be. However, in this day and age, when IBM has lots of developers sending nice, digestible patchs to the Linux kernel, ditto for Sun with regards to GNOME, and a bunch of other large corporations and high-profile open source projects, the Apple effort seems rather half-assed.
Because KHTML is licenced under the LGPL, is Apple even required to “give back” to the KHTML team? Couldn’t they just totally take a copy of the code and run without even talking to KDE people?
If Apple had been able to use KHTML without making any changes, then they would not have had to distribute the source. That makes sense, since the source is right there, on kde.org. However, since they’re distributing modifications of the LGPL’d libraries, they must also make the source available to anyone who gets the binaries. The difference between LGPL and GPL is in linking; if KHTML were GPL, then anything linked against it would be considered a derivative work, somehow. At least, that’s my understanding of it, but it really doesn’t make much sense to me…
“The difference between LGPL and GPL is in linking; if KHTML were GPL, then anything linked against it would be considered a derivative work, somehow. At least, that’s my understanding of it, but it really doesn’t make much sense to me…
”
The GPL does not rely on a definition of “linking” per see. It just relies on the copyright definition of derived work which is a gray area is some cases. When did legal matters appeal to common sense anyway?
No, Apple cannot do that. The LGPL requires they release their source code to any KHTML-derived product (ie: webcore), but not to Safari. So yes, Apple is in complience, to the bare-minimum level they need to be.
Assuming your first sentence is responding to: “Couldn’t they just totally take a copy of the code and run without even talking to KDE people?” then you are incorrect. Apple could have taken the code and not provided the source code to anyone but people who purchased their product. That is the bare minimum required by the license. The fact that Apple gives the source to anyone other than their customers is already going above and beyond the license. That said, one of Apple’s customers who received the source would have had every right to give that code to the KHTML team.
The specific license text says “You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange.”
http://www.opensource.apple.com/darwinsource/tarballs/other/
IMHO the press actually missed the point of Zack’s blog.
It wasn’t about Apple’s “misbehavior”. I’m sure Zack would also like Apple to be a little more cooperative, but I don’t think that he expected that at that point anymore.
IMO his blog was more about the user’s misbehavior and misconception. Since Apple picked up KHTML there were a lot of users that expected every new feature in KHTML to be a merge from Safari. There was no credit given to the hard work of the KHTML developers anymore. That’s the problem the developers are really fighting with.
the problem with Konqueror is that its bound to every KDE release, so upgrading to major patches isnt really often enough. KHTML development is slow, I’m sure they have clean code, but when it comes down to it, users want better workable code.
What Apple saw, is As fast as KHTML is, it certainly doesnt work with a number of websites. Its pretty obvious what KDE needs to do, unbound Konqueror/KHTML from KDE, have a different release cycle for Konq, so it can it move faster in development, and thus accept patches easier from Apple and a general merge between Webcore and KHTML can happen (both ways).
The reason KHTML developers can’t accept patches from Apple is that
1. The original KHTML engine has been significantly altered in the transformation to Webcore, including the use of Apple specific cocoa calls. KDE would need to write a whole Cocoa compatibility layer to incorporate their patches, and since they’ve already got one (Qt) that’s a lot of unnecessary code bloat.
2. As a result of (1) above, the two code bases are now quite different, which makes integrating patches very difficult. In fact, most KHTML developers don’t even try to apply the Apple patches to KHTML any more, they just use them as a reference from which they write new code to apply the feature / fix themselves.
3. Patches from Apple tend to be quite large, and aren’t explained very well (e.g. they might just refer to a number in Apple’s bug-tracking system, which KDE developers can’t access). As a result, it’s hard to tell what a patch is meant to do, which makes the process of incorporating them that much harder.
I don’t see how there can be a difference between “clean” and “better workable” code. You appear to be looking for a faster rate of new features and compatibility fixes. KDE developers are working on this, but without any commerical support (such as Apple or the Moz Foundation and its supporters), they have to do this in their spare time, which slows down the rate of development. Developing a rendering engine for the modern web is an extremely difficult task, so it’s not the kind of thing the casual developer can just leap into.
As I’ve explained, the pace of KHTML development has nothing to do with being a part of KDE; consequently, unbinding KHTML releases from KDE releases won’t have much of an effect on it. As it is, KHTML’s dependencies on KDE and Qt are deliberately limited (this is why it’s been easy to port to Mac OS X and Atheos), so in a way it already is “unbound”
Apple could have taken the code and not provided the source code to anyone but people who purchased their product.
While this is strictly true, the fact that any of those users can then post it on the web means that almost nobody bothers to take all those source code requests, and just puts up a tarball instead. So “bare minimum” isn’t the appropriate term — but “lowest common denominator” is.
I’ve been part of organizations that licensed another company’s source code.
These kinds of issues happen all the time. You’re lucky that Apple developers leave comments in the checkin fields.
When you have two development organizations ostensibly working on the same codebase there will always be procedural conflicts like this. There’s nothing new here, except that this stuff is being made public.
At least only one side needs to merge. If both sides needed to merge with each other, life would be orders of magnitude more difficult.
that article suffers from some serious comma abuse, especially in point number three.
You didn’t read the second to last sentence did ya? Maybe not a complaint, but insults always stem from something…
“Maybe for Apple – at the very least for their marketing people.”
“that article suffers from some serious comma abuse, especially in point number three.”
————————————————————–
I would like to correct a few people with respect to comma abuse. Its called coding style for the Enlish language, plain and simple.
Developers, Developers, Developers (said in an evil Ballmer / Unlce Festers voice).
Just kidding. Hope someone is laughing, other than me. 🙂
I see a certain bias in favour of Apple, but in fact nobody ever accused Apple, they just said; the kde developer cannot merge the changes because Apple only does offer obfuscated large diffs with heavily use apple-specific extentions. What they do is okay, but there is no collaboration as they only provide minimum returns.
The Mozilla developer who did not get informed first and drew his own conclusions has to apologise to KDE about his unappropriate flame against KDE developers.
This whole issue is stupid. Apple has done a lot with other OSS projects, but people only want to talk about KHTML. Well, they didn’t help out as much as everyone wanted, go cry somewhere else. The issue is stupid, and KHTML will still develop, and become better, and so will WebCore. The issue needs to be dropped, and people need to quit gripping about Apple.
And yes, Apple isn’t an open source, non profit, corporation. They are out to make money, so i have no problems with what they are doing, as long as it’s not illegal.
If you don’t like it, don’t buy Apple. Everyone has the right to choose what OS they want to use.
Thanks for the link to webcore; so, the source is there, what is stopping KDE from simply dropping in the code, and link everything back up again? I mean, according to some people here, its just a matter of merging a bit of code.
As outlined by the blogger, PARTS where REJECTED by KDE DEVELOPERS. So if there is something corrected in Webcore, and hasn’t been merged with the main KHTML tree, your argument should be with the KDE developers and their reasoning for not merging in that change – not Apple.
Apple has provided the source code; as far as I’m concerned, and the legal-beagles, everything they’ve done is above board. Yes, I know that OSSS fanboys would just *LOVE* for Apple to pump money into KTML and improve KDE, but hello boys? its a business, not a chariety.
>what is stopping KDE from simply dropping in the code
You are obviously not a programmer, or else you should have seen several important factors why this can not be done.
Webcore are basically a fork of khtml 3.0.1, with Apple adding some but not all of the changes the KDE coders have made to the code since then. It’s over 2.5 years old, what do you think the khtml programmers have done since, waiting for Apple?
In addition Apple adds code tied to Coca and the Apple’s api, which are not compatible with KDE/Qt.
And they puts out a great blob of code, containing several months of undocumented work . Any work to move the changes over to khtml have to involve splitting the code up into separate manageable patches and figuring out what they do and how they affect the code. Then try to rework the patches to work with current khtml. Sometimes more work than doing it from scratch yourself.
What Apple could have done was making the changes available on a patch by patch basis with comments, which is how they already have it in their SCM. Providing it would have cost near to nothing, making the cost a non issue.
Someone at Apple have fumbled this really badly, and from a business point of view they should fire the manager responsible. With not keeping the two codebases in better sync they loose the continuous work and support from people like Zack, Allen, David et.al. Any manager who don’t want the added contribution from several highly skilled workers for free or nearly no added cost, does not deserve his paycheck.
“Someone at Apple have fumbled this really badly, and from a business point of view they should fire the manager responsible. With not keeping the two codebases in better sync they loose the continuous work and support from people like Zack, Allen, David et.al. Any manager who don’t want the added contribution from several highly skilled workers for free or nearly no added cost, does not deserve his paycheck.”
Again, it’s not apple’s responsablity to develop khtml, just their fork. No one fumbled anything from either side. Just drop this stupid arguement. Each side does things their way, and that’s their rights.
>No one fumbled anything from either side
Apple got bad press associated with their OSS work, which they did not want.
Apple loses added benefit of highly skilled developers by not keeping code in sync.
Both could have been achieved by minimal cost, that’s called fumbling. It does not have anything with responsibility to khtml, but business and management responsibility from Apple. It’s people like you who try to make it a khtml issue, when its pure bad management from Apple(Not using available resources and making things more expensive than needed).
“Yes, I know that OSSS fanboys would just *LOVE* for Apple to pump money into KTML and improve KDE, but hello boys?”
Yes, and Apple Fangirls would love for Apple never to do anything wrong, to always be in the right, to be the “good guys” but that’s simply not always the case…
<
You are obviously not a programmer, or else you should have seen several important factors why this can not be done.
.
.
.
What Apple could have done was making the changes available on a patch by patch basis with comments, which is how they already have it in their SCM. Providing it would have cost near to nothing, making the cost a non issue.
>
You obviously aren’t much of a programmer either. Providing what you specify wouldn’t cost next-to-nothing. It would have cost a bunch of resources doing a bunch of work for no real benefit to Apple. Those resources have better things to do than to make it easy for someone else to do a clean merge.
When you’re working with people that move fast, you have to keep up or deal with the consequences. Open Source means other people can use your code, not that other people can stroke your ego.
>It would have cost a bunch of resources doing a bunch of
>work for no real benefit to Apple.
Wrong, the information are already pressent in whatever source management system Apple uses, setting up a CVS mirror or equivalent of it would practically free. Both in work and other resource cost. Stating otherwise are plain stupid, SCMs are nobrainers.
The benefit to Apple would have been two very identical sourcode trees, making any changes or bugfixes to the khtml tree much easier for Apple to merge into their WebCore tree. Wasting less time and resources rewriting those to fit into WebCore, dramatically increasing the number of developers working on the code at a minimal extra cost. Maintaining the illusion that the khtml developers don’t contribute valueable code are idiotic, particularly since it was their coding skills who made Apple chose khtml in the first place.
> Yes, I know that OSSS fanboys would just *LOVE* for Apple to pump money into KTML and improve KDE, but hello boys? its a business, not a chariety.
Let me get this straight. It is okay for Apple to take code that is worth hundred thousand of dollars and several man years work for free. But it’s not okay to ask for something in return?
Safari would never be where it’s now without this head start. So Apple used KDE as charity.
“Apple loses added benefit of highly skilled developers by not keeping code in sync.”
I don’t think apple cares about losing the help of the khtml team at this point. The WebCore developers can do more work in 2-3 days than KHTML people in a week. So, why would Apple want to wait for the KHTML developers?