Re: Blocking Gmail ads
On Thu, May 15, 2008 at 09:44:50PM -0500, Jordi Guti?rrez Hermoso wrote:
> On 15/05/2008, Gregory Seidman <gsslist+debian@anthropohedron.net> 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
Reply to: