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 :)

> 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).

> 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.

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!)

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.

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.

>> 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.

> 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.

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. ;)

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.

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

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.

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.

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 ;)

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.

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.

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.

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.

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.

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.