Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
Open-source divorce for Apple's Safari? (ZDNet)
ZDNet covers the disconnect between Apple and the KHTML developers.
"The suggestion, which KHTML developers said they were unlikely to accept, comes as Apple tries to quell rising dissatisfaction among the original architects of KHTML. Two years after hailing Apple as a white knight, those developers are calling the relationship between their group and the computer maker a 'bitter failure.'
In a conflict some call emblematic of what can go wrong when corporations embrace open-source projects, developers are airing longstanding gripes against Apple, accusing the computer maker of taking more than it gives back to the open-source group."
(Log in to post comments)
Open-source divorce for Apple's Safari? (ZDNet) Posted May 12, 2005 14:54 UTC (Thu) by marduk (subscriber, #3831) [Link] AFAIC this was something waiting to happen. Apple Computer has never really been a part of the open source community, but always keeps a foot in the door to save face. MkLinux, Darwin, and KHTML are all examples, IMHO, of "we want your technology but we don't want you."
OSS developers should make a point not to deal with Apple. The FSF boycott should still stand.
Open-source divorce for Apple's Safari? (ZDNet) Posted May 12, 2005 15:04 UTC (Thu) by gowen (guest, #23914) [Link] The FSF boycott should still stand.How does one prevent people using GPL'd code, as long as they release the source for their derivative works? Indeed, isn't that point of the GPL that you cannot prevent people reusing for whatever projects they like.
Open-source divorce for Apple's Safari? (ZDNet) Posted May 12, 2005 15:36 UTC (Thu) by bfields (subscriber, #19510) [Link] How does one prevent people using GPL'd code, as long as they release the source for their derivative works? Indeed, isn't that point of the GPL that you cannot prevent people reusing for whatever projects they like. The GPL is a tool, not some sort of comprehensive moral code. It is possible for some behaviour to be worth denouncing even when that behaviour is not explicitly forbidden by the GPL. --Bruce Fields
Open-source divorce for Apple's Safari? (ZDNet) Posted May 12, 2005 15:51 UTC (Thu) by nix (subscriber, #2304) [Link] The FSF boycott should still stand.This would be very bad for GCC, at least.
Open-source divorce for Apple's Safari? (ZDNet) Posted May 13, 2005 2:36 UTC (Fri) by njhurst (guest, #6022) [Link] Out of interest, what has apple contributed back? Is there a web page or something listing gcc contributions?
Open-source divorce for Apple's Safari? (ZDNet) Posted May 13, 2005 2:57 UTC (Fri) by marduk (subscriber, #3831) [Link] From what I can see just by grepping the source, they made some contributions to the Objective C/Java backends, the Altivec platform (surprise) and the testsuite.
Open-source divorce for Apple's Safari? (ZDNet) Posted May 13, 2005 7:13 UTC (Fri) by komarek (guest, #7295) [Link] ...and heavens knows what we would do without Apple's objc improvements. Why, just the other day, I said I would switch to MS Visual Objective C if it wasn't for Apple's improvements. And given the widespread adoption of objective C interfaces for popular libraries...
Not that the parent poster said otherwise, but I'll make it clear that I don't think gcc would suffer much had Apple not contributed objc improvements. Probably even altivec improvements don't matter much overall, but at least they're more broadly useful.
Open-source divorce for Apple's Safari? (ZDNet) Posted May 13, 2005 14:30 UTC (Fri) by nix (subscriber, #2304) [Link] Apple employees are *very* visible on the GCC lists, and have been for years. Going by current email addresses in random order the list includes at least Mike Stump, Matt Austern, Dale Johannesen, Mike Stump, Geoff Keating, Jason Molenda, Andrew Pinski, Devang Patel, Stan Shebs (the original One Apple GCC Hacker), Caroline Tice... the list goes on and on, covering C++ standards deities, members of the Steering Committee and experts on just about every part of the compiler (my apologies to the dozens of people I've left off). Many of these have worked elsewhere (e.g. Cygnus/RH) in the past, but they're at Apple now. The influence of these people on the compiler is too large to easily state.
I'd call Apple a fully-paid-up member of the GCC community, active in *far* more areas than Objective C. I'd not say that GCC would collapse without Apple, but a lot of that is because what matters are the *people*, and they'd find somewhere else that let them hack on GCC if Apple stopped giving them time to do that. Apple is certainly contributing a lot of their time to it (and getting a better compiler in return).
I think this proves that the DHTML fiasco is not due to some evil influence intrinsic to Apple. :)
Open-source divorce for Apple's Safari? (ZDNet) Posted May 12, 2005 20:40 UTC (Thu) by sepreece (subscriber, #19270) [Link] The ZDNet article didn't make me feel that Apple had done anything wrong, just that they had done something different. The KHTML developers want to retain control over their code and Apple wants changes that the developers wouldn't accept, so apparently they need to go separate ways.
Saying "they took more than they gave back" seems misleading, since Apple is apparently willing to give back everything they've done. It's just that the khtml folks don't want it.
The whole point of the OSS movement is that different entities have different needs and open source gives them the opportunity to meet their own needs, by doing their own work, if the mainstream developers of a project don't meet those needs. If partnerships end up needing to go different ways, there's no reason to assume that one partner is a good guy and the other isn't.
So, if Apple set WebCore up as a separate project, I wonder whether it or KHTML would get more time and effort invested in it. Which would be the better base for further work? I'm not suggesting I know the answer - I just don't see any reason to assume one or the other.
Where Apple is not playing nice Posted May 13, 2005 0:10 UTC (Fri) by jmayer (subscriber, #595) [Link] Just rephrasing the core point from ZRs blog:Apple is giving back their changes but only fulfilling the letter and not the spirit of the license: - Apple provides one huge patch that does big changes to the source, some of them clearly not wanted by the khtml developers. - They did not provide a changelog that was usable: Had Apple provided the patches in the form normally used by open source projects - one change at a time with a proper log message, things would have looked differently. But as things are, finding out which changes form a "unit" and then to decide which "units" to apply would be more work than reimplementing all the interesting features that Apple added. And one last remark from me: Just applying the patch wouldn't do much good. Even if it worked, the khtml maintainers would no longer understand the code to the extent needed to do some of the more difficult stuff. So no, Apple isn't playing nice here - if they would provide the changes in the chunked form that were certainly applyed internally, including the changelogs for each chunk, then they would be fulfilling the license in the spirit as well.
Where Apple is not playing nice Posted May 13, 2005 20:16 UTC (Fri) by sepreece (subscriber, #19270) [Link] As I read what it said in the article, Apple did provide patches along the way, but the maintainers didn't want to take them as fast as Apple provided them (or, in some cases, at all). That's what the article seems to quote the KHTML developers as saying.
I have no direct knowledge of the details of the interaction between them.
I think the "spirit of the OSS community" has to include the freedom to fork, if that's what you decide is in your best interest.
better tools make it easier to play nice Posted May 19, 2005 19:38 UTC (Thu) by zooko (subscriber, #2589) [Link] If this is true that Apple provided the changes, but not in a way that was useful to the otherKHTML devs, then maybe things would have been different if they had been using a nice revision control tool such as darcs.
This is assuming that Apple provided the changes in large-grained format because it would have
If you haven't worked on a big branch like that then you might not understand just
If everyone involved had been using darcs, it might have been different. Maybe next
Parallels with gcc? Posted May 12, 2005 15:50 UTC (Thu) by stevenj (guest, #421) [Link] Long ago, NeXT adopted gcc as the compiler for its operating system. They complied with the GPL and released source for their changes (after some reluctance), but made no great effort to get those changes merged into the mainstream sources. Years later, when NeXTSTEP became MacOS X, Apple was faced with a hacked-up gcc that lacked many features in the latest GNU version, and they had to begin to retroactively get as many of their changes as possible into the mainline tree...at which, to their credit, they seem to have done an excellent job.On the other hand, KHTML is not in the same position as gcc. gcc has no real competitors in the free-software world, and so it continued to attract substantial free (and commercial) efforts. KHTML, on the other hand, is eclipsed in popularity by the Mozilla engine, and perhaps it will stagnate compared to the Apple fork rather than vice versa.
Parallels with gcc? Posted May 13, 2005 9:29 UTC (Fri) by ecureuil (subscriber, #3507) [Link] KHTML is actively developped by the KDE developpers and is for some pagesbetter than Safari. Now Apple has to find a way to collaborate better with KDE. The initial fork they have done was certainly a quick way to get their own browser but a common HTML renderer, shared, developped and tested jointly is a surer path to excellence.
Parallels with gcc? Posted May 19, 2005 9:28 UTC (Thu) by nix (subscriber, #2304) [Link] KHTML is actively developped by the KDE developpers and is for some pages better than Safari.Alas, for all pages that don't set a background colour I've found it to be much, much worse. It gets the background colour from your theme, but makes no effort to do the same with textual colours, even if the page doesn't set a colour for text at all. So I, for instance, end up with black text on a dark blue background. I'm sure this is fixable: I just haven't found the time to understand the KHTML codebase enough to fix it.
Open-source divorce for Apple's Safari? (ZDNet) Posted May 13, 2005 8:27 UTC (Fri) by petegn (guest, #847) [Link] One of theses daye we will find a rotten Apple full of Maggots (M$ Corp shaped ones at that).
Open-source divorce for Apple's Safari? (ZDNet) Posted May 13, 2005 13:43 UTC (Fri) by dkite (guest, #4577) [Link] Apple has lived up to it's legal obligations regarding the khtml code.That is the only thing you can say about the relationship. Apple worked on WebCore (what they call their fork of khtml) for about a year in secret before announcing and releasing the betas, and as per licenses, released the code. The code releases are in the form of a large tarball, including a changelog. khtml has benefitted from the work, and for the first year or so much of the khtml work was merging technologies that Apple developed. khtml has improved considerably. So I wouldn't say that it has been a one way street. The codebases are diverged to the point that patches cannot be applied. The acid2 (?) patches were the first time small discrete patches were provided. khtml developers have requested over and over to have some kind of access to the bug database, or the source code repository, even offering to sign nda's. Again, no. So we have two separate projects that maintain (presumably) regression tests, bug databases, repositories, developer communication, etc. To suggest there is a divorce is to assume there was a marriage at all. There wasn't. Derek
|
|
||||||||||||