On Thu, May 15, 2008 at 09:44:50PM -0500, Jordi Guti?rrez Hermoso wrote: > On 15/05/2008, Gregory Seidman <[EMAIL PROTECTED]> wrote: > > > Looks like Apple did terrible harm by devoting resources to improving > > the functionality and releasing them to the world, eh? Oh, but it > > isn't getting back to KHTML quickly, you say? That sometimes happens > > in a code fork. > > Well, the rules (LGPL) say that they have to give back the code.
No, they don't. They say that if you distribute something built with the code, you have to release the code. There is a common misconception that the (L)GPL forces people give their changes to the original authors (or current maintainers). This is not supported by the actual language of the (L)GPL, nor by the GNU Foundation's intent in creating the (L)GPL. Furthermore, if you actually read the Free Software Definition <http://www.gnu.org/philosophy/free-sw.html> you will notice that the four freedoms listed specifically support Apple's behavior. They wanted to run the KHTML code as a Mac web browser (freedom 0), they wanted to adapt it to work well on the Mac (freedom 1), they wanted to distribute it with their operating system (freedom 2), and they wanted to make it a best-in-class web browser engine (freedom 3). > Which they did, in large chunks, a year later, in ways that were > impossible to put back into KDE. They didn't break any written rules, > just didn't act in a way that is traditional in the free software > community. They acted like a corporation would (this is not a compliment, > despite what the "profitable == moral" people think). So the problem is that they aren't "traditional"? Yeah, whatever. They produced a better, more flexible, more functional version of the library and have consistently fulfilled and exceeded their responsibilities for maintaining it as Free software. That they did it by taking it in-house instead of trying to convince the people who tied it to KDE that it should be more general is utterly irrelevant. > Forking is generally seen as a hostile falling apart within our > community. Forking happens with big disagreements, negative publicity, > and internal flamewars. Xemacs vs Emacs, XFree86 vs Xorg, Funpidgin vs > Pidgin... And I don't see Apple's forking as a friendly move either. > And it's taken a long time for KDE to benefit from it, and in the > meantime the whole thing caused flamewars within KDE. It's easy for people to take offense. Apple did what it did for business reasons, not to piss off KDE. The KDE folks didn't like that Apple made their code way better and released it in a form that people outside of KDE actually wanted to use? Yeah, not feeling any sympathy here. Apple took a weird, niche browser from a bunch of not-invented-here coders and made it good. So good that the library ON WHICH KDE IS BASED decided to incorporate it. Is it hostile to fork code? How about creating an independent, competing codebase (e.g. KHTML vs. Gecko)? Again, no sympathy. > Fiasco, I insist. [...] And I call bullshit. > > Not KHTML? Actually, since WebKit is part of Qt > > these days, KDE could just ditch KHTML and use WebKit instead. > > It's not so easy. Technical obstacles loom ahead: > > http://www.kdedevelopers.org/node/3073 The technical obstacles there are not with ditching KHTML, but with porting the advantages KHTML currently has over WebKit; the article doesn't go into detail about what those advantages are. It also makes two important points: bug-for-bug compatibility with Safari has advantages (if you're using the same engine as a significant installed base, web sites might actually gear content to work around your quirks instead of just ignoring you), and pushing their patches through Qt's branch (i.e. WebKitQt) is a good alternative to dealing with Apple's turnaround on patches. It sounds to me like it's mostly a problem with bruised egos, for which I have (say it with me) no sympathy. > - Jordi G. H. --Greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
