Slashdot Mirror
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.
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.
- 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.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.
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!
they suddenly turned into closed source.
So why is this a bad thing?
In fact, that is one of the points of OSS, isn't it?
There is always the possibility that somebody will fork, and the fork is still OSS as far as I know, so there is nothing wrong with interchanging code.
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.
Obliteracy: Words with explosions
Its probably best to think of Apple's WebCore as a fork of KHTML; they are no longer one and the same. Apple has already changed WebCore enough that backporting changes to KHTML is very non-trivial. As usual, they are starved for developers, especially when the task is simply porting someone else's code, rather than solving problems for yourself. Many devs would much rather do the latter, even if "results" come more slowly.
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".
What I'm listening to now on Pandora...
Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?
This is not a danger, it's simply a attribute of OSS. Do you really think Linus sat down to write the kernel and ever considered it'd be used on millions of computers worldwide for mission critical systems? When you release your code Open Source, your basically saying to the world "do with it as you please". Some license clauses may prevent certain uses (i.e. many OSS SMTP Servers have a clause that says if you use this software for Spam, you're in violation of the license). But as a OSS Developer I can't say that only Americans can use my code, or prevent those of other religions from using it to benefit their religion. And I certainly can't prevent some company from "leeching" by profiting from my work without giving back equally to the OSS community. That's life and that's OSS. Most companies however realize that as a whole, you get back what you put into something.
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
If you didn't realize that's possible, you're just being stupid. If they're going in a direction you don't intend, then by all means continue in the direction you DO intend and don't worry about it. Would it be nice if Apple maintained a set of OSX specific patches and did as much as possible in the upstream project? Yes. Do they have to? No. Will it bite them in the future? Perhaps. The farther they diverge, the harder it will be to bring changes the other direction as well.
Duh. Of course. Do I really need to provide a list? Can't anybody here on /. think for half a second and come up with one or two OSS projects sponsored by corporations where the code and goals are "harmonized" as the questioner puts it?
Yeah, I'd like to hear about one or two projects like that. I'm not aware of any.
I don't respond to AC's.
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"
Personal Website
Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?
Oh come on, is this really a "danger"? Nothing in any open source license says that you keep the right to direction of whatever your code ends up as.
This is like the "danger" that your source code can be "hijacked" in commercial applications if you use the BSD license.
KHTML is not objectively any worse off because of this... Apple isn't hurting them, Apple isn't taking anything away from them, their project is not imperiled in any way. It may make them feel bad that their source is out there with improvements and it's not as easy for them to merge them back into KHTML as they would like. It's quite a mental exercise to try to think of a rational justification for that feeling without becoming extremely vague (try it), one which no open source license could ever protect them.
To borrow a phrase from ABC News' mustachioed libertarian: Gimme a break.
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.
Could Jesus microwave a burrito so hot that he himself cou
The story is blowing up something that should not be. Apple has been contributing code back to the KHTML team. The team has difficulty integrating it due to the large differences and lack of man power. Apple is simply suggesting that the KHTML team work with Safari to have one code base, which is a good idea. while I am not wild about the KHTML losing control of things, Apple has a full time group working on the base. So why not do the firefox/mozilla thing and move to where the action is. Besides, if KHTML moves to working closer with apple, it will produce a third major code base, behind MSIE and Mozilla. Basically, 2 out of the 3 will be in the *nix world. In addition, the 2 will follow the standards closer, which will lead to more developers following standards.
I prefer the "u" in honour as it seems to be missing these days.
"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.
T Money
World Domination with a plastic spoon since 1984
There are no trails. There are no trees out here.
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.
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.
#DeleteChrome
...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.
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.
Software sucks. Open Source sucks less.
Maybe not, but why wouldn't Apple do this? Of course they want Konquerer to use the same rendering engine as Safari. First of all, it increases the user-base, which increases the chance that web developers will test for their rendering engine. Second, every improvement that the KDE team makes to the engine amounts to Apple getting a developer to work for free.
My general understanding (guess?) is that the divergence is a result of Apple and the KDE team having different methods and using different tools and such. The idea that Apple would specifically avoid being able to work with the KDE team seems unlikely. It doesn't really gain them anything.
It's not Apple's fault the KDE development community doesn't have a lot of use for the code that makes WebCore.
This is the nature of OSS. Software continues to evolve and fork.
KHTML developers who can see the big picture beyond their own egos should be ecstatic that somebody has applied their effective, standards-compliant codebase to a commercially viable, successful product that will help bring tighter standards adherence to html / web authors.
It would certainly be a lot more sportsmanlike than "boo-hoo I can only use 10% of Apple's code".
Suck it up. You develop open source so that people can modify it for their own needs, provided they share their code with you.
I suppose the typical GPL liscence states that you need to share your changes or otherwise make them available.
But in practice, I dont think there is much stopping any given company from using an open code base to use a more or less closed product. The BSD liscence specifically permits this.
Being the sort that does not care much one way or the other about this topic, is Apple doing anything that the liscence in question prohibits?
If not, then its permitted, and if its permitted, no use complaining. If your going to have a code base that open, then you should not be shocked when someone uses that liscence to their own advantage.
END COMMUNICATION
Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?
No, because that isn't a danger and doesn't hurt you in any way. If you're worried that your feelings might get hurt over something like this, though, perhaps open source isn't for you.
Secession is the right of all sentient beings.
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?
Sure information wants to be free, but how much are you willing to pay for the packaging?
I wonder if this would be as big an issue if Apple had started out by saying, "we want to fork the code." The license gives them that right. This is essentially what's happened. Neither team is actively using the others patches.
My experience is that merging code on large projects is a pain. Even when you share the same respository (CVS) and have teams working on different branches. I hate the thought of trying to merge code that's several months apart developmentaly. Besides just dealing with the code, check-in comments, when they exist, are usually vague, brief, and overly broad (25 files modified, the comment only actually refers to two of them).
It sucks, but, they might be better off just accepting it as the fork that it is. Both of these teams have differing objectives. Trying to keep the code in sync while trying to (in all intents and purposes) create different end products may be more pain than its worth (to all parties).
The developers of KHTML should be proud. They created an excellent product. A large company felt their product was of high enough quality to warrant distribution in a mainstream operating system.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
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...
Work is punishment for failing to procrastinate effectively.
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.)
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?
is competition good, or is duplication of effort bad?
or forking. Forking implies someone with different goals/ideals starting a new project in keeping with those goals/ideals. As near as anyone can tell the Safari projects goals are perfectly in line with khtml's, it's just the corporation making things a little rough around the edges. What's bothering everyone here is that if it was just between projects then there's no technical, legal or political reason everyone couldn't just play nice together. Having a large corp involved is complicating things. This isn't necessarilly the end of the world. There's people at Apple no doubt trying to work this out.
At any rate, if people don't complain a bit, how's Apple going to know we want them to shape up the code a bit.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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.
eom
they're complying perfectly with the license the code was released under. why the hell would you expect more?
"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!
...to Apple. The day Jobs stepped back into Apple Computer Inc, was the day Apple became a mercyless plundering machine of anything it wants.
Apple don't give a shit about KHTML, in fact I can guarantee they are laughing. If i were KHTML devs I would try and change the licence and lock Apple out.
Apple have used you, exploited you and now want to chuck you in the garbage and forget about you. They have got want they wanted from and that's it. KHTML have been done up like a kipper.
Just like Konfabulator.