Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

qt 2.0 released 157

Posted by Hemos from the come-and-get-it dept.
kris writes "Those funky Trolls up there north have released Version 2.0 of the Qt library. Unlike Version 1, this one is available under the QPL Open Source license, which is in compliance with the Debian Free Software Guidelines and qualifies as Open Source. Qt 2.0 also contains tons of changes and improvements, such as Unicode support, better I18N, rich text, theming and thousands of other things. You want to download their stuff to give it a try. "
This discussion has been archived. No new comments can be posted.

qt 2.0 released More

qt 2.0 released

Comments Filter:

  • Peace, brother... (Score:1)

    by Anonymous Coward
    Don't start that nasty bickering again.

    Pixmap themes: Will be compatible (Mosfet working on that)
    As for more advanced theme engines: Qt/KDE styles offer more control and flexibility than gtk, e.g. the geometry of sliders etc (AFAIK gtk slider 'grips' have to be symmetrical or even in the middle).
    But as few themes really use even the capabilities gtk offers, this will probably not be of high importance.

    Drag and Drop:
    In reality, GTK+ (and therefore GNOME) supported as many DnD standards as possible, while KDE decided to go it alone.
    Nonsense, similar to the "WM independent" stuff.
    KDE uses the Offix protocol (developed for this 'oddice suite'), Gnome/gtk another exotic one,XND IIRC.
    Why didn't they use Motif DnD? Because it sucks: much too complicated, yet not powerful.

    Gnome implemented Motif DnD for compatibility (mainly with Netscape) later, and recently it seems to work properly.
    In KDE there is currently somebody implementing Motif DnD (for Empath?), and this may go into KDE 2 as well. So much for being liberal.

    But the new XDnD protocol is a real chance for Unix/X, and should be taken.

    And BTW, "parity with GTK+"? For theming, perhaps, but for the rest, gtk still has to do some homework...

    B/A

  • It's not there, this is FUD (Score:1)

    by Anonymous Coward
    Of course you can distribute modified versions.

  • KDE release based on Qt2.0 (Score:4)

    by Anonymous Coward on Friday June 25, 1999 @03:40AM (#1833761)
    The KDE Team tries to have a developers release
    of KDE based on Qt2.0 out by the end of this summer.

    A stable KDE release based on Qt2.0 can be
    expected in the first quarter of '00.

    Those who don't mind hacking a bit themselves
    can of course always have a look at the
    tgz-snapshots or follow KDE development from
    day to day via CVSup.

    KDE development has been based on beta versions
    of Qt 2.0 for some time already. As of today
    all development will be based on the released
    version of Qt2.0.

    Cheers,
    Waldo Bastian
    bastian@kde.org

  • Don't give up on Harmony just yet. (Score:4)

    by Anonymous Coward on Friday June 25, 1999 @03:55AM (#1833762)
    Sorry about the AC, I'm at work and going through a proxy, so I can't telnet to my machine to get my password.

    I've read the QPL. I do like some of it's ideas. First and foremost the requirement that the Free Edition is limited to use with the X Window system is a wonderful idea. But it seems like Troll Tech wants to force requirements on people that it isn't willing to undertake itself. For instance, the QPL states that the author of programs using the QPL has to allow others to make modifications to their programs and they have to allow others to redistribute the modified version of their program. This all sounds well and good, but Troll Tech isn't willing to submit to the same restrictions. Specifically with regards to QT:

    people are forbidden from distributing modified versions of QT,

    and their programs can't require a user to make changes to QT.

    So, while the license is somewhat better, it ain't the GPL (any version); and I still have hope for the Harmony Project.

    _____
    It's ironic that Microsoft's goal is to write good software and Linux's goal is world domination.

  • 'stuff' URL (Score:3)

    by DeadBeef ( 15 ) on Friday June 25, 1999 @03:53AM (#1833763) Homepage
    It appears that the 'stuff' url on the short description should be ftp://ftp.troll.no/qt/source/qt-2.00.ta r.gz [troll.no]
  • Sounds great. What's the story with KDE's licensing?

    I understand that the libraries are LGPL (which appears to me to work fine with the QPL). I have been told that some but not all of the programs are Artistic, and some programs are still GPLed . How do I find out which programs are which? The FAQ still says that everything is GPLed. I'm mostly interested in the licensing of the core apps: kwm, kpanel, kfm, etc.

    Disclaimer: I'm not looking to flame anybody, or to get flamed, I just want to know which things are covered by which licenses.
  • I'm guessing there are at least a hundred, and possibly as many as a thousand KDE contributers, and wouldn't all of them have to agree to have their segments relicenced? If i'm correct that would be one hell of a hard task, especially knowing how many GPL purists there are.(i'm not a real fan myself)
  • For any distribution that includes KDE, could QT be considered a "system library" (or whatever the term is)? That would resolve the GPL problem, no?

    This is important to me, as I'm devloping some free software and am at the point where I need to choose a toolkit. I'd like to release under GPL, and I'd like to use QT, as it is the most "C++" toolkit I've found (wxWindows is not _quite_ as nice, IMHO).

  • Okay, I'm not going to speak in any official capacity here, but after all the conversations I've read on debian-devel and the #Debian IRC channel, here's the situation as I see it:

    Debian does not and will not immediately include KDE, even with the release of the DFSG-free Qt 2.0, because KDE's license, namely the GPL, does not allow linking with libraries with licenses other than the GPL.

    The GPL also includes this clause:

    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.

    The problem with this is that if KDE and Qt 2.0 are both put into main, then the second part of this clause ("unless that component itself accompanies the executable") comes into effect. I'm not sure exactly about what happens if KDE is put into another section, but then, I'm sure that's been discussed also, and anyway, if it were in another section, it wouldn't be part of the official Debian distribution, anyway.

    So one of the following has to happen, I believe, before KDE can be included:

    1. KDE is relicensed with a clause that says it can be linked with Qt
    2. Qt is released under the GPL
    3. The GPL is modified to allow linkage to DFSG-free libraries

    I believe 3 has been looked at, and been decided against. I believe that Joseph Carter is working with KDE to resolve that part of the problem, and if they is successful, then it will be included.

    Anyway, if I'm wrong in any way, I'm sure someone will correct me... this is just as I understand it.

  • What is cited above was the original Qt v1.x "Free edition" license. Qt v2.0 uses the QPL, a real honest to gods free software license. Trust me on this one, I knew what I was doing. The QPL can be found at http://www.troll.no/qpl [troll.no] and has been determined to be free software by Debian, OSI, and Richard Stallman. If you believe that we're all wrong you're not required to use it naturally.

    However while the QPL is in fact a free license, it is not compatible with the GPL used by KDE. Of course, it's not the first free license to have this problem---the BSD license isn't compatible with the GPL either. I tried to make the QPL compatible with the GPL, but the methods I was able to offer them for this compatibility would have left them open to things such as immediate forks made just to spite them. Before the final license was published, I was was convinced their fears were not in the least unfounded. Fortunately the fires have cooled a bit now and hopefully in the future they won't have anything to fear from a GPL compatible Qt if not directly a GPL'd Qt. Time will tell.

    In the meantime, there are two options which I see available to actually solve the compatibility issue:

    1. Extra permission in addition to the GPL - A clause can be added to the license of KDE by its Copyright holders. Note for borrowed code from other programs not written by KDE, someone will have to contact the appropriate Copyright holders and make arrangements with them to use the portions of code required with this exception. As this is likely to be required still, my offer to assist with this stands.
    2. KDE under a different license - The KDE team has expressed some complaints about the GPL as a license. It's not very short and simple and I swear if I gave three people a paragraph from the GPL, I'd get at least four interpretations back (granted, at least two of them are likely to not make much sense, but that's a seperate issue..) To address their concerns, a new license can be written. In fact I'm working on such a license when I've got the patience for it (the heat's getting to me of late) and will post a draft of the license to the debian-legal mailing list as soon as I have something worth posting. This still means that people whose code is being used by KDE must still be consulted for permission to use their code either under this license or under GPL+permission for Qt as above.

    If you are looking for the best way to grant permission to a GPL program, feel free to email me.

  • I have worked with them on this before, but have not been working at it with them actively lately. Mostly it's my fault---I was supposed to get back with people after I had a draft license and I still don't have one. I'll probably work on it tomorrow. I think they'll like the license I've got in my head, but I've got to put it in writing first. =p
  • It's not something they really want to spend their time on.. They'd rather code. And yes some of them still don't see the problem. Many of them do however at least realize that something can be done and therefore should be. So people like me end up being crazy enough to offer to help.
  • You miss a very subtle point.. GTK is LGPL, not GPL. LGPL is not "anti-social" the way the GPL is. GPL fans please don't take that as offensive, it's not meant to be. I just can't think of a better way to describe what in a number of cases is a very useful feature, but in others is most decidedly a misfeature.
  • The XFree License allows you to GPL the X server. I'm not kidding, you just add the GPL to the top of a list of other copyright notices and call it good because the license allows you to do so. This satisfies the GPL. Sick, isn't it? =D I've come to the decision that Copyright law is perverse.
  • Minor nit... Commercial apps can be made freely. Proprietary ones cannot. You're equating the two simply because people usually want you to equate them so you don't expect source for the app you just paid for. Don't do that, you'll be giving them what they want. =>
  • First, I openly admit I am a free software fanatic (not necessarily a GPL fanatic..) I went into the QPL thing as this and everybody involved knew that my priority was free software. However, I STILL got tons of hate mail personally for my work. And what's worse, I'm still getting it today. When you say they got hate mail, you are not at all kidding. I got a small taste of what they have gotten and will likely continue to get.

    It's a shame too because it's possible that at some point in the future, the GPL would make an excellent license for Qt. I'm not going to lose hope in the Qt license becoming GPL compatible at some point, however I'm pretty certain they won't put Qt under the GPL itself. Perhaps in time Troll Tech may consider the license I've been working on and plan to present to kde-licensing and debian-legal RSN for opinions and other hashings.. I'm going to make the license not specific to KDE at all because I really believe other people are likely to find the licence more suitable to them than the GPL for a number of projects. Protection of the software is going to be a focus of the license (much like the GPL), however I think the results will be more "social". It will be compatible with the current QPL and pretty much any DFSG/OSD compliant license for that matter. This is a design goal.

    hmmm, perhaps I should quit typing about the damned thing and finish writing it? =D

  • Hiya JHM..

    Unfortunately no, at the time I couldn't come up with a way to make the thing GPL compatible and still protect KDE from malicious action that a number of people were threatening. Right now I want to work on the KDE license since there is still a real legal issue left to hash out. I'm trying to address this with a new license since the KDE team is about as happy with the GPL at this point as Troll Tech is, for much the same reasons. They'll undoubtedly be happier with the license I'm working on when it's finished. If it works out well and we can't blow any large holes in it, perhaps Troll Tech may be able to be convinced to adopt the license. I'm not going to push for that now though, it's their call. Qt is now free and I'm personally satisfied with that. GPL compatibility would be nice, but I want to be sure that the license is going to be successful first. I also want the legal issue to be settled and have been settled awhile first.

    To be quite honest, if Troll Tech starts considering a new license which is GPL compatible, I will advise against it if I'm still getting mail like I have been over the past six months. Hostile, not infreqnetly threatening, usually riddled with poor spelling and grammar, and just plain obnoxious hate mail. And this for working damned hard to take a piece of non-free software and give it a free license. More than once I've been accused of compromising the ideals of free software because I couldn't live without something that worked like windoze...

    For the record, I don't even use or like KDE. I am just happy with my console and screen. X is a waste of resources and a desktop environment more so. So then why am I doing it? Because free software is important to me. And because I'm sick of the ritual flamefests on the subjects to the lists.

  • Depends. Anyone who has made significant contribution to KDE should be heard on the subject certainly. The person who fixed a typo can't exactly claim Copyright since they don't actually have any claim to original work as part of the whole. Those part of the KDE project aren't so much the worry as those outside the project whose code was used. Arguably anyone who contributed to KDE directly has pretty much given their consent for the code to be used with Qt simply because they did so knowing that's what would be done with their code. Those who didn't directly contribute to KDE need to be consulted more specifically however. And any of them who come back and say they don't want their code in KDE... Well, if that happens, KDE will have to remove their code and rewrite their own in its place. This could be a minor nuisance or a real PITA depending on what happens. Won't know till people start getting asked and giving their answers will we?
  • It will happen. If I have to contact just about all of them myself, they will be consulted. Particularly those whose code was simply borrowed and used for KDE.
  • Consider it this way ... Anyone who can get a binary of a GPL program has to be able to get the source. If nobody other than those in-house can get the binaries, nobody except those in-house need to be given access to the source.

    I think the provision in the QPL preventing this is quite deliberate. It didn't occour to me at the time that Troll Tech would have wanted it this way for a reason, but I probably wouldn't have been too quick to change it if I had realized---especially given that you still can do in-house software with Qt freely, but if Troll Tech asks for the source you have the provide it. If your code is that secret that you aren't willing to give it out, it's essentially proprietary IMO and Troll Tech doesn't want you using Qt to write anything proprietary without paying for it. The license I'm working on for KDE will be more GPL-like on this matter and will allow you to develop in-house software without distributing it. Of course you'll still be bound by the QPL's requirement that you publish source if Troll Tech asks for it.

  • Don't I wish! You have any idea how much headache I would be spared if this were the case!? Eesh! No, the system library thing only applies if you're not distributing the thing with the library in question. Debian distributing KDE and Qt together in main makes that clause not apply. Even then it's a badly worded clause and I don't like it much. I've pleaded with RMS to rewrite it for the sake of clarity and sanity in the GPL v3. Hope he listened.
  • Oh, we can include Qt now as part of the system sure... However we couldn't distribute KDE ALSO as part of the system. Kinda annoying, that. I've no intention of giving up getting both Qt and KDE into main just yet, however. Qt 2.0 can go into main anytime now. KDE needs more work. When I'm done with the work in question (may take a few months before EVERYTHING is done), if one cannot get a KDE built for Qt 2.x, I'll try to convince Troll Tech to QPL the latest 1.x version for us. =>
  • I certainly hope they are going to get permission for this license change from all the people who have contributed code to KDE, or else remove that person's code. Changing the license on somebody else's code without their permission is a definite no-no.
  • As the KDE team is made up of volunteers, they don't have a scheduled release date, AFAIK. I've played with the stuff on CVS recently, though, and my (un)educated guess would be late this year or early next year for KDE 2.0.

    It really is shaping up to be a nice package. Already, at pre-alpha stage, you can see the vast improvement of konqueror over kfm. When you pick up an item in the current kfm, there is a noticeable delay, and some disk thrashing. When you pick up an konqueror object, *bang*, you have it immediately. The drag-and-drop should be very fast and smooth.

    Currently, most things compile (the switch from Qt 1.4x to 2.x caused a bit of a setback in this regard, but it of course had to be done some time). I believe the current thought is to bundle KOffice [kde.org] with KDE 2.0. KOffice is shaping up to be a commercial-grade office productivity suite. KWord looks very, very nice, and should have most, if not all, of the functionality of the big boys (plus DTP functionality). KPresenter is a presentation program vis-a-vis PowerPoint. KIllustrator is a Corel Draw-type vector graphics program. There are a number of other smaller programs in there. The only thing that probably is a bit feature-starved (from my brief perusal of it) would be KSpread, the spreadsheet program. It's fairly simple, and doesn't have all the doo-dads of Excel or StarCalc.

    All in all, KDE 2.0 will be a fantastic Unix desktop environment! As a subscriber to kde-devel, I can tell you that the KDE developers are serious about avoiding bloat whereever possible, and creating a desktop that anyone can use, not just programmers and/or sysadmins.

    While a lot of people gripe about Microsoft's dominance, the KDE team, rather than complain, are doing something about it. KDE 2.0 (as well as GNOME) will definitely make Linux and Unix a desktop contender for the masses. And with the price advantage, I predict it will start putting the hurt on Microsoft's market share.

    Needless, to say, I see it as a good thing. :-)

    --

  • Sometimes you just want to (must to) write some commercial software and then QT just isn't the option.

    Pardon me, but this seems *extremely* hypocritical. You want to write binary-only software (presumably for pay), and you criticize Troll for wanting you to pay them for their software.

    Despite its flaws, that is probably the best thing about the QPL; it discourages closed software, and makes those who would write closed software pay for the privilege. For that reason, I like it better than the LGPL (but I still prefer plain old GPL).

    --

  • >This assumption is generally done by people who do not know the effects of using bad OO techniques such as templates (just look at what it does to your cache)

    What the Sam Hill do templates have to do with your cache? A template in C++ is essentially a super, type-checked macro with the ability of specializations for specific data types. It can and should be compiled to as efficient code as non-templated stuff. (In the variants of Java with templates, the template handling is basically done as a pre-process.) The only cost, if the compiler/linker is competent, is to the programmer in terms of extra link time to eliminate duplicate template function instantiations.

    >operator overloading

    Can be wonderful. Can also be misused, but so can many other things.
  • >Look at the code it generates then.

    That's rather like slamming the internal combustion engine because Yugos are crap. If no compiler handles templates well, then that means it's a feature ahead of its time, not that it is inherently awful.
  • I wondered at first why the GPL was written this way, but I've realized that it's because RMS didn't want people distributing his software along with their proprietary operating systems.
    I don't think this is the intent or effect of this clause. This is how I read it:

    To allow portability to non-free operating systems, operating system-specific libraries can be linked against the program even though that would otherwise violate the GPL.

    However, this is "unless that component itself accompanies the executable." I read this to say (and intend) that you not use this to justify taking some OS library and distributing it with the program. Like if some company made a GPL program dependant on their library (which they normally included with their OS), then distributed this GPLed program with their library, making the program only useful if you have the (proprietary) library.

    This would be a way of coopting the GPL, since while a portion of the program would be free the actual working program would not be free.

    This is actually very much what KDE did with Qt, trying to get a proprietary library in the back door (so to speak). It becomes more subtle with Qt 2.0, as the program is no longer less free because of its association with Qt (well, not much less free), but it is less GPLed, and the GPL doesn't make a distinction between non-free and non-GPL. (trying to make that distinction in the license would make it terribly unwieldy and vague)

    These license incompatibilities all risks diluting the GPL and the collection of GPLed software. A minimal number of licenses makes for a much more powerful set of free software.

  • I didn't mean to imply KDE was being sinister. I do think that Troll Tech's Qt1 licensing was boarding on the sinister -- but only by free software standards. By business standards what they were doing was fairly normal. KDE was seduced by their offer, which wasn't great of them, but certainly not evil of them. Their ultimate motivations were noble.

    RMS/FSF/GNU did think about this before, however. The widget thing has been a problem for a while, and until GTK there wasn't much of a solution. Xawe was the only free widget set, and Xawe is not exactly pretty or full-featured. (GNU) Emacs used it anyway, however, because that's all there was.

    But many free applications used Motif, another non-free widget library. And many of those applications used static linking as well, which quite clearly violates the GPL. But no one did anything, because the alternative was no GUI at all. KDE people would often point to this because they thought there was a hypocracy in persecuting their use in Qt. They had a point.

    Oh, and you can include gcc in your homemade OS. It's not uncommon. You can include any GPLed program. Many OSes already do. I think the qualification in the GPL is meant to keep you from including the OS with the program, not the other way around.

  • I'd really like to see Qt become more of an application framework rather than just a widget set. When working on a Qt project, I got very caught up in just getting a good solid framework created. I still have hardly even started on the project.

    (I'm not the type of coder to just bang out code, it's got to be done right.)

    Seems like the only free framework we've really got is wxWindows and, while not bad, there are a lot of things I don't like about it.
  • Well, I'm having problems getting Qt to even compile. I've got an Alpha Tru64 workstation, but the main problem is with egcs/gcc (--version='egcs-2.91.66'). It has problems with the QString class. It warns of an implicit declaration for va_start on line 10922, and then procedes to report a bunch of parse errors. Any ideas?
  • You *do* run Red Hat, don't you?

    No. But how arrogant of you...
  • Did I use Gnome 1.0? Nope. Matter of fact, I didn't pick up Gnome till about 1.0.6 or so.

    As for Qt getting out of beta, there's one thing. Lots of people don't use betas very much, but everyone immediately grabs for the 1.0 releases. It's as though your testing pool suddenly quintupled. THey'll find bugs you missed the first time, guaranteed. Even the Linux kernel isn't immune to this; if I remember correctly 2.2.1 came out only a day after 2.2.
  • Actually, they still count as themes.

    As I understand it, a "theme" is simply one "look" which can be set once such that all apps which support that theme style will then use it.

    For GTK, these are Default, Redmond95, Notif, and Pixmap.

    This also means that the "themes" we commonly see at gtk.themes.org are, strictly speaking, usually not themes in the strictest sense of the word; rather they are configurations of the Pixmap theme plus the necessary graphics to make the configuration run. I suppose "skin" would be a better term for those types of themes: a GUI widget configuration for one program, which in this case is the Pixmap theme. Because that program is itself a theme, Pixmap skins act like themes.

    "Themes" sound cooler than "skins" anyway :)
  • Actually, it's another abuse of the patent system. This one is called a "design patent" and it really does simply put a patent on look and feel. Apple's got loads of them, including Platinum, Hi-Tech, Gizmo, Drawing Board (I think), and loads of others that no one really knows why they have since even Apple doesn't use them.

    If I could remember the patent numbers I'd post links to them. In any case, I'd imaging M$ has patents on the look and feel of Win95 and 98 too (though why would you want to patent such bad stuff?)

    Either way, you're discounting the possibility that perhaps they licensed the looks from Apple and M$. Unlikely, to be sure, but possible (little-known fact: Apple actually had purchased licenses for all the GUI stuff they took from Xerox. M$ did not have licenses for what it took from Apple).

    Anyway, that's the thing there. Troll might get sued for it. Then again, I don't think either Apple or M$ will bother to do it.

  • Interesting... (Score:3)

    by Millennium ( 2451 ) on Friday June 25, 1999 @03:28AM (#1833795)
    I won't be downloading it (not because of any GTK zealotry; I'm waiting for 2.0.1 and all the inevitable bug fixes the Troll guys missed). Besides, I have a few questions concerning themes:

    1) How compatible are the themes with those from GTK (at least for pixmap-based themes; I know the engine-based themes have no hope of compatibility)? It'd be nice if I could use the same theme for all my apps, and since work on Qt's themes didn't even start until after GTK's was cemented the only reason to make them incompatible is for incompatibility's sake.

    2) Assume that GTK and Qt themes are incompatible (which is likely, unfortunately). How easy is it to convert the themes between toolkits? Might we be seeing a program in the future to do this?

    3) Suppose the second isn't possible. Might it be possible for either toolkit to eventually gain the ability to read in the other's theme format?

    As you can see, my biggest concern is interoperability between the two. While I don't have any Qt/KDE apps (never saw the need for any of the current batch, again I don't consider myself a zealot) it'd really be nice to use them seamlessly with GTK/Gnome apps (this is also why I'm pushing for a common desktop API which both KDE and Gnome could support, so a developer could write the code once and support both DE's. XDND is a start, but drag-and-drop isn't the only thing which needs the help a common API gives).
  • Well even if it wasnt it could have been included in non-free couldnt it?

    Actually contrib is the place for free-but-depending-on-non-free software.

    I thought the problem was the lackluster linking of KDE stuff against GPL'd stuff?

    The core problem is the interaction between Qt's license and KDE's (GPLed). It can be solved by changing KDE's license, but that will mean replacing the third-party GPLed code in KDE, or getting it relicensed, which may prove difficult.

    And I do remember reading that the QPL although it does conform to the Debian Free Software Guidelines is still not compatible with GPL.

    Indeed. Essentially, the GPL requires that code linked to by a GPL-ed piece of software be under the GPL or under a license that imposes no more restrictions than the GPL (like public domain, the MIT license, or BSD without the ad clause), except when that code is part of a major system component (something like a proprietary Motif or C library in an environment where they're always present (think Motif on SUN)).

    X doesn't qualify as such a component (you can have a perfectly working Linux system without it, and X is not part of all distributions), so Qt, a layer over X, doesn't either. And Qt's license, now the QPL, imposes more restrictions than the GPL (e.g. the "patch requirement" that modified versions may only be distributed as original code + separate modifications).

  • Can KDE now be included again in the debian distribution?

    No. Qt can (and will) however now be included in Debian proper ("main"), rather than being available in "non-free".

    Or are the licensing concerns still as valid as they ever were?

    The licensing concerns [debian.org] are that Qt's license is incompatible with KDE's (GPL). This has regrettably not changed with the QPL [troll.no]. Knghtbrd [slashdot.org], one of Debian's developers, provided a lot of input to Troll Tech regarding the QPL, but they couldn't be convinced to make the QPL GPL-compatible.

    If the licensing issue had been about Qt1's non-freeness by itself, KDE could simply be in the "contrib" section. But the licensing issue is an interaction between licenses that prevents us from redistributing KDE binaries.

    Luckily, there are strong indications that the KDE developers will be changing KDE's license to one that does not interact badly with the QPL (e.g. an Artistic-like license); once that happens, KDE can go in Debian proper.

    What Qt 2 being free means to Debian is that Qt itself will now become a part of Debian proper, and that Qt-using software that doesn't suffer from the licensing issue (e.g. like pi-address [in-berlin.de], which is GPL + exception clause) can go in Debian.

  • >First and foremost the requirement that the Free
    >Edition is limited to use with the X Window
    >system is a wonderful idea.

    No offense, but I think that that is a terrible idea. I'm contemplating a gui-based open source project and the ability to have a windows version would be a big plus.

    However, I was under the impression that the free-on-X-only requirement did not apply to version 2.0. The QPL says nothing about platform at all, and the QPL is the license for Qt 2. Am I missing something?

  • Im currently using matching E and GTK themes. The 'looks-cool' factor is very important for me and Ive tolerated the sluggishness that comes with it so far. However, I cant help but wonder why the hell these simple graphics take so damn long to draw. Its not like were doing dozens of layers of alpha blending or animated fractal generated height map rendering with environment mapping and specular highlighting from multiple colour animating, moving lightsources. Actually, I feel my P2-400 should manage that just fine. It can certainly scale and display a few pixmaps faster than this.

    I should stop whining and do something about it. Too bad I'm such a lazy sob :-)
    --

  • I haven't actually read the QPL yet, however, it sounds like it is compliant with the Debian Free Software Guidelines (and therefore, the Open Source Definition), so I don't see why not.
  • Gee, I was just about to point out that we finally managed to get through a single Qt thread without belittling the Gtk-- project. But the I found this. (BTW I believe wxWindows has been arround for even longer that gtk+, it is just the Gtk wrapper which is new.)

    If you feel that Gtk-- is immature and poor, why don't you stop by and help mature it. We are currently in a major overhaul mode which makes much of our code autogenerated (improving the maintainablity which is the downfall of so many wrappers.) We are reintegrating it with the recently released libsigc++ [ucdavis.edu] library, which is a very modern C++ callback frame. It can use a lot of grunt work converting over procedures and improving the code generator.

    If you can't see that the underlying language that the code is written in is irrelevent (if though is given how to make wrappers easily), then I don't see what will convince you. By the way much of the berlin code I have looked at is wrappers on the C OpenGL API. So saying things that use C are inferior hits a lot more than you know.

    --Karl Nelson

  • The question has never been about the intent of the KDE authors. They always intended to distribute with Qt regardless of the license. And the only way that could really work is if they put a waver in the license. (RMS said several times that the system library clause was meant for propriatary libraries on propriatary systems, not for distributing propriatary libraries on free systems!)

    Thus if the KDE folks added a waver to their license everything would be fine. There in lies the problem. They can't add that waver because they don't own all the code. The borrowed some of their basic starting code from other GPL projects and linked it to Qt (which is illegal.)

    There is only two ways to clean up this mess. Remove the others code, or ask permission from the authors which they took it from. Personally, I don't see why they don't do this. It can't be all that insurmountable task if someone put their mind to it. (However, some of them feel it is a none issue so they just ignore it.)

    --Karl

  • I hadn't heard that RMS was now saying that they couldn't add an ammendment to the license. I will have to look it up.

    As for dealing with modified licenses, I would look at the libraries that come with the gcc compiler. A large number of them are under the GPL (not LGPL) with the exception that they can be used with the propriatary software. The way this works (to my understanding) is that for anything other than what the extension covers it falls back to standard GPL. This would be a sensable addition to the KDE library. Thus combining KDE code (without Qt goes to GPL.) If you want to combine new GPL code into KDE, you must ask to extend the license. As a programmer, I would perfer to be asked to extend my license. Just as I am sure if Windows spliced windows code they released under some non-GPL license got spliced in.

    If they don't want to rush, I understand, but the least they can do is to mark those things in dispute as such and add the waver to the rest, so this whole silly issue it at least making progress. (From what I have seen of RMS, I don't think he is going to declared Qt a system library and resolve the issue. Then again I could be wrong.)

    (I am also pleased they dropped the patch requirement.)

    --Karl

  • Where in my message did I say "our software stinks " -- IT DOESN'T. I said if the user dislikes the other so much and feels ours needs improving, why doesn't he come to help. Obviously, any distiction is lost on you.

    Second, we have a large number of users so obviously it does stink all that much. The reason for writing free software is in general dissatisaction with what is currently available, something the first author was obviously expressing. Or because writting code is fun and enjoyable hobby, certainly that is my reason. Or perhaps that not everyone is going to stop using gtk+ tomorrow and some people would just as well use C++ with the gnome framework.

    Personally, I find the Qt signal system to be poor compaired to what is possible. It lacks the flexibly of a full callback system and requires a code generator to parse the code. Both of which are definite drawbacks. And if you for some reason think that I don't know what I am talking about go visit my comparison [ucdavis.edu] between Qt's signal system and my own. Qt's system may be nice but one can do far better. (Of course one peice does not the whole make.) They can certainly turn arround tomorrow and use libsigc++ in Qt, of course that only proves my point that people should always be working on alternatives.

    --Karl

  • The *authors* think gtk-- is not ideal for C++

    Who? I am one of the main authors, go look on the authors pages. If you are referring to Guillaume Laurent comments, I suggest you go back and reread. He said that all wrappers have problems with maintainablity and that they don't solve all the problems. Neither of these imply the Gtk-- can't be a good C++ widget set. Only that there are problems that must be addressed.

    Signal/Slots are just a tiny little part of a GUI toolkit.

    Huh, whenever someone points out the great features of Qt they always place the signal/slot mechanism as one most the important features. I consider the intergration of printing and drawing systems to be a close second. The fact that I call my system a callback framework insulted some of the KDE developers. (Signal is too overloaded already.) So it is a very important piece. Without signal/slots most of the ease of use goes out the window.

    As far as all these users, how many real apps are written in Gtk--?

    As with any free kit, who knows! Unless people mail you saying we use this or place that fact prominently on their web site, there is no way to know. Since I released the libsigc++, I have only now discovered that 4 projects were using the old Gtk-- signal system (without Gtk--) in their projects. Had they not mailed me with comments, I would likely have never known unless I sat down to compile one of them.

    Do you seriously think that all projects which compete with a more mature product are a waste of time?

    --Karl

  • Boy, we really pulled the zealots out of the woodwork today!

    First of all just because A exists doesn't mean that B is {useless, unjustified, worthless, ...}. There is always room for two competing products. Without such competition progess slows and stagnates (refer to Microsoft). Saying "GNOME works, there is no justification for KDE anymore" is exactly the same logic that someone used to tell me that Gtk-- wasn't needed because Qt existed. Qt does not exclude gtk+, KDE does exclude GNOME. There can be coexistance.

    Second, templates can be used as a strength to make code much, much better. On the other hand it can be used to blow both legs clean off. It can produce faster and smaller code then C. On the other hand one can produce large, slower more bloated code with it. Does that mean it is bad? No. The irony of this is that gtk+ uses macros like templates more that Qt uses templates at all! (there are only 16 templates in all of Qt.)

    --Karl

  • I'm wondering when the new KDE will be released, now that QT is out. Also, what new features will it have?

  • AFAIK KDE won't allow pixmap themes ... to me this is no great loss, they are too slow anyway. Mostly the pixmap themes just serve to give Gnome a rep for being slow (and most are very poorly thought out, with black text on dark backgrounds)
  • Read the page at [troll.no]
    http://www.troll.no/changes/2.0.html. It is not binary compatable. You must recompile Qt programs for use with 2.0. It is not 100% source code compatable; some things have changed.


  • What would be the point of booting into Windows to use the scroll wheel when you'd be using different programs anyway? Duh!
  • I don't think this is pixmap themes in the GTK sense. If I remember correctly, all themes are implemented using a dynamic library via virtual functions. These libraries can use pixmaps themselves if they wish. Correct me if I'm wrong on this, it was a while since I read it.
  • Then you get to choose from Mac(Platinum), Windows, Motif, and CDE.

    Thank God for themes then ;)
  • That's excellent. (although gtk+ pixmap themes are slower then slow, even on accelortated X / fairly fast machine).

    Personally, I agree theme engines are the future, since they are flexable and fast. In GNOME I reguluarly use Ice Theme or the GTKstep theme, just because these theme engines are fast.

    Speed and snappiness (looks nice), is a important aspect to get new users to fall in love with Linux.

    I am extermely excitied about Qt 2.0, just because the technology is cool and, Qt has reputation of being a solid good toolkit.

    And, I am also looking at GTK 2.0, that should have some great improvements too.

    Qt really has a strong and brigth future, with commerical developers helping to pay for it's improvements, and free (freedom, not price) developers, who make wonderful applications like KDE or KOffice.
  • Qt has it good points and bad ones, as does Gtk+.

    In my experience GTK+ unthemed runs circles around Qt (in speed) on an unaccelorated X Server.

    The new Qt 2.0 and Qt 1.44 are catching up on speed.

    GTK+ has the advantage that it's LGPL, so it can be used cheaper for commerical closed source apps. It also is more flexable at certain things (gnome tear off is great).

    Qt 2.0 licensing scheme encourages people to consider GPLing raditional shareware applications (a good thing, IMHO, since most shareware is crap, and it could be easily improved / intergrated into other programs). It also allows to develop commerical apps linked to it, for a 15 hunderd dollar license (for commerical developers). This price isn't bad if you are big company or were planing to develop for NT. (Stuff required for developing for NT is much more then 15 hunderd dollars a work station).

    It's pretty reasonable. Of course for shareware developers, or low-cost program developers they can always use GTK+, as did SheepShaver.
  • Don't worry about it, Ivan E. Moore II has a great selection [tdyc.com] of apt-get'able KDE packages:

    http://kde.tdyc.com/Debian/ [tdyc.com]
  • People please read http://www.troll.no/qpl/plaintext.txt and see the truth for yourself. The QPL is a very simple license. It is the simplest license I have ever read, it is much simpler than the GPL. It is simpler than many postings here on slashdot, it is simpler than this posting. It is in plain english. You will understand it much better by reading it than by reading postings here.

    people are forbidden from distributing modified versions of QT
    No, no, no, no! I can't believe this crap has been ranked up. It is so blatantly false. Did you read the wrong license? Please follow my link.

    Firstly distribution takes place as one of two forms either distribution of binaries or distribution of source code.

    Clause 4 (of 6) allows you to distribute binaries of modified versions of QT under the following 3 conditions
    a) You must include the license document.
    b) You must make the source code available.
    c) You must place all your modifications under the same license (the QPL).

    Note that the distribution of binaries under the QPL protects your freedoms better than the GPL does, because the QPL contains no "privacy loophole".

    Clauses 2 and 3 (of 6) allows you to distribute modified versions of the source code. Clause 2 allows me checkout the original QT from any CVS repository (or copy it off any CD). Clause 3 allows me to CVS update (or apply a patch script on a tar file of modifications) to update to a modified version of QT (source code).

    That is clauses 2 and 3 allow you to distribute modified versions of the QT source code under reasonable conditions. There is no problem here!

    Okay onto your next point
    and their programs can't require a user to make changes to QT.
    A honestly don't understand what you are trying to say here. If your program requires the user to use a modified version of QT then distribute a binary version of your modified QT along with your program.

    while the license is somewhat better, it ain't the GPL (any version); and I still have hope for the Harmony Project.
    I have news for you.
    1) The GPL ain't perfect.
    2) None of the Harmony Project source is under the GPL, it is under the LPGL.

    Not that I'm against the harmony project, BTW.

    If you are going to complain about the QPL please find something worthy of complaining about!

    Now I'm no Troll Tech lackey. I admire the GTK toolkit and have great respect for those who developed it. If you are a GTK/GNOME supporter and want something to complain about, then complain about this:

    The QPL makes it harder to reuse code than the GPL or BSD licenses do. Clause 3 of the QPL effectively prevents you from taking a bit of Troll Techs QT code and including it in your own program. The QPL is an "indivisible" license if I may be permitted to coin a phrase.

    Personally that is a feature of the QPL I really don't like but I'm prepared to live with given the great work (code) that the Trolls are producing.

    I hoped this cleared a few things up. (Well I know full well that in another couple of weeks the same people will just post the same crap again, but at least I got to reread the QPL and double check my facts (again))
  • Qt and GTK themes are not compatible and probably never will be.

    HOWEVER, KDE and GTK themes will be able to get along just fine! What do I mean? Well, we've essentially abstracted the themeing layer a bit higher than the Qt level. Thanks to the incredible work by KDE developer Mosfet, all theme work can be done at an "rc-file" level. Soon, there will be a easy to use GUI to do all of this in a point-and-click manner.

    Mosfet is also now starting to integrate GTK themes into this. I believe he is having troubles finding the official GTK theme specification (I looked for it myself with no luck -- I'm sure it's out there somewhere but it is sure not easy to find). Once this is done, it should be possible to use GTK themes in KDE *AND* to apply KDE themes to your GTK apps.

    It is a given that somebody will also code the "other" direction. I would be very suprised if you would not be able to use KDE themes within GNOME someday.
  • Oh christ, templates again. Look idiot, from Ada to Haskell to variants of Java (Pizza), Generic Programming is a good thing, it's here to stay, and atavists who insist on going back to assembly with drum memory and tape drives for all are not going to change that. Tell me, do you have ANY formal background in CS to qualify your wild assertions about what ideas of programming are good or bad?

  • > QT is an excellent library but it ain't free (speech).

    Tell that to RMS, who has blessed it with the Free Software moniker.
  • Well, the current KDE isn't based on this anyway
    and won't be until the first quarter of Y2K, so
    there's plenty of time to thrash this stuff out.

    One thing that has puzzled me for a while though.
    If mixing KDE's GPL and Qt's QPL is a problem, how
    does the mix of Netscapes NPL + GNOMES's GPL(?) + GTK+'s LGPL manage to avoid all this? GNOME are using Netscapes NGlayout widget in some of their tools aren't they?

    No one ever seems to talk about this (that I have seen).

    Macka
  • The situation is by far not as clear as you present it here.
    And you are not sufficiently up-to-date concerning the QPL.

    Indeed. Essentially, the GPL requires that code linked to by a GPL-ed piece of software be under the GPL or under a license that imposes no more restrictions than the GPL (like public domain, the MIT license, or BSD without the ad clause)

    The problem is, that this is a very arbitrary interpretation of the GPL except when that code is part of a major system component (something like a proprietary Motif or C library in an environment where they're always present (think Motif on SUN)).

    Qt is for Caldera/Corel/easyLinux/etc. what Motif is for SUN.

    X doesn't qualify as such a component (you can have a perfectly working Linux system without it, and X is not part of all distributions), so Qt, a layer over X, doesn't either.

    Motif is a layer over X just like Qt. There is no difference wrt licensing.
    And your definition of system component is your own, not that of the GPL. The GPL doesn't say *essential* component. It even mentions the compiler, although a precompiled Linux runs very well without one.

    And Qt's license, now the QPL, imposes more restrictions than the GPL (e.g. the "patch requirement" that modified versions may only be distributed as original code + separate modifications).

    That's not true anymore. This was the case in the first draft of the QPL, which was heavily critizised for that. The QPL 1.0 only demands that new code is clearly marked as such with info about the coder. The GPL requires the same.
    There is no "patch requirement" anymore, at most a patch or CVS recommendation.
    Even RMS admitted that, and you should too.
    The only remaining problem RMS saw was the "non-non-disclosure" issue. You can't use QPL'd code secretly in-house without notifying TrollTech, while the GPL allows for such quasi-proprietary development.
    I'm not quite sure if this is rather a loophole in the GPL than a flaw of the QPL.
  • Sure you can use the system library exception.

    Qt is NOT part of the regular KDE packages (check for yourself).
    It is expected to be present on the system (and it mostly is).

    Debian's problem with KDE was that they couldn't include Qt as a 'system component' as long as it didn't conform to the DFSG.
    Now that Qt 2 is DFSG-free, Qt can be a system component and the respective clause can be applied.
  • However, some of them feel it is a none issue so they just ignore it
    ...and they may well be right with that.

    The GPL is very unclear when it comes to dynamic linking of any kind (Corba with non-GPL apps will be a mess).
    Let's face it: The current GPL is not suited for modern software development anymore. Even RMS knows that and is working on a new version.

    Until this new version is released, it is IMHO very sensible to just sit back and wait. "Adding a waver" to the KDE-GPL is a hairy thing. What about compatibility to the "plain" GPL, e.g. when combining code...

    And while RMS has said once that adding such an amendment would be fine, he has said later, it wouldn't work anyway... As long as the GPL depends on the whim of Mr. Stallman, I wouldn't rush and change things in a hurry.
    And besides that, as long as no author complains, there is no urgent reason to act. Even RMS was kind of pleased with the latest changes in the QPL (except for the missing code "secrecy"), esp. as they've dropped the patch requirement.

  • Hmmm (Score:1)

    by Avus ( 9506 )
    With a little bit of imagination, one could probably find a way to use this as a loophole to develop "in-house" applications that are in fact propritary programmes.
    With huge international corporations like DaimlerChrysler 'in-house' could be quite big. So you could make additional contracts between (independent) divisions that prevent free distribution without some sort of payment...
    That way, companies could 'steal' GPL'd code with this clause (they couldn't distribute it outside of the company, but that is not wanted anyway in some cases - the 'intra-corporation' market is big enough).
    I'm not sure if this could be prevented somehow, but the danger is there, and getting rid of it is not necessarily such a bad thing...
  • I still stick by my view. I don't think that RMS envisioned a situation like KDE's ever occuring because it's fairly bizarre; we have created an entirely free system, but then a nice-looking proprietary GUI library pops up and people reuse the traditional free license when writing software for it, mainly because the GUI's license encourages it. You make it sound as if the KDE team's plans are sinister; I do not think they were "trying to get a proprietary library in the back door."

    To address your example, why would a company make a proprietary library and then distribute an application for it under the GPL? If they wanted to free it, they could simply write it under their own free license. The GPL has two purposes: to protect existing software from being abused, while allowing it to be extended. The purpose is certainly not to prevent people from making their software free, open, liberated, or whatever you want to call it. It's just a generalized free license (hence the name "General Public License"), inappropriate for certain specialized situations like KDE's.

    Let's say you're Joe and you write JoeOS. But you're too lazy to write a compiler, so you bundle GCC with it. People will buy your operating system because it comes with a nice compiler. This clause prevents this situation from occuring, and I'm glad. Now... wait a minute, doesn't Be do that? HMM...... Oh boy, I don't want to start a flame war. But I have to wonder, is this the key to force Be to release their code under the GPL? Can some Be user tell me if GCC is bundled with BeOS?

    Argh, I promise this is the last post I'm making regarding this situation. Must go get some actual work done. So go ahead and flame me to death now. And the above disclaimers still apply; just call me Mr. Layman.
  • First of all, a disclaimer: I am not a lawyer. What I say below is purely opinion. I am not in any way connected with the Debian project, other than through the existence of a package of something I wrote.

    I think you're right, annoyingly enough. I spent some time trying to think of a way to allow KDE and Qt to accompany each other. I came up with an idea, but I don't want to relate it here because it would just make me look stupid, mainly because it didn't work. After reading the above post, I realized I had missed that last part "unless that component itself accompanies the executable," which I think probably makes KDE under its current license, sadly enough, undistributable. In order for KDE to be distributable, Qt would probably have to normally come with Linux distributions. This is a little iffy right now, and it still doesn't let KDE be distributed alongside Qt. Of course I want KDE to be distributable; although I personally don't use it, I think it's easy to see that it's a worthwhile piece of software to say the least, and that its creators obviously wanted it to be legally usable and treated just like a normal GPLed piece of software.

    I wondered at first why the GPL was written this way, but I've realized that it's because RMS didn't want people distributing his software along with their proprietary operating systems. This is a protection that I didn't even realize was present in the GPL and it makes me feel a little safer; I know that any silly games that I write won't be sold by SCO or something on their CDs.

    Now that a free-according-to-Debian Qt has been released, my hopes were renewed, if only slightly. First of all, realize that KDE is now legally distributable, if one can assume that Qt is now "normally distributed... with the major components... of the operating system." However, realize that it says "unless the component accompanies the executable." That means that if ONLY the source form of Qt is distributed along with KDE, the two can be distributed together. Of course this is incredibly annoying to the end-user as he will have to compile Qt in order to install the KDE on his CD. And on a sluggish old Sun IPX this is really annoying. Don't even get me started with Pine/Pico, either.

    That having been said, who does this really affect? The answer is probably almost nobody. Debian packages of KDE have been available the whole time on KDE's site. Nearly all of the people who use KDE are going to be using a distribution other than Debian anyway. And though the way most distributions would distribute KDE are probably illegal, nobody really cares. Even if some crazed KDE developer decided to sue, I think sufficient evidence could be shown that the intent of the KDE team is clear enough, and that the license is vague enough, making statements contradictory to the situation like "... the GNU General Public License is intended to guarantee your freedom to share and change free software" that his case would probably be thrown out. Either way, things would get worse in a way that nobody wants. If it wasn't, distributions everywhere would be struck a major legal blow, and I have a feeling most would disappear. And if it was, the GPL would be threatened, and I'd probably have to switch to a new license for any software I write. It's in nobody's best interest. (Of course, that hasn't stopped people before.)
  • KDE is just to neat and clean. Its getting to be like the rest of this Linux stuff, it works without a hitch. I need software that chrashes and gives me problems so I've got excuses for not getting any work done.

    Dennis
  • AFAIK it includes both qt 1.4 and 2.0 branches.
    Just peek at www.oreilly.com, they know.


    ---
    The day Microsoft makes something that doesn't suck,
  • KDE included GPLed code, which means they can modify their license, but not that of the code they included. Which means they can't link with KDE. GNOME does not yet use NGLayout (at least in any distributed version, the GTK NGLayout component is just a proof of concept right now). When they do start using it, they will probably implement NGLayout as a component, accessible as a CORBA object, so it will be a seperate program, exporting services. Go read up on the relevant software before showing your ignorance of the GPL and GNOME and your own personal biases. It is anything but "simple as that."
  • ... but KDE is not a 'product' without the QT library, so you can't just say that they're seperate because functionally, they aren't.

    GPL essentially says that GPL'd code can not be made to be reliant on non-GPL'd code. If it's not a product until you add non-GPL stuff, it can't be distributed.
  • hmm. well of course I was a little bit inaccurate with that statement, too vague. Of course, X11 being a "standard system library" on most any UNIX distribution, is an exception. Regardless, you could apply the GPL to XFree86 any time you like under its current license.

    If a GPL licensed product is not complete without including a non-free component (not including basic system libraries) it cannot be distributed. That's what I should have said.
  • I'd guess that this [linuxtoday.com] can answer some of your questions :)
  • KDE provides a ton of useful app framework objects... try out the new version of KDevelop and you'll even get templates for doc/view structured apps :)

    http://www.cs.uni-potsdam.de/~smeier/kdevelop/



  • No, it's still not the GPL. What did you expect? The Artistic license isn't GPL either. Nor is the MPL. Come to think of it, the LGPL isn't the GPL either!

    If you're demanding that every license be the GPL, then methinks you have a lot of growing up to do. The QPL is open source. No, it's not 100% free, but neither is the GPL! I, for one, am grateful that Troll Tech is sharing their code with me.

    The reason that Troll Tech has some difference from the GPL is that Troll Tech actually makes money off of Qt. The don't want someone going off and selling a different version of Qt. Neither do they want to support someone else's implementation of it. They are quite up front about this. Qt belongs to Troll Tech. They don't want code forks. Compare this to the continuing recriminations about XEmacs.

    If everyone who bitched about Qt would have contributed to the Harmony project, it would have been done last year!
  • Gnome can do it because they have Richard's blessings to do so. KDE is not allowed to do it because Richard doesn't like KDE. Simple as that. This is the definition of free software in practice.
  • There is no restriction in the GPL that you can't dynamically link to a non GPL library. I've read it through dozens of times, and it's just not there. Section zero of the GPL says that the license ONLY covers copying, distributing and modifying. It does not cover dynamic linking. It doesn't matter at all whether RMS doesn't like QT. All that matters is what the GPL says.

    The clause cited above refers to distributing the source code. The QT library is not part of KDE's source code.
  • So, you're saying that a dynamic library is not "a separate program, exporting services"? Since you seem to be the expert on the GPL, where in it does it say you can't link to a non-GPL library?

    KDE include *NO* code from the QT library. Again, if they have, and I am mistaken, please show me the QT source code that's inside the KDE CVS tree.

    I have read the GPL and I have examined much of the KDE code. I've also read the QPL, and the previous Qt Free Edition License. I can find no evidence of licensing infringements.
  • It's your code. You are the licensee. You can do whatever you want. The GPL imposes restrictions on the "licensee", but it is legally impossible for it to impose any on the original developer, the licensee. If it did, it would not be a license, it would be a contract.

    But thinking of your users, go ahead and use the Qt library. You can certainly consider it a "system library" if it comes with your operating system. It comes with most (Debian, Redhat, Slack, SuSE, Mandrake,...).

    But it really doesn't matter if it's a system libary or not. Qt is not part of your source code. It is not your module.

    The GPL is very clear that you can dynamically link with any libary, GPL, QPL or anything else.
  • Where does it say this in the GPL? I'm being serious, I really want to know. I hear it proclaimed from thousands of people that the GPL is exclusionary, but where does it say in the license that it's a GPL-only club?

    One must draw the line somewhere as to when one project ends and another begins. Since KDE and QT are made by two distinct development teams, I would think it logical that they are distinct.

    As a counter-example, if I write a small little Gnome app, do I have to distribute all the Gnome libraries, the gtk library, and any other library I happened to have used? My 5K source code just became several megabytes. What if my tiny website only allows 5 megabytes? Am I now not "free" to redistribute someone's gnome application? ( I could of course send the application along with a written offer for the source code, but I only wanted to give the code to my friend, not start a Gnome distribution service).
  • Nobody took much of an interest in the Qt license until KDE became popular. Before then, it was just another non-GPL library, like xforms. After KDE became popular, there was some worry that Qt might become essential for the GNU System. The reactions to this were varied. Some politely asked Troll to be a bit more liberal in their licensing. This action got Troll's attention, and they released Qt under the QPL open source license.

    But other actions also got Troll's attentions. They were deluged in hate mail. By "hate mail" I mean vitriolic, obscene and threatening communications. Everytime the subject of Qt or KDE came up on a forum, religous bigots would crawl out of the net to lambast them yet again.

    As a group, the GNU community told Troll, "you're not wanted."

    Well, Troll Tech heard. In the future, Qt might be released under a BSD or Artistic like license. But it will never, ever be released under the GPL.

  • It's not politically uncorrect anymore, but who knows - QPL could be against his religion or something.
  • I wondered at first why the GPL was written this way, but I've realized that it's because RMS didn't want people distributing his software along with their proprietary operating systems.
    Indeed, this is complete boulderdash. Digital used to package a whole bunch of GNU tools with DU for years. Sun bundle Xemacs with SunPRO C/C++ (at least the version at work). I'm sure the FSF encourages such practice.

    Its really got nothing to do with putting GPL'd code with a proprietry operating system, but with making a GPL'd product depend on a proprietry library or component for non-replaceable, and core functionality. Such that the product will not function without it.

    That was no doubt the intent (purely proprietry), but it will still apply to other non-GPL compatible licensed code too, e.g. the free QPL. And so qt falls squarely into this category.

    I hope all these KDE developers changing to weaker licenses like the Artistic license dont get burnt, or even Perl for that matter, in its rush to get popular.


    __// `Thinking is an exercise to which all too few brains

  • GTK+ has had mouse support since 1.2.0. Thats why gnome and GTK+ apps has the wheel support.

  • Is this qt lib 100% backwards compatible with the old qt? Can I go in and axe my non-gnu qt lib and put my system at peace (I don't have KDE installed, I really only installed qt for licq)?

    This actually makes licq GNU-friendly. I like that. And hopefully, KDE will be made GNU-friendly as well..
  • Tell me, do you have ANY formal background in CS to qualify your wild assertions about what ideas of programming are good or bad?

    Not to be terribly picky, but since when does owning a slip of sheepskin -- or the persuit of such -- make one better qualified to make assertions, wild or no?

    I take exception to the idea that some self-styled elite knows what's best for me and the real world. In fact, I find it downright humorous, given that a noticable portion of the formally educated folk I know are essentially spreadsheet jockeys, and most of the best programmers and systems architects I know are graduates of U of Hard Knox.

    And there's nothing like the anecdotal evidence of your own two eyes.

  • Here you can find an iwheel rpm [w3.org].

    You *do* run Red Hat, don't you? If not, use alien or something.

    To make it work, you'll have to make a few changes to your XF86Config file (add the line "ZAxisMapping 4 5" to the Pointer section for your mouse).

    After that, just run imwheel and stuff should just magically work. Run "imwheel -k". Read the docs in /usr/doc/iwheel* for more info.

  • "imwheel", bro. Feel it, use it, love it, be it.

  • Yeah, this seems like a real hot seat in the arena of libraries.

    Now personally, I don't know of modifications I would make, other than ADDITIONAL libraries; and quite frankly, either I WOULDN'T distribute those, or else my distribution circle would be known (i.e., downloads on my web site would be limited to those who KNOW that my web site exists -- not that I have anything to hide).

    [And of course, I'm assuming another person actually has an INTEREST in my libraries]

    Good point on paper, but immaterial for me (I think). I'll leave it to the lawyers.

    [One last word: I may not be very concerned with this issue only because I'm not sophisticated enough of a developer to care one way or the other. I only mention this because I'm not alone, and we're in the majority]

  • I think this is flame material and am suprised how many people responded to this. Someone re-awakens the QPL flamewar and the slashdot thread becomes huge.

    Flame bait. Just say NO.

    --

  • I've been looking at picking up that O'Reilly Qt Programming book. It is for the older version AFAIK. Did the API drastically change, or will I be safe picking this up.

    Thanks.
  • If Windows became open-source, I'd bet that within a few years it might actually become a usable system. At the very least, if the source was released (all of it, not just pseudo-open-source), then projects like WINE would be greatly helped along. Imagine how fast WINE development would take off if they didn't have to feel around in the dark.

    So, while I probably wouldn't use Windows if it became open-source, I would be very pleased because I'd be able to run MS Office under Linux using WINE. (Eventually)
  • Very good point!

    Linking Netscape with GTK is no problem, because the NPL allows it. However, linking any GPL'ed gnome apps with the NGLayout library would be exactly the same situation as linking a GPL'ed app (say KGhostView) with QT.

    Of course the authors of such a Gnome app can resolve the problem by simply relicensing any app which calls NGLayout under a looser license.

    The difficulty for the KDE developers is that some of their apps include GPL'ed code, and therefore cannot be relicensed without replacing the GPL'd code.

    (The same problem *may* exist for some Gnome apps, but remember all KDE apps need QT, only a few Gnome apps use NGLayout).

    It would be useful to have a list of all the KDE apps which include GPL code. It is possible that Debin could distribute KDE by simply throwing out some of the apps.

    Kevin (running KDE 1.1.1 for now, but not KGhostView)
  • The article mentioned above (about KDE 2.0 and KOffice) is still wrong.
    Both KDE 2.0 and GNOME 1.0 have a theme engine system. Both of them use theme support from a DSO, and include a DSO for pixmaps themes. The article would love you to think that KDE will be fast, because it doesn't use pixmaps. In reality, most theme authors are lazy, and most themes will use the pixmap engine.
    For GNOME there are already some clean, fast theme engines, and there's no reason to believe it will be any different for KDE 2.0 -- but that's still months away. Likewise there are slow, bloated themes for GNOME, as there will be for KDE.

    It's also misleading (deliberately perhaps) for the KDE developers to talk about KDE and GNOME "standardising" on a drag-and-drop protocol. In reality, GTK+ (and therefore GNOME) supported as many DnD standards as possible, while KDE decided to go it alone. This is finally fixed by Qt 2.0.
    Try this, right now, in your Desktop Environment: Go into Netscape, and drag a URL icon onto the desktop or task bar. Doesn't work? Sorry, your desktop environment doesn't agree with "Be liberal in what you accept".

    Nick.
  • I think I heard after Qt 2 was announced as OSS that Debian was considering including KDE as an option. I have no clue whether they actually will or not, though.
  • > I'm not quite sure if this is rather a loophole in the GPL than a flaw of the QPL.

    The GPL gives you the *freedom* to develop in-house without releasing source. It only demands you release source if you distribute the program. I think that is an important freedom- the choice to *not* distribute your program/code.
    This provision of the GPL is a feature, not a bug. :-)

Slashdot Top Deals

"Imitation is the sincerest form of television." -- The New Mighty Mouse

Close