Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
KDE GUI

TrollTech Responds To QT Accusations 148

David B. Harris writes: "On freshmeat.net Erik Eng of Trolltech responds to various accusations thrown at TrollTech about their QT libraries' licensing problems. Set the flame dial to low when you read this one, he seems sincere."
This discussion has been archived. No new comments can be posted.

TrollTech Responds to Qt Accusations

Comments Filter:
  • im going to lose karma over this but wtf iv got to say this
    I am a Linux user not a programmer and I dont give a crap about licences
    All i want is software that dont suck!
    Face it as a desktop os Linux sux as bad as winblows
    So what do the morons do talk world domination then attack
    someone nice enuff to allow them to use a decent
    toolkit that someone odviously thinks is
    worth spending money on for free
    To all the ungratefull idiots out there
    GO JUMP IN A LAKE
    To all the peaple that put there time energy
    and skill into linux/*bsd/gnu/qt/kde/ect
    to make them suck less thank you!
    This includes the qt programmers thank you
    for helping make free operating systems suck less!!!!!!
  • Did you even read the article? If you did I am forced to wonder if your brain is functioning properly.

    There is nothing illegal with linking GPLed code to non-GPL libraries!

    As the article states, people were writing GPLed software against the uber-proprietary Motif libraries for years. Emacs made system calls on non-free OSes. There is nothing illegal about writing GPLed code which uses the Qt API and libraries.

    One keeps seeing this, and it is wrong. It is pure FUD spread by some zealots--GNOME users? GPL fanatics? who knows.

    Disclosure: I dislike KDE, but agree that Qt is much more attractive than GTK. I like the GPL and support it. Doesn't mean that I support fanatics in their zealotry or their lies.

  • I'm probably getting trolled... oh well....

    1) It's not his job to deal with KDE or the GPLd code in KDE. He codes Qt. Not KDE. The issue wasn't KDE/GPL, he was addressed why Troll chose the QPL, not the GPL.

    2) False. Some are employed my Mandrake, part or full time. Corel has some. Caldera has some. The vast vast majority are volunteers are non-affiliated. KOffice is funded by some company in Asia. KDE, unlike most open source projects, does not have a "benevolent dictator" to steer, anyway.

    3) I have no inmmediate problems with the QPL, except for the GPL incompatibility. Compared to crap coming out like the APSL and SCSL, the QPL is a really nice license. I still, however, maintain that it's GPL incompatible (due to my definition of linking). It was nice to learn it's GPL incompatible because of their definition of linking, not from some secondary motive. The issue of the license should be taken up by the KDE team, not Qt. And the KDE team has shown great apathy towards licensing issues. I'm generally a "shut up and code" kind of guy, but this issue has been there for years, and hasn't been solved yet.

    KDE and Qt are totally seperate. This guy is from Qt. We heard from Debian before. Let's hear something from KDE, they're the ones at fault in the minds of the Deian developers (and others), not Qt.
  • Apache is a webserver, as such, it imitates other web servers already in the market.

    You're both right and wrong about this one. From http://www.apache.org/ABOUT_APACHE.html [apache.org]:

    In February of 1995, the most popular server software on the Web was the public domain HTTP daemon developed by Rob McCool at the National Center for Supercomputing Applications, University of Illinois, Urbana-Champaign. However, development of that httpd had stalled after Rob left NCSA in mid-1994, and many webmasters had developed their own extensions and bug fixes that were in need of a common distribution. A small group of these webmasters, contacted via private e-mail, gathered together for the purpose of coordinating their changes (in the form of "patches"). Brian Behlendorf and Cliff Skolnick put together a mailing list, shared information space, and logins for the core developers on a machine in the California Bay Area, with bandwidth donated by HotWired. By the end of February, eight core contributors formed the foundation of the original Apache Group.

    The name Apache came from "A PATCHY server", because it was originally a bunch of patches to NCSA's reference httpd. So one could argue that Apache copied NCSA httpd, or one could say that it is an extension of it -- in which case Apache is the original product, and all the commercial webservers are copies of Apache.

    But apart from that, you're quite right about OSS vs. commercial software: OSS is best at projects that meet a well-defined, pre-existing need. Innovation (real innovation, that is, not M$ "innovation") into new areas of software is typically done by companies with plenty of money to spend on R&D.
    -----
    The real meaning of the GNU GPL:

  • Actually it's a (mis)interpretation on the Debian developers' part; it's why, if they were taken to court over this, they would be run through the wringers for libel.

    The GPL only deals with the code in question (the software that is licensed under the GPL) being used in other works, hence the derivative works argument. It *does not* deal with linking to the libraries.

    Heck, one could argue that GNOME apps are illegal. X11 libraries aren't just not released under the GPL, and IMHO (and against RMS's NSHO) not really GPL compatible (at least in this particular misinterpretation) the X11 libraries are also not essential system libraries. Nope, don't try to say they are: you can run your system just fine without X at all.

    So what does it all boil down to? FUD. I read through the licenses, and the only *potential* problem I found was perhaps the fact the QPL *demands* that any works linking to a QPLed piece of code be released free as in speech *and* beer. The GPL only requires that software be free as in speech. However, if you release your code for a fee, you'll just have to pay the (hefty) licensing fee for QT.

    So, what does it all boil down to? FUD, aimed at those gullible enough to believe this without reading the licenses for themselves. Don't believe me? Go to http://www.gnu.org and http://www.troll.no and read the licenses. Print them out if you have to. But read them.
  • Coming from a non-X programming background, how hard would it be to implement the QT api as a C++ wrapper to GTK???

    That would solve all the problems... KDE with GTK..mmmmm


    Simon
  • Careful.

    I could take one amendment of the United States Constitution, quote it, and tell you that alcoholic consumtion and/or production is illegal. Is it? No.

    What's my point? Granted, the analogy isn't all that close. The point is this: you're quoting one specific part of the GPL and excluding other parts. You're also *completely* excluding the terms of the QPL. The QPL has terms that allows for QPLed software to be linked to by "open source" programs. The original licensing agreement called for software to either be GPLed or some other (freer) license.

    IMHO (although IANAL) this is just FUD in an attempt to kill KDE. You'll notice the arguments are mostly against KDE. I really haven't heard too many arguments against, say, WMFinder (IMHO the best X11 file manager.) But, hell, it isn't "competing" against GNOME directly. KDE is.

  • AAAAAAAAAARGH!

    LiteStep is illegal! You have to have VC to compile it!!!!!

    Okay...where's the zealots with torches?

    Anyone?

    Sigh...guess it's just KDE we want to nail to the cross, then.

    PS GNOME is illegal too.
  • I agree.

    This is true of KDE as much as QT. In hindsight, the KDE developers would have probably chosen a different license, but now that it's popular, the QT and KDE license don't work so well together, so goes the argument.

    The real problem is that one apparently needs a savvy lawyer right from the start, but none of these projects have the money to make this happen. Why should I need a lawyer to do free software? This is the real problem with the GPL and its intricacies. It needs to be either clearer or more flexible.

  • Yes, that would indeed make it GPL incompatible. :-)

    The solution is to require that everyone who wants their patch to appear in the official Qt release assign the copyright to TT, much like RMS begs people to assign copyright the FSF.

    If you ask me, it's a no brainer. TT should do this for its own good, because it benefits when KDE succeeeds, and KDE won't succeed unless this license issue is fixed!
  • Just one note about a GPL Qt. TT would have trouble incorporating patches from users since they will fall under GPL. They must have the patch authors permission to include it in their proprietary version of Qt. The code that TT has written is of course no problem. TT could add a clause to their GPL which says that they can use it in their proprietary version. But I am not sure if that makes the license non-GPL compatible.
  • He compares Qt with Motif:

    "When we first released Qt there was already de-facto acceptance in the community that one could make GPLed programs using Motif, even before Lesstiff came along. Motif was a proprietary and non-free library with a much stricter license than Qt."

    GPL allows linking (dynamic and static) to libraries that are not GPL compliant if they are considered a part of the OS. Hence, an application in windows that uses WIN32 API has no problems. Qt is not part of the OS on any system, not even Corel Linux.

    But Motif is logically no more part of the OS than Qt is. They're both UI toolkits that are not required for basic system operation.

    This is the one thing that bothers me about the GPL in the current situation. The prevailing wisdom seems to be that it's OK for non-GPL software to be built on top of GPL software as long as the communication mechanism doesn't involve mapping the GPL software into the same address space as the non-GPL software. If it's done by dynamic loading a GPL library, though, the result is apparently considered a derivative work. In real world terms, this seems like a stretch. The line between use (which is not covered by the GPL) and incorporation/modification (which is) is now blurred, and is becoming more and more so with time, as runtime loading and such become more and more universal.

  • He is married to a beautiful French woman

    Hold on, isn't that redundant? :D

    Note: this may sound more funny if you know that I am French myself.

  • The GPL restricts distribution of a GPL program unless you can provide the entire source of the program down to virtually the OS level, including libraries and everything needed to make the program work, under terms no less restricive than the GPL, with the exception of components that are part of the operating system.

    Wrong. The GPL prevents redistribution of a program unless you provide the entire source of the program. Period. As has been pointed out before, GPLed software can be written for any platform (where platform = hardware + OS + libraries). Even granted your mistaken belief, I challenge you to define `operating system.' Acc. to the strict and proper definition, the OS is only the bit which deals with resource allocation--it's not the shells, not the libraries, not the graphics systems, not the window managers, not the desktop environment; it's none of those. And yet GPLed software has been written under those circumstances. The license hasn't changed. Thus, if that GPLed software were legal (one hopes so, since that family includes emacs and gcc), then your phrase `operating system' is equivalent to my `platform,' and Qt, being a library, fits into that category. Ergo, GPLed programs may be linked against Qt.

    This reminds me of the FUD spread by the anti-GPL folks, that software compiled with gcc could only legally be itself GPLed.

    So, for your wrapup, that's essentially what KDE does when it takes other peoples GPL code, ports it to the old-style-licensed Qt, and then distribute it. Someone's property, made semi-proprietary through dependencies. That is the reason people have been rather upset.

    It takes GPLed code, modifies it and releases those modifications under the GPL, as it is required to do. No law has been broken; the GPL has been followed. So where is the cause for complaint? That someone has modified one's code? Is that not one of the reasons for the GPL to begin with? It is no more semi-proprietary than code written against Motif or on a proprietary OS is.

  • Your general message seems to be that the open-source/free software community spends way too much time discussing licensing. This might be true, but a license is like source code - it can always be improved.

    With the coming of the New Internet Economy (feel free to hurl), Intellectual Property is becoming an important topic. As companies go to even greater lengths to ensure that nobody else makes a single buck from their "work", it has become equally important that the open-source/free software community makes sure that their own efforts are not abused. This, I presume, is why a new improved version of the GPL is on its way.

    I agree, there is no need for endless rants and flames about the subject. However, the community must be able to voice their opinion, however annoying and bad PR this may produce.

  • Note: this may sound more funny if you know that I am French myself.

    No, it doesn't.

    -Jan
  • Motif in Linux have the same problem as Qt (at least before lesstif). It was one of the reasons why lesstif was developed.

    I can't tell exactly if Motif is considered a part of the OS in e.g. Solaris. I would consider it a part of Solaris, but that's just me.
  • Seems to me that TrollTech have the same right as everyone else to do what the hell they like with their software. Just like Sun or ... oh, come on, let's do some overkill ... like Microsoft. The only question for me is: is their software any good? If it's good, it's probably worth some money - though I can't see from here who's paying them any. Who are TrollTech's customers?


    As the absolute total of newsgroup messages increases, so entropy rises, resulting in a rich cache of pat replies which can be invoked as incatations in place of arguments. In many forums, it is customary to accompany such incantations with insults, as these too are a valuable way of attacking whilst having nothing new to say. As this entropy reaches a maximum, the need for human involvement will decline below the level needed to sustain interest and people will revert to more traditional exchanges such as fist-fights and poison-pen letters.
  • So, for instance, I take work "myprog.o" and add "libqt.a" and create work "myprog". "myprog" is a derivative work of a GPL'd work "myprog.o" and a non-GPL'd work "libqt.a".

    That is one opinion. IMHO it is incorrect. I've always thought that the whole linking issue has been viewed incorrectly. It comes from looking not at source code, but at executable files. The important thing is that GPLed code remain GPLed. The executables are generated by the compiler. What if an OS-provided compiler is used which links in a propietary library without which the program cannot run? It is insane to say that this is wrong. If the GPL does disallow this, then it should be modified.

    I doubt that it really does disallow it. As has been pointed out before, Stallman himself has written code which had to link in proprietary libraries.

    The LGPL is currently needed, but the reason is that the solution of simply including source to statically-linked GPL libraries is not satisfactory; it is not possible to replace them. Dynamically linking, OTOH, solves this problem. The GPL should be modified to allow dynamic linking with distribution of source and static linking with distribution of source on platforms which still do not have dynamic linking. Then we can get rid of the GPL.

    IMHO, the idea of `derived work' has been taken too far. A program is not a derived work of a library; otherwise I would have to pay Apple for every program I write on a Mac, or M$ for every program I write on Windows. A library provides the other end of an API.

    The GPL does not prohibit deriving GPLed works from proprietary object code. Otherwise every single older FSF project would be GPL-incompatible.

  • by SEE ( 7681 ) on Saturday July 01, 2000 @06:31PM (#964401) Homepage
    That is one opinion. IMHO it is incorrect.

    In that case, you are saying that RMS misunderstands the GPL, as RMS has repeatedly stated that position, and defended it as necessary to prevent the subversion of free software.

    The important thing is that GPLed code remain GPLed. The executables are generated by the compiler. What if an OS-provided compiler is used which links in a propietary library without which the program cannot run? It is insane to say that this is wrong.

    See this FSF text written by RMS [fsf.org]. And point two of this one [fsf.org]. And this other one [fsf.org].

    It's supposed to be impossible to link a GPLed program to a library that can't be distributed under the terms of the GPL, and it's supposed to be impossible to link a GPLed library to a program that can't be distributed under the terms of the GPL. It was done deliberately. The only exception given was for OS components, and only because it was necessary to allow that in order to make free software available for those OSes.

    (Yes, the definition of OS is fuzzy, and one can make the case that Qt is an equivalent of Motif, a system library for the X subsystem of the OS. That addresses this specific case, not the general.)

    Steven E. Ehrbar
  • If developer time were that much of a premium, people wouldn't be programming in C++. Obviously, there are other tradeoffs.

    Obviously there are -- but still, developer time and/or developer productivity is important, and good development tools are worth quite a bit.

    In any case, I don't think Qt is particularly competitive among commercial cross platform toolkits. Many of them are more mature and have better tools support (GUI builders, scripting, etc.).

    So what would you suggest for a Linux/Windows app ? Qt is by a long shot the nicest toolkit I've seen on Linux.

  • There are several high quality toolkits out there without such restrictions...

    Umm, you forget to list any restrictions. I can only find two restrictions that anyone can point to even vaguely onerous. Both of which, if you had read the article, are about to go away.

    1) Patch clause. Gee, every OSS project I know of accepts only patches anyway. In any case, the only thing this restricts is forking.

    2) No private distributions. If you distribute the software, you distribute the software. No if ands or buts.

    I think it's valid to ask the question whether this is a good deal.

    It's an excellent deal. Qt is Free Software if you're using it to write Free Software, but it's proprietary if you're writing proprietary. In a world where everyone keeps telling me "life isn't fair", this is a breath of fresh air.

    And Qt is so expensive that I would have serious concerns about using it even as a purely commercial toolkit.

    Have you priced out commercial toolkits? I don't mean those half-assed Microsoft offerings, I mean real-world high-quality tools.
  • I'm pretty sure a lot of the KDE developpers don't grasp the difference between Free software and Open Source.

    So what is the difference?

    I've read Richard Stallman's definition of Free Software [gnu.org], and I've read the OSS's definition of Open Source [opensource.org]. As near as I can tell, anything that is Open Source must also be Free Software. Which one of RMS's four points does the OSS definition not cover?
  • OK well i bet penis bird person guy thing to it.
    but what i dont get is why does everyone race to get fp?
    what is so special about it?
    can some ??"normal"?? geek out there explain this to me???

  • the only substantive reason a distribution would include Qt is so it can include KDE

    Oh wow! This must be why Debian includes the Qt-2.x library! Thanks for clearing that up for me.
  • by garnier ( 204518 ) on Saturday July 01, 2000 @12:11AM (#964407)
    I agree with this fellow about KDE and such QT-based programs being fully GPL'd. I've read the GPL closely, and it does not make any restrictions of the compilation/linking of a GPL'd program. It DOES restrict non-GPL'd programs from linking with GPL'd libraries/programs, but a -> b does not equal b -> a. Since KDE(a) is linked against QT(b), eveything is good. No proprietary code is linking against a GPL'd program/library. QT is not linking against KDE, so where's the problem? Sure, QT links against LGPL'd libraries, but that's why they're LGPL'd. This license expressely allows proprietary programs to link against an LGPL-licensed program.

    However, I this this person should really wake up and just say what everyone knows: They want to make money. They should just admit it. It's their software, and they can do what they want with it. Instead of bitching about it, make another library. Oh, wait, people did - GTK+.

    So, just to wrap this up, I'd like to pose you a question. What if someone said that your nice, nifty, Free program, distributed under the GPL, should be proprietary? What if you had hundreds of people downright DEMANDING that you move to a draconian license? You'd be pretty upset, wouldn't you? Because it's your property. It's your blood, sweat, tears, and time. Everyone who is about to flame TrollTech should think about that.

    Philippe

    P.S.: I have a TrollTech-Free computer.
  • I'm thinking (with no particular evidence) that Trolltech is the company that may be involved in the rumored FSF GPL testcase.

    Extremely unlikely. If it were true, RMS and his lawyers would walk out of the courtroom five minutes after they entered, then proceed to the men's room to wash the egg off of their faces.

    The FSF can only sue on behalf of its own software. It does not hold copyright to any part of KDE or Qt. Furthermore, Trolltech doesn't even release anything under the GPL. What possible legal grounds could the FSF have against either of these entities?
  • The GPL says "normally distributed (in either source or binary form) with the major components".

    You say "If the library in question is a standard part of the"

    Now, the last time I checked my dictionary, 'with' and 'of' had very different meanings. One version or another of Qt is distributed with the major components of all free unix-like operating systems, including Debian. But even if it weren't, all you would need to do is distribute the Qt source code.
  • Qt can't be used for internal/research projects w/o paying $1500

    Bullshit. All they have to do is make it open source. Hell, they don't even have to go that far. All they need to do is give Trolltech a copy.

    It wasn't too long ago when half the people here at Slashdot were excoriating Corel for having a closed beta distribution. Now suddenly when the license isn't the sacred GPL people are demanding the right to private distributions.

    If you distribute the program you distribute the program. No if, ands, or buts. It doesn't matter if you distributed it to your coworker, you still distributed it.
  • by nocent ( 71113 ) on Saturday July 01, 2000 @12:12AM (#964411)
    This article [freshmeat.net] by Joseph Carter entitled "Why Debian doesn't include KDE" is what Trolltech is responding to.

    Among other things, Carter wrote:

    The draft license seen by me last before release of the final QPL was GPL compatible. I was proud of it. So, it seemed, was Troll Tech. And then the final license was released, undoing the parts of my work which made the license GPL compatible, but retaining enough to satisfy the definitions of "Free" many distributions (including Debian) use.

    But the license issue remains. Qt is not non-free software. But it's not GPL compatible either. Some KDE core developers admit this privately, but won't do so in public because of the implications: that much of KDE is not legally distributable until they contact some people that are damned scarce these days and make the necessary arrangements.

    There's a lively debate on that page already.

  • No, you're the jerk. You so caught up in Stallman's rhetoric that you fail to see true freedom when it stares you in the face.

    'banbeans' chose Linux of his own free will. He was not under any duress or coercion. The fact that he was able to use Linux without legal or physical hinderances demonstrates that he was in fact free all along. He was free before he used Linux, he is free now, and he will still be free even if he chooses a 'non-free' OS. Maybe when you and your cohorts stop calling free men slaves you'll get more respect.
  • I've got no idea, maybe they were working on this change for a long time, maybe not...

    In any case, it's clear why the article was published now, as a response to Carter's. What I fail to see is, how this necessitates the events described by you.
  • The main changes we plan to make are to remove the patch clause and clause 6c.

    The patch clause was meant to avoid leaving Qt users with slightly incompatible versions of the library without the possibility to tell where the code stems from. However, the Qt user community is now so large that we believe that this is less likely in the current situation. We also see that people tend to send their patches to us so we can include them in the official versions of Qt.

    Clause 6c has been claimed to be the major reason for GPL incompatibility in the QPL. This clause gave us the possibility to ensure that companies writing internal Open Source software indeed release their source code to the general public.

    The QPL version 2.0 will hopefully end the license discussions once and for all and get us all back to coding again.

    Hopefully this action will be enough for the Debian folks to be able to include Qt-linked software. So... a Linux distro got that far to let a company re-license it's software? Really, talk about devotion...

    But, as always, the real zealots will find something to complain about as it isn't adopted to their holy GPL. Probably some complaints about certain programming languages et cetera.

    Really, if some of us would start being productive, a hell of a lot more could have been accomplished by now.

  • What for?

    Besides, that would not alleviate the problems of Debian (I don't agrre with their interpretation of the GPL, but let's pretend it's correct for the moment), which is their claim that distributing binaries of GPLed programs linked to Qt is illegal.

  • Hi, assume that I am a poor student, not being able to afford the $2k to buy a commercial QT lincense, but wanting to write a small app which gets then sold a few times for let's say $50.

    I want to write the app using Qt because I like the API. Is it ok to release only the parts which contain Qt API calls, and keep closed the rest (because I have some killer-algorithm in the app's engine which I don't want to publicy disclose). ??

    Since the GUI sourcefiles of my app call other functions (and include the engine's headers) which are located in other files, the code I would release would of course not work. (does not compile because of missing parts)

    My question: am I breaking the QPL by doing so ?

    Or do I have to revert to a client-server model (GUI client opensource) and engine (=server) in order to avoid breaking the QPL ?

    thanks for your infos.

  • GPL allows linking (dynamic and static) to libraries that are not GPL compliant if they are considered a part of the OS.

    Define OS. This is a weakness in the GPL. Linking to anything from GPLed code should be allowed. IMHO linking anything dynamically to GPLed code should be allowed as well; a library simply provides the implementation of an API. Should a proprietary app be prevented from calling a GPLed ls?

  • by Jaldhar ( 24002 ) on Saturday July 01, 2000 @04:34AM (#964418) Homepage
    It's really not TrollTechs job to clean up the licensing mess KDE made. The QPL meets all the requirements of the DFSG just fine. It's KDE which should have thought about the implications of using the GPL. I'm a Debian developer and enthusiastic KDE user and it breaks my heart to see two great projects not coming together because of silly trivialities. And it makes me angry that KDE is still trying to avoid and deny the problem instead expending a tiny amount of energy to fix it once and for all.
  • What you're missing is that there are many people who would prefer the GPL to be viral, not in the usual sense that it's accused, but in the sense that it infects anything which touches it. Is it illegal for a proprietary app to call a GPLed ls? Of course not; that's utterly absurd. So why do some think that dynamically linking to GPLed software should be illegal? Because they are fanatics.

    I appreciate the GPL; I dislike proprietary software. But I am willing to co-exist. As long as my code remains free and open, I am happy. If my code is dynamically linked against but the source is included, I am happy. Free software will win in the end, for the most part. I'm sure that there will always be some proprietary software. Big deal. I needn't exterminate my enemy, but simply defeat him.

  • Actually Corel and Debian had a dispute with dpkg (the package tool in Debian). One of the authors had the opinion that the proprietary command-line interface of dpkg couldn't be used from a non-GPL GUI application. But RMS and others didn't have any complaints against it.

    The command 'ls' is part of the POSIX standard, so there's nothing unique about that command.
  • Actually, in fairness, the GPL does make a special exception for linking againts system libraries. That term is not well defined, though.
  • Well my impression was that this is not the
    whole problem. But as to the problem described
    on the web site: I don't think it's real.

    Sure the GPL may contain restrictions the author
    doesn't actually want. This is only relevant if
    that license is the entire basis of your contract
    with the author. Contracts in general do not
    have to be in written form. Neither do amendments
    to contracts.

    E.g. waving to a waitress with two fingers
    can create a contract: "I want two beers" (well
    assuming the right environment).

    Also drinking a beer which has been put in front
    of you creates a contract - now you have agreed
    to pay for it. (This is true even if you didn't
    actually order the beer.)

    The same thing applies with KDE. The programs
    calls the QT library. That means the author calls
    for that library to be included. So that
    constitutes permission to link against it.
    That's all that's needed.

    It gets more interesting if the KDE code contains
    other GPL code. The example I've been told
    about is kghostscript, I assume there is more.
    (Is there a list anywhere?)

    Then if you feel that QPL+GPL doesn't work
    (I'm not really clear on this) you'd have to
    get the author of ghostscript to agree to the
    linking. Or politely ask the Troll people to
    make a change to their license.

    However I don't see that changing the KDE license would:
    - be necessary in any way or
    - provide any benefit at all

  • OK, this will be a real big example. Exageration are intended to show the point. Take a big company, said MS. Let this company removing there dear Explorer and replace with, said, Konqueror. Let this company use there dear "Embrassed and Enhanced" practice and modify it so Konqueror can now display multiple new MS-XML proprietary extensions through a DLL. Patches for Konqueror are distributed normally under the GPL, but no code for the libraries which even required a special registrations and agreement to not used it under anything else than MS products. Aren't this fare? (1)

    I think not. Konqueror is licenced to be free. Free to use by anyone on any OS. The example addon made by MS in my examples just made Konqueror-with-MS-XML a part of MS with no regards for the intentions of the original authors, which should be clearly disclaimed in their license. They treat their code mostly like public domain code, breaking the usability of the code and crippling the software for use on other OS. I really feel like KDE (not TT) take all this issue the same way. They take GPL software, add dependencies over a non-free library (remember that most KDE 1.2 are release over Qt 1.x which aren't under the QPL), and doesn't even ask for permissions of the original author. They choose to ignore the warning of several people, mostly because they don't care about all this and don't believe it there are any issue. If there are no issue, why they simply don't add the "exemption clause" stating that you can link the program (including ghostview) against Qt?

    Instead of simply make their lessons KDE choose to don't care about and then complain about conspiracy from Debian because is the only distribution who refused to engage themself into distributing codes where the license said you doesn't have the right to do so. KDE simply refused to clarify this issue, preferring hide their heads in the sand of their own interpretation (are they lawyers? have they ask the original authors?).

    I'm really happy to see TT trying to make the QPL 2.0 compatible with the GPL but this doesn't change the arrogant attitude that KDE has with regards to the intentions of the authors, stated by the license under which the code is distributed. They modify it and distribute it, adding dependencies with a more restrictively licensed library, without even asking the original authors if they can, especially when the issue was often points by many as not that clear as they claim. The simple fact to trying to reach those authors would had prove their respect to free software authors but their mailing list show that even initiative to do that by some members was clearly seens as a waste of time.

    For this, I avoid KDE the best I can, whatever the technical merits of their desktop, just like I avoid MS: they both behave badly regarding usage of other people code, making cheating a common practice that we should ackowledge.

    (1): I know that the GPL has loophole permitting this. MS just have to distribute the DLL with their OS and sell Konqueror-MS-edition a separate bundle. Is not my intention, neither my hability, to analyse such text. I will try to make my point by defining the licenses as a (fuzzy) claim of intention from the author of the software. When the intentions became ambiguous, it should be the responsability of the authors of derived works or the distributors to ask the original authors for a clarification. This task is necessary to improve the license and not build our relationships around misinterpretation.

  • From The GNU.org license list [gnu.org]
    Since the QPL is incompatible with the GNU GPL, you cannot take a GPL-covered program and Qt and link them together, no matter how.

    However, if you have written a program that uses Qt, and you want to release your program under the GNU GPL, you can easily do that. You can resolve the conflict for your program by adding a notice like this to it:

    As a special exception, you have permission to link this program with the Qt library and distribute executables, as long as you follow the requirements of the GNU GPL in regard to all of the software in the executable aside from Qt.
    You can do this, legally, if you are the copyright holder for the program. Add it in the source files, after the notice that says the program is covered by the GNU GPL.
    .....Updated: 28 June 2000 rms
    In other words, it looks like it is possible to create GPL code alongside QPL library as long as you explicitly say so. I would think that it should be possible to do that with the vast majority of the KDE code. If/when TrollTech improves their license, things will get even better.

    From what I can see, it would be much harder to release proprietary QTized code that used GPL stuff too (almost impossible, I'd say).

    I don't get mad at MS for releasing non-free software. I get mad at them for releasing shitty non-free software and trying to pretend that it's the best there is.
    `ø,,ø`ø,,ø`ø,,ø`ø`ø

  • So what is the difference, exactly, between a command and a function in a shared library? Both implement an API; the one in a shell, the other in some other language.

    And the bit about ls is exactly my point. It's an implementation of an API. Can non-GPLed work use the GNU extensions to ls?

    Allow dynamic linking; disallow static linking. Static linking defeats the ability to rebuild th binary, but dynamic linking allows any library in the background. If we wanted we could write a GPLed Qt-alike.

  • Actually, that sounds quite fair. We would have the patches; we could write a free library to implement that API. It's not as though it is some undocumented API; we would have the code, and thus have all the docs we need.
  • The big difference is not so much in the Open Source Consortium's OSS definition but in the interpretation of the meaning "open source". Obviously, not everyone who has heard about Open Sourse has read the "official definition".

    Today, any company that gives away some source code clams to be an Open source company and, not counting the community's opinion on it, they are. So they release "open source software under a licence which *RESTRICTS YOUR FREEDOM* and some outside developers start to work on the code but the company still profits on his work in an exclusive way because the licence is not a Free(freedom) Software licence.

  • It's speculative prediction on my part.

    In the context of competing products, like KDE and GNOME are, as long as both a viable, they will eventually become indistinguishable by the users (like CocaCola and PepsiCola, McDonald's and Burger King, IE4 and NC4, Intel and AMD, etc.).

    Imagine a day when both GNOME and KDE are in that state. Which one would people choose to use? The one with a licensing shadow hanging over its head, or the one that's GPL/LGPLed free and clear?

    For the 90% of the people who don't care, it'll be half and half, so 45% for KDE and 45% for GNOME. For the 10% who cares, it'll go GNOME! So GNOME gets 55% while KDE gets 45%.

    Granted this day won't come within this year, or the next, but as long as GNOME is alive and well and attracting developers, it will eventually come.

    The current technical merit (which KDE/Qt seems to have a lot over GNOME/gtk+) doesn't really matter in this argument.

    Like I said in the first post, the best Trolltech can do is to make Qt at least as free as gtk+, and hope to get even at the end. But I'm afraid that they can't do that until too late. In a sense, the QPL was already too late.

    (Netscape gave up on the $29.99 revenue for every copy of their browser too late. Motif released it's (semi-open) source too late. etc.)

    These are no accidents. Proprietary technologies won't have a reason to lower their price until a competitor come along. But if a competitor gives out the same functionality for free, then the proprietary technology is hosed! Because they CAN'T afford to make their product completely free. They have to attach a little string to their 'free' product, because the livelihood of every employee in the company depends on it. It is that final string, however short, that separates them from their truly free competitors.
  • Then nearly anything can be compatible with GPL. Either you concede the point that 2. doesnt apply for dynamic linking or everything has to be licensed under GPL. There is no middle road.
  • by Millennium ( 2451 ) on Saturday July 01, 2000 @04:54AM (#964431)
    OK, first of all, the Qt guy doesn't even get it. Then again, most of the GPL guys don't seem to get it either. What the whole problem with Qt and the GPL is.

    It is not illegal by any means to compile and link programs against Qt. The GPL has no restrictions on this.

    What it is not legal to do is distribute such programs, because Qt violates one of the terms of the GPL through its discriminatory licensing. It can be made legal again by appending an exception to the GPL.

    I develop a GPL'd product for the MacOS which uses PowerPlant, a proprietary toolkit. But my program is perfectly legal to distribute. How, you ask? Because I add the following to the license:
    This product is developed using PowerPlant, a toolkit written by Metrowerks, Inc. PowerPlant is NOT Free Software; because of this, our product would normally not be legal to distribute due to the fact that not being able to distribute PowerPlant's source means that one cannot distribute the program.


    To remedy this problem, you are granted the following exception to the GPL: even if you are not authorized to distribute the source to PowerPlant, you may still distribute this Product, under the terms of the GPL. However, you must still make the remainder of the source available.

    This license does not excuse you from the terms of Metrowerks' license. If you do not know whether or not you are authorized to distribute the source to PowerPlant, you must assume that you are not authorized to do so unless you have received explicit written permission from Metrowerks, Inc. to distribute it.

    Now, Qt does have a pseudo-Open-Source license, and the code can be distributed (unlike PowerPlant's). This makes a Qt-style exception even easier. In fact, it would take no more than two sentences...
    As an exception to the preceding license, you are granted explicit permission to compile, link, and distribute this software with the Qt graphics toolkit. This does not excuse you from the licensing terms of the Qt toolkit, which must still be distributed per the terms of its own license.

    ...and all of the licensing isues magically vanish. It really is that simple. Why the KDE team can't swallow their pride and admit that they made a very tiny (and understandable) oversight in their choice of license is beyond me. It's not like it would be that much work; I could do it with a Perl script in five minutes, including the time it takes to write the script. They never struck me as being too arrogant to admit their mistakes; I've seen them do it in the past. If they've kept decent records, they should still have contact information for the developers, not a single one of which would refuse to make the program legally distributable.

    Honestly. This issue is so simple, and it can be resolved in a manner that leaves everyone happy, except maybe RMS. What's the big deal about?
  • Have you ever tried to maintain a Perl system? (Hint, try "perldoc Test".)

    Have you ever compared how much nicer it is to have an automated test-suite than it is to not have one?

    Trust me, any large distributed project that is used across multiple platforms can benefit from a test-suite. Making it easy to build one is a good thing. Being able to drive an interactive gui program that you may not have source for from a command line is in and of itself darned useful. (The lack of an integrated ability to be so driven during batch processing is a major drawback of most of them, and is one of the things that I dislike about having to work with stuff that was thrown together in VB.)

    OK, now that I have addressed usefulness, let me address Debian. Debian's problems would be totally resolved by this. The program would be distributed with dynamically linked against a program with no license problems. The fact that most users would actually link it to Qt after you distribute it is just fine. The GPL doesn't prevent you from doing that, it only prevents you from distributing it that way.

    Cheers,
    Ben
  • Why are you guys harping on TrollTech? Aren't the KDE guys the ones who are doing the illegal action by incorporating non-GPL compatible code? It's like sueing Sun if Linus incorporated non-GPL Solaris code into Linux.
  • by bartok ( 111886 ) on Saturday July 01, 2000 @05:28AM (#964434)
    You voice my mind exactly.

    It's KDE's developpers that the free software community should be pointing fingers at. One of the main thing advocated by the FSF is to value freedom over convenience and the GPL serves as a legal groundhold to that philosophy.

    The problem is that I'm pretty sure a lot of the KDE developpers don't grasp the difference between Free software and Open Source. Why would anyone who understand what they're dealing with choose to put oneself in such a (legal) mess?

    Unless of course you're one of the KDE developpers that work for TrollTech. Then, you know it't good for you if every developper that wants to code a GUI app to the GUI's native toolkit has to pay you if they want to develop closed source. It's really that simple yo know. You develop a desktop that depends on you proprietary software and try to make it become a standard on Linux; then you sit tight as you watch the money pouring in.

    Wait a sec. If KDE's main developper is working for TrollTech, that make them as guilty as anyone. This is just plain parasitic.

  • nasty nasty nasty this is exackly what im talking about
    Atleast I had the guts to put my nick on my post
    and im sorry if the only advantage linux
    has going for it is the gpl then it deserves to fail
    No i dont think the only advantages to linux are the gpl or I wouldnt use it
    Linux is one heck of a server os and i use it for that
    but as a desktop os it isnt ready yet
    and being an ungratefull snot
    nosed name calling pup like you
    when someone offers us something isnt going to help that at all
    Again I would like to thank all of the peaple that put thier time energy and skill into making
    linux/*bsd/qt/kde/gnu suck less:}
  • by be-fan ( 61476 ) on Saturday July 01, 2000 @05:36AM (#964436)
    Actually you forgot something else. Companies tend to produce two other good things.
    A) Best in class software. If I have the jingle for it, I am usually much better off buying commercial software because they tend to be superior products. Photoshop vs. GIMP, 3D Studio vs. Blender, Solaris vs. Linux (for my quad proc SPARC box :), Visual Studio vs. KDevelop, MSVC or Intel C/C++ vs. GCC, etc. Actually, about the only best in class Open Source software that is widely used is Apache, and maybe Samba.
    B) They tend to innovate more. I've yet to see Open Source software that really redifines a market segment or brings something new to the table. All the high profile stuff is essentially a free implementation of stuff that's been done before. KDE is a CDE-workalike. Even though its better, its still nothing new. Same thing for GIMP, Apache, KDevelop, Blender, Gnumeric, Bonobo, KParts, Konqueror. None of these things really have any new features that make you step back and go, "wow, I never expected software could do that!" Even MS induced those feelings the first time you embedded an OLE object into Word. Even something like Berlin, which is pretty nifty, doesn't have anything that's been done before.
  • OpenDOC was released to developers a few months after OLE applications were already on shelves. Unless there was another OpenDOC before the Apple on, I'm pretty sure that OLE came first. (Though IBM's SOM predated COM.)
  • Speculative indeed!

    Though your reasoning seems to be more sane in this post than in your initial one, I still fail too see how it could be too late NOW, after you've just stated "Granted this day won't come within this year, or the next,...".

    Especially since "this day" only means 55:45, according to what you said. *wonders*
  • The point is this: you're quoting one specific part of the GPL and excluding other parts. You're also *completely* excluding the terms of the QPL.
    I didn't quote the QPL because the QPL isn't the problem. The terms of the QPL are totally satisfiable under the status quo arrangement. The terms of the GPL aren't. The problem isn't that either licence is bad - it's that when the two are co-applied to binary distributions, they cause the GPL to become unsatisfiable.

    And it shouldn't surprise you that most of the arguments are directed at KDE, since it has tried from the beginning to garner as much press as possible. Making yourself a highly visible target has its consequences. (WMfinder - hmm - can't find it in Debian, can't find it in RedHat - have there been pushes to have it included in either?)

    But this argument has been beaten into the ground a thousand times before...

  • There's stuff in debian that's only used by its maintainer, and sometimes even he's only a tinkerer :-)

    Let's see... what packages in frozen-main depend on libqt2? A licq plugin... qbrew... qcad... qcam (superceded by v4l)... regexplorer... xgmod... xsidplay... that's it. 7. Wow.

    And how many of those are primarily front-ends for software someone else wrote?

    I stand by my assertion - Qt is seldom present unless (a) the system belongs to a developer targeting Qt specifically or (b) the system has KDE installed. (a) is fine (I've got Qt on a few systems myself - it's a nice library to work with) - just don't pretend that anyone except KDE advocates thinks Qt qualifies as any sort of "standard" component.

  • So they release "open source software under a licence which *RESTRICTS YOUR FREEDOM*

    It obvious that these programs are not Open Source and do not meet the OSD. So what? How is this any different from a company doing the same thing but calling it free software? I distinctly remember Microsoft calling their cost-free browser "free software".
  • Okay, you're getting very personal here. One of those programs is mine, and it is NOT a front end for anything.

    A few months ago there were dozens more Qt-2 programs. When I pointed out to the debian-legal list during one of its rounds of KDE bashing that there were several Qt-2 programs that were licensed under the GPL without Stallman's disclaimer, they were removed within the hour.

    just don't pretend that anyone except KDE advocates thinks Qt qualifies as any sort of "standard" component.

    Prediction: within the next two years Qt will replace Motif as the X toolkit of choice by commercial unix developers. Already it is used for Opera and Kylix. So how many applications is required before you give Qt gets its official imprimatur of "system library"?

    But difference does it make if its primary use is with KDE? KDE is front and center on many Linux distros. For Corel, as an example, it is a vital and necessary component. You can't even install the OS without it.
  • GPL allows linking (dynamic and static) to libraries that are not GPL compliant if they are considered a part of the OS. Hence, an application in windows that uses WIN32 API has no problems. Qt is not part of the OS on any system, not even Corel Linux.


    So it is not okay for one to link against the QT libraries, because they're not part of your system - but it's okay for them to link against, say, the Metro-X libraries? I fail to see how the X Server is in any way shape or form part of the OS, yet it is okay to link against a decidely PROPRIETARY program.
  • If I have the jingle for it, I am usually much better off buying commercial software because they tend to be superior products.
    The super-configurable Gnome panel, with its myriad applets, has been making my life easier and desktop prettier ever since October Gnome, and is further improved in Helix Gnome. Nothing it does is 'innovative' per se, but it is the best panel I've ever seen, anywhere.

    None of these things really have any new features that make you step back and go, "wow, I never expected software could do that!"
    Debian's APT is the slickest installer/updater/package-manager in the universe. I dread the thought of going back to RPM-based distributions (let alone Windows).
  • and no doubt TT will be trying hard to ensure GTKs failure, and no doubt the main way they'll do this is by making QT better and better.

    As long as they try to beat GTK by enhancing QT I am GLADE ;). This is the spirit of capitalism, competition, and this is why having both KDE and Gnome is good, as long as everybody plays fair.

  • Really, illegal is strong word for mere allegations... Besides, only a very small part of KDE code was not originally written by KDE people, so even if Debian's license interpretation were correct, it would only concern those few areas.

    It's hard to do something illegal with your own code, you know.
  • GPLv2, end of section 3, starting halfway through second-last paragraph.

    "However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary
    form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component
    itself accompanies the executable."

    Pretty clear. If the library in question is a standard part of the operating system you are designing for, you don't have to include source.
    If you are shipping the library with the GPL'd program, then you DO have to include source.

    So.. if libqt is part of Mandrake 7.1, I don't see a problem with saying that you are coding for mandrake 7.1, and that your software is designed for mandrake 7.1.

    It is a bit misleading.. it should say 'intended platform' instead of 'platform on which the software runs', as that is non-specific.

  • I could do it with a Perl script in five minutes, including the time it takes to write the script. They never struck me as being too arrogant to admit their mistakes; I've seen them do it in the past. If they've kept decent records, they should still have contact information for the developers, not a single one of which would refuse to make the program legally distributable.

    Unfortunately it's not so easy... Email addresses have the tendency to become invalid over the course of the years, and some parts of a few KDE applications originated outside the KDE development community.

    For example, I grudgingly grant explicit permission to link KSysV with Qt (grudgingly because I don't think this permission is necessary), yet I haven't seen KSysV included in Debian, yet...

  • Except, if QT is considered a standard part of the OS(and if the distribution includes it, then it is), then they are free and clear.
  • The GPL permits making proprietary derivative works, as long as they are not distributed. The big difference is that Troll Tech wants to derive revenue even from internal usage (research, internal applications). Effectively, that means that every developer at a commercial site needs to get a commercial Qt license, an expensive proposition, even if they never produce a money making product.
  • I'm under the impression that the allegations concern distribution makers distruting KDE along with Qt, which (supposedly) is illegal according to the GPL.
  • My understanding is that anyone who provides the executable would, if
    the source licenses were incompatible, be prevented from fulfilling
    the conditions on providing the source, and thus be in copyright
    violation for illegally copying the code.


    What I don't understand is how this situation can occur with open
    source software. The provider can redistribute all the different
    parts of the source under the individual licenses (which always allow
    redistribution of source), and so the recipient then has code
    necessaryto compile the code, so the licenses considered separately
    are fulfilled.


    Just because the issues are so unclear, it is legal hairsplitting. If
    it were a clear violation of the GPL, and the people who committed it
    were aware of it, then I would agree with you.


    I understand that both KDE and SuSE (along with Redhat, Slackware,
    etc.) distribute the executables, andso would be liable if any such
    liability existed.

  • by hawk ( 1151 ) <hawk@eyry.org> on Monday July 03, 2000 @09:29AM (#964465) Journal
    I am a lawyer, but this isn't legal advice. If you need legal advice, see an appropriately licensed lawyer.

    >>There is nothing illegal about writing GPLed
    >>code which uses the Qt API and libraries.

    >Writing a derived work from GPLed and QPLed
    >source is not the problem or illegal. The
    >question is wheter distributing a derived work
    >based on a GPLed application and a QPLed library
    >is.

    No, there's a question even before that--to which the answer is that "KDE is not GPL software."

    It may or may not be true that KDE has violated the GPL license of other software by including it within KDE. I don't know (and am not even interested, for that matter :)

    However, it is *not legally possible* for the authors of software to violate their own license. The general claim that "Program XXX violates the GPL" is generally nonsense--a program may violate other licenses that provide material, but the GPL is not some abstract; either it provides the terms for that piece of code, or it does not.

    In the case of KDE and several otehr purportedly GPL projects, it does not. These are a class of projects which put out code, call it GPL, but at the same time invite, implicitly or explicitly, people to modify and redistribute--in spite of relying upon (typically) libraries which are not subject to annexation by GPL software.

    The action (publication) is inconsistant with the words (GPL), and the law resolves the conflict: the actions govern, and the contract/license is "reformed" in accordance. The software is not GPL, but Quasi-GPL (QGPL).

    This doesn't necessarily solve the problem, though. For example, I mentioned above the possibility that GPL software was included in the QGPL software; this could be a problem (offhand, I don't see how it couldn't be). In fact, the various QGPL licenses may be mutually incompatible, depending upon which terms of the GPL must be tossed for each.

    Bottom line: release software with an invitation to develop and distribute, proclaiming "GPL" from the treetops, but link to a non-annexable libray, and you land in the land of QGPL, not GPL.

    Ugly? Yes. But that's life :)

    hawk, esq.

    The article seems to cleam that the distribution is legal, but that does not make it true.
  • by hawk ( 1151 )
    >There are very few OSS projects(maybe with the
    >exception of KLyx) that really revolutionize
    >their market segment.

    Klyx??? Klyx was a one-off port of a badly out of date version of lyx. It allowed multiple windows to be open at once, and cut and paste between them, but twas otherwise *very* far behind. Unless things have changed recently, there is *no* plan for another version of klyx prior to the toolkit independence of lyx (though there was initially a plan to eventually merge the two).

    however, if you s/klyx/lyx/ , I'll agree with you. I'll also point out that lyx solved the QGPL license problem :)

  • I am a lawyer, but this isn't legal advice, etc.

    Actually, even if you don't *say* so, but just *act* that way, the same thing happens.

    *However*, whether by your disclaimer or your action, you're going to have trouble including other GPL code once you do this.

    I don't agree with rms on much of anything, but, from a legal standpoint, it is *quite* usefull to have a standardized way of doing this. The only way out of this mess that I see is for the possiblity of such a clause to be included is placed in future versions of the GPL--which effectively places that clause in all GPL software, which will create new religious wars, and a fork of the GPL :)

    Currently, there are programs that have done the same thing--I wrote the LyX disclaimer, another is mentioned above, still others do it by actions. It is fare from clear that these projects can currently share code; if they all used the same disclaimer (whether mine or rms'), they could.

    hawk, esq.

  • How exactly is what I posted flamebait? Sure, I insulted an AC, but certainly with reason: his post was mere assertion apparently uninformed by reading the article. I pointed out that the article itself addressed his points.

    I'm quite willing to take moderation based on objective facts, but being modded down solely due to having expressed an unpopular opinion is a bitter pill to swallow. I know that when I moderate I take the job seriously. Generally I only mod down people whom I agree with, but whose method of posting is indelicate, for that is the only way that I can be objective.

    Insulting an AC's mental skills is hardly flamebait, esp. when his post is obviously ignorant and he has not read the article referred to.

  • I still maintain that it is *not* illegal to distribute GPL code linked against QT, provided that QT is standard on the target platform.
  • It got me thinking... Does the API itself fall under the copyright? For a while there, the Harmony project was working (If I understand things correctly) to create a GPLed library with the same API as QT. With two libraries out there each with the same API, one free and one not, that really kind of muddies the waters. I'd think you could ship object modules (Not source) even if one of the libraries was pure GPL. I wonder if Stallman ever considered this scenerio.
  • Apache is a webserver, as such, it imitates other web servers already in the market. Also, Apache is very very good at what it does, but doesn't really have any features that haven't been done before. My point about OpenSource sofware being derivative still stands. I was talking more about features than the genere of the software. Stuff like document embedding which was introduced (to the masses) via OLE and later OpenDOC, or the nifty media node features of BeOS, or the array of cool features like Intellisense in VisualC++, the great integration of desktop publishing and word processing in Word Perfect, the web integration of fireworks. All these things are new, innovative, and genuinely usefull features in products that are otherwise just an image editor, or just a word processor. The problem is, that there is very little open source software that brings these kinds of new features to the table. There are very few OSS projects (maybe with the exception of KLyx) that really revolutionize their market segment.
  • That's an interesting assertion, and in the abstract it might be possible. The GPL says:
    (Paragraph 3)

    However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

    Which leaves us with one question: On what platforms is Qt "normally distributed with [a] major component"? ATM, the only substantive reason a distribution would include Qt is so it can include KDE, which is predicated inclusion, while the GPL exception is for non-specific inclusion. There would need to be a non-trivial base of non-KDE Qt applications out there to argue that such an inclusion is non-specific.

    So your assertion does not address "the fundamental KDE problem": their target platforms do not satisfy the condition that would make them non-problematic for binary distribution.

  • At least one customer is NASA - our lab has two Qt development licences. One HUGE advantage of a commercial Qt licence is that you can use the exact same source code for Windows and *NIX, which has saved my butt several times. It also allows me to do 90% of my development work on my preferred platform (Linux), then port to NT or IRIX at the last minute.

    Even though $2000 seems like a huge amount for an individual developer, it's a drop in the bucket for a large organization.

    I view the commercial Qt licence a lot like the Cygnus commercial licence - it's a way to generate revenue so that they can continue doing what they like to do best - write code.

    If you ask me, the whole open source thing is getting way to politicized. Are we lawyers or coders?

    Cheers,
    Mark Allan

    http://ic-www.arc.nasa.gov/ic/projects/neuro/ifc /active.html
  • Arg! Okay, so, let's say you like a GPL program(let's say Program) to QT("QT"). Your binary file now has TWO licenses and TWO seperate parts. There's the Program, and there's QT. QT is not a derivitive of Program, so it doesn't have to be GPL'd. While QT functions are embedded in a statically-linked Program executable, they ARE STILL QT, and therefore are a) under the QPL, and b) not a derivative work of Program. I can distribute a statically-linked program that uses QT, so long as I say "Some parts of this binary are under the QPL, and some are under the GPL. The source for the GPL parts is available at ."

    Now, if QT was to link against a GPL'd program(NOT the same as a program linking against QT), then we'd have a problem. But QT only links against libraries that it's allowed to(ie: either LGPL or some other license is applied to the libraries).
  • I have been trying to make this point for ages -- that Qt can't be used for internal/research projects w/o paying $1500, or more, per workstation, to TrollTech.

    Very well written. I agree that it would be better to use any of the others (even give up and go MS) before using anything that depends on Qt.

    The fee for the commercial license is ridiculous. I can get a great OS, window system, window manager, thousands of programs, distribute them thoughout a company and develop on them internally for free, without releasing any code (as long as GPL licensed code is not modified).

    Add TrollTech's Qt libs and all of that grinds to a halt. The MS solution is far cheaper in such a case.
  • by Deosyne ( 92713 ) on Saturday July 01, 2000 @12:35AM (#964487)
    To quote from the editorial:

    The QPL version 2.0 will hopefully end the license discussions once and for all and get us all back to coding again.

    Not likely, Eirik. Sorry to bear bad tidings. Developers such as these try to do the right thing, but they aren't lawyers, and open source licenses still have yet to be put to the test in the courts, so nobody is really sure how they are going to stand up anyhow. Hell, GPL supporters spend gigabytes arguing over the fine points of the GPL, nevertheless other licenses. So there are no truly effective guidelines to creating an open source license, and "just use the GPL" doesn't work for everyone, nor should it have to.

    It seems as though there is a decidedly hostile atmosphere surrounding open source software; when a company decides to open the source to their code, they seem to be opening themselves up to attacks against their business practices by the OSS legions, even when they had no problems when the source was closed! Admittedly, it is a small portion of the open source supporters that do this, but they are quite vocal, and the last thing that a company needs when considering a controversial (within the business community) move like opening the source code to their software, needs is bad press associated with the decision. I am certainly glad that Trolltech was not in this position, as they were already OSS supporters, but even they, after having showed this support for several years, still get flak from the community because there license wasn't written to the critic's specifcations, as if Trolltech was going to announce tomorrow, "Ha, fuck you! We left a nice little loophole in our license, so no more damn source code for you!" Its a wonder that traditionally closed source businesses ever decide to open their source, considering the immense risk, not from hax0rs or competitiors, but from the bad press that can result from the crowing of OSS supporters! It never ceases to amaze me how a bunch of computer geeks suddenly become Harvard law professors just because the law happens to involve software. Give these folks a break, already; sure, their licenses may not be ironclad bastions of open source might, but damn, try to be cool about it! After all, they were cool enough to release the source code to their products, and they sure as hell didn't have to do that, as closed source software seems to sell just fine.

    Deo
  • by broonie ( 5807 ) on Saturday July 01, 2000 @12:48AM (#964488) Homepage
    The problem with the GPL isn't at the source level, it's in the binary. There's no concern about distributing a GPLed QT-using application in source form, but when you compile that application and try distribute the binary then that binary (which is derived from both the GPLed components and QT) you find that you can't distribute the binary and satisfy the GPL.

    Dynamic linking makes this a bit unclear (to say the least), but that's the gist of the problem.
  • 1.The Qt API is adopted as a POSIX, IEEE, or other organization which publishes standard cross-platform interfaces.

    Is Motif a POSIX or IEEE standard? (I don't really know).

    2.The Qt API is certified by the Open grou (as Motif is) or in some other way by the holder of the Unix trademark.

    Why? Why does the Open Group need to certify something as being normally distributed with Debian?

    3.The Qt library is included as a component (on distribution media) of any 4 of the following unices:

    Why four? Why not three or five? There's already at least two unices that have it (Linux and FreeBSD).

    Any of these would establish Qt as an accepted, "normally distributed" component.

    But the GPL does not have these requirements. It only talks about stuff normally distributed with the OS or major components. Like it or not, some version or another of Qt is normally distributed with Debian GNU/Linux, Corel LinuxOS, Redhat Linux, SuSE Linux, FreeBSD, NetBSD, and many others.
  • The GPL restricts distribution of a GPL program unless you can provide the entire source of the program down to virtually the OS level, including libraries and everything needed to make the program work, under terms no less restricive than the GPL, with the exception of components that are part of the operating system.

    So, for your wrapup, that's essentially what KDE does when it takes other peoples GPL code, ports it to the old-style-licensed Qt, and then distribute it. Someones property, made semi-proprietary through dependencies. That is the reason people have been rather upset.

    Troll Tech should not be flamed in any case, and this move on their part is, frankly, a lot more than they could be expected to do. All good to them for it. This will probably solve the entire issue either way.
  • Qt is a high quality GUI toolkit, well documented, and easy to use. That is a given.

    Trolltech wants everyone to use Qt instead of Motif on the pure commercial side or Gtk+ on the free software side. That is also a given.

    Trolltech wants to make money. That is also a given.

    The problem is, these goals work against each other.

    And now, for the first time, they are scared! They thought they had a big advantage over GNOME/Gtk+ five years ago (GNOME doesn't exist yet!). That advantage was in the process of being eliminated two years ago, when they released Qt under the QPL.

    The QPL was meant to kill the copycat project called the Harmony. They succeded in that.

    The QPL was also meant to somewhat blunt the rapidly maturing GNOME project. Thay failed at that miserably.

    Now that GNOME 1.2 is out and getting rave reviews, it woun't be long before more of the distributions make GNOME their default desktop.

    If that happens, Qt will lose out completely. And that is a sure thing now. They can see it. They can sense it. They have no way of slowing the trend down.

    At this stage, not even releasing Qt under the GPL will save them.

    The GPL has won another battle.

    --
    IIO
  • by Utter ( 4264 ) on Saturday July 01, 2000 @01:56AM (#964495)
    He compares Qt with Motif:
    "When we first released Qt there was already de-facto acceptance in the community that one could make GPLed programs using Motif, even before Lesstiff came along. Motif was a proprietary and non-free library with a much stricter license than Qt."

    GPL allows linking (dynamic and static) to libraries that are not GPL compliant if they are considered a part of the OS. Hence, an application in windows that uses WIN32 API has no problems. Qt is not part of the OS on any system, not even Corel Linux.

    He also seems to confuse GPL with LGPL:
    "If the GPL effectively protected a GPLed library from being used to develop proprietary software, we would allow relicensing Qt under the GPL. But, as I have said, it is not our belief that using a library is making a derivative work. "

    The LGPL license was developed to give non GPL compatible software access to GPL libraries. If a library is GPL:ed there is no way of linking (dynamic or static) with that library. E.g. the cygwin library is GPL:ed in Windows, so you can only create GPL:ed software with Cygwin.

    Having said all this, Debian could include KDE if they added a clause in KDE that allowed linking to Qt.

    This at least is my interpretation of how GPL works.

  • by jetson123 ( 13128 ) on Saturday July 01, 2000 @07:51AM (#964499)
    Whether or not QPL is compatible with the GPL is one issue, but it isn't a very important one to me or lots of other people.

    The main sticking point with the QPL is that it requires all software, even software written written for internal or research purposes, to be released, and to be released under the open source model. Troll Tech's intent is clearly to get every potential commercial user to pay for each of their developers, presumably under the assumption that commercial institutions have lots of money to spend. And at between $1500 and $2400/developer, Qt is (IMO) uncompetitively expensive.

    Unlike many other libraries, GUI libraries are complex and require a significant amount of time on the part of the programmer to learn how to use them. So, you should ask yourself: if I invest this much time in the library, what do I get back? With Qt, you commit to either contributing code to Troll Tech (under the QPL) or money (under the commercial license).

    If Qt were the only game in town, theremight be some justification for that kind of deal. But there are lots of good, free toolkits and there is no need to make such a tradeoff.

    Incidentally, similar considerations apply to GPL'ed GUI libraries. If you invest a lot of time learning a GPL'ed GUI library, you severly limit your options later with what kind of GUI programs you can write. So, I think even placing Qt under the GPL wouldn't help much given the available alternatives. At least the GPL allows internal and research use, however.

    Altogether, I doubt Qt is going to make it in the door where I work, and I wouldn't view knowledge of Qt as a big advantage when hiring. My recommendation is: learn GTK/Gnome, Tcl/Tk, wxWindows, FLTK, Java/Swing, even Motif or Win32/MFC.

  • by Carl ( 12719 ) on Saturday July 01, 2000 @07:56AM (#964500) Homepage
    > There is nothing illegal with linking GPLed code to non-GPL libraries!

    Linking is not the problem. The GPL does not restrict the use of code in any way. What it does restrict is distributing derived works based on the code. The complete derived work must be distributed under the terms of the GPL (or less restrictive terms) and that includes all parts that the program is based on. So that includes libraries.

    > As the article states, people were writing GPLed software against the uber-proprietary Motif libraries for years. Emacs made system calls on non-free OSes.

    There is a special exception in the GPL for making a work based on "anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

    > There is nothing illegal about writing GPLed code which uses the Qt API and libraries.

    Writing a derived work from GPLed and QPLed source is not the problem or illegal. The question is wheter distributing a derived work based on a GPLed application and a QPLed library is. The article seems to cleam that the distribution is legal, but that does not make it true.

    Except for the special exceptions in the GPL for system components and the exceptions that normal copyright law makes for fair use the whole program is considered a derived work and should be distributed under terms that are not more restrictive then the GPL. Since when you make a derived work from GPLed (KDE program) code and QPLed (QT library) code the complete program cannot legally be distributed without violating the GPL.

    > One keeps seeing this, and it is wrong. It is pure FUD spread by some zealots--GNOME users? GPL fanatics? who knows.

    The reason you keep seeing it is because a lot of people (including the people that wrote the GPL!) think that is intent of the GPL. The above paragraph may seem like FUD spread by a zealot to you, but that doesn't make it not true.
    (It also doesn't make it true of course, but a lot of "GNOME users" and/or "GPL fanatics" seem to think it is true. And I think that if the GPL is ever tested in court it will be shown to be the correct legal interpretation.)
  • One huge advantage of Qt is that you can target Windows and *NIX with the same source. We use it in our lab at NASA, and have no regrets at all. I do agree that Qt is a bit pricy, but we've found that the platform flexibility allowed by Qt is worth it. I evaluated wxWindows and FLTK before commiting to Qt, and although they are both quality toolkits, Qt offered more functionality, flexibility and has a (IMO) cleaner coding style.

    Unlike many other libraries, GUI libraries are complex and require a significant amount of time on the part of the programmer to learn how to use them.

    This is another big advantage of Qt: it's really, really easy to learn and use. The coding style is very similar to Java, and it leads to clean, easy to read, easy to maintain code.

    Java, unfortunately, just isn't there yet. It's not stable or fast enough for many of the things we need to do (although we do use Java for some projects). Because of the similarity of Java and Qt, many of our APIs and some of our apps will work with both toolkits, and some developers bounce between the two.

    I'm not a laywer, and really don't care to become one, but why do you think the QPL is any different to the GPL for internal use? Section 6 has this line: These items, when distributed, are subject to the following requirements: It seems to me that Qt is find to use for internal research, as long as you don't distrubute it - same as the GPL.

    In my opinion, Qt is a superior technical solution than any of the other toolkits available (free or commercial). It is expensive, but we've found it to be worth the cost on more than one occasion.

    Cheers, Mark Allan http://ic-www.arc.nasa.gov/ic/projects/neuro/ifc/a ctive.html
  • It seems as though there is a decidedly hostile atmosphere surrounding open source software; when a company decides to open the source to their code, they seem to be opening themselves up to attacks against their business practices by the OSS legions, even when they had no problems when the source was closed!

    Troll Tech is a business, and releasing Qt under the QPL isn't an act of charity, it's a business strategy. In particular, Troll Tech wants two things. First, they want bug fixes and code contributions from users. Second, they want lots of people (in particular, students) to get started using their toolkit so that when they move into companies, they'll buy the toolkit. I think it's valid to ask the question whether this is a good deal.

    While your opinion may differ, I don't think it is. There are several high quality toolkits out there without such restrictions, and where bug fixes and code benefit everybody. And Qt is so expensive that I would have serious concerns about using it even as a purely commercial toolkit.

    Just because a company dumps some source code on the world under some license doesn't make them immune from analysis. But to be clear, my view isn't that Troll Tech should change the license or that they have done anything "wrong". My view is that people should stop using Qt because it simply isn't a good deal and because there are good alternatives available.

  • Very unlikely. No-one says the QPL is not open source, the only
    complaint is that some allege it is incompatible with the GPL. If
    that is so, then it is KDE and not Trolltech who are violating the
    GPL.


    Personally I think Erik is right: there is no GPL violation involved.
    Still, I really don't understand why Trolltech don't release Qt under
    the GPL if the aim is to stop their code being used in closed-source
    products: that is precisely what the GPL is supposed to achieve.


    This is also purely legal hairsplitting. Surely no-one objects on
    moral grounds to linking two pieces of open source code together!

  • by knghtbrd ( 593 ) on Saturday July 01, 2000 @10:11AM (#964506)
    KDE's the one with license issues, not Troll Tech.

    That said, Troll Tech was in a perfect position to fix them (3-4 clauses changed in their current license would do it) but they chose not to. As soon as Red Hat agreed to ship KDE, they didn't have to worry anymore in their thoughts. The license issues aren't their problem, but they certainly do profit from nobody beliving KDE has a problem.

    Read the actual claims made by myself and some of the other Debian people. Don't rely on Slashdot histeria and rumors as to what we think the problem is. Find out what the problems really are - they're a lot simpler in nature and really very clear.

  • Now that GNOME 1.2 is out and getting rave reviews, it woun't be long before more of the distributions make GNOME their default desktop.

    I don't know about that. I'm a former member of the GNOME UI team(hi guys), and until Helixcode/Eazel signed up, I honestly didn't have much faith behind there being any real unifying elements to the desktop...we all spent so long arguing about dumb stuff like whether there should be a File menu and (the real important issue) whether GNOME should be doing something or whether that was the job of the Window Manager.

    Meanwhile, KDE was and probably still is the most integrated environment for Linux at the moment, and KDE2 is rumbling like nothing I've ever seen on the Linux platform.

    *Sigh* The sad part is that we're struggling just to get to the point where Win95 has always been... the ironic part is Konquerer :-)

    Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com
  • This isn't a hard task, read the license [gnu.org] for yourself.

    It is a far more subtle document than one would think just reading it, and sometimes it has surprising consequences. For instance here is a summary of Debian's issues with Qt [debian.org]. Can these be addressed? Yes. Are they somehow claiming that Qt is a derivative work of KDE? Nope. They are claiming that KDE is a work that cannot be distributed by the terms of its own license.

    But I think that there is a way to solve this problem for once and for all which is not discussed. Produce a GPL-friendly interface to Qt with a GPL-friendly implementation behind it. Have it support the full programming interface, but don't worry too much about it "looking nice" or usability for the end-user. Ship KDE with this and with some easy way to switch from this (bad) default to Qt. Then KDE can ship in compliance with the GPL completely separately from any license issues that Qt may have.

    Cheers,
    Ben
  • That's interesting, because I see the trend as exactly the opposite.

    About a year and a bit ago, with the then new Gimp being a flagship for GTK, things looked very good for Gnome. Then, as I saw it, there was a long period of real or perceived Gnome instability and people started looking at KDE. With KDevelop and KOffice starting to look like more than vapour, KDE seems to me to be on the ascendancy.

    TT's business model seems quite straightforward to me. They are writing software that is so good that people will pay for it. However, no matter how good it is, those paying people won't want to use it if no one else does. So, TT creates a userbase by giving it away for free beer to those who wouldn't have paid anyway. However, free beer isn't good enough, because that user base cares about free speech, so TT give it away free beer and free speech, which is still fine because those people still weren't going to pay either way. Net result, TT makes money by selling QT to those who want a very good toolkit, TT gets some OS style help in the form of patches, and TT's paying customers feel good that there are lots of other developers keeping the toolkit popular.

    And yes, GTK is a direct threat to this model, and Gnome's success is therefore a threat. This is all fine - it's a perfectly good business model, and no doubt TT will be trying hard to ensure GTKs failure, and no doubt the main way they'll do this is by making QT better and better. Sounds good to me.

  • I'm not a laywer, and really don't care to become one, but why do you think the QPL is any different to the GPL for internal use? Section 6 has this line: These items, when distributed, are subject to the following requirements: It seems to me that Qt is find to use for internal research, as long as you don't distrubute it - same as the GPL.

    If you read on, you will see that this section is actually ambiguous, since later it states that Troll Tech can always request software from you that you developed under the QPL. Furthermore, Troll Tech states in their QPL FAQ that it is the intent of their license that you must buy a commercial license even if you develop only for internal purposes.

    Companies don't like ambiguity and they won't generally risk getting dragged into some legal spat, so making the QPL ambiguous and stating their intent in the FAQ essentially ensures that most companies who want to use Qt will license it, yet to the open source community, Troll Tech will appear as if their license is "almost like" the GPL. You have to decide for yourself whether this is legal incompetence or a Machiavellian plan. The fact remains that the QPL is much more restrictive than all of the other widely used, free or open source toolkits.

    As for the quality, if you think Qt is worth the license fee, good for you. My point is that most people (including consultants, corporate developers and students) who pick Qt for development should view it as a commercial toolkit that costs between $1500 and $2400/developer, since most likely they will have to pay. Qt needs to be evaluated and compared to other toolkits on that basis. I suspect for the kind of money you are going to pay Troll Tech for all your developers, you could often already have some consultant or in-house developer do a significant amount of custom development and fix whatever shortcomings you see in one of the other toolkits.

  • Get permission from Troll to use their interface files (literally).

    Put in useless stubs for everything you don't want.

    Turn it into a scriptable toolkit, usable for writing automated tests against. Basically do for Qt-based applications what Expect does for interactive command-line applications.

    Start working on an automated test suite, similar to the one that (for instance) Perl uses.

    Cheers,
    Ben

You can be replaced by this computer.

Working...