lkml.org 
[lkml]   [1998]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linus Speaks About KDE-Bashing
I didn't want to get into this again, but Linus specifically mentioned
"bad blood" between "*gimp*/kde people" (emphasis mine), which isn't
entirely true.

> The point is that the whole area is gray. Qt is not the EVIL with capital
> letters that some people make it out to be: neither is KDE. There are
> precedents for much "worse" libraries (ie Motif) being accepted silently
> and without discussion.

Yep, this issue is a gray area, and I believe that it's best to stay on
the side of caution in this case. It would be quite bad if a judge later
on explicitly rules that linking GPL apps with Qt is illegal.

I'm not a lawyer, and have precious little expertise, so I'm not willing
to comment on the legality of the issue or not. Neither RMS, or Alan, or
Linus, nor most of the people posting to this discussion. Frankly, I won't
be satisfied till there is some actual legal precedent, set by a judge.

This is why I have advised the KDE people that if they wish to distribute
their KDEified GIMP, they should get permission from every tenant of the
GIMP copyright (which includes the FSF, there is FSF copyrighted code in
GIMP). If one tenant disagrees, no go.

> The additional problem is that there is obviously much animosity
> completely unrelated to copyrights between the gimp/kde people, with bad
> blood between rival systems. The GPL was _meant_ to allow sharing of code,
> and as such I find it disturbing that people are now using it to try to
> force non-sharing.

Before this Kimp thing, there wasn't much animosity at all, if any. Many
of the GIMP developers didn't care one way or the other about KDE/GNOME.
It must be stressed that GIMP and GNOME share little except for a common
toolkit, CVS repository, and a very minor overlap of developers. I
personally avoided any flamewars, and tried to get some actual work done.

The problem is, the way Kimp was done, pissed off many of the GIMP team
(myself included). Since this is going to kernel-list, I'm going to make
an analogy:

(note that I'm not a kernel hacker, so this may not completely mesh with
the way the kenrel is architected. The theoretical point should still hold.)

There is a proprietary network card driver library under a Qt style license.
It costs no money, you get source code, but you can't distribute modified
versions. These network card drivers give slightly better performance on
networks with lots of Macintosh clients, since lots of optimization has
gone in with detailed timing of the specifics of the Mac ethernet hardware.

Someone goes in, takes the Linux kernel, and makes it work with this
driver library. Problem is, the driver interfaces are different from
the standard Linux netcard driver interfaces. So a perl script is
written to convert all the code to the new driver interface. Some
glue code is written to bind this thing together. Also the old Linux
netcard drivers aren't thrown away, since the new driver library doesn't
support all the cards that the old one did. This person then calls it
"Kinux".

Note that nothing about this project was mentioned to Linus, or to anyone
on linux-kernel for that matter. The kernel developers only hear about this
project through hearsay and rumors. Direct communication between developers
is nonexistant.

Later on, in the regular kernel, optimizations to the original drivers are
introduced that nearly double the performance on SMP machines. The
proprietary driver library isn't even SMP aware. The vendor refuses to
make modifications, because they would have to completely redesign their
driver library.

Now take Joe Sysadmin. He hears about this really cool operating system
written by a guy named Linus. But wait; there is a Linux and a Kinux. So
which is better? Oh, guess Kinux is, since there are a lot of Macs at
my site. Guess I'll use that, huh?

[later on...]

Hmm.. there's this optimization that will increase performance for my
dual PII 266 for Linux. But I'm using Kinux and it doesn't work?! So
I need to install Linux now? ARGH!

Fuck it. I'll just use FreeBSD.

In the case of Kimp, this is exactly what happened. The conversion was
done from GTK to Qt by a perl script, and there was glue code written.
The conversion was far from complete, all the the plugin UIs still are
GTK. Qt is not (at least to my knowledge) threadsafe, and lacks XInput
support. GIMP 1.1 makes use of both threads and Xinput.

See, the problem with Kimp isn't just about licensing. It's about ethics.
None of the GIMP developers were consulted beforehand about the port.
What, do we not have some helpful ideas about code we've been working with
for so long? No the GPL doesn't require you to ask, but it's common
courtesy. So a lot of the animosity towards KDE now is reactionary to the
rather insulting way this project came about in the first place.

There also is the precedent that KDE has of provoking project splits. LyX,
nethack, ezppp; all have had rifts between the original projects and the
KDE ports. These are out and out splits. Bugfixes and new features are
not smoothly transitioned, and sometimes not even put in on tree at all.
This sucks for users and developers alike. I don't want this to happen
with GIMP, and would very much like to be proved wrong on this.

I'm not against making GIMP work better with KDE. I just don't think
we need to link with qt to do it. The man who we need to talk to,
Matthias Ettrich, is on vacation, so there is little that can be
discussed now. It's good that they are finally willing to open this
to discussion, and I commend them for respecting our wishes by not
distributing Kimp until all the issues are resolved.

-Yosh

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.187 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site