Trolltech announced today that they will release a GPL version of Qt/Mac on June 23rd at the Apple's World Wide Developer Conference (WWDC) 2003 in San Francisco taking their successful dual licensing strategy for Qt/X11 to the Mac. Also the upcoming Qt Script for Applications (QSA), Trolltech's scripting toolkit for Qt-based applications, will be available under a dual license on Mac OS X.
Sam Magnuson from Trolltech already got much of KDE building on Qt/Mac a while ago (screenshots showing Konqueror,
Kontact, Games and KOffice). The new license now offered allows to distribute binary builds of KDE for Qt/Mac soon.
Dot Categories:
Comments
As we all know, Unix on the desktop is about 1% and MacOS (in general here, i think OSX came in like 1.5%-2% this was talked about last year on the MacApp list) is about 4% of the desktop... Macintosh has had a looooong history of open/free/shareware software (Hyperarchive anyone?) so this is going to be a welcome path for developers to port KDE apps to MacOSX and MOST importantly port MacOSX apps to KDE!
Anyway, now Im happy because now native KWord can ship on OSX, not that it matters because their Xlib vesion has flawless printing, and AA fonts, still native is cool :)
Cheers
-ian reinhart geiser
> Macintosh has had a looooong history of open/free/shareware software
> (Hyperarchive anyone?)
Hmmm? Shareware is very different to free software.... Mac hardly has any history at all in that field.
> and MOST importantly port MacOSX apps to KDE!
How does that work? MacOS X apps are built on proprietary APIs, not Qt. You would have to rewrite the apps in order to port them, and AFAIK there are no open source programs that are sufficiently compelling and unique to warrant that. It'd just be the same old thing, open source code gets ported to MacOS, but none comes back. It's expected, same thing has been happening for years with Windows. Making even open source Windows programs run on Linux is very hard, but the reverse in not true (to the same extent).
I'm not sure how this benefits KDE, except perhaps by having more users of Qt based software (but then again mac users could use that before via X11).
The nice thing is that Qt/Mac software, unlike X11 based Mac software, looks and feels native. Thus, software can be coded for OS X and QT/Mac, and easily be ported to Linux and Qt/Linux.
Yes, that's true enough. I'm not convinced Mac developers would use a non-native toolkit personally. Boy, do they love their cocoa ;)
Also, as I stated later, I think it uses a skin. A good skin, but still not native controls mind...
> I'm not convinced Mac developers would use a non-native toolkit personally
I dont think the Mac version of Qt is marketed for primarily Mac developers, but insteadd for people who want to develop apps cross platform. Mac users are being increasingly exposed to free software and I think more and more people
> Also, as I stated later, I think it uses a skin. A good skin, but still not native controls mind...
Based on what I've heard, it uses carbon. Qt-Mac apps, such as Psi (great app-- best jabber app ever btw, use it all the time) or TOra (which hasn't officially been released for OSX, but preview builds work), look and feel just like Carbon apps. If it uses skins, i'll be VERY suprised because it works with the carbon no-lines hack. Only thing that seems to be weird is the toolbar handle but I think that's because carbon doesn't natively support moving around toolbars. MS Office v.X has it's own toolbar handles as do any apps with that functionality.
Right. Early versions of Qt/Mac used a skin (pixmap based QStyle), but we changed over to using the OSX Appearance Manager API to draw widgets some time ago.
This is native, even if an OSX machine is using a third party (unsupported) OSX theme, or if apple brings out a new theme then Qt apps will draw widgets using that theme.
Don.
cocoa, once you start using it, proves to be IMHO the greatest interface and programming environment ever. don't get me wrong, i'm still a 40% linux user, and gcc is minimalistically awesome. but the 40% mac user in me loves cocoa to death. and the dev tools are free, like they should be. forget visual studio! but this Qt/Mac looks promising, considering that i now do some of my linux coding in Kate running inside X11 on Mac OS X, but it's a hindrance to have to run X11 just to get Kate to run. great job, guys! (in case you were wondering, the other 20% of me is windows XP!)
If you like Cocoa and Linux, you might want to look at GNUstep (if you haven't already). It's based on the same OpenStep framework as Cocoa.
I think, from the Konqueror shots, it just looks like a skin, because the Konq toolbars don't integrate so well into a Mac look.
MacOSX doesn't have a standard widget for windows-style toolbars handles. That's why it's like that. Microsoft apps, such as Office v.X are similiar-- but imho, a better apporach-- toolbar is a mini window at the top of the screen.. that isn't very OSX like, but is at least classic macos like. It's not a skin. You can prove this by running one of many aqua themes from resexcellenece =)
Other apps on OSX that have Windows-like toolbars also have their own custom toolbar handles. Even apps made in Cocoa do.
They use Carbon, after all, which isn't really native like Cocoa is. Besides, I think the only reason the KDE screenshots look like they're using a skin is because the KDE toolbars don't fit the OS X look very well.
> They use Carbon, after all, which isn't really native like Cocoa is.
Yeah, Qt/Mac uses Carbon, but this doesn't matter anymore in since MacOSX 10.1.5. Both Cocoa and Carbon in 10.1.5 (and 10.2.x) go through the Appearance Manager before being sent to the Window Compositing Manager. Back in 10.0.x and 10.1.0-4, Carbon apps often looked similiar to Cocoa apps, but had "one pixel off"-type of problems that didn't always make them feel like Cocoa apps. This isn't true anymore and you're likely not to notice the difference.
Apple did a real great job with this after initially blundering it up in the initial release(s) of OSX. It's a good model that Microsoft didn't follow between win16 and win32.
shipping with KHTML, tcsh, apache, X-Window System, Mach-Mk/BSD/Darwin etc.
This is great news
Oh yeah Unix on the desktop == 1% ... I expect that to increase to greater thatn MacOS share very soon. If you audit a campus for "type of desktop" you'll see lots of Unix and it's increasing.
Our campus is more like 5% Unix or more ...
Erm, MacOSX is perfectly a form of a Unix (but isn't officially a OpenGroup-labelled "UNIX"), and has more of a right being called that than Linux, which is only Unix-like and not directly decended from either svr4 nor bsd, does.
See http://www.levenez.com/unix/history.html
>> Macintosh has had a looooong history of open/free/shareware software
>> (Hyperarchive anyone?)
>>
> Hmmm? Shareware is very different to free software.... Mac hardly has
>any history at all in that field.
No. From a HyperArchive search, all of these are free, with source code that one can reuse.
- SpriteWorld
- TransSkel
- Mozilla
- Mesa/Mac
- GW-Ada/Ed-Mac
- Brian Hook's 3D tools
- AIFF/DSP framework
- StonerView "produces a weirdly hypnotic helix of rippling colors"
- ircle, IRC client
- Blender/Mac, 3D modeler
- Jotto II, a word game based on logic and frustration
- Quesa
- Darwin
- QuickTime streaming server
- Road Runner/Mac
- GCC enhancements.
- Improvements to KHTML and KJS.
- Countless enhancements to other free software.
> How does that work? MacOS X apps are built on proprietary APIs, not Qt.
Qt is as much a proprietary API as OpenStep.
> You would have to rewrite the apps in order to port them
Not using GNUStep.
> It's expected, same thing has been happening for years with Windows.
It is true: the rest of the world is still catching up to Unix circa 1980.
But we are catching up.
> I'm not sure how this benefits KDE, except perhaps by having more
> users of Qt based software (but then again mac users could use
> that before via X11).
GNUStep and Qt are the best multi-platform solutions that I know of right not. Java needs speed and a free, obvious RAD environment. I just became exposed to Qt and it was by Qt/Mac. Perhaps now I will port my free software to Linux.
Everyone wins as programmers become free to distribute on multiple OS's.
Cheers,
James
[email protected]
remove _uhuh and the second underscore to email
This is real welcome and great news. It means several things.
1). KDE apps running natively on OSX without X. Yummm! I've been running KDE apps in OSX through fink for a while now-- they work well, but it'd work so much better, and natively, through Qt/Mac.
2). It would be easier for MacOSX developers, such as Apple, to use KDE technologies, such as khtml. :)
Mad love and props to TrollTech!!
Yeah, maybe the will use the KHTML engine to build a nice browser!! I wonder what they would call such an app...
This is the best time to start a UI revision team improving KDE programs' UI by creating .ui files of suggestions. I expect something like that to work best with OSX users since they tend to be very picky about UI's. Let's take that opportunity. ;)
In fact, I could tell when people from TrollTech started to port parts of KDE to Qt/Mac :)
Now, ask yourself, why would they do that? KDE is a huge way to show off what Qt can do, and porting it to Qt/Mac would undoubatly get more buyers of the commercial Qt/Mac.
Thanks Trolls!
"Hell, let's just merge Qt and KDE, release for all platforms and be done with it."
That's not a statement from the in-charge-guy at Qt, but I wish it was. ;)
in-charge-guy at TT, of course. But surely you got that.
Maybe QT+KDE+GNUstep running on Mach Microkernel and BSD ... practically equals free less fancy OS/X where all apps are easily portable over to the commercial OS
Eventually a replacement for X would be nice though :-)
I need to port a Win32 app to the Mac.
I started a feasibility study of using wxWindows to do this, but their Mac port is a little too behind the curve to use at this point.
Could the same study be done with the GPL'd QT/Mac? I sort of remember QT's stance being that you couldn't use the GPL'd version unless you're writing GPL'd code - even if you're willing to pay up before releasing your code.
My problem is, without a feasibility demo, I can't get my company to spring for commercial QT, but the company's even less likely to commit to GPL - especially for the purposes of said feasibility demo. I need to operate below the radar at this point, and a strict GPL requirement would make this impolssible.
Any comments?
Easy. The Qt evaluation program.
http://www.trolltech.com/download/qt/evaluate.html?cid=10
The Qt Evaluation program was made for people/companies exactly in your situation.
I don't understand your dilema. You may use GPL code internally without releasing it. As long as this is just a feasability study, you should have absolutely no constraints. If you decide to bundle your app or sell the app then you have to make your application GPL. The GPL makes it easy to operate below the radar until you are ready to sell your app. It sounds like that is the time you would want to purchase your commercial license or better yet GPL your code!. Just my 2 cents.
Brian
I thought QT specifically said you can't use the GPL version to develop an app and then pay up when you decide to release a non-GPL version.
But other posters mentioned a QT evaluation program, so I guess this problem's been eliminated.
Thanks,
Rob
GPL is GPL and Trolltech cannot prohibit using GPL version for any internal purposes, whatever they are. They are just unhappy when 5 programmers create commercial QT application, then they buy 1 licence, recompile application and release it. Such a behaviour seems legal to me, but a bit unfair, of course.
Jerzu
They can't put restrictions up the GPL, but they can put any restrictions they want on their own license for Qt Commercial. They can say, "Qt Commercial can't be used in the development of an application that has previously been developed by Qt Free Edition without keeping the app open sourced..."
Of course, I've never actually heard trolltech going after someone for doing this...
> They are just unhappy when 5 programmers create commercial QT application, then they buy 1 licence, recompile application and release it.
Yeah, this policy was made to stop this from happening.
Actually, there was recently a discussion on the Qt mailing list covering that topic.
The result was the following:
If parts of an application have been developed using Qt/Free you can't license that application with Qt/Commercial.
This was also confirmed by Dimitri from Trolltech. However, this seems hard to enforce. Still if you have product that uses Qt/Commercial and it somehow turns out that parts of this application have been developed using Qt/Free, you're violating the license terms and should probably call your lawyer ;)
--
Stefan
From the announcement, this appears to be GPL only. It is not the X11 GPL/QPL licensing. What this means is that non-GPL but still 100% Free Software applications cannot use it. Examples of stuff you CANNOT port to GPL Qt/Mac include Cervisia, Kicker, and PixiePlus.
Please, Trolltech, offer this under the QPL as well. It makes absolutely no sense to have to purchase the proprietary version of Qt in order to distribute Open Source Software.
Please, Trolltech, offer this under the QPL as well. It makes absolutely no sense to have to purchase the proprietary version of Qt in order to distribute Open Source Software.
If you purchase Qt you can distribute your Qt app as closed source. Read before you post.
And you should understand before you post.
Uhhh... he was talking about free and open software that simply wasn't GPL'd. Examples of this are anything in KDE which is BSD, QPL, Artistic, etc.. licensed.
Much of this is made possible by the dual licensing.
I don't know about the other licenses, but BSD apps can certainly be linked with GPLed QT, it's just that the derivative work is licensed under the GPL.
Nope, since QT is also under QPL which allows any and all true FOSS licences the app can keep its BSD licence.
We are going in circles here.
Cartman was asking for QT/Mac to be licensed under the QPL - it isn't at the moment.
Then anon asserted that this prevented BSD licensed software from linking with QT/Mac legally.
Then I pointed out that this wasn't true, since you can link BSD and GPLed software, with the derivative work being GPLed.
The fact that other versions of QT are available under the QPL doesn't mean that the Mac version is. The Mac version isn't, and this means that if you want to link to it, you must agree to the GPL, pay for the commercial license, or use the evaluation version, which expires after 30 days. None of these are the QPL, and only the GPL is feasible for an open-source project to use.
Yes, you are right, I got fooled by the line stating QT/Mac has a dual licence (commercial, GPL). I guess I better start calling QT/X11's licencing scheme a triple licence (commercial, QPL, GPL) for avoiding confusing myself again.
That's like saying you can vote for whichever candidate you want, so long as you vote for the one Trolltech wants you to vote for. It's not a BSD licensed app if it must be licensed under the GPL.
If I'm interpreting correctly, the app+Qt combination is GPL licenced on the Mac; if you ship a binary dependant on Qt/Mac, that binary as a whole is under the GPL. If your app is also available under another GPL-compatible licence, the end user can obtain that application under *that* licence, and is only then forced back to GPL if they distribute a Qt/Mac binary based on the free edition of Qt. If they use the commercial edition of Qt, they are not forced to GPL the combination.
No.
You write code. The copyright on this particular code belongs to you. This work can be licensed however you want. Let's say you pick a BSD-style license.
When linking it to the QT toolkit, you are creating a derivative work (the binary) based upon both your work and Trolltech's work. Now, you need a license from Trolltech to distribute this.
Trolltech offer a number of licenses. If you are linking against the Mac edition, you have the opportunity of paying them for a license (the "commercial" license option), you can choose the evaluation license (which expires after 30 days), or you can choose the GPL license.
The first two options let you distribute the derivative work however you see fit. The GPL has a clause that requires any derivative works to fall under the GPL license.
Now, somebody else comes along. They may want to distribute the derivative work under the GPL. That's okay - since you offered your copyrighted work to the public via the BSD license - which allows incorporation into any and all derivative works without any other requirements. They can therefore distribute the derivative work under the GPL. This is what is meant when people talk about "GPL-compatible licenses".
Now, another person comes along. They have a commercial license for QT, and wish to distribute the derivative work in binary-only form. This is also okay - your work is under the BSD license, which allows incorporation into any derivative works, and they already have a license saying that it's okay for them to do the same with Trolltech's work.
At no point has your original work not been available under the BSD license. If people have a commercial license for QT, they can give away binary-only forms of your work. If they port it to a platform where QT is available under the QPL, they can link it with that and give away binary-only forms of your work. If they partially rewrite it so that it uses a different toolkit, they are subject to that toolkit's licensing constraints.
It is only the Trolltech original work's license that is restrictive - you are free to license your work any way you see fit, and you can pick the BSD license if you so desire. But you can't relicense Trolltech's works for other people, you can only ask them (politely) to offer licenses that you want them to.
When linking it to the QT toolkit, you are creating a derivative work (the binary) based upon both your work and Trolltech's work. Now, you need a license from Trolltech to distribute this.
Linking does not create a derivative work. In the case of static linkage, the GPL applies because you are actually distributing the library along with the binary. But in the case of dynamic or runtime linkage, you are not copying, modifying or distributing the GPLd work, so the GPL should not apply. Trolltech and the FSF disagree, put here's a link to an informed and educated counter-opinion by the general counsel of the Open Source Initiative: http://rosenlaw.com/html/GL18.pdf.
I don't have my own team of lawyers, so I find it easier to simply ask Trolltech to offer Qt/Mac under the same terms as Qt/X11, rather than challenge them on the matter in court.
It's simple: Even dynamic linking creates a derivative work.
The reasoning is not legal, it's technical. Dynamically linked binaries contain information from the libraries against which they were linked against. In the case of linking your application against Qt, you are incorporating code compiled by from the Qt headers (which is under the GPL) in your binary.
Linking as "creating a derivative work" is so widely accepted in the community that I would certainly not want to go against it. That's a good link David, I was aware of the position, but unaware of the document to go with it. Thanks.
I personally disagree with the technical reason you cite, anon. Otherwise, merely cloning the interface would be enough to infringe on the copyright (remember Harmony?). There are fringe cases such as macros though.
Well it does mean that, and as far as I know it is true.
If you clone the interface/macros etc in a clean room manner, then you've hit the jackpot. Of course you have to link against your clone and make sure it actually works with the real Qt.
Logical conclusion...
Dynamically linked binaries contain information from the libraries against which they were linked against
The information they contain is limited to a reference to an interface. You are using the library in its intended manner through a published API. Absolutely no code from the library is incorporated into the application. A good analogy is a hyperlink on a webpage. Does that hyperlink indicate derivation from the linked page?
p.s. Macros and inlines may be an exception. If there are few of these then Fair Use may allow their fair use [sic]. If there are a lot of them, the argument might still be made that implementation has been placed into the API allowing it to be used by the intended and customary mechanism.
I don't want to distribute my Qt app as closed source. I want to distribute it as 100% BSD licensed Free Software. I want to distribute my software with zero restrictions, but Trolltech is telling me that their "free" software requires that I restrict the rights of my users.
GPL doesn't restict the right of users, on the contrary, it protects users by not allowing companies to come along and integrate the open source code into their products and close it down into proprietary lock-in software as is unfortunately possible with BSD-style licences.
Basically, the GPL restricts the freedom of people to restrict the freedom of others.
When it is not allowed for my users to use my software because Qt/Mac is GPL-only, then the GPL is indeed restricting the rights of my users.