Someone asked me my opinion on the licensing of Qt a couple of days ago; not that my opinion is worth that much but this is a relatively interesting change. On the face of it, moving to LGPL isn’t a major difference – obviously, it enables proprietary software to use the library without paying a commercial license, but the market for third-party applications on GNU/Linux is pretty slim. The relaxing/opening of the development process is much more important, assuming that it actually happens, although I imagine that won’t sink in for a little while yet either.

What this does remind me of, though, is a blog post from the middle of last year. It took me a little while to find it again, but I think it’s worth quoting a little bit of it. The subject of the post is “Flames Welcome (Is a Qt GNOME desirable?)“:

“Is this going to happen?

“First off this is a highly unlikely scenario. The planets would have to align, Qt would have to go LGPL, Nokia would have to loosen controls on contributions to avoid a fork, the Qt team would have to accept a community which has slightly different goals and the GTK+ team would have to signal their willingness to move.”

So, what I think is interesting here is that this alignment of the planets seems to have half-happened: Qt has changed its license, and supposedly it will be easier to contribute. While the original idea had some roadblocks in the way, it does seem now that there is nothing preventing this scenario.

The rest of the blog post is well worth reading: it outlines some of the many advantages in moving to Qt. The main thing, for me, is that Qt is a relatively complete toolkit with a reasonable design – it’s not perfect by any means, but a lot of what people want Gtk+ to do is already being done in Qt today. I suspect the effort needed to catch Qt up to Gtk+ in those areas it isn’t as hot would be comparable or less than getting to Gtk+ 3. And while the ISVs currently using Gtk+ would be expected to switch, Gtk+ seems to be an API break anyway.

Of course there are plenty of downsides – it would be a huge effort for not much immediate gain. However, I don’t think the decision would be usefully made on looking for immediate gain – it would need to be a longer term play in any event. Which leads me on to my second point:

In these days, it does seem very bizarre that application designers are so thoroughly tied to widget toolkit. Clearly, when you need to write custom widgets then you’re locked in, but it’s a bit odd that many apps create their UI from code rather than from some kind of designed file. Perhaps the switch shouldn’t be to a new toolkit, but a more standard way of describing UI. Qt Designer has a format, MonoDevelop/stetic has a format, there’s libglade or whatever, etc. etc. What would be really useful would be a better, more standard, system for writing the simpler apps which don’t require much in the way of custom widgets and things: maybe as well as being able to choose between Gtk+ and Qt at runtime, you can maybe also choose between Flash, or AJAX/HTML – or some other future toolkit which doesn’t yet exist…