Slashdot Mirror
Trolltech to Extend Dual-License to Qt/Windows
scc writes "
Trolltech announced today
that Qt 4 will be available on Windows under the GPL.
While Trolltech has long dual-licensed
Qt on X11 (Linux, various Unixes), Mac, and embedded,
Windows developers have had no options other than a commercial license."
Can't I just download their software under the GPL, and redistribute it to anyone to be used under any setting at all?
Don't blame me; I'm never given mod points.
Yay! The blue fairy has arrived, and soon The Gimp can become a real program!
Didn't someone external to Trolltech port the GPL-licenced code to Windows and licence it under the GPL? Without special clauses in the licence to prevent that, that would presumably be allowed.
Or, do the X11 and Windows versions differ so greatly that such a port is an insurmountable task?
Microsoft asks and they shall receive!
Screw application heterogeneity, write once, compile thrice, and run everywhere!!!
500GB of disk, 5TB of transfer, $5.95/mo
I suppose this is the end of the KDE on Cygwin project, and good news in general for Qt/KDE applications on Windows?
since they have a large audience now that can take advantage of them maybe LyX will start accelerating development and adding in some nice features that will make document creation much more productive.(integrate a bib database for god sakes!!!)
I am the Alpha and the Omega-3
Goodbye, MFC.
This is exactly what has been requested by many Qt/KDE developers over many years. This will bring about a flourish of new applications being ported from linux to windows (whether you like that or not). This will heat up the Gtk vs. Qt arguments as a major argument against Qt no longer holds. This will also help push KDE Enterprise efforts as many enterprise concerns will be resolved by this move. Good move Trolltech!
So this means that the application itself is free (as in beer) as long as you release any software that you develop with it under the GPL? And for commercial software you have to buy a license?
Sorry if that's blindingly obvious to everyone, but I don't totally understand what this means.
Sinch
This should increase the availability of quality F/OSS software on the windows platform, which can help ease the transition to Linux.
I only wish this were the case a few years ago. TORA (Toolkit for Oracle) was a great, inexpensive cross-platform PL/SQL editor. I tried to get my boss to standardize on it so that we could use the same tools in Linux and Windows, but he was turned off by the need to charge for Windows support. (He interpreted that as Linux arrogance and was worried that the Windows support would be lacking. Even though I explained it was because of Trolltech licensing.)
Turns out the boss was right, though for different reasons. Tora got bought out by a windows pl/sql tools competitor and basically killed.
QT is the base of KDE, no? So when do we get KDE for windows?
10 ?"Hello World" life was simple then
Especially for QT opensource software.
Sounds interesting.
This is indeed a good news regarding the portability of GPL, QT-based applications; this decision brings QT on par with GTK in that respect.
Now, I just hope they'll not make us wait for too long for QT 4 !
Here's for The Gimp!
This marks a glorious day for trolls like me to finally break into the open market and spread our trolldem to faraway lands through trollful globalization of the trolltech enterprise.
hip hip hurray!
A troll dem is a Democratic Party troll, like like this hot-head. You probably mean to say trolldom
Don't blame Durga. I voted for Centauri.
i've taken a number of qt-based linux apps off kde-apps.org and recompiled on windows - as long as the developers stick to the Qt API, its a breeze to port!
--- blackironprison, where ignorance is bliss....
I was under the impression that Trolltech did have a GPLed version of Qt for Windows. I thought it was the one included in their GUI programming book (the book is at home so I can't look it up myself). I also seem to recall at least a few projects stating that if you contacted Trolltech and notified them that you were working on an open source project and would like Qt for Windows, they'd give it to you for free (although maybe under a different license?).
LilMikey.com... I'll stop doing it when you sto
Now the KDE fanboys will talk about how good GPL for windows is instead of +5 score uping each other for criticizing those who questioned Trolltech's licensing.
At least now they "get it".
I guess it's much too late, WinForms is just as nice; if not a lot nicer; and puts no restrictions on the product.
Yea! Hopefully, now since cross platform OSS programs can now use QT, the GTK will die an awful awful death. No more hassle making custom widgets in C. Thank the lord. I hope that there is at least some very good competition between QT and GTK now. They are now fighting on relatively equal licensing ground now.
Do you mean KDE that can be run in Windows, like for a POSIX layer? Well that already exists, as others have noted, it works in Cygwin, and probably could be made to work with a native POSIX layer like the one SFU installs.
Do you mean as in a replacement to explorer? Then no, likely not. KDE is all X based, and I just can't see a reasonable way of getting it to tie in to the Win32 enivronment. You have to remember that Windows doesn't have a distinct concept of a window manager. It has a shell that manages desktop interactions, that being explorer by default, and you can replace it. However all it does is handle the desktop. Windows management, fonts, etc are done by the OS itself. There isn't a discreet layer since Windows doesn't function without its GUI.
There's a fundimental design incompatiblity, as I see it. UNIX is such that you have a kernel, and on that you run an X server to handle graphics and fonts, on that you run a window manager to deal with client windows and more advanced GUI features, and so on, or rather with KDE you run a graphicsal toolkit (QT) on which you run the WM.
In Windows it's all part of the OS. Win32, the API in which Windows programs are written, already contains all the calls for window mamagement. The code is part of the OS and indeed, parts of the graphics code run in kernel mode (something many UNIX people heavily critize Windows for). There isn't any logical seperation of the layers, from the OS view. If the GUI goes down, the OS goes down with it, it doesn't drop to a shell because the GUI is treated as a necessary part of the OS.
Now maybe I'm wrong, but I can't see any way of reconsiling the way KDE works with this in a useful fashion. I suppose one could develop an explorer replacement that looked like KDE, but you'd probably have to do it in native Win32 code since you couldn't really run an X-server to do it.
The KDE fanboys use their mod points as a weapon ... so beware.
It does look like trolltech got into bed with SCO/Canopy without fully appereaciating what they were getting into. Canopy has rights to put a representative on the Trolltech board. Fortuneatly, it's only one vote and can't veto marjority board decsions (I think, at least the Trolltech president said so in a long ago slashdot post).
It does look like TT is stuck with them but were smart enough not to sign over their souls to them. Hopefully they can just ignore the Canopy board member and conduct business as they see fit.
I'm sorry that the KDEers don't see this as a legitimate issue.
It is. They better off facing reality and admitting there is a wart on Trolltech.
QT is a fine product otherwise.
the mac version has been gpled on the os X platform I think in 2003. Go and see some cool project http://ranger.befunk.com/blog where they try to port KDE to OS X natively.
This is the best news of the year, for me at least. No longer will I (and many other developers) need to compromise when writing multiplatform C++ code -- Qt is just the natural choice for this task, and I'm very glad they decided to release Qt again under the GPL.
Again, kudos to Trolltech -- great companies like them are pretty much the exception these days.
Join the NFSNET. Our prime goal is making little numbers out of big ones. http://www.nfsnet.org/
But at least Bush, unlike Dean, knows better than to give a political speech during a full moon.
Don't blame Durga. I voted for Centauri.
So, if you write GPL code, OK. You want to relicense, OK. But the commercial version of Qt states,
NOTE: Qt Free Edition is licensed under the terms of the GPL and not under this Agreement. If Licensee has, at any time, developed all (or any portions of) the Application(s) using Trolltech's publicly licensed Qt Free Edition, Licensee must comply with Trolltech's requirements (see http://www.trolltech.com/developer/download/qt-x11 .html) and license
such Application(s) (or any portions derived there from) under the
terms of the Free Software Foundation's GNU General Public License
version 2 (the "GPL") a copy of which is located at
http://www.gnu.org/copyleft/gpl.html#SEC1 (i.e., any Product(s) and/or
parts, components, portions thereof developed using GPL licensed
software, including Qt Free Edition, must be licensed under the terms
of the GPL, and the GPL-based source code must be made available upon
request).
They will NOT license you a commercial version if you try to do it. They will withdraw your commercial license if you do this. See? You do this, you are left with only a GPL distributable. They also said in their email release that they will enfore their license. So please, don't try to pull a fast one on Trolltech.
You have your rights to relicense software. They have their rights to license their software to you.
Bye bye GNOME. This is the final endhit and endgame for those who fucked the once so cool GNOME desktop up the ass.
Gimp uses GTK, not Trolltech APIs.
This is fantastic news!
Opensource projects won't have to choose between Java Swing (and all the baggage that comes with Java), a heavyweight wrapper like wxWidgets (and BitTorrent, written in wxWidgets, isn't the prettiest app), or a fairly ugly port of GTK, which I've been forced to use.
Does this mean we'll see a port of KHTML (Konqueror/Safari) to Windows?
Move over Firefox, this is going to become a 3-way!
How would you compile it under Windows without needing cygwin? I guess we'll have to wait for Qt 4.0.0 when the first version for Windows with GPL is released.
By the way, what's up with gcc.gnu.org? It's been unreachable for days!
DNA is the ultimate spaghetti code.
You may know that there's a project to port KDE and its apps to Mac OS X using Qt/Mac. :)
The developer(s) of this port replaced some X11 functions with Qt funktions, but the KDE project didn't accept them, because they caused some (AFAIK minor) problems. Now with the upcoming release of Qt/Win32, I hope that there will be some more pressure toward the KDE developers to accept those patches and work out the (minor) problems. If KDE won't depend that much on X11 any more, other plattforms may get working versions of Scribus, KOffice and Co.
Nice troll there.
I've got a fever and the only prescription is more COBOL.
Over the years, there have been complaints from various developers that it's not possible to distribute free ($) software for Windows using Qt: a license costs an arm and a leg.
Finally Trolltech have corrected this (again - do they mean it this time?) but I fear it may be too late. Qt has always been an excellent development platform, but the grass roots support hasn't grown as it could have.
I'm going to try compiling some of the Qt-based software I wrote, years ago, for Windows, but I've become quite used to exceptions, a useful debugger, reflection and decent testing/coverage tools. I'm not as excited by the prospect as I might once have been.
Rik
It is a miracle drug...No
See here for an example of its use
See http://paulinim.freeshell.org/example.html
That's not true, I installed Qt3 on my Windows machine and I had the option of using the GPL.
I came on a CD with this book http://vig.prenhall.com:8081/catalog/academic/pro
We have asked Canopy to divest since SCO turned against Linux. Unfortunately under US and Norwegian law you cannot force someone to sell something. We have sold all our investments in Canopy companies a long time ago. We do not like the fact that Canopy and SCO owns shares in Trolltech. The irony is that they became shareholders because the old Canopy/Caldera wanted us to continue to create good Linux software. Canopy/SCO owns a very small share of Trolltech and has no control or influence whatsoever on the strategy and operations of Trolltech. Trolltech is controlled by it's employees. Eirik Chambe-Eng (President, Trolltech) -----
You are wrong. I am not a "fanboy" of either KDE or Gnome. I just think trolltech is far to good a company to have a crimminal like Ralph Yarro on the BOD, and to be financially involved with the likes of canopy and scox.
Question: if trolltech really and truely disapproves of canopy and scox; then why doesn't trolltech publicly ask canopy and scox to divest? Trolltech could then divest their own interests, and of course ask Yarro to leave.
If canopy can force trolltech to stay associated with canopy, then so be it. At least I could feel comfortable about trolltech having clean hands.
http://twiki.iwethey.org/twiki/bin/view/Main/Ralph Yarro
Just admit Canopy owns a chunk of Trolltech and move on.
Qt3/X11 and Qt3/Aqua have been dual-licenced with the GPL for a while. There's really no issue. If you can use it under the rules of the GPL, fine. If you want to use it outside the rules of the GPL, get a commercial license from TrollTech.
So yes, my understanding is that your scenarios would be OK.
GTK2 on win32 is good (and easy to install/bundle with your software)
wxWidgets is a very nice toolkit and has been showing up more and more in sofwares.
MS now allows developers to download their compilers and build tools in the SDK WITHOUT CHARGE, so it isn't a requirement that you buy a version of Visual C++ or .NET anymore, but you do have to use the command line only tools.
If I remember, it was the cost of being a "developer" on windows systems that directed their previous choice to charge for all windows QT software.
I really wish the Qt XML implementation would support XPath.
XPath allows you to easily select part of XML DOM documents, simplifying your life...
XPath is powerful enough to become part of a programming language itself (Comega), in Microsoft's opinion...
However, last I checked, Trolltech doesn't think it's worth it. Booo!
PS., Designer and Qt are way better than WinForms!!!
Trolltech are a great company, and if this move helps spread OpenSource to the Windows platform (by making cross-platform coding easier) and helps promote Qt then this is a win-win all round.
I know some in the F/OSS community are weary of commercial involvement, but the Trolls have proved that they really get the GPL license.
Kudos for removing one of the last things people used to complain about their GUI toolkit, and if you can afford it - buy a license to help them keep going.
Great ! Thanks a lot, Trolltech !
That's the best day in my whole life, for sure !
Yes ! Yes !
I'm so excited !
Let's watch some pr0n to calm down a little!
Youhoooouuu !
kde itself is under gpl too, and so is the kernel, glibc, etc, etc. I don't think it is going away anytime soon. QT is very actively developed and kde gets much better every release. some people actually like gpl above lgpl.
Please don't port all the good KDE apps to Windows.
The Windows people need as many reasons to switch as we can muster.
Like, you know, Kate and Kmail. And Kwrite. And even Konqueror!
www.kiwilyrics.com - a wiki for lyrics
As a Windows C++ developer, Qt4 is now open-source for my purposes. Since Qt4 is obviously much better than MFC this is very significant.
But it is very frustrating since Qt could have been a very significant C++ framework on windows if it had done this years ago. Now it is a bit late for most of us.
The other frustrating thing is that TT, in the best tradition, is pursuing lock-in (vs. standards) in QT4. By deciding to embrace templated containers in their own proprietary way, vs. the standard, STL, way, they make it much harder for a programmer like me to convert to QT, both practically and morally.
I know they will have all the usual excuses for breaking the standard (I've heard them from MS in the past). It's kind of ironic that, just when MS stops playing games and finally puts out a truly standards compliant compiler (VC7.1) with a great standard library, TT decides to imitate the old MS.
Canopy has finally, publicly spit on Canopy.
Good.
It's been a long time.
They've gone from silence to denial to mild criticism.
Say it, Trolltech, CANOPY SUCKS !!!!
Now doesn't that feel better?
I wonder if that small stake Canopy has gets their opinions heard in board meetings. Is it enough to let them hold the floor for any time at all?
Why do I have this? I don't smoke.
Also, under Windows, if you want to purchase development tools (Visual Studio or otherwise), you certainly can. Still, there are free ones out there, and you can go quite a long way with those. The Mac comes with everything you need; when you buy the machine, you get the tools. And of course the GUI-API and widgets are 100% "there" on the Mac as well.
Under Windows, you also have the option of using an older, very much less expensive version of Visual Studio -- those are still 100% functional and produce fully functional applications under XP (and 95, 98, 2000, and NT) and I see no reason they won't remain so.
I think that if Linux ever matures enough to "come with" a standard, always-there, reasonably modern GUI-API such that software can be directly written to and for it, you'll see a significant burst of commercial development, porting and deployment. Until then, the job of trying to figure out what toolkit has the fewest warts and gotchas will be a significant stumbling block for commercial developers. I know it was for us. We shelved our port-to-Linux project for this very reason. As our application is a large one in terms of code, comments and OS window/widget objects, we need to be extremely conservative about launching a porting effort. The cost of a late-stage failure or roadblock would be very, very high.
Linux has really worked itself into a corner here. There is a bizarre social aspect, a "we don't need your steenking commercial software" attitude that will probably keep it there, too. It's interesting to watch.
I've fallen off your lawn, and I can't get up.
write once, compile thrice, and run everywhere!!!
Write once, don't compile, run everywhere.
http://www.wxpython.org/
I love Qt, and I've been wanting this to happen for a long time. I never expected that TrollTech would actually do it. This is such a wonderful shock.
Wow...now, we'll actually see some Qt or even KDE apps become cross-platform. Maybe even KDE itself. I'm stunned.
I support the Center for Consumer Freedom
It's the best news of the year!!! (But we are at february yet) qt is a mature and strong library for linux as much a for windows, and this is a very rare case, nor gtk nor wxWidgets are so completes as Qt is. assistant and designer are uniques in the open source world (glade is good, but it hasn't comparation point yet). Using assistant you simple type the function, class name or whatsoever you were looking for and in a moment you get all the documentation about it. Gtk doumentation is poor compared with Qt, and is not easy to use it. I don't like windows, but it's a reality, and if I develop and application it seems great to me that with simply recompile it, I can use it in windows.
Thank you. That is good to know. I feel much better about trolltech now.
Good observation.
You have a constitutionally protected right to be wrong, and I the right to ignore you.
This is of course a Good Thing (tm). Qt is a first-class toolkit. Perhaps the new license will encourage more developers to build cross-platform software. And we all know that the more cross-platform software we have out there, the easier it will be for people to gradually make the move from Windows to Linux (or at least from Microsoft to non-Microsoft).
Look at the success of applications like GAIM and Ethereal, which use the Windows version of GTK. This, folks, is the obvious long-term path to loosen and eventually dislodge Microsoft's death grip on computing.
Tired of FB/Google censorship? Visit UNCENSORED!
This makes it possible to lay waste to all sorts of expensive proprietary software on windows.
... I like both but given
This also means a cross platform consistant library for the java qt bindings.
Not so good news for GTK
a choice it will probably be qt for targeting both platforms.
Got Code?
programs can now use QT, the GTK will die an awful awful death.
Yep. Except, of course, for the fact that there are far more apps written in C than in C++ for *nix platforms. GTK leverages that workforce and knowledge.
And you're insane if you think GNOME, GIMP ( father of GTK, btw ), Gnumeric, Inkscape and other high-profile apps will simply drop GTK and go for a commercial entity-controlled toolkit instead.
No more hassle making custom widgets in C.
Sure, wait for Trolltech/Microsoft/Borland/Whatever do it and package it for you. And hope that they suddenly change the license terms in the future once the usage is widespread.
I don't feel like it...
Supposedly there is an implemented SWT port for Qt, but it has not been released because of licensing issues. Will it be possible now?
(Not that I have a problem running it with GTK+..)
KDE.org has a nice interview with the president of TrollTech, Eirik Chambe Eng. Definitely worth a read!
8 of 13 people found this answer helpful. Did you?
You don't need to pay anything to have access to a very broad spectrum of OS widgets when developing for Windows (or the Mac), no matter if you are developing in a traditional commercial sense or using any other financial model.
That's my point. In contrast, with Qt, I have to pay even for developing basic GUI apps. Therefore, if Qt became the default toolkit on Linux, it would put Linux at a big disadvantage relative to Windows and the Mac. Fortunately, Qt isn't the only toolkit on Linux.
Linux has really worked itself into a corner here.
No, Linux hasn't "worked itself into a corner" at all, because we do have Gtk+ and other toolkits that are covered by the LGPL. Those toolkits are friendly towards commercial use, and that's no accident. That's, after all, why most of the system libraries (C library, etc.) do allow closed source development.
There is a bizarre social aspect, a "we don't need your steenking commercial software" attitude that will probably keep it there, too. It's interesting to watch.
Linux needs commercial software much less than Windows or Macintosh because it comes with so much out of the box. And a lot of "steenking commercial software", we indeed don't need. A lot of "steenking commercial software" is also overpriced crap. But the small percentage of commercial apps that Linux needs and where commercial development makes sense, it support via toolkits like Gtk+.
Write once, don't compile, run everywhere.
I've been told that common implementations of Python are much slower than C99 or C++ for applications that perform digital signal processing. Is this still true?
Glibc is under the GPL with a linking exception, exactly to allow commercial development without paying anybody. The Linux kernel doesn't trigger the GPL. Qt is the only major system library that does not allow commercial development without paying someone.
Qt and KDE may be getting better, but a desktop platform must make it cheap and easy for developers to develop commercial software for it, and Qt doesn't do that. Its close ties with C++ further put it at a disadvantage.
The question isn't even whether it's "right" or "wrong" to pay Troll Tech, it's simply that vendors that try to put together commercial offerings out of Linux don't want to depend on a little company completely beyond their control.
I think Qt is essentially doomed in the long term because of these factors. Either the KDE guys will clone Qt, or the entire KDE project will just be replaced with Gnome. It doesn't matter whether KDE is better than Gnome or how much effort went into it.
With pythonqt i believe we will have a true VB killer available across all platforms.
Wow. This is the best news Ive heard in months...
--
John C
Actually all KDE libs are required to be LGPL or GPL compatible BSD.
Isn't Mono v2 supposted to support WinForms?
There are two ways Microsoft can stop this. First off, Microsoft can pull the old "embrace and extend": make WinForms 2 and convince app developers to release WinForms 2 apps before Mono v2 can upgrade its WinForms reimplementation to match WinForms 2. This technique of continuously extending the Win32 API is what had held Wine back.
Worse, Microsoft might sue Novell, the corporate maintainer of Mono, for patent infringement and get an injunction against distribution of Mono v2. Novell is headquartered in the United States, a country whose courts recognize patents on an ordinary computer running a novel algorithm. Though Microsoft has permissively licensed the patents on the parts of the .NET framework standardized by ECMA, WinForms isn't among those parts.
The Windows people need as many reasons to switch as we can muster.
I've said it before: I'll switch to GNU/Linux as soon as you get a working Microtek Scanmaker 4850 driver in SANE.
True, but up to now it looked as though any free Windows app using QT was going to have to be locked into the version 3.whatever release that came with the book. Now we know that the latest and greatest 4.0 version will also be made available under the GPL, which is a good thing.
according to the Qt Dual License FAQ: "the tools shipped with the GPL version support the popular GNU CC compiler. The C++ compilers from Microsoft, Intel and Borland are not supported by the tools in the GPL version."
Notice how the MinGW compiler is not explicitly mentioned - is this ommission by accident or by design? Do they only want GPL users to develop under Cygwin?
Eirik Chambe-Eng:
Thank you for publicly stating this.
It is good to know, as is disclosed on your website, that SCO and Canopy control less than 6% of Trolltech's stock.
It would be nice to also have the information I requested last July about SCO's ongoing retention of SCO Chairman Ralph Yarro as a director:
Good one trolltech now people can actually write crossplatform applications that look good in C++.
What does Qt Commercial Editions have that the Qt Open Source Edition does not?
Commercial database drivers
Was just recently looking at other truly open toolkits so that I could get the project out of this situation. Now I can just stay with Qt, which is nice because it has worked very well in the project.
Good move Trolls!
mhack
Building a better ribosome since 1997
Windows and the Mac provide GUI/widgets for free, no restrictions whatsoever. Widgets which work in all cases, from any language, upwards compatible without recompile or legal hoop jumping or the requirement to provide source for this, or binaries for that, or recursive versionitis fuckarosis (for instance, try getting the GIMP going on a stock Redhat 9 system and you'll see exactly what's wrong with GTK+'s ability to interoperate from a commercial standpoint.) Until/unless Linux handles these issues, Linux is in a corner.
GTK+ isn't a good answer. It isn't even an answer in some cases.
Linux comes with plenty, and there's plenty you can immediately add without too much effort. Fine. No argument (I'm a Linux fan, I'd be very unlikely to argue this point.) However, that doesn't obviate the point that there is more to be had, and if Linux was more compatible with commercial efforts, we'd definitely have more of those things (I say definitely, because the fact is I get to make some of those decisions. :)
In my particular area of expertise, the GIMP is "what is available" for Linux. But I have access to something quite a bit more powerful than the GIMP under Windows; despite the years of development put into the GIMP, and ignoring, for the moment, the terrible compatibility problems the GIMP has with not 100% up-to-date Linux systems, the very best that the latest GIMP has to offer, assuming you can get it to work, isn't good enough. For instance, it is ridiculous to contemplate going back to twenty-odd layer blend modes when your workflow normally spans seventy-plus; it is a royal pain in the butt to only be able to see one layer at a time; when CYMK work is required, you're simply out of luck; it is hugely annoying to have to select an area, then go select the op, then select, then op, ad infinitum when you are used to working by setting up the op, then selection, selection, selection... etc. Your working speed is reduced by a factor of (at least) two. There are many more issues like this, but these are enough by themselves to pretty much leave the GIMP unused around here.
These kind of things are like being forced to drive a golf cart to work after you've been driving a car. You can't go back -- or if you do, you wave your hands about saying, look, I'm using the junk transport!
Now, the GIMP is free, and as such is definitely worth eve
I've fallen off your lawn, and I can't get up.
Riverbank computing - PyQt. I've aleady been there done that. It is every bit as good as you think it is.
a d. php
http://www.riverbankcomputing.co.uk/pyqt/downlo
Enjoy!
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Disclaimer: I prefer Tk for cross-platform GUI apps, and don't use Gnome or KDE on my Linux desktop, so I'm reasonably neutral, but possibly not as up-to-date on all the quirks of each system as some. But nevertheless, it seems to me that this simply maintains parity between the two systems.
In the early days of KDE/Gnome development, neither Qt nor GTK could be used for developing Winapps - Qt because the license for the Win version didn't allow it, and GTK because GTK didn't run on Win. Now, the GTK port for Win has (reportedly) become fairly mature, and GTK apps are starting to appear on Win. So with this move, the same GPL'd Qt/KDE apps that exist on Linux can begin to appear on Win as well, maintaining the balance between the two systems. All the other advantages and disadvantages of each system continue unchanged.
Personally, I think the competition between these two systems is a good thing. (Among other things, I think it increases the chances that one or the other will eventually evolve into something I'd want to use.) So I definitely applaud this move by Trolltech. Plus, it's a classy thing to do - Trolltech definitely seems to understand the issues a lot better than they used to. It may just be a case of "keeping up with the Joneses," but it's still a classy move.
http://shit.slashdot.org/article.pl?sid=05/02/07/1 47223
Instructions are
Here
for the GPL version of PyQt for Win32 Qt/3.3.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
I wrote, "[i]n the early days of KDE/Gnome development, neither Qt nor GTK could be used for developing Winapps." Of course, what I meant to say was that neither one could be used for developing Free/OSS Winapps. Sorry about that.
Why should I develop using GTK or Qt simply to say, "Oh sure it is cross platform... see here in our docs where it lists these system requirements? Those are the GTK/QT runtimes you must have installed correctly"
Nah, I would rather develop using a platform neutral and very robust (or is "rich" the term for that these days) system that is compiled to be native, whether that is GTK, QT, gdi (or gdi+) or Motif. If that isn't the solution, then I want merely to include a very small, very efficient, and very WORKING translation system with my app. If this is already installed? Great, then I can make use of that one that some other app installed. However, the bloaty GTK and Qt sytem on Windows are not appropriate solutions except for Kiosks and Closed systems completely known and controlled by admin/IT.
If the QT License actually allows only GPL, how can the KDE Libs, who are direct derivative works of QT, actually be anything else than GPL'd themselves?
Under Linux XFree, you can use GTK+, fltk, wxWidgets, Java, C# w/Mono, or even straight xlib. Again, the only environment that has any type of stupid restrictions is KDE/QT, so stay away from KDE/QT if you don't want to pay a fee. Under Linux, GTK+ applications run just fine under any other desktop environment, including KDE/QT. I personally think the KDE team made a _huge_ mistake when they pick QT. To require a commercial license for native desktop tools is just stupid IMO. However, there are _plenty_ of other great toolkits like GTK+ that have none of those restrictions. With GTK+ you can develop OSS or closed, the choice is yours.
Sure, and you can also do the same under Linux _or_ you can freely download the latest IDE under Linux with no costs. The problem with the much older MS Visual studio IDE's is that they are not very good and certainly do not support the latest features of MS's development environment. None of those older environments support MS'sThere is no single "utopia" OS or development environment. Trying to single out just Linux makes you sound naive, especially when the MS windows development environment has just as many quirks.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
In response to several scattered posts that touched on the GPL and `internal software'...
Let's dissect the interesting scenario. Your company is working on some software for internal use. You have no initial intention to sell or distribute it. It just solves some local problem you need solved. It's based on GPL software, hence, it's subject itself to the GPL. It embodies proprietary business logic that you would prefer not to share. Therefor, you decide not to distribute it, as once you did, the GPL would prevent you from further limiting what distributees could do with your proprietary business logic.
Theoretically, this might apply to your own employees: does `distributing' the software to them force the GPL to kick in? The Free Software Foundation's GPL FAQ has something to say on this topic: Is making and using multiple copies within one organization or company "distribution"? The short answer is 'no', that should be OK. In this situation, the FSF at least feels the GPL doesn't stop you from telling your employees not to give away your source code. On the other hand, that same FAQ item points out "In particular, providing copies to contractors for use off-site is distribution."
So when consultants from a professional consulting company come to help out and you have to give them a copy of the software so they can do their job, that does count as `distribution'. If a big company sends analysts to do due diligence, and you have to give them a copy of the software so they can complete their analysis, is that `distribution'? If the big company ends up buying your little company to keep as a research division, and they decide your software could be useful to their accounting team in Iceland, will that be `distribution'? Does the GPL give your Icelandic accountants permission to give away (or even sell) your proprietary business logic? These questions haven't yet been answered in the courts, but my gut feeling is at least two of them would absolutely be considered distribution, if not all three.
We could continue examining case-by-case to decide if we might be forced to obey the GPL in any particular situation. Those who ask `will the GPL apply to me' in this way plainly are asking because they don't want to be encumbered by the GPL. Those people shouldn't build atop GPL software; and they can have Qt unencumbered: just buy a commercial license.
Again, it goes back to the underlying theme in dual licenses of quid pro quo. Why in this situation would someone use GPL software in the first place? Do they truly intend to abide by letter and spirit of the GPL? If they do, then more power to them. They're getting something of value and they're electing to pay it forward by sharing their work with the community (in lieu of backward to the originator, funding continued development). On the other hand, if they are taking software under the GPL all the while trying slip past its terms, then they are stepping on `free as in speech' and `free as in beer' to get to `free as in lunch'.
No. It isn't. You pay with obligation if you're not paying with money. You also pay with time, because a lot of this stuff needs work, you have to pick and choose which one, etc. Time is money. With MS and Apple, the GUI just works, and you don't need to worry about it. You just dig in and make your app. That's what it is about. Not "choice", I and most other commercial developers don't give a northbound rat's southern expanse for "choice." What we want is standardization, functionality, reliability, and a well defined API. Truly, you can keep your "choices" -- they cost too much.
Perhaps you can (MS will definitely give you the code given some "I won't tell" legal t-crossing an i-dotting, don't know about Apple), but why on earth would I want such a thing? All I want is a defined API. I have no interest in how it works, just that it does work. We spend enough time writing our own stuff that we have very little interest in looking at the OS code. Define the API and you're done, as far as I am concerned.
As for older MS IDE's "not being very good", that's nonsense. They're not as up to date, but they contain significant debugging tools and pretty much everything you actually need to get an application done. I am speaking from experience here. WinImages is built using an older VS, and it all works just fine. No point for you on this one.
Now, not using recent OS features can be an advantage. The more recent OS features you use in a commercial application, the more you limit your audience. For instance, if you choose to use an older VS and the libraries that come with it, you can write code that will run without any modification or hoop-jumping on everything from Win95 to XP. Look at putting the current GIMP on stock RH9, which is actually a very recent distribution if you think about it; yet, it simply won't go. GTK+ requires later stuff and there are other issues as well. Basically, if you want to build the current GIMP, you need a significantly more current system. It doesn't have to be that way. This is a shortcoming of the GTK+ widget library design.
Well, to you, perhaps so. My situation is that I have a complex, powerful product I'd like to bring to Linux. Every path we could find had significant roadblocks on it. Many of them were legal pitfalls, but some had amazing shortcomings (like, widget sets with no menu support!) What I think I know about Linux at this point in time is that to get our app ported in such a way as to work on the very largest set of machines without legal pitfalls and unacceptable source code obligations seems to require that we build our own widget set and incorporate it so that all we require from the OS is xwindows and basically fopen() and crew. Right now, that's too much, so a port isn't going to happen. YMMV as your requirements do, and of course, I may discover something tomorrow that obviates all of this, but this is where we are today.
In very sharp contrast, when we looked at porting to the Mac, it all went smooth as butter. Standard GUI, standard API, dev tools all lined up and ready to go. So there is a significant difference here, much as you might not want to acknowledge it.
When Linux gets a standard GIU-API, it'll have "grown up" as far as I am concerned as a developer and commercial software provider. In the interim, our port to Linux remains on hold.
I've fallen off your lawn, and I can't get up.
No. GTK+ has some restrictions and issues.
So does every commercial license in existence.
The LGPL is far from a panacea, and anything that uses the LGPL is full of pitfalls for commercial use.
Commercial licenses also have pitfalls.
But that's not the point. I'm simply pointing out that the GPL/QPL license for Qt is a big problem for Qt and KDE. The LGPL simply seems to be a license that works for many commercial companies in the real world. It worked well enough for Sun to build a desktop on.
In my particular area of expertise, the GIMP is "what is available" for Linux. But I have access to something quite a bit more powerful than the GIMP under Windows;
Well, and in my area of expertise there is lots of software that runs well only on Linux or UNIX. What's your point? For lots of different reasons, different communities use different platforms.
The assertion I come back to is that if Linux were more commercially friendly in general, it'd be better off.
Yes, and your assertion is total bullshit because there are lots of companies that are developing commercial software for Linux.
A standard, always-there GUI/API is a key element in this, and, at least as far as I know, there are no solid widget sets that are free of some kind of license / cost / restriction encumbrance, and that is giving both Windows and the Mac a distinct advantage.
Both on Windows and Mac applications are developed using dozens of different toolkits. And neither Windows nor Mac toolkits are "free of legal encumbrances" either, you just choose to ignore the encumbrances they come with.
For instance, it is ridiculous to contemplate going back to twenty-odd layer blend modes when your workflow normally spans seventy-plus; it is a royal pain in the butt to only be able to see one layer at a time; when CYMK work is required, you're simply out of luck; it is hugely annoying to have to select an area, then go select the op, then select, then op, ad infinitum when you are used to working by setting up the op, then selection, selection, selection... etc. Your working speed is reduced by a factor of (at least) two. There are many more issues like this, but these are enough by themselves to pretty much leave the GIMP unused around here.
Well, so it's not the piece of software for you, what can I say. None of the features you mention matter one bit to me, and I work with images daily. I suspect the Gimp already has more functionality than most users, even most professional users, ever really need. (In fact, I suspect that you are simply using the wrong tool for your job out of habit, but that's your problem.)
Now, the GIMP is free, and as such is definitely worth every penny everone pays for it. The commercial alternative I'm talking about will set you back about fifty bucks (US)
Well, then convince the vendor that your $50 are worth porting to Linux for, or contribute to the Gimp.
# If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it.
...It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.
Vendors do this automatically, since Gtk (like most libraries) is a DLL.
# there is no warranty (implicit in this is there is no accountability and no responsibility... IMHO for this reason a commercial developer would do far better to write their own widget set, frankly, than use an LGPL'd set)
Microsoft and Apple also provide no warranty, accountability, or responsbility.
# we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license.
Yes, that is entirely reasonable, and it is basically the same with commercial software.
# you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications
And your point is?
#
What's your point? Microsoft doesn't supply MFC for Linux, and Apple doesn't provide Cocoa for Linux. LGPLed libraries are legally compatible with Linux. They also happen to be legally compatible with Windows and Macintosh and dozens of other platforms, but that's just gravy. What the hell more do you want?
Aside from that, there is a huge difference between one well defined, encumbrance free target and the multiple encumbered (and moving) targets that comprise the Linux patch-a-GUI fractured environment. No amount of bluster will make this not so. The only thing that can fix it will be actually fixing it. And in the interim, you'll continue to suffer from a dearth of commercial apps. Yes, certainly you have some. But you could have more. You don't have any of the big three graphics programs, for instance, and the OS sure could use them, given that the GIMP is all you have right now.
As for your other comments about graphics, thanks, very interesting. Also very funny. You might want to do a little research before you wing it like that; In fact, you should do some right now. That'll give you time to pull your foot out of your mouth; the poor thing is sizzling in your stomach juices presently. :)
I've fallen off your lawn, and I can't get up.
No. This is for linking the library into the application. You should read the LGPL. Not to mention the rest of the thread. :)
No, in fact, they do. They both provide support, fixes, workarounds, suggestions and code. However, if you roll your own for Linux, you can do this yourself, which is interesting and about the only point in its favor, frankly.
No. It's not. Generally speaking, if I roll a patented technology of ours into a library, I can proceed to distribute the library no problem. This is an LGPL limitation, although it may be a limitation of other non MS and non Apple libraries as well, couldn't say. There's a big difference between a loadable library and code that's linked right in so it'll always work and doesn't depend on an external component.
The point was that if you include an LGPL'd library, you may not be able to include other libraries because the LGPL says so. It's a legal minefield for developers. I decline to walk in it.
I suggest you do yourself a favor and actually read the LGPL. It's very interesting. :)
I've fallen off your lawn, and I can't get up.
That's all I can say!
Yay!
I've been waiting for a long time. I really like QT, but I could not afford the Windows version of QT to develop apps. This is great news for F/OSS!
Some questions are just too embarrasing to answer.
WTF? What are you talking about? The majority of Linux GUI toolkit are under the LGPL. That means that you can develop Open Source apps _OR_ closed source apps. Your choice, there are no strings attached. There are no "obligations", you don't have to give away your code, you can keep it "secret". That is the _whole_ point of the LGPL you ninny.
All right crack smoker, come back when you have actually used Linux for more than 30 seconds. You really don't have a clue to what you are talking about. Gnome and even KDE are very full featured desktop environments and have many features that MS windows users would love to have. If what you said was even remotely true, why on earth would professionals like Disney Animation migrate to Linux (Disney Shifting to Linux for Film Animation, I have tons more links)?
Damn, you must have about three brain cells? Please tell me exactly _why_ the current Gimp won't work on RH9? Did you know you can download as many versions of GTK+ and Gimp you want, and install them all? The latest Gimp _will_ work on RH9. Even if the version of GTK+ on RH9 is not new enough, you can just install a newer version and Gimp will run.
Please tell me what this "complex, powerful product" is exactly. Oh and what are these "significant roadblocks". Based on your previous responses, I am sure that I or another /. member can solve these "significant roadblocks" in about 30 seconds.
Huh? You can pay a little money for QT (just as you would pay under MS for Visual Studio) and develop in a cross-platform environment, Linux, MS Windows and Mac OS X. Or, you can use a bunch of the other tool-kits that I already pointed out in a previous post such as GTK+ or wxWindows(x-platform, Linux, Mac, MS). These products have _no_ legal roadblocks. They are under the LGPL, which means you can develop your "super secret" closed source app and not had to worry about it. Please, tell me what your "unacceptable source code obligations" were? What tool-kit were you using that _required_ you to give away your code? I am going to have to say BS on your post.
Damn, dude, you must be one piss-poor developer when it comes to Linux in that case. So what language is your "great" application written in? What tool-kit/API does it use? What tool-kit under Linux did you try to use that caused you such "burdens". I know you are talking FUD, since there are _NO_ source code obligations with Linux GUI tool-kits. You can keep your code closed as much as you like.
Nope, Linux has all this as well. Standard GUI? Check. Pick
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
Unfortunately, Qt still has one shortcoming - it draws it's widgets itself on Windows (as does GTK+, BTW). The only multi-platform toolkit that doesn't do this is wxWidgets. That said, wxWidgets has a horrible API, with macros everywhere and the need to use #ifdefs for many platform differences (ugh...)
No. There are strings attached. The reason you don't know this is because either (a) you have not read the LGPL, or (b), you didn't understand it.
If (a), go read. You're just making yourself look uninformed (not to mention the silly namecalling... what, are you 12 or something?) If (b), I'm sure I'll figure it out next time you post, no further action needed on your part. :-)
In order: C, Win32, and none. As I mentioned previously, and as you would know if you had read the thread, we stopped the whole Linux port before we got to code because of the legal issues. Cost is not an issue. More is available for this project than it could possibly cost. We've ported three times; never did it go over budget or over time. Time is a big issue. Legal encumbrance is a big issue. Stability is a big issue. IP protection is a big issue.
Just to be clear, I am sure we could code to pretty much any widget set without much trouble, assuming it is reasonably feature complete (in other words, I am leaving out utterly silly ones like those that don't have menu support or only run under certain desktops) and assuming the widget set doesn't require that you use something other than C to get at it.
I see. Well, when you've actually read the LGPL, you come back and give me an informed opinion, K? Thaaanx.
Hmmm. Maybe you're confusing my posts with someone else's posts. All I've been discussing is an unencumbered widget API so that applications can code to a standard target. This is a very specific area and that's all I am talking about here. We don't need any libraries other than those required to interface with the OS, basically we need to be launched, we need fopen() and friends, malloc() and friends, and we need a graphics API that supports windows and controls. Collectively, widgets. But there is no graphics API (I refuse to count xwindows... it is far too awkward compared to more modern current metaphors) In Linux, what we have instead are a wide variety of widget sets.
I am agitating for a standard, with-the-OS, and so always-there-to-use, widget capability. Windows has this. The Mac has this. Linux does not have this. I would like Linux to have this. Instead, Linux has this, that and the other thing from third (and fourth, and fifth) parties, and when you try to install an app you're just as likely to be told you can't do that because you don't have the latest and greatest this that or the other thing. I don't want our customers to have that experience. Ever.
Now, you can tell me why you think Linux should not have this, and I will pay attention and (perhaps) even respect your opinion, especially if you read the LGPL before you next reply. :-) However, if you try to tell me that gnome is a widget set, I will proceed to ignore you for what I hope are obvious reasons.
Certainly, I'm quite familiar with the process. But what made you think we would want to distribute a package someone would have to compile at install time? What we want to do is provide an executable that runs when you execute it. We might go so far as to provide a tissue-thin w
I've fallen off your lawn, and I can't get up.
True, but up to now it looked as though any free Windows app using QT was going to have to be locked into the version 3.whatever release that came with the book.
That would work, except the license for the version included with the book explicitly states not to distribute it. It is for testing, evaluation, and learning only. Yes, I own the book, and yes, I have written Qt applications using its software. However, I was forbidden from distributing them.
24 beers in a case, 24 hours in a day. Coincidence? I think not!
While I love python, I don't think this would really qualify as being in the VB catagory yet. I do find python to be a far more enjoyable language to work with, but the beauty of VB is as much the IDE as the language. Eric isn't even close the last time I looked at it, with the GUI editing and code editing pretty far removed from each other. BlackAdder seemed to have the same limitation last I saw it as well. Admitingly it's been a while since I last saw either.
Everything will be taken away from you.
Methinks you're missing a few facts that would seriously affect your post had you known them.
Qt is the only major system library that does not allow commercial development without paying someone.
As far as I know, and I just can't imagine the GPL having such a loophole in it, if you write a commercial GPL application with Qt, you don't have to pay a license fee to them. Period. You got Qt under the GPL, and it would violate all of the rights the GPL guarantees you if you couldn't write a program that used Qt-GPL and distribute it. The only time you have to deal with paying for the damn library is when you want to use any other license other than the GPL.
The question isn't even whether it's "right" or "wrong" to pay Troll Tech, it's simply that vendors that try to put together commercial offerings out of Linux don't want to depend on a little company completely beyond their control.
One of the big things about the original Qt/GPL deal was that if TrollTech disappears or tries to take their library back, then the last open source version immediately becomes BSD-type licensed, so it gets freer than dirt. Depending on TrollTech isn't a big issue. Pay their license if you need to, fine. Don't pay their license and use the GPL, and there's *nothing* they can do that will hurt you.
Like what I said? You might like my music
OK, I'll bite.
The Windows GUI API has no restrictions on it at all.
One thing the Windows GUI API has in common with all GPL/LGPL/LMAO licensed software is that it comes with NO WARRANTY EITHER EXPRESS OR IMPLIED.
Additionally, if there is a bug anywhere in the Windows GUI API, that bug is in your software, and there ain't jack shit you can do about it. You're screwed. Completely and totally. What do you tell your customer? "OH gee, that bug is Microsoft's fault for building a shitty library." Right.
Contrasted with numerous open source libraries that you can do all sorts of wonderfulness with, you can fix the bug in the library!
Hm. And if GTK isn't your flavor, or Qt, you have several others to choose from. wxWidgets gives you all the creamy goodness of a BSD-style license, and the (blech) GTK interface in Linux. How do you get around any so-called limits in the LGPL for Linux? Simple, you're depending on wxWidgets, which uses native widget sets on each platform. So you're not confined by the LGPL in any way.
There are several toolkits available that do just that. Now, how many are there for Windows? What range of license possibilities are there?
Last time I checked there was only one, for th eopen source programmer, that is. Buy (that's right, buy) a license for Visual Studio, or only write C programs because otherwise you just don't have enough stuff to link, and you don't have the permissions you need to distribute dependent libraries. Or you could buy (that's right, buy) a Delphi license (or another of Borland's point-and-click languages), but then you can't even keep to the terms of your GPL license when you distribute! Because you can't provide source for libraries that aren't reasonably expected system libraries (the winAPI stuff is, but borland's wrappers *aren't*). What else is there? I'm sure I missed quite a few.
Hm, there's Qt, which requires you to buy a license. There's wxWidgets, which doesn't. There's FLTK, which doesn't (and is another one available under Linux). MOzilla provides a complete RAD environment, not necessarily point-and-click but what could be faster than jsut writing an xml file?
come to think of it, most of the really good shit is cross-platform and open source. I suspect the real reason people still use Microsoft's crappy libraries is inertia.
Like what I said? You might like my music
I'm getting a chuckle out of your debate with that fanboy. But here goes. :)
All I've been discussing is an unencumbered widget API so that applications can code to a standard target. This is a very specific area and that's all I am talking about here. We don't need any libraries other than those required to interface with the OS, basically we need to be launched, we need fopen() and friends, malloc() and friends, and we need a graphics API that supports windows and controls.
If that's all you need, why not wxWidgets? You can link to it statically and you're safe, as far as I know. I know the LGPL has some crap about providing object files in case the user wants to recompile underlying libraries, but that's been an obsolete method for quite awhile now. It's not necessary. If someone asks for them, you just say "If you're asking, that menas you're running on a supported platform and it's not my problem" and you ask your lawyer how it's legal that way. :)
As far as I know, linking to wxWidgets doesn't immediately incur the problems you associate with the LGPL because GTK because a system library at that point. Maybe it will anyway, I'm not completely certain, but that's provided as one of the selling points of wx anyway.
I am agitating for a standard, with-the-OS, and so always-there-to-use, widget capability. Windows has this. The Mac has this. Linux does not have this. I would like Linux to have this.
Man oh man does this irritate me. You can expect Qt or GTK+, but that's it. You can usually expect both at the same time (neither KDE nor GNOME satisfies everybody at the same time). Yeah, this little issue frustrates me too. Furthermore, I just can't stand targetting GTK. I've been targetting wxWidgets instead (using wxPython anyway, so I'm the Linux version of a VB hack). I'm *so* happy Qt is going to be GPL on Windows now. (I only write open source stuff, so this is obviously not an issue for me)
As far as what Qt accomplishes, you're still safe, so far as I know, except you have to buy a Qt license to use Qt in your application. Could get expensive, but numerous folks have reported "I think our TCO was lower with Qt!". So there's at least a high level of satisfaction fo rpeople that use it. :)
I don't personally think it's unreasonable for a free platform to require someone to pay in order to distribute non-free software of their own making for that platform. Call it what you want, I don't see how it's unreasonable. The point of the platform, unlike Windows, was never to make anybody money. The point was always freedom (except in the case of the kernel itself, but you'll find the point still had nothing to do with making money for anyone). regardless of what that other guy said, if you (or any other developer) isn't willing to deal with what we've built and the for-pay alternatives that get you onto this platform aren't good enough for you, then too bad for both of us. And I think we're better off accepting those consequences, because you can't come much closer than you have (for reasons you've said you have but haven't detailed, which is fine, they're probably confidential), and we have no obligation to come any closer than we have.
The thing you and yours need to be asking yourself is, "Is it a real possibility that I'll have to accept these terms someday? Can I hold out for better terms? Can I afford to?" If the answer is "yes", then there's not even any reason for us to try to make a deal. If the answer is "no", then you're not in the bargaining position you might think you're in.
Like what I said? You might like my music
While I love python, I don't think this would really qualify as being in the VB catagory yet. I do find python to be a far more enjoyable language to work with, but the beauty of VB is as much the IDE as the language.
VB and pyGTK/QT aren't even in the same league. VB allows one to plop down a shitty painted GUI, but what do you do when you have to layout the geometry programatically for internationalization/accessibility. I love it when we run even Microsoft apps on our 120 dpi system and the fucking widgets and graphics are fucked up.
I realize that there are some jobs where all you need are shitty little GUI apps and VB is the ticket, but don't complain when your job is outsourced to the lowest bidder (even though I know you will (this isn't addressed at the OP)).
GNAA? General Nutjobs Association of America? Green Nocturnal Asshole Alliance? eh?
The GPL can only grant exceptions to copyright, because it does not want to be a EULA which is believed to be unenforcable. If copyright does not prevent you from doing something, then the GPL does not prevent it.
The only way GPL3 could make in-house code illegal would be to somehow find a way that it is illegal under copyright. I think that is unlikely, all internal copying falls under fair use.
You also pay with time, because a lot of this stuff needs work, you have to pick and choose which one, etc. Time is money. With MS and Apple, the GUI just works, and you don't need to worry about it. You just dig in and make your app. That's what it is about. Not "choice", I and most other commercial developers don't give a northbound rat's southern expanse for "choice."
If you don't care about choice, then if nothing else you can just pick one and use it. You seem to be making the assumption that the standard on Windows is automatically going to be better than an arbitrary choice on Linux - you'll have to back that up with evidence (in my experience, the MFC is the worst GUI toolkit I have come across).
Secondly, there's still choice under Windows, for example the MFC, or Borland's toolkit. These may be wrappers to the same underlying API, but there are still significant differences to the developer. Does the fact that I had to spend time trying these out before I discovered that Borland made Windows development a lot easier mean we can make the same criticism of Windows?
The LGPL is very clear and very basic. You can keep you code closed and you do not have to license your code under the LGPL. The only requirement is if you make changes to the _original_ LGPLed code/library, than you have to release those changes. For example, you write you application in C/GTK+. GTK+ is an LGPLed GUI tool-kit. You do not have to release _your_ source code. You do not have to release _your_ source code under the LGPL. The only time you would have to release _any_ code is if you went and actually changed the GTK+ tool-kit itself, which is not someting normally done, since you just _use_ the tool-kit. This is no different than under MS Windows. Do you think Microsoft would allow you to modify their Win32 API and distribute those modifications as your own? Nope.
Gnome is a desktop environment. Gnome does have its _own_ API on top of GTK+ which is the tool-kit for Gnome. Here is a link to the GNOME Developer Platform Libraries.
GLib - GLib provides functionality which makes C more pleasant and convenient to use. It is used throughout the libraries of GTK+ and GNOME as well as in GNOME programs.
GObject - GObject provides the object system used for Pango and GTK+.
Atk - Atk - The ATK library provides a set of interfaces for accessibility. By supporting the ATK interfaces, an application or toolkit can be used such as tools such as screen readers, magnifiers, and alternative input devices.
At-spi - The AT-SPI library provides interfaces which are used by accessibility technologies. The documentation above describes the C bindings for these interfaces.
Gail - The GAIL library provides accessibility support for GTK+ and libgnomecanvas by implementing AtkObjects for widgets in these libraries.
Pango - Pango provides font and text handling that is used for GDK and GTK+.
GdkPixbuf - GdkPixbuf is a library for image loading and manipulation. The GdkPixbuf documentation contains both the programmer's guide and the API reference.
GDK - An intermediate layer which isolates GTK+ from the details of the windowing system.
GTK+ - The GTK+ widgets.
libXML - Powerful and feature complete XML handling library.
libxslt - The XSLT C library developed for the Gnome project. XSLT itself is a an XML language to define transformation for XML. Libxslt is based on libxml2.
libglade - The Libglade library gives applications the ability to load user interfaces from XML files at runtime. These interface files can be created with the GLADE user interface builder. Libglade is also capable of automatically connecting handlers to the signals defined in the interface file.
libGnome - Library containing extra widgets to let your GNOME applications shine.
libGnomeui - Library containing extra widgets to let your GNOME applications really shine.
GNOME-vfs - Library for letting applications seamlessly access remote and local files.
GConf - GConf is a process-transparent configuration database with a model-view-controller architecture and a number of other spiffy features. Like the Registry, but fixed up and on steroids.
Libgnomecanvas - The libgnomecanvas library provides a widget for creating interactive structured graphics in object-oriented fashion.
Libart - Libart functions - Libart handles the drawing capabilities in GNOME. All complex rendering is handled here.
ORBit - ORBit is an implementation of the C CORBA specification. It is among the fastest CORBA ORB's available.
Bonobo-activation - Bonobo-activation allows you to browse the available CORBA servers on your system (running or not). It keeps track of the running servers so that if you ask for a s
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
Now that there have been some significant changes at the head of Canopy have you asked them again to divest?
They might not be any more responding than the Yarro led canopy but then again, they might.
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
The Windows GUI API has no restrictions on it at all. None.
How naive can you be? You have to agree to the Microsoft EULA in order even to run the stuff. It is completely under Microsoft's control, they can change the license and the code at any time and impose whatever requirements they like on you. If you really annoy them, they just start introducing deliberate incompatibilities into their code.
If you find a bug, you can tell them and they will (for a price, generally speaking) figure out what is going on and either fix it or tell you what you need to do to get around it.
Paying Microsoft to fix bugs? Are you from an alternate universe or something?
Aside from that, there is a huge difference between one well defined, encumbrance free target and the multiple encumbered (and moving) targets that comprise the Linux patch-a-GUI fractured environment
Again, you are being naive. There are dozens of toolkits people use to develop Windows applications with. The one that Microsoft happens to put their stamp of approval on, their own, is one of the worst of the bunch. And it is something that Microsoft itself keeps changing. If you want long-term API stability, there are excellent choices for both Windows and Linux.
You don't have any of the big three graphics programs, for instance, and the OS sure could use them, given that the GIMP is all you have right now.
Unlike you, I realize that there are many different user communities with many different needs. Photoshop weenies like you indeed aren't well served by Linux, and I do recommend you stay away from Linux. Please buy yourself a Windows machine or a Macintosh--it's all the computer you will ever be able to handle, and you obviously have no ability to make a positive contribution to Linux. You go pay Adobe or whoever your annual tribute and they'll give you all the shiny, pretty buttons that you so much like to play around with.
Its only a "legal minefield" if you insist on static linking, which apparently you do for some reason. Most developers of commercial software I suspect will target their support to a particular version of a particular Linux distribution, which will mean that they'll just rely on the standard dynamic linking which avoids all the complicated language in the LGPL about static linking. When you're dynamically linking to an LGPL'd library, the license is straightforward.
If Bioware can ship their premier game, NeverWinter Nights, as one big static app except for the LGPL'd stuff it uses, which in the case of one of the libraries is actually shipped with the game itself in case the user doesn't already have it, most software developers will not have problems working with LGPL'd libraries in a Linux environment.
Maybe you have some issue specific to your project that you haven't mentioned that prevents you from using dynamic linking and thus makes this a "big difference" for you, but I don't see your warning as applying to most developers of closed source apps in Linux. As long as they dynamically link, they don't have to worry, and if they use a library that isn't popular and not likely to be on a Linux system, they can just ship it with their app. It just requires an install program to handle the details, which isn't any more complicated than install programs on Windows that have to worry about DLLs being present and the right versions, and so on.
Since most commercial apps can just dynamically link with the LGPL'd library, either the one the system provides or the one shipped with the app, where is the "legal minefield for [all] developers"?
Why put up with the overhead of the support code, when you can easily use the OS' GUI natively? Oh yea, cross-platform compatibility! But if you only want to use Windows, you would be an idiot for not using a mature, well tested, and well document GUI that comes at a very affordable price.... Free!... and unlike QT with no restrictions.
With that said:
I have to agree that a very small number (I can only think of Mozilla, Firefox, Sunbird, Thunderbird, and GIMP at the moment) of good software are cross platformed. But the vast majority are written in Windows which admittingly comes from being the 400lb gorilla of operating systems.
Anyway my points are:
a. come to think of it, most of the really good shit is cross-platform and open source.
Is not much to brag about when the complete population of cross platform software is microscopic when compared to the total population of software applications. And the majority of cross platformed software is proprietory between Windows and Macintosh, which doesn't support your open source argument either. I know I just blasphemed a sacred cow, but facts are facts. It is not my fault that the Windows and Macintosh platform has been around a lot longer than QT or GTK. It is also not my fault that even though UNIX is older, nobody really cared about it until Linux made it affordable. Besides being open source was not the argument, it was the ability to use the GUI library *WITHOUT RESTRICTIONS*. Open source has its place, but not as a straw man for a weak argument.
Funny thing, I use great cross platformed tools that don't use QT or GTK+ (or at least directly) and the authors don't have to worry about restrictions or processor type. It's called JAVA! Seriously, I went from loathing it to almost can't live without it. I still program in C for my embedded stuff, but I use Eclipse to do it (via CDT).
b. I suspect the real reason people still use Microsoft's crappy libraries is inertia.
Shows your lack of understanding of software development. While its true that the Windows GUI is not cross platformed, it was never designed to be! However, it is mature and that is something that can not be said of any GUI on Linux.
If you desire cross-platform compatibility, I recommend wxWindows. I don't use it for any windows only code because it adds a considerable amount of code. However if I am targeting multiple platforms, it is first on my list. I especially like its layout manager (similar to Java), and it doesn't come with all the BS associated with QT.
Given all the alternatives, QT is last on my list of recomendations. Save your money and use wxWindows. It is free, open-sourced, and has absolutely no restrictions (THANK YOU JULIAN SMART). Did I mention it is a damn good library too.
Brgds.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
You made a number of good points that I don't think I need to respond to, except for a couple that you missed. :)
While its true that the Windows GUI is not cross platformed, it was never designed to be! However, it is mature and that is something that can not be said of any GUI on Linux.
YOu're making a few logical errors here. I never said the winAPI was designed to be cross-platform. Quite the contrary, I said it was shit, and the good libraries you can use that are better than the winAPI *are* cross-platform. I intentionally didn't mention Java because it's *not* without restrictions.
Anyway, you also say the winAPI is mature and you can't say that about any GUI on Linux. Quite the contrary, both Qt and wxWidgets are mature. wxWidgets has been in continuous development since, what, 1992?
Another point you're seeming to ignore is that Windows has had steady third-party desktop development support for almost its entire lifetime. Unix, and specifically Linux, has not. You mention that "nobody gave a shit about Unix until Linux made it affordable", but you forget that Unix was deployed on machines that costed thousands/millions of dollars. Never was a serious desktop Unix released until Linux came along, and by then Microsoft had sealed their monopoly and already taken all the third-party developers.
All things considered, it looks like the GUI libraries we have in Linux are well-advanced considering the length of time the platform has been in existence. Just like you can't expect a 10-year-old to be able to perform brain surgery, I'll let you finish the sentence.
QT is last on my list of recomendations. Save your money and use wxWindows. It is free, open-sourced, and has absolutely no restrictions
I don't see the difference. I realize for many developers, GPL is too restrictive. I like it, though. I don't have a problem using Qt now that it'll be GPL on Windows as well. The reason I used wxWidgets instead of Qt was because wxWidgets was Free on Windows. If it costed money, I'd now be saving up to by Qt. Seriously. I'm going to move my desktop development to Qt as soon as I see the other necessary libraries (pyQt and pyKDE) supporting the GPL Qt in Windows. Were I to have time, I might try to help with those efforts.
When you get right down to it, I don't like using KDE and developing applications that depend on GTK, no matter how nice wxWidgets is.
Like what I said? You might like my music
I am confused. I didn't know there were any restrictions on applications written in JAVA, except the need for a JVM...
Anyway, you also say the winAPI is mature and you can't say that about any GUI on Linux. Quite the contrary, both Qt and wxWidgets are mature. wxWidgets has been in continuous development since, what, 1992?
Well technically QT was started in 1991. However, it didn't really have the feature set people wanted until QT2.2 was released in 2000. But I will give QT some credit on a good API. However, I still disagree about Windows GUI being crap (No I don't own stock in MSFT).
Two things to add in this civil discussion:
I have the original Blue and White box for Windows/286 that I bought in 1987. I didn't use it much because at the time I liked Digital Research's GEM environment. I also had a windowing API for DOS called Z which looked great. I would even say Z looked better than many of the widgets in use today... Now only if I can find that box (and my 5-1/4 drive).
I was one of the first to upgrade to Windows 3.0 in 1990. I picked it up at the reseller on the release date. It was a big improvement over Win/286.
Anyway since I shorten QT's history to version 2.2, I will shorten Win GUI to version 3.0. By my math Microsoft's API is 10 years older than QT, and 2 years older than wxWindows. If I use the development start dates then Windows 1.0 was announced in 1983 (released in 1985), which makes it 8 years older than the start of QT's development, and 9 years older than the start of wxWindows' development. My point is that I am old and so is the WinAPI ;)
As I said in my last post, wxWindows works better as a wrapper to the native GUI. However, it has a couple of more features (I don't remember what they are) if you elect to use the wxWindows code.
Despite what my last post sounded like, I do like the GPL. I don't believe all software should be free. I do believe if the author wants to release something to the public, he should use the GPL to protect his gift to the community. Widgets and smaller routines can use BSD or Public Domain. My biggest gripe is applications.
Case in point, ArgoUML. ArgoUML seems to be stagnant, while the comercial product Poseidon from Gentleware is coming along quite nicely. Needless to say, I feel uncomfortable about giving code to ArgoUML so that Gentleware can make $249 to $3500 on that contribution. Sure Gentleware may have spent some money to make ArgoUML commercially viable, but it doesn't appear that ArgoUML has benefited from it.
Gentleware now says that they are using a different codebase, and to be fair, Gentleware does offer a crippled "community" version of Poseidon for free.
I do believe that ArgoUML would be significantly better than it is now if it was GPLed.
Anyway, I am starting to go a little off topic...
Brgds. Bill
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
I am confused. I didn't know there were any restrictions on applications written in JAVA, except the need for a JVM...
You're still stuck with the underlying libraries. You do have choices, and they aren't good (not for GUI anyway, but Java's used mostly on the server the way I hear it). I'll admit I don't know a whole lot about Java, just that it can be tricky to get java programs running from time to time (Sun *won* this part of the antitrust case, mind you).
Well technically QT was started in 1991. However, it didn't really have the feature set people wanted until QT2.2 was released in 2000. But I will give QT some credit on a good API. However, I still disagree about Windows GUI being crap (No I don't own stock in MSFT).
I don't like the Windows GUI at all, period. I find it mind-dumbing. I think that when I use Windows I become ADD, seriously. Heh. As far as the API itself goes, I dont' have a lot of experience with it, but what I've seen has been pretty convoluted. I went into MFC long enough to figure out that I didn't like it. I dropped Windows soon after that anyway, so the question of whether I'd like MFC after going further into it is moot: there's no reason I would do such a thing.
I don't believe all software should be free.
I agree that not all software should be Free as in Beer, you know. But I do think it should come with source code and you should have certain rights associated with it. :) In my perfect world, software patents would exist and only apply to the binary, copyright would only apply to the source code, and to get a patent you'd have to give up the source code. I think that would in and of itself solve 99% of the Free/Proprietary discussion to everyone's satisfaction. It may not look like it would from here, but I feel confident that if implemented, everything would turn out fine and we'd all look at each other and say "Why did we ever start that mess in the first place?"
Widgets and smaller routines can use BSD or Public Domain.
I have a pretty strong feeling that libraries should have non-restrictive licenses. I don't like GPL libraries, but I'll use them. Qt is so beautiful in Linux that I'm looking forward to learning all about it. If the API is all it's cut out to be, I may never look back. But i'm happy using GPL libraries, even if any library I ever write will be more permissive. I also think libraries should come with source code and so forth. It's an integral part of your program during execution, why would you have such a large part of your own program in a blackbox? You're still responsible for bugs that are caused by the library! So, yeah, we may not see eye to eye on all of this.
The thing you might want to keep in mind, and I was saying this to someone else actually. Many of us that write Free Software don't give a shit about commercial viability. I really don't care if the development model makes money or not. I don't define Right and Wrong in terms of how much money it generates for the economy, and I don't really give a shit if thousands of programmers have to find new jobs because they can't make money with their software in a freer IT world. I think, after some pretty thorough analysis, that that's not ever going to happen. I mean, if all software was suddenly open source, I don't think we'd see thousands of programmers go unemployed. Quite the contrary, I think it would be a great boon to our economy! (We could go into it, but I really don't feel like it, sorry) So when people come to Linux and say "There's no standard GUI widget set, it's a legal minefield, we can't do it" all I can say is "every other platform is a legal minefield and there are plenty of good widget sets. maybe not great, but there's plenty of good software that uses them, so think about it."
When a commercial company sees the tradeoffs as worth it, great! Come along and play with us. When they don't, we both lose. Too bad, but it's because of choices we have both made and I'm not about to unmake mine. Neither do I expect them to unmake theirs.
Now I'm off on a tangent.
Oh yeah, you wanna see a hairy API? The first widget set I ever worked with was for AmigaDOS 1.3. *THAT* was frickin' hairy!
Like what I said? You might like my music
Considering GTK+, wxWidgets and QT are all available on windows, it's kinda not a good point.. There are also several f/oss C++ ide's and compilers, as well as several f/oss toolkits and compilers for other languages.
.net with wx.Net (wrapper for wxWidgets) with very few cross-platform issues... now, for advanced graphics, and 3d, it gets harder.. for audio, harder still... as it stands wx.Net is probably the easiest path to cross-os development..
a complete app can be made in
Michael J. Ryan - tracker1.info
You don't need to pay anything to have access to a very broad spectrum of OS widgets when developing for Windows
Where'd you get that idea? Windows XP Pro ~$500. Application framework and tools comparable to Qt from Microsoft ~$600. Qt ~$1000. So, access to those widgets on Windows costs about the same as Qt cost on Linux if you are developing commercial applications.
Or you could use a free widget library like GTK+ if you were really worried about the money.
If I go that way, I've not bought the OS at all. But I still have the opportunity to write applications for the widgets, because there is no cost or obligation for using widgets under Windows, contrary to your attempt to make it seem so.
You just can't accurately say that charging for the OS, or the development tools is the same as charging for the widgets. It's not the same thing at all. And if you really want to get into realistic assessment of costs, Linux has cost me more in time to get set up, and I still don't have a generally usable set of widgets I can target. My time is expensive, and by that metric, Windows is not -- and Linux is.
Re GTK+, it is LGPL encumbered, hence not useful to me. If they want it to be free, then they need to make it free, as in, "here, do anything you want with this." That's free. "Here, you can do this limited set of typical development tasks, but not these other typical development tasks (like mixing my stuff in with their stuff, or proprietary stuff in with their stuff, or patented stuff in with their stuff)" is not free. It is (a) a legal minefield, and (b), annoying to need to bring a lawyer in when you want to just write an application under a GUI, and (c) even more annoying to have the lawyer tell you "nope, you can't use this."
But Linux doesn't have a standard GUI-API, it has add-ons. Tons of them. All with different licenses and costs and limitations and features. All I want is for Linux to develop a nice, standard set of widgets -- basic windows, buttons, checkboxes, lists and so on -- that I can legitimately use without having to read and subsequently compensate for a bunch of legalistic crapola. I want these to work on every Linux machine, and I don't want to have to compile the application for every variation of Linux out there. As long as these issues remain unsolved, I'm not interested in going forward.
Anyway, Windows widgets and use of the API is indeed free. You can do anything you want with them, from any software platform or cross-development environment you can manage to cobble up, and no one will ever say "boo."
I've fallen off your lawn, and I can't get up.
Darwin doesn't have a standard GUI-API either, yet you said MacOS was okay. Like MacOS is an environment layer on top of Darwin, KDE is an environment layer on top of Linux*. When you are using KDE as your "OS" you have a standard API, it's called Qt. If you are using the GNOME "OS", you also have a standard API, it's called GTK+.
Your problem with standard APIs seems to be purely marketing and not about the technology at all.
Part of the cost of the operating system is to provide you with those widgets. The cost is just passed on to the end user instead of the developer in the cast of Qt. You mentioned WINE, but that is a reimplementation of the Windows widget set.
Speaking of WINE, there is a widget set for Linux that you said suits your requirements. Why don't you use it?
How do you plan on modifying the Windows API on Windows, like you plan on doing with GTK+? According to your post you have big plans to modify GTK+**, so one would assume you'd want to make those same changes to the Windows API. But last time I checked the source wasn't even available, let alone license issues.
* And various other systems, I know.
** "Here, you can do this limited set of typical development tasks, but not these other typical development tasks (like mixing my stuff in with their stuff, or proprietary stuff in with their stuff, or patented stuff in with their stuff)" is not free.