Slashdot Mirror
Konqueror Passes the Acid2 Test Too
An anonymous reader writes "A month after Safari , and after a lot of controversy, Allan Sandfeld Jensen announced today that Konqueror passes the Acid2 test too. Half of the patches could be merged from Apple's Webcore, the rest needed to be rewritten from scratch."
Sorry, dont know what that is. Could someone post a link...
"Allan Sandfeld Jensen announced today that Konqueror passes the Acid2 test too. Half of the patches could be merged from Apple's Webcore, the rest needed to be rewritten from scratch.""
It's amazing what people can do when sufficiently motivated.
I for one am very glad that the Gecko/Mozill engine is not our only choice in free software based renderers. There is some security in seeing that we have at least two projects with excellent browsers available for the community.
Congrats Konqueror team!
I wonder if anyone is working on a Windows port of this?
Throw the bums out!
There were never any gpl violation wrt khtml.
Konqueror guys didn't like the patches from apple.
Looks like they could handle these patches, though! good for them.
jeff
ipv6 is my vpn
Both Safari and Konqueror have improved because of Open Source. Even though the two teams worked independently, they benefited from having access to the other's code.
Does it really matter what Apple's motivations were? The end result is that Open Source development has helped both products.
I'll probably be modded down for this...
What's C? What's RSA? What's a race condition? It isn't "News for people who are too lasy to learn things on their own", now is it?
I think it's great that the KHTML team have managed to pass the ACID2 test only a month behind Apple. However, I am skeptical if this kind of pace can be continued in the future. Firstly, it looks like the KHTML developers might have been working harder than usual just to pass the test so that they wouldn't lose face. As the two code bases diverge (they only merged half of Apple's patches) it will become increasingly difficult for the KHTML guys to keep up. Webcore is effectively a fork, and there's a diminishing degree to which code can be shared between the fork and the original.
Unless KHTML receives extra resources (in money, developers, etc.), I fear that they may be left behind Mozilla and Webcore.
OLPC Australia
There isn't any violation, technically, but IMHO the spirit of the GPL has been broken. Of course, spirit isnt legally defensible. Apple released patches in large gobs instead of in easily digestible chunks, and their code comments made many references to bugs in the internal Apple bug database (which isn't available to the KHTML team). They also made many Mac OS specific (KDE incompatible) changes and they disallowed CVS access.
OLPC Australia
Still waiting for Firefox and Opera to pass the test, too.
shouldn't Apple be doing more?
Doing more then what? By what people can tell, most of the dispute is because the Safari/WebCore and the Konquer people are doing different things with the code and also use different source managment systems. Apple uses one that most of the OS X devs use. And that is completly different then the one the KDE folks use.
Thus far, most of the complaints has been "Apple isn't doing it our way." Apple shot back with "Use WebCore, we will even show you how and assist on making it multiplatform", but that got shot down by the K folks. The issue isn't just with one side, it's with both using their normal work flows and expecting the other side to change everything.
Apple doesn't ship Konquer in their OS and has no plans to. KDE has no plans to use WebCore. So diversity issues are going to happen, and either side can just live with it, or do something about it. But it seems the KDE folks would just rather sit and whine about how Apple isn't doing things their way.
Maybe I missed it, but if you can point out to me where in the GPL it says you must bend over backwards to make a group of people happy, I'll conclude Apple is doing something wrong. Until then, I'll file this under the "people are never happy" section, and be one of the few to appreciate what Apple is doing to help OSS, and to promote the adoption of Unix in many areas. Sure, it's not the Linux way of things, but Apple is doing a hell of a lot better then say Sun with Solaris or HP with Tru64/HPUX to push the Unix platform across all spaces.
Actually, if you read the email exchanges, you see Apple engineers discussed the patch tarballs and actively assisted khtml developers when they asked for reasonable things (ie, not access to internal Apple revision control systems). KHTML devs did not reveal this (to my knowledge) in their "open letter" this cooperation, which is quite a bit more than the LGPL. The LGPL requires you make the patches available- that's it. Apple sent them, discussed them, provided help interpreting them, did work by proxy, etc.
This is a logical fallacy called "fallacy by omission", and the specific technique employed was called "Stacking the Deck".
What becomes apparent is that the KHTML team doesn't like that Apple is doing everything they should be, getting commended for it, and that the work (supposedly) wasn't useful to them (we see now that's not the case, as half the patches were easily applied).
If integrating half of the patches only took a month or two, guess what- it wasn't nearly as impossible as the KHTML team made it out to be, and the code wasn't nearly as useless as they portrayed it to be.
WEBCORE CODE CANNOT JUST BE DROPPED INTO THE KHTML TREE. Webcore directly uses OS X features. That is one problem. The code bombs Apple drops periodically have inadequate documentation as to why some changes were made and not others.
The second is irrelevant because of the first; they're also unrelated, though you imply them to be compounded. It's not Apple's responsibility to turn over Webcore, or convert the code to use something besides Webcore. They're not allowed to sit on that code, they HAVE to provide it.
Second, they've provided several of what you've referred to as "code bombs", which is one step ahead of a company that would just provide them with ONE tarball; they're sharing work progressively, and have an active dialog with the khtml team.
Webcore at this point is a khtml fork that is about two years old.
And your point would be what? The LGPL doesn't say "help integrate old code". It doesn't say, "only fork recent code", or "don't fork code at all". It doesn't say "provide changelogs". It doesn't say "provide the project coders with access to your internal revision control systems and corporate network". It doesn't say ANY of that! EVER! PERIOD!
I'm sorry, but this whole thing has left me very embarrassed for the open-source community, and left me with a very bad taste in my mouth. Apple IS one of the better companies as far as contributing to open-source, they've brought open-source technologies to more desktops than anyone else, they've come up with some truly unique technology which they've provided source for- and they still get kicked in the teeth.
A lot of companies are looking at how Apple was treated, and thinking, "geez, Apple did more than just send tarballs, and they got pretty beat up for it." Question: do you think this will encourage or discourage companies to do work on open-source projects?
Please help metamoderate.
Actions speak otherwise- half the patches integrated according to the article.
It means in future open source projects will know what's coming when Apple decide to get "involved".
Yes. They can expect to get regular tarballs, participation of senior team leaders, active dialog on public mailing lists, and assistance of Apple engineers in interpreting the tarballs.
(No, seriously. Go read the archives and look at the discussion that follows when Apple sends in a code base. The "burnt out guy" whines. Another developer or two actually get to work and look at the code, start talking to Apple engineers, etc. An Apple engineer says "let me take a look at that" and a little bit later, comes back as promised with an answer and help.)
After starting out optimistic he's now bitter.
Optimistic is a funny word. He seemed under the impression that Apple was obligated to provide changelogs, access to internal revision control systems, etc. He also got upset when he realized that Apple had forked code. It sounds like he had unreasonable expectations, and when Apple said "I'm sorry, we can't do that" or "I'm sorry, we're not allowed to do that", he threw a hissy fit.
The Konqueror developer in question also used a logical fallacy called "Stacking the deck", a kind of fallacy-by-omission. He did not discuss any of Apple's assistance provided to developers on the mailing list, and repeatedly asserted that Apple was meeting "minimum" requirements of the LGPL, when in fact Apple was doing more.
That is why he got burned. Not because of actions on Apple's part- and your insinuation that Apple is to blame for the actions of its "Apple fanboys" is absurd. You're distracting from the core issue- that the developer used fallacies to promote his version of the facts. Sadly, few people bothered to actually read the mailing list exchanges.
Apple got the code to a rendering engine for free and gave back little to nothing
Again, you're distorting facts. Apple gave back all the code it was obligated to, and participated in an active dialog. If half of Apple's patches were integrated within less than a few months, that's a lot more than "little to nothing". Question- how long would it have taken the KHTML developers to become Acid2 compliant without the contributions by Apple? And if the patches were so worthless, why did they "waste" time and effort if writing their own stuff from scratch would have been more productive, as was implied if not outright stated by khtml developers?
Please help metamoderate.
Yes, there's the bit that says you have to release "in the preferred form for making modifications", and it is implied in the preamble that is what you use yourself to modify it. I very much doubt the huge monolithic patchsets are what apple devs use internally, far more likely they use their VCS tree complete with comments. So that's what they should release.
I am trolling
So if the KDE people say that they want every file and directory in WebCore to start with the letter 'K', does Apple have to comply with that?
What if the KDE developers say that the preferred form is on a 160GB SCSI drive installed in a dual G5 with a 30" Cinema display attached to it, does Apple have to comply with THAT?
I think that people may be taking those words from the GPL a little too far. To me, what they mean is that if I get a binary, I need to get the source required to recreate that binary.
Apple does the bare minimum the LGPL requires with Webcore but the khtml devs accepted that.
No, let's be clear. Apple does ALL AND EVERYTHING that the LGPL requires. Implicit in your statement is the suggestion that free software can be free if it includes tacit, implied promises not to fork and to satisfy its authors with all its changes. That suggestion is flagrantly inconsistent with the notion of free software, in any sense.
Fundamental to the notion of free software is that its authors cannot limit the rights of others to access and modify the software. Forking is not a problem with free software, it is a feature.
Ordinarily forking *is* a problem for the community, when the initial developers are adequately satsifying the needs of the community as a whole and working well with others. But this is not always the case. Sometimes politics, legitimate and petty, and aesthetics, legitimate and ludicrous, gets in the way of good agile development. When that happens, the community may well be better served by a fork.
Apple and the Konqueror clan were not working well together, but both had important and significant constituencies to serve. It was either going to work or not, but neither Apple nor the clan "owned" this free software. In its feral state, BOTH were free to decide by what methodology development of their respective trees will proceed, what features the code will have and what will be the quality of that code.
Darwin (no pun intended) takes care of the rest.
Evolution by forking is not the preferable state of nature, but it happens when it needs to happen. And people will abandon what is useless and use what is important.
If, someday, there is actually a need to harmonize this code, it will be harmonized. Otherwise, it may well be for the best there was a fork. The problem that it is difficult to harmonize advances in one tree into another is salient, but it is not due to any malfeasance of anybody. Apple WAS FREE to do what it would with the code. And glory be for that... So, too, is the Konqueror clan, and glory be for that.
The remaining whines in the message are puerile. Don't like the doco or the coding style? Its free software, change it. Don't like the way others are working on the code? No problem, ignore them, and use the free software of the existing code. Got a feature you need? Great. Code it up. Don't want to? No problem, but why are you posting your gripes HERE?
Apple has a free software realationship with the K-clan. K-clan could work with them or not, and vice-versa. If it doesn't work out, so be it. The code is out there. It was built the way it was built, and people may use it or not. Nobody has a gripe, because it is free software -- if you don't like it -- change it.
I've programmed professionally for a living for about 10 years. Never met anyone who edit patchs or changesets as their primary method editing code. I've seen people fix up patches and then apply them (even that is very rare). I've seen them review the history of the code via the VCS. However, not a single person I've ever met, generates a patch from scratch and then applies it to the source. They edit the source and generate patches. The patches are there merely as a convienent way to express the changes.
Comments you might have a point (lacking the comments, I could see a legitimate argument that it's a simplified form of variable and function obfusication), but patchsets are completely irrelavent, they are a by-product of the editting, they aren't necessary to build the source. They aren't what anyone edits to create source. I never have to edit an old patchset to fix a problem. I just go edit the source code.
Patchsets are useful for pulling in other peoples changes, they aren't useful for making changes to the software yourself. Nobody will interpret what you want that to mean in a legal sense.
Kirby