Slashdot Mirror
Safari And KHTML May Never Meet
diegocgteleline.es writes "Announcing that Safari passes the Acid2 test has raised some voices in the KDE world. Apple, they say, isn't playing friendly. They don't provide a CVS history, just the modified files where nobody can understand how and when things have changed. It's quite likely that KHTML developers will have to write their own code to pass the acid2 test. Zack Rusin writes: 'All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist.'"
Looking at Safari developer Dave Hyatt's blog it looks like he's provided some patches. I'm sure it will take some work to get those into KHTML, but that seems to be a pretty good start to me.
Apple has abided by Safari's license and released their changes. This is what is required and expected. I don't remember reading anywhere that they have to hand-hold you through understanding their code.
Interested in open source engine management for your Subaru?
I give up, no more computers for me.
Love many, trust a few, do harm to none.
No, it seems like they're doing everything they're legally bound to do.
And that only, nothing more at all, which is the part that annoys the KHTML team.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
... they're duping comments.
Hey, that gives me an idea - find a nice little comment somewhere a week or so back and submit it as news... yeah...
We Build Beautiful Websites
In a shocking and unsuspected announcement, Apple will change their name to 'KApple' in an effort to patch relations with other Kommunities.
What difference would it make to Mozilla if they had used Gecko? Absolutely none. RTFS, it doesn't even make a difference to KHTML. It would be nice if Apple contributed more to KHTML, but they're not hurting them any more than you and I are.
English is easier said than done.
Have you ever worked on a large project?
Without the revision history, it can be very difficult to track what effect particular changes actually have. Intermediate code cleanups, reorganizations, additional features, etc. can combine to make the code look much different in a fairly short amount of time.
Looking at "what has been changed" makes it much easier to figure out "what does the changed code do".
Dave Hyatt seems fairly responsive to emails. He's replied to one's I've sent in the past asking questions about Safari. He's a Free Software guy, I'm sure he can appreciate the frustrations here, and might be able to help - afterall, I don't believe he, or Apple really want to 'screw over' the KHTML people - it might just be that communications haven't been really made.
Email him - ask?
Join the Free Software Foundation
This might be a good time to remind everyone that the patch has not yet been released to the public. The patch might make the browser unstable - further testing will be required. Depending on how long it takes before the patch makes it into the public version, Safari might not be the first browser to support Acid 2.
From yesterday's summary:
The patched Safari is not yet avaliable for public consumption. It is unknown when the patches will appear in a public version of Safari.
I'll probably be modded down for this...
Not quite that if I have understood the case correctly.. they took open source component as a core to their browser, modified it and now they have to contribute back to the project, since the stuff Apple used is under GPL, if you use & modify, you have to provide the changes you made when asked..
Nice idea, except they're not violating the GPL!.
a) it's the LGPL
2) they're doing everything they have to
d) the ACID2 patches have been released to KHTML developers before Apple have actually released them, themselves.
Sure, Apple could be doing more, but they're not violating anything.
Join the Free Software Foundation
When the diff is 6MB yes its damn hard.
Never learn by your mistakes, if you do you may never dare to try again
Come back when you'll actually have seen code
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Uh, just how is this a GPL violation? They're providing the modified source code. The GPL doesn't require you to explain how you wrote your code or how you got from the old code to the new.
Huh? They got Khtml and Kjs from KDE, without them there is no Safari , No Dashboard. Got it?
Never learn by your mistakes, if you do you may never dare to try again
I would agree. Nowhere does the GPL require you maintain and distribute CVS logs so everyone can see what changes have been made. Nor does it require you detail what has been changed from the original source. It's good enough to say "Here is the code after we made it do x y and z". If the original developer wants to see how they did x y and z, then he can diff the code.
I don't see how fragmenting KHTML is going to help it much... If people code for Safari, and Safari is the only KHTML based browser that acts lke Safari, the what good does it do for anyone else?
using namespace slashdot;
troll::post();
I'm not sure about that. From what I understand, open source doesn't mean you have to give other people everything verbatim, and explain the changes.
You have to make available the source you based your code on. That's all. Apple would be under no obligation to make modifications publicly available. It's just a bit silly not to contribute back, otherwise they end up working off a completely different source tree, and lose most colateral benefits of having an open-source basis.
Apple might simply plan to let the open-source crowd stay a few months behind their closed source implementation. That way the community still contributes useful bits, but doesn't ever get in Apple' face with competition for users.
So is GPL v3 going to fix this issue?
Or will any attempt to do so put too much burden on the users/modifiers of code?
badness 10000
The code for the Acid2 test fixes was all given to you in a nice list of small easily applied patches (which was posted on /. no less), and you still can't manage to integrate it without having full logs of Apple's interval versioning system? Come on.
I'm getting really sick of the anti-corporate bullshit that gets thrown around so copiously by a certain faction of the OSS community. And it's not just Apple being treated this way either.
No matter how much a big corporation gives to the community in terms of money, code, paid personnel, free advertising, etc..., there's always some crank complaining that they're not giving enough, and they'll eventually turn on us.
Well, given the way we treat them, I wouldn't blame them for turning on us.
Every change in khtml has to be run through a regression suite to make sure it doesn't break anything. Now if you fix something a new regression test is added for that.
If you get fixes with no log of what they fix you will end up with bunch of code which you have no idea how to test for regressions. This is just one of the reasons why diffing codebase doesn't cut it.
Another good reason is damned diff is ~6mb because Apple guys never send small patches but only dump WebCore tarballs.
Never learn by your mistakes, if you do you may never dare to try again
This isn't true. They are legally bound to include a notice telling their customers that they are entitled to source, and they are legally bound to supply it to a customer of theirs, should they ask for it, for the price of shipping. They don't even have to send patches back to the KHTML team.
They are doing more than the license forces them to. They are just getting criticised because some developer wants them to do more.
Also, everybody whining about suing them for GPL infringement? You are clueless. Not only are they abiding by the license, it's LGPL, not GPL. You haven't even bothered to read the license and you are advocating suing them? Typical American attitude.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
It's strange, where should we draw the line for what we expect from private companies?
That they allow fair-use and backup?
That they make file-formats public?
That they go open-source?
That they make all their software free?
That they not make any money?
hmmn...
And they'll rename Tiger to KTiger (or Kiger) to get around the lawsuit from TigerDirect.
Software sucks. Open Source sucks less.
Now that diff can't tell you why they've changed, but for Pete's sake, you're a developer. You've got the code. You've got the standard. You've got the changes in the code. You've got the old code. You can see how behaviour changes in each. You've (hopefully) got an reasonable general understanding of the codebase.
You obviously didn't read the blog entry.
The problem here is that Apple drops a huge diff on them for every release. It's not individual diffs for each change, but one massive one. We're talking about a diff several megabytes in size consisting of hundreds of changes. With all kinds of changes mixed in with eachother and mixed in with all kinds of Safari-specific stuff.
Yes it is possible to sit and pick that apart. But it's a lot of work. It may very well take more work to seperate out a change than to re-implement it from scratch.
On top of that it's unnecessary work, because there's no reason Apple wouldn't be able to hand over all individual patches seperately, which would make things immensely simpler for the KHTML guys.
Apparently the KTHML guys have tried and tried to get Apple to do this. And they haven't helped.
I can't access kdedevelopers.org, so here's the blog entry:
/. about Safari supporting the all crack Acid2 test and people raving how great it is for KHTML. The truth is that KHTML will probably never get those patches. Whats most probably going to happen is that one of us will simply reimplement it from scratch (and at the moment the reality is that if its not going to be Allan or Germain its not going to happen).
/. or some other equally stupid site will be praising Apple.
You cant even imagine how I hate that question. The truth is most probably never. I just read the article on
Code in Safari is hugely inconsistent and changes are always interdependent. Theres basically no way of merging in one change without bringing a whole bunch of others in. And you know what? Dont even tell me about merging stuff like render_canvasimage.h,cpp. It outright uses OS X apis. Well never be able to merge that in - someone will have to implement it. And whats going to happen when someone does? Some jackass on
In the past when someone spent long hours implementing something in KHTML, they at least got a thank you from people using Konqueror. Now its well finally! It was working in Safari. khtml developers are lazy. Wheres the fun in that?
Do you have any idea how hard it is to be merging between two totally different trees when one of them doesnt have any history? Thats the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDAs with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL.
And you know what? Thats their right. They made a conscious decision about not working with KDE developers. All Im asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. Theres absolutely nothing great about it. In fact it doesnt exist. Maybe for Apple - at the very least for their marketing people. Clear?
it seems like they're doing everything they're legally bound to do. And that only, nothing more at all, which is the part that annoys the KHTML team.
Not even that: it's *other people's* attitude that the KHTML devs dislike - from TFA:
This is where the serious fun begins.
1993 called, they want their flamewar back.
Woe! Disaster! JWZ's changes to the Emacs codebase can't be easily folded back into GNU/Emacs. It's full of things that are XEmacs specific!
It's called a fork, folks. It's very possible, albeit not very common, with Open Source software. You've given your code to people to use how *they* want, not how *you* want them to. Deal with it.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
You obviously work on a grand total of a couple thousand lines of code at work, if at all, and aren't working in a source control managed environment.
Since Safari is a big fork, in order to know how to reintegrate the files, you need to know WHEN as well as WHICH LINES of code changed in order to reintegrate major changes into the source management, or you'll run substantial risk of overwriting previous patches the other fork doesn't have or need, especially if there aren't a lot of people and time to figure this out. Otherwise, the time to reintegrate is much more than...just writing it yourself from scratch.
Your comment is so moronic and naive that it is officially a troll. If a key guy like this is complaining, then: THERE'S SOMETHING WRONG. He's not lazy and he's not whining, you dumb fuck, he's legitimately frustrated. I would say this is very helpful, since it straightens up all the iPod-hypnotized Apple apologists on this site. If there are a million consumers who buy Apple's marketing, fine. But this was supposedly a site for intelligent technical people.
Apple is what it is: a talented amoral corporation led by a greedy egotistical amoral CEO. They aren't "Different", they aren't "feeeel-gooood", and they don't care about OSS unless it makes them money.
Hey, I'm just your average shit and piss factory.
It's really simple. If you're going to release your code under a license that makes it easy for them to fork your codebase, you'd better be setting the pace.
If KHTML was a strong, vibrant project that was making steady advances, there would be a motivation for Apple to fold their changes back into the trunk so they can continue to reap the benefits of other peoples improvements. If Apple aren't making an effort to fold their changes back in, it indicates that they don't feel having easy access to future KHTML improvements is worth the trouble.
Improve the KHTML code enough that Apple is losing out by not being able to easily fold changes into the next version Safari and see their stance change. Complaining isn't going to get respect from Apple or from anyone else.
-1 Uncomfortable Truth
Actually the biggest problem right now is that Apple are not keeping up with code-cleanup. We constantly try to develop more elegant easier to maintain code, where as Apple wants the right features - right now.
Safari is basically still KHTML from KDE 3.1 with a ton of bug fixes and features. Many of the features takes time to port because they do not live up to our coding standards.
If folks want things like a mandatory CVS repository or changelogs in addition to contributing back your changes to the source, those sorts of requirements should simply be a part of the license itself. If what you want is not required by the license you're releasing under, moaning and groaning because Apple is complying with your license - and no more than your license - is silly.
Propose changes to the GPL, if what you want isn't in there.
It's like called courtesy?
Someone spends years writing some code which X company uses to give their OS a severe boost in the browser department. An OS with a poor browser is a poor internet desktop, you would think Apple would be grateful for the groundwork done by the KDE team.
there's no reason Apple wouldn't be able to hand over all individual patches seperately, which would make things immensely simpler for the KHTML guys.
I see you've spent some time involved in the Apple workflow. Has it occurred to you that the Safari team's development methodology might not easily lend itself to individual diffs and CVS logs?
Apple's samba patches have also never made it into the main code because they break samba on windows.
Anyone can create a patch. The hard part is working with others.
Again, it's the "Power of open source. The Stupidity of Apple."
Let me guess... you're not a developer, right? From what I understand, Apple doesn't send back patches for specific issues, they just periodically make a tarball of their webcore tree and lob it at the KHTML devs. A 'diff -u' would probably give you a 5-10MB patch file. Is it useful? Sure. But it's a royal pain in the ass to sort through it and figure out what does what.
And why is this important, you ask? KHTML, like any rendering engine for a complex document format, is a complex piece of software. If you're going to change it, you need to be absolutely sure that the changes aren't going to have an impact on another part of the rendering pipeline. You can't do that when you have 5+MB worth of multiple possibly-unrelated changes to sort through.
Xfce: Lighter than some, heavier than others. Just right.
Unlike Apple's own GCC team you mean who works side by side with other gcc hackers and even some of them takes care of gcc bugzilla.
Never learn by your mistakes, if you do you may never dare to try again
Apple, they say, isn't playing friendly. They don't provide a CVS history, just the modified files where nobody can understand how and when things have changed.
First of all, anytime you fork off a large project like KHTML the source code bases will start to grow apart. When the new fork has a dedicated group of engineers updating it for their needs then it will quickly diverge to the point where it makes little sense to attempt to keep patches in lock step. In my career I can recall several times where this has happened, and it always seems to come as a surprise to the people maintaining the less active fork.
Apple doesn't use CVS as their normal source control system. To provide CVS documentation, Apple engineers would have to maintain a CVS database as well as maintain their patches in their standard internal SCS. This used to be perforce, I believe, and probably still is as switch a SCS is generally a royal PITA.
Because the sources have been diverging for several years, it's unrealistic to expect that the Safari patches will be directly applicable to KHTML, and I frankly doubt that even having the Safari patch documentation would help very much after several years of Apple patches. This probably isn't anything underhanded on Apple's part. It's just the way engineers work - they change the code to fit their needs, and rarely consider the impact on the old fork that they started from in the absence of an explicit mandate to stay compatible with the old fork. That level of compatibility would require the Apple folks to always have the current KHTML sources and be familiar with that source and particularly to understand the differences between the KHTML code and the Safari code.
Apple does provide the modified files, and usually this is a huge improvement on starting from scratch in implementing a new feature or fixing bugs. It does require the KHTML engineers to be able to read and understand the Safari code. To say that nobody can do that sounds a little strange.
It's quite likely that KHTML developers will have to write their own code to pass the acid2 test.
Well, yes. Should Apple engineers be expected to maintain the KHTML engine also? Apple's engineers are probably focused on their code base exclusively. The KHTML engineers are the right people to modify their own code base. Does anyone expect Apple engineers to be responsible for maintaining compatibility between Safari and KHTML? Apple makes changes, and they provide the changes files to the KHTML team. The rest is up to the KHTML folks if they want to extract the Apple code they want to use and put it into their code.
The source is intended to be understandable. Not only that, it has to be "the preferred form of the work for making modifications to it". If you release something that is not, you're not fulfilling the terms of the GPL license.
See this previous comment on how the patches released don't allow to understand or modify the changes made by Apple.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
It isn't because the KHTML developers want them to do more. That isn't the complaint. The complaint is that all the Slashbots read the Acid2 article and assume that those changes will quickly make it into Konq thanks to Apple's good will. That isn't the case. It is the misperception that is being complained about.
Lasers Controlled Games!
Unfortunately, we have to inform you that you are simply not welcome here in the free software community. Obviously, you are just being a parasite by commercially supporting the use, maintenance and extension the KHTML library. Not only are you making bug fixes and amplifying the usefulness of the code, but you're also sending them back to upstream for them to integrate. This burden you are placing on us is clearly unacceptable.
Happily, we don't care for or need your help - as you know the use of free software amongst large and recognizable corporations is incredibly commonplace, and all those companies have no problem at all helping out the community and contributing back in the way we desire.
Although you're new and unexperienced in the free software community, you'll understand if we have no patience for your assistance. Still, I'm sure you found working with us to be a great experience, and we hope that you consider us in the future when you're developing other projects. Clearly, nobody else will see this situation as any sort of reason not to bother dealing with free software in the future.
Thanks again!
http://www.talknerdy.org
I was a borderline "fanboy" when I switched to the Mac a couple of years ago, but once I got past the "ooooh, shiny!" stage, I realized that Apple was no beter than Microsoft or Dell or Intel. Okay, maybe a _little_ better, but still. So, yes, at least one of us changed our minds.
I guess I'm more accepting of Apple's "evil" behavior because their stuff works better than Wintel. The hardware's (mostly) great, the OS is vastly superior, the apps I use work and look better, etc.
Nothing is inexplicable; only unexplained -Tom Baker, Doctor Who
The parent may seem like a Troll, but I've worked on Darin Adler's code before, and it's "messy."
That said, the problem for KHTML is that they're working with Rolling Thunder. I mean come on, these dudes are cranking the stuff out. They're not going to take the time to go through Radar and pull their changelists.
If you can't keep up, stay home.
Doing stuff like this isn't going to win you any friends either.
Pretty code is much easier to extend and maintain than hacked together 'the browser fucking works' code.
Thank you for posting that. :) It's amazing how many people here have no clue about coding.
The APSL does not play well with OSS. If I hack on APSL code, and then end up suing Apple for, say, anything, even if it's unrelated to the software, I lose my rights to use that software. An old link that still rings true.
Even if the diff-logging process was made automatic someone has to script that and then make sure it doesn't break. Even if their VCS has easy-to-use changelist descriptions like Perforce someone still has to go extract them all for you.
And obviously you have little experience of version control systems. I have yet to see one (including perforce) which can't export diffs and changelogs to some simple format. Why would they need to write a script for that?
And you're completely missing the point: If Apple did cooperate more with KHTML, then that would be beneficial for Apple, too. It's not just a question of giving.
What's happening now is a release is getting diffed against the previous one and the results shared - very simple and easy.
Simple for Apple, and not very useful for the KHTML guys.
I'm amazed at the whining that's going on here. How about Apple gives you NOTHING, and you get something real to complain about, eh?
That's just trolling.
The post right above your's addresses this exact issue. Diff is a pretty simply utillity and this would be a great idea if they were sending small patches. But Apple of dropping HUGE files and only periodically. Not only that but (if you read the article) their changes make calls to the OS X api's. Let see you diff that! :)
Its not the end of the world, but obviously Zack Rusin got tired of being called lazy or some other intollerable (read: typical) OSS user crap while Apple is snowballing their changes (but playing it like their all one big KDE/Apple family...because that makes us feel more warm and chewy about Apple).
Zack does mention that they are staying true to the letter of the LGPL license, so its not an 'at arms' issue. Just an issue he felt needed some clearing up.
David Saxton put a copy of his blog entry up if you'd like to read it: here.
All and all a good story. I'd been thinking that Apple was playing all kittenish too. Lol. But its business.
Quack, quack.
And read TFA.
Mada mada dane.
Only if you have OSX installed...
(see article, those patches actually require MacOs functions)
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
Bitch all you want, but Dave Hyatt's changes to WebCore stand a good chance of finding their way back into KHTML
Do you even RTFA? Hell, do you even read the headline? It's written by one of the KHTML Developers.
If you had RTFA, you would have noted that he's not complaning about Apple. He's complaining about you and your uninformed comments. He's asking you, in a more polite way than I will, to shut the fuck up. Because most of Apple's code is completely unusable to KHTML.
Using version control doesn't necessarily mean "check in each feature/bug fix as one change".
I didn't really say that must mean that either. But regardless of what version control system they are using, they do have a version history saying what changed and why. And whatever version control system their using, it's likely trivial to export that.
stop whining
Who's whining? I've just stated what I believe the KHTML guys were saying. I don't deny that Apple is within their rights not sharing any form of version history.
All I'm saying is that they'd be a better "open source citizen" if they did, and that it's not something which is very costly or hard to do.
What's so wrong about that?
Please, just read the article. He's not complaining about Apple. He's complaining about people who think there is some big cooperation between Apple and KDE when there really isn't.
They are just getting criticised because some developer wants them to do more.
Read this, as I don't feel like typing it again.
You are clueless... You haven't even bothered to read the article...? Typical Slashdot attitude.
Dont you think Apple has already done enough for KHTML?
What have they done for KHTML exactly?
At this rate, Safari will end up with a completely different engine from KHTML. How will n million installations of a distantly related browser help KHTML?
Malike Bamiyi wanted my assistance.
1. Use FREE source code from BSD & Darwin.
2. Get lots of FREE BSD & GPL Unix utilities.
3. Use FREE browser source code from KHTML.
4. Beg & plead with MS to continue making Office for Mac.
5. Write the GUI in house and a few other cool apps.
6. Bundle it up and sell it for lots and lots of money and take credit for it all.
users DO NOT CARE if your code is 'elegant' and 'easier to mantain', users WANT THINGS TO WORK whether or not they are 'elegant' or 'adequate'.
I stopped using Konqueror ages ago because it just had way too many incompatibilities with sites I visited, I know the sites were non-standard, likely poorly written or written with IE in mind, but if I need them to do my work, I'll find a web browser that renders them properly.
It's really easy for an OSS project to get caught up in 'elegance' and just keep rewriting and rewriting and rewriting things to make it 'clean' or 'modular' code-wise, while the users get fed up with the glacial features development pace and move on to OS/X or Win32 because they actually need to USE the product rather than look at the pretty code.
-- the cake is a lie
Safari And KHTML would meet if only they would use an internet dating service. They just have to tell what they are compatible with, and how they can meet in real life.
He who knows best knows how little he knows. - Thomas Jefferson
What does Apple stand to gain from having a better HTML renderer than Linux (or even Windows for that matter)?
Either HTML is portable or it's not, and Apple does not have the market power to succeed with a non-portable version.
The larger the pool of standards-compliant web browsers (whether on Macs, Linux or Windows boxes), the better chance Apple has to complete on a level playing field. As it is, Apple's still in a position to be screwed by websitest supporting non-standard ie-only extension.
So when it comes to KHTML, I ask, why *not* give back.
Posted from my Android phone. Oh, I can change this? There, that's better...
I have a few questions? How does asking a bunch of "X11 related questions" make you feel better? And do you usually deal with issues your having by behaving like an immature 7 year old? Were you one of those kids who had the ball, but only wanted to play by his rules? "NO!!! WE DO IT THIS WAY!!!...YOU GUYS SUCK! I'M GOING HOME! GIVE ME MY BALL BACK!" Honestly, I have no issues with Safari. It works fine. FireFox, which I also have downloaded, works fine. I use Mail.app, and it too, works fine. Maybe it's because I'm not using some "super 1337 g33k feature" that you are, but for me and my typical, everyday usage, it's a decent app. As far as productivity - yes, it is the apps that make the difference. But the apps that come bundled with Mac OS X is what makes OS X so special. I have met people who had a digital camera, a digital camcorder, but was using a Windows machine. It wasn't until they got their fast Mac that everything started to come together. iMovie, iPhoto, and iDVD puts a lot of power into the hands of the average user. Lack of Airport Extreme support in Linux is a bummer. But it's hardly an Apple issue. Well, if you consider it Apple's fault because they chose that particular card, then yes. But, BroadCom is the manufacturer of the card, and they have decided not to open their wireless cards. Honestly, if you can't stand the iBook as much as it sounds like, you should sell it on eBay. You'll find that Macs have a great re-sell value. Just becareful of all the scammers...then again, an "i-i-i-iBook" story would be nice. :)
>>Where in the GPL does it say you have to provide a CVS history?
>Here: The source code for a work means the preferred form of the work for making modifications to it.
Um, I hate to break it to you, but the "preferred form" wording in the (L)GPL is an anti-obfuscation clause. It means that I have to give you the code in the form that I actually use for development -- no stripping out all the whitespace and comments, changing function names and variables to random strings, etc.
It does not mean that I have to give you the code in whatever form you want.
Besides, CVS server logs are not source code anyways. Or maybe you'd like copies of their email and IM conversations, too?
Jay (=
They're providing the modified source code. What they're not doing is adhering to the project management standards (version control, changelogs, whatever) that KHTML uses. The GPL doesn't require this. As I see it, Apple is modifying and using KHTML and releasing the modified source back to the KHTML team, thus fulfilling the GPL. There's no requirement that it be easy to build or that they document their changes well or that they not fork the project.
In fact, forking is not a bad way to describe what they're doing. They've made a legitimate fork. They're releasing patches, they're playing by the rules.
The OP is right. They're not 'cooperating'. Guess what--they don't have to. The GPL, however much RMS would like it to, doesn't mandate having a social conscience.
My preferred form for making modifications would be CDs made out of gold. Actually, I'd like to have one CD for each source file.
Free Manning, jail Obama.
At some point it seems like they have to do a re-synch to get more in line with what you are doing, or they're not going to be able to patch in changes you make either - is that in the works at some point?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Few reasons.
- Mozilla doesn't integrate into KDE. If I choose settings X,Y,Z in KDE, I will then have to configure them again in Mozilla. Some settings may not even be available.
- Mozilla doesn't integrate into KDE. If I want to use an HTML rendering engine inside of a KDE app, I'd have to devise a hacked up way to connect it to Mozilla.
- Mozilla doesn't integrate into KDE. I'd have to load yet another 70 MB on my system. Not only is it wasteful, but it also takes more time to start up. And if I'm lucky, I may even get to deal with dependency issues.
- Mozilla doesn't integrate into KDE. Have you ever tried to use it as a file manager? If not, consider yourself lucky.
- Mozilla doesn't integrate into KDE. The Konq sidebar allows the application to be much more flexible than mozilla... such as the ability to browse my media (amaroK module), folder heirarchy, etc. not just my history.
- Mozilla doesn't integrate into KDE. All of the widgets rendered flow nicely with the rest of KDE, and perform the same way. For instance, all of my text boxes are spell-checked by default.
And then there are a few other things that don't matter quite as much (Like integrationNot that you have to like it. I, however, do.
" He's complaining about people who think there is some big cooperation between Apple and KDE when there really isn't."
Complaining about idiots never works.
Or even read just the Slashdot summary. You will find this quote:
'All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist.'
This KDE developer is frustrated because people misunderstand the contribution (or absence thereof) Apple is making to KHTML; he's not flaming Apple or suggesting Apple's duty is to be more helpful to the KHTML people.
You've got it backwards.
We should pick on any company (or person) who merits it.
We shouldn't give Apple a free ride because they aren't MS and have the most popular brand in the world (according to some article I saw here on
MS, Apple, Red Hat, IBM, etc. they should all be judged on their merits.
Not to mention Linux, Gates, Elison, etc.
The gripe of the khtml guys is pretty simple: Apple is providing the required minimum, which makes it hard for the khtml team to integrate any changes. If Apple would cooperate just a little bit more, both parties would gain in the end.
On top of this, a lot of end users seem to think that Apple is to be credited for a lot of development in khtml while in reality there's a lot of work done by the khtml team. A lot of OSS developers are doing what they do (partly) because of the recognition. Currently they're not getting that much...
Okay... I'll do the stupid things first, then you shy people follow.
[Zappa]
Why is everybody missing this KHTML developer's point? It's right there in the short Slashdot summary. He acknowledges that Apple is fulfilling their legal obligations by providing the modified files. But they're not providing any help at all in making their changes useful to the KHTML team. So, there's no "collaboration" at all from Apple's side. That's all. He's not even flaming Apple. If anyone, he's flaming people who misunderstand this situation.
Sorry, gotta call BS on that.
For one thing, KHTML is saving them money, since it gave Apple a great basis for a browser by which they could (at least partially) unhitch themselves from their direct competitor, who otherwise had them by the nuts on browsing.
Secondly, many computer science projects rely on academia for fundamental algorithms etc., and that generally works just fine.
In IT, just as in science, cooperation works, and competition harms not only the wider IT culture, but the individuals who try to go proprietary. And no, MS didn't get where they by going proprietary, they did that by monopolistic practices which have been ruled illegal in courts of law.
Well, confusion on this point is probably the result of Apple using open source as a marketing gimmick:
While it is doubtlessly good for Apple customers that Apple uses standard and high-quality open source components, they seem to have forgotten about the "contributing useful stuff back to the community" part that goes along with it. Oh, they put out a lot of code, but it's usually not useful: their gcc hacks haven't been useful, their KHTML hacks haven't been, Darwin isn't used much or very useful, etc.
So, we people understand that Apple is a business and doesn't want to help other companies. Now, if only they could be more honest about it in their marketing materials.
Even if you're checking in stuff weekly, you're still checking it into a local source control system. I promise you that... anyone's who dealt with "weekly" checkins, and lost 4 days of code on an early Friday morning is motivated to do this stuff.
Either that, or the developers at Apple are dumbasses who love living on the edge. And I don't think they are.
They just don't want to play nice. That's their right.
"Apple is in it for the money"
And how do you think the KHTML base that Apple got for free was worth? How much would it have cost Apple to replicate it (assuming they COULD produce a browser of equal quality on their own)?
Cooperating with the KHTML team results in a more closely matched codebase. This means the work done by the KHTML team has a greater chance of being relevant in Safari and Apple benefits immensely from that. In the end that saves more work than it creates and therefore results in a better bottom line. Whether Apple is another mindless profit machine or the "good guy"s they would have their users believe, this is in their best interest.
"KHTML developers ARE whining,"
Yup, at users who are bitching at them for not having features/functionality that is in Safari. NOT at Apple. The REASON they do not have those features and functionality is that Apple is not playing ball. They are simply directing annoyed users to correct party to complain at.
How is this "a non-started argument if I just think a little creatively about it?"
Problem: I want to test my code against Safari 1.0, 1.1, 1.2, 1.3, and 2.0.
Solution: I need 5 different machines (virtual or otherwise) to run five different browsers?
That's a shitty dilemma, isn't it? Somebody's underlying architectural problem becomes my QA problem.
Why does half the browser have to live in the OS libraries?
Why can't these same libraries be bundled up in developer releases so I can at least have five executables on one OS?
Safari is the new AOL of browsers. Feh.
It is really cool to see apple fanatics go up against linux fanatics. Maybe I should throw a 'this is all M$' fault' into the discussion...
No, I don't trust in god. He'll have to pay up front, like everybody else.
Since its so easy to merge patches from safari into khtml, why don't you stfu and do it? Clearly you are so much smarter than the konq developers since you find this such a trivial task, so go ahead and do it. Prove how smart you are. Its open source, you are welcome to help. Or are you really only capable of critisizing others anonymously when you don't even understand what you are talking about?
One mans "Doing the bare minimum to comply" is another mans "Doing everything requierd of them". .Your problem is not with Apple ,it is with the LGPL license.
If you have a problem with how apple is handling the code releases
Personaly i belive perhaps they could make it a little easier on the KHTML Devs , though they are under no obligation to do this
The only things certain in war are Propaganda and Death. You can never be sure which is which though
as a developer that has worked with open source projects and developers (from the contributing and organizing sides both), this kind of 'requirement' would be absolutely impossible to enforce.
as an open source developer, you either take what you can get (ie spend the time integrating the changes into the primary build) or you don't.
having patches that are 'compatible with the rcs system used by the original developers' is absolutely ridiculous. this is what diff is for.
trying to enforce things like specific commenting types and 'descriptions of the code' is just ludicrous - you should be happy people provide you with code, period - if it's too difficult to integrate, perhaps the original developers need a better revision control system that has a diff that works?
i can't count the number of days that i have spent integrating code from random developers around the world into our own open source project - could i have developed said features from scratch?
possibly, depending on what is being submitted.
could i have better spent the time doing new development for the project? potentially...
this kind of 'take what you can get' system is the foundation of open-source. you either take the contributions, or you don't.
whining about it because you have a big company that happens to have adopted your program is ridiculous.
there are hundreds of thousands of open source projects out there that would kill for a company like apple to donate code to them.
open source simply requires that they post their changes, not that they provide you with a 1-step integration of their forked code into your who-knows-what-has-changed 'primary' branch.
trying to force people to specifically donate their changes to the specific developer that happened to have posted the original code completely breaks the open-source model as well.
our current generation open-source game engine has gone through multiple lead developers - several of which just 'disappeared' off the face of the earth. being open source, other developers picked up the ball and continued the development of the engine.
in our case, the underlying graphics engine is owned by a company that has zero interest in supporting the open-source community (they bought the technology after it was open sourced) so this kind of forced submission process just will not work in the real world.
not only will it not work, but if the 'official' development team decides not to implement the code changes, who knows - perhaps there is another team out there that WILL integrate the changes...
this is the world of open-source. not every project has a linus at the top with the override of every step of the process.
Gekido's Lair
Let's be frank, folks.
- A bunch of developers finds a bunch of bugs and fix it in their source base.
- They hand you their source base, along with loads of information on where the bugs are, and patches that you can't integrate into CVS HEAD.
And the KHTML team is sitting around bitching about the fact that KHTML != WebCore anymore, and how none of the patches can be run against HEAD...
Ok, I was *at* Netscape at the time. I have no doubt that he and his team continue to bust their asses to ship good code, and they're passionate about doing so.
That is not to say that they:
1) Should feel restricted to KHTML's API. That's not in Apple's best interest, and they're not doing this *for the KDE team or organisation*. It's also not fun - they don't run Linux desktops, or KDE, and don't feel like re-entering Netscape's cross-platform hell.
2) Is KHTML nice and segregated? The whole reason WebCore happened was that KHTML was littered with KDE calls. Now the KHTML team is complaining that the WebCore code is littered with Mac API? Imagine my shock. Really.
3) A bunch of people just gave you a ton of information, bug reports, and example code you can *LIFT OUT AND REWRITE*.
Lazy? You're damn right you are. Disillusioned? Yeah, I'll bet. Apple didn't add developers to the KDE project - they added them to Safari. Any idiot can tell *from the starting point* that the only way the browser would happen was to do in WebCore what the KDE team did in KHTML; utterly fail to abstract platform-specifics from the rendering engine.
Personally? I could wish that some big commercial development house would take an open source product I was on, commercialise the development, submit its source code quarterly for me to scavenge for ideas and code where possible, and for it to remain legal to do so.
Is it "ideal"? What's "ideal"? A bunch of other people bend over backwards to make your codebase a nicer place to live in, so they can throw away their deadlines, fix the fact that you didn't separate out the platform dependency in the first place, and burn money on things in the codebase that don't have *any* outward impact except to make it easier for someone else to suck up the code into their tree?
I'll bet you're frustrated. All those damn clouds keep getting in the way of your panoramic view.
It may not be perfect - but it's more than just a little better than nothing; it's actually a hell of a lot of time and effort spent to give back to the community. Even if, in this specific instance, what's given back isn't instantly reusable by that community.
Meanwhile, you can go back to KDE. Not a bad product, but strangely enough, it's hard to run KDE applications without running KDE. It's hard to develop a KDE application that would/could. If anyone has experience with writing applications in an environment that has to cross APIs with fundamental differences in how they perform simple actions, it's the person you're accusing of... of what? Of not being "helpful enough"? Of not being a KHTML team member? Of not being an Apple employee paid to work on a KDE-specific project?
I'm having a really hard time imagining what the fuck is going on in your head, and I'm just not sure it's worth bothering; I suggest you start a rock band and burn off some of that angst on teenagers who are more likely to think that every word that comes out of your mouth is gospel, rather than the drivel it sounds like to those of us of older generations.
-- A mind is a terrible thing.
this looks pretty easy to understand to me it's all laid out in nice small txt files and the link to each txt says exactly what the patch does. http://weblogs.mozillazine.org/hyatt/archives/2005 _04.html#008042
OMG Ponies!!! with Glitter!!!! I miss Pink
So Safari is a fork of KHTML then? Fine. Again, I don't want to hear anyone talk about how great Apple is because they give back so much to the open source community.
Since when is doing a fork not "giving back"?
The whole point of open source is that anybody can do anything they pleases with the code. I.e., the license not aimed to protect the rights of the original developers, but to protect the freedom of the subsequent users/developers to do what they want with the code, including making a fork.
If the KHTML developers don't like the changes Apple made, they are free to not put them back into their project, and let Safari branch out on its own. What's the big deal? Oh, turns out they want the functions added, but didn't like the way it is done? Tough luck, I say, life is not always how you want it to be.
If the KHTML developers don't like that, then they better not use an OSS license in the first place and then complain when people actually use the rights granted by the license!
OTOH, if Apple refuses to release the source of Safari when they distribute the binary then we have a valid complain. As long as the binary isn't distributed, we don't even have grounds to tell Apple to give us the source code! Much less give it in a way we like.
Oliver.
What you should be asking yourself is "why not read the article?"
Apple has given back the changes. Apple has even built a new framework around KHTML. What Apple hasn't done is do all the integration work for the KHTML people. Who are now whining about how hard the changes are to work back in.
The KHTML team doesn't seem to be working very hard, so a fork happens. Forks happen. They rarely stop at one, either. I expect sooner or later we'll see another fork of KHTML that will try to bring the Apple changes onboard, and will thus leap over the existing KHTML project.
But in the meantime, we get to hear the lamentations opf the lazy.
If you distribute the binary, then you must make available the source code to anyone that receives *your* binary. So let's say I give you a binary of my GPL application, but you don't know it's GPL because I didn't tell you (violation of the license, I have to at least tell you). You copy it for a buddy, and he recognizes it as a GPL application. He asks you for the source, you don't have it. He can climb the ladder to me and ask for it and I have to comply.
In Apple's case, they only have to provide the source code to KHTML (with their modifications) to the people who receive a binary for Safari. And that's it. Not the KHTML team, not KDE, not you (unless you have a copy of Safari), and not me.
A little side point that's worth mentioning. :) Both the GPL and LGPL require you to mark your modifications to the code. You can't just change the code and claim ownership to it. If you change my GPL code and don't put your name around the parts that are yours, then you have just given me your code. You haven't licensed your code to me under the terms of the GPL, you've given it to me. Later on, I decide to take my GPL code and wrap it up as shareware and start charging all users of it. Since you didn't mark your code, you have no claim of ownership on it, you can't force me to back off and release my now proprietary code as GPL again.
what's the moral of the story? Apple needs to be marking their changes to KHTML. It's part of the license. So these complaints about the code not being easy to see what they changed are actually valid--the license does require it. Without doing so, Apple can't claim ownership of that code.
SO all you open source developers out there, make sure you put your own copyright notice in the patches you send in!
Realistically, using version control reports and stuff as evidence APple can probably get a court to respect their ownership of the code they wrote that wound up in KHTML, but why go through all that expense for the sake of promoting bad coding habits? Mark your code if you own it, otherwise don't bitch about it when someone claims it as theirs.
Like what I said? You might like my music
You obviously work on a grand total of a couple thousand lines of code at work, if at all, and aren't working in a source control managed environment.
Let's make grandiose and inaccurate assumptions, shall we? FYI, I've written version control systems and worked on large portions of commerical operating systems. On really big systems, I hate to tell you, sometimes history isn't there either. Some version control systems suck worse than CVS, as you ought to know from your vast experience.
Apple is what it is: a talented amoral corporation led by a greedy egotistical amoral CEO. They aren't "Different", they aren't "feeeel-gooood", and they don't care about OSS unless it makes them money.
This displays profound ignorance about Apple's motivations, and those of Steve Jobs, a man notoriously unaffected by money. He was a billionare before he was thirty. Money doesn't move him. He can be convinced, you idiot.
And you -- you -- you're wasting time flaming me. Apple can be convinced to really buy into open source. Since you're so much more experienced, intelligent, and moral than I am, why not set up a meeting with Jobs?
Because I'll tell you something: Apple has neither the version control technology nor the internal motivation to provide history. They use CVS. The last time they tried to export source via external CVS servers, with Darwin, it didn't work out so well. So they shut it down. They could fix this, but they don't care enough about open source. Tell you what: you should either help them care, or go fix KDE so that it's a viable alternative GUI.
Jesus. Nothing better on slashdot than to be flamed by some holier-than-thou script kiddie who contributes a couple of lines of code to KDE and thinks he's qualified to judge "morals."
Good point. I think it's normally interpreted as "the form you use yourself for modifying it". Which means if apple people really do just use these humongous patches or modify the source with no scm at all they're ok, but I doubt that's how it works.
I am trolling
If those developers absolutely want stuff like CVS histories and changelogs provided, they need to make sure it ends up in whatever license they're releasing under. Apple is a big company with about three thousand other things that need to take priority. Making the lives of open source developers easier may be warm and fuzzy, but it's not important.
The flaw is in the GPL, if it doesn't provide KHTML developers with what they want.
Apple are "giving back" what they're required to under the license for which they obtained KHTML source. The complaint here is that Apple isn't doing more than is required of them by that license.