Messages in this thread | | | Date | Sun, 12 Jul 1998 14:36:39 -0700 | From | Manish Singh <> | Subject | Re: 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
| |