Hacker News Reader

Comment by lazypenguin | Hacker News Reader

Qt is great and I get disappointed that the discussions surrounding it often devolve into nitpicking the pricing and licensing terms. Seems people are less willing to pay for high quality tools these days.

On the technical side, the qt quick desktop styling is intriguing. My main use case for Qt is for desktop applications and while qt quick is often recommended I usually go for qwidgets instead. 9/10 times I need a traditional interface with menu bars, forms and tables. While qt quick lets me make nice looking UI, I often need something that just works similarly to how a traditional desktop application works, looks be damned. Im curious if they'll manage to close that gap in qt6 but I'm skeptical which means I'll probably stay on widgets for the foreseeable future.

View on HN

> Seems people are less willing to pay for high quality tools these days.

On the contrary, I think companies are more willing than ever to pay for quality 3rd-party tools and software. The reality is that the Qt licensing costs are a bargain relative to time saved for enterprise customers. It's not even a question at this point.

The complaints usually come from people thinking of lean startups or selling hobby projects, where the licensing overhead is another non-trivial number on your cost of goods sold. Many of the complaints here would only realistically be a problem for someone selling a very small number (<100) of their product per year with very low margin, which is far more rare than people think.

Regardless, Qt still has a separate small business license with a different pricing structure: https://www.qt.io/qt-for-small-business

Another concern for lean startups and hobby projects are that you cannot develop them without first paying for a Qt license. Their licensing clearly states that you cannot transition from the open source license to a commercial license.

I've spent some time working on a desktop application I hope to sell, but I wont consider Qt, because I'm not even sure I will follow through and finish the product. When it's just a hobby class side-hustle, my first step isn't giving Qt $200 this month, and $200 next month, while I work on my side project for 2 hours a week after the kids go to sleep.

This.

There is the "small business plan" which reduces it down to $500/year, which isn't outrageous, but it's still $500 for something I probably won't get that value out of because of the likelihood of the project ever finishing.

Instead, I'll find other ways to do it. If Qt was free under $X, $500 under $Y, and $$$ over $Y it's a much more persuasive argument. Unreal manage it :)

You should be fine with the LGPL license of Qt.

I would like my application to be easy to distribute. I was hoping to distribute it as a single executable file. I don't think this is possible with the LGPL?

You would distribute it anyway as one file, because you're going to pack it into something which does the install. i.e. dmg/pkg file, installer, Linux package, etc.

I don't think I've ever seen a Mac app which consisted of only one file. The whole idea behind .app apps is that they consist of several files.

> I was hoping to distribute it as a single executable file

I don't know of any applications whose scope would require to use Qt to come as a single file.

The installer (be it dmg, exe, pkg, whatever) will, but then it's not a problem with the LGPL.

As I understand it, Qt is released under a mix of GPL and LGPL, so as long as you release the source code of your application you should be fine.

I'm not sure how they can prevent you from transitioning from an open source license to a commercial license? You can develop your app for a year either as open source or privately without releasing anything, and then decide to purchase a license? Not sure if I'm missing something, but how does could they prevent this (legally or practically)?

The license explicitly specifies that you cannot start developing using the free license and then purchase a commercial license when going commercial.

Can you please cite and link the relevant part?

> If I have started development of a project using the open source version (LGPL), can I later purchase a commercial version of Qt and move my code under that license? This is not permitted without written consent from The Qt Company. If you have already started the development with an open-source version of Qt, please contact The Qt Company to resolve the issue. If you are unsure of which license or version to use when you start development, we recommend you contact The Qt Company to advise you on the best choice based on your development needs.

https://www.qt.io/faq/tag/qt-commercial-licensing?hsLang=en

People bring up this misconception every time Qt is mentioned. It is free as in beer (LGPL) at least on desktop. You can sell a proprietary commercial application using Qt without paying a dime as long as you dynamically link Qt (which can be included in the installation bundle).

(But you shouldn't. There is little need to distribute closed source software anymore. If you are shipping a binary with valuable trade secrets, then it won't be secret for very long. You can do server-side rendering of all the UI like all the large cap tech companies do then it won't matter if the client application at the edge is open source.)

I similarly stick to QtWidgets, but have to say they don’t seem to scale well in Windows. That’s likely a function of the underlining Windows components, but it’s undeniable, sadly. QtQuick / QML deals better with that scenario, but one ends up having to reinvent a bunch of things (ironically, considering the “quick”) that QtWidgets have had for years already.

Qt posts to HN never include a single technical comment. It is unfortunate, but I suppose that's mostly due to the particular subset of programmers that visits HN.

Can you provide an example of a comment sufficiently technical to be worthy?

I'm saying there isn't one (well, a hundred messages in and there are a handful at last :) ). Nobody is discussing what's new for instance. I'd be interested in the status of moc (isn't mentioned on the page).

The MOC is still present in Qt 6.0, if that is what you are asking.

Even with CMake?

Yes. That's orthogonal. And people have been using CMake with Qt (and moc) for almost as long as cmake exists

Question should be "even with C++17?". Cmake has had moc and uic support for years now. The question is why they don't leverage the c++17 features to get rid of moc, ffs.

There is some features used by moc expected in c++23 like reflection. I think that in qt 7 they will drop moc an some stl replcements in qtcore

> Even with CMake?

Why would Cmake eliminate the need for Qt's moc? Cmake is a build system/makefile generator. You don't generate c++ from form files or Qt-annotated C++ files out of magic.

Weird, last time I noticed Qt being discussed on HN, I got a really useful and technical comment which is still something I'm basing my future plans on.

You can't say that and then not link the comment!

Weird, can you link it?

It is the culture of free beer. On my circle most developers don't even care that sites like HN and Reddit exist.

They do whatever is needed, mostly with commercial software, and then leave to home, where their hobbies are completely unrelated to coding.

In what concerns Qt 6, I care about the multiple 3D backend, C++17 and the upcoming QML to C++ compiler.

Mind that nice things also come from the crowd which you call hipster, whereas your 9-5 crowd is writing some dotnet accounting app. I couldn't care less about what enterprise java developers do, not because I disrespect them, but it's not discussed because it's not interesting.

It seems like you somehow think paid shitty software was / is better than free shitty software. Mind that free shitty software has its upsides too.

And counterpoint: People don't hate intellij like they hate oracle or Qt. People hate takeover by suits.

I bet the majority those non hater people using InteliJ don't pay for it, and the enterprise customers are the majority of their paying customers, and most likely they also get some money from godfather Google thanks to Android Studio and Kotlin.

Speaking of which, if eventually Google ends up buying them, lets see how much love is left.

Yep, that doesn't counter my main point though.

We all know there's a dark matter of enterprise programmers, out of which a good portion is perfectly capable, but just doing it as work 9-5. But that's not what we expect to see on HN/Reddit/open source projects.

You seem to not like that dev tools are not a sustainable business today. That was kind of inevitable. Using paid dev tools alienates contributors in open source development, and students/3rd world can't afford them, and lot of paid tools are specialized to some domains (think SAP). Doesn't help that proprietary vendors try to lock down stuff and lot of rent seeking behavior (Oracle, qt company)..

Atlassian made some steps in lowering this barrier of entry, and built a pretty good business IMO, though not much developer specific.

If there's anything to learn, unless there's an app store like low barrier to entry platform for dev tools with student discounts, free trials etc.. people may learn paying for high quality developer tools.

Naturally I don't like, something like C++ Builder is impossible to achieve if one relies on the people that want to get paid, while unwilling to pay for their tools, just like in every other profession.

Somehow a culture of people that feels entitled not to pay for their tools has sprung off, killing a whole industry that naturally only focus on enterprise customers.

Wth everyone trying to kill GPL and its derived licenses, this will eventually be a thing of the past, then everyone will just suck it up with the demo version, BSD/MIT license, or shell out for the commercial version.

I use Qt professionally. What exactly do you want me to say here?

Salivate over bullet points on a release announcement when we treat every update as maintenance to a core featureset that's been sufficient since Qt 4.8? Jump into a tangent about the meta object compiler on a release announcement? Talk about the translation system apropos of nothing?

The only things that matter here to me now are if the license details change, if they made breaking design changes or deprecated features.

> Salivate over bullet points on a release announcement

For instance.

> when we treat every update as maintenance to a core featureset that's been sufficient since Qt 4.8?

Or discuss why this is true for 'we'.

> Talk about the translation system apropos of nothing?

How is that more nothing than license details?

Re: "I often need something that just works similarly to how a traditional desktop application works, looks be damned."

It's annoying how many dump efficient UI design to chase the latest fads. We Vulcans cry.

I just don't understand the free/commercial differentiation. I was trying to get some projects working from uni, and I wasn't sure what I was allowed to do nowadays. I thought it all had to be commercially licensed so gave up.

Most people (especially small indie devs) will be fine with the free LPGL version, regardless of whether you charge for your software or whether it is open source or not. Just make sure that you dynamically link the Qt libraries (so the end-user can theoretically replace them if they want to) and don't use any of the GPL-only add-ons (unless you are OK licensing your whole product as GPLv3).

You can statically link as well:

https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...

I knew someone would bring that up! Yes you can statically link but its harder to go that route and probably not worth it for most people (although for some platforms like iOS you might have to, not sure about that).

I've used Qt for over 15 years and I've never once wanted/needed to statically link it since dynamic linking has always worked just fine for the type of apps I've worked on.

At least as of Qt 5, the main drivers were static linking, liability, and not having to say you’re using Qt, iirc.

I've never switched from Qt widgets to QML. It is more important to me that the controls look platform standard. Also I am a programmer, not a designer.

We migrated away from Qt in large part because of the licensing uncertainty. The discussion always devolves into nitpicking about the license and pricing, because it's such a major handicap for Qt.

It feels like every six months they completely revamp the licensing program, and the LGPL version always seems to suffer from a corporate sword of Damocles

Yeah. I'm giving up on it for these reasons:

- For CLI apps, Rust has a better event loop, better language, more libraries, and is easier to deploy

- QWidgets seems like it's not "cool" anymore, and I don't feel like learning QML. I liked QWidgets because it was mostly the same from Qt 4.0 through Qt 5.0.

- The commercial side has no financial interest in adding cool new features to the LGPL code

- So how long will volunteers keep fixing the LGPL side, when their work is funding a business that does not help them?

- I'm waiting to see how Copperspice (A Qt fork that cuts off support for older C++ versions and uses STL and UTF-8 aggressively) turns out

About 10 years ago, Qt was my _jam_. I did everything in Qt. Games, CLI, GUI, IRC bots. I think I tried to build a Qt web server a couple times. For a kid who hated Windows and web stuff, it was my gateway to event loops and modern programming concepts. I just quit loving it. It's still in use at work, but I'm making plans to back out of it. Oh well.

> - I'm waiting to see how Copperspice (A Qt fork that cuts off support for older C++ versions and uses STL and UTF-8 aggressively) turns out

Copperspice forked at the time of Qt 4.8 and has had since then a couple thousands commits from a dozen contributors - in the meantime Qt itself had literally tens of thousands of commits, bugfixes, new features, etc from hundreds of contributors

A lot of those commits are related to features some people might not care about. For example, I imagine a lot of work has been done on the JavaScript compiler for QML - but if only use QWidgets, that's irrelevant to me.

Actually I'm only talking about the qtbase repo (core, gui, widgets, network...) in the Qt case, while for copperspice since they forked before 5.0 it's still a monorepo and the commits encompass everything (eg same that for Qt, plus script, WebKit and a few others they kept).

"So how long will volunteers keep fixing the LGPL side, "

As far as I know, it's not 'indy devs' supporting the LPGL, rather the LPGL is merely a term of release of the regular, mainline branch. It's the 'same code'. Am I missing something?

For the core and majority of the library, yes, but some specific features (eg Charts) have been released as commercial-only.

Charts and several other modules are released both under GPLv3 licensing and commercial licensing. For Qt6 some of these modules have not been released yet, but should be available by 6.2, the first LTS.

> I'm waiting to see how Copperspice (A Qt fork that cuts off support for older C++ versions and uses STL and UTF-8 aggressively) turns out

It's been around for 7 years and is maintained by two people as opposed to a publicly traded corporation (Qt) with hundreds of employees. It has already turned out.

There is no alternative to Qt. It is the best in its class.

But you don't need it. You don't need Electron either. Just build a .NET application for Windows, a SwiftUI one for Mac, and a ncurses one for Linux. They can all share the same business logic code (if it has any), either via C ABI, IPC, or RPC. Your application will always be at the bleeding edge with the latest security patches and accessibility this way, as opposed to waiting for the next Qt/Electron release which is guaranteed to be later than the OS bugfix. Imagine if desktop OSes release, in addition to dark mode, a pink mode. Do you want your application to stand out as the ugly duckling?

> (..). and a ncurses one for Linux.

Nurses as an alternative to a QtWidgets GUI app? I'm not sure you're serious.

Most Linux users would prefer a well-designed curses application over a GUI. You don't have to ask me, just look at what Linux users actually run and share screenshots of. I'm talking about real Linux distro users not Chromebook users.

> Most Linux users would prefer a well-designed curses application over a GUI.

I've been using linux both professionally and for personal use for over a decade and, with the exception of working over ssh, the thought of using ncurses apps over good old GUI apps is so outlandish that it doesn't even register in the realm of possibility.

Your comment sounds like a meme of how linux users are detached from the real world with regards to usability.

The applications I write are mostly GUI code, so that would mean nearly 3 times the work.

I'd guess they really want to get rid of the LGPL option (which was introduced when Qt was owned by Nokia and presumably they were more interested in Qt as a platform to develop their own products on than as a revenue stream), but the KDE Free Qt agreement means they can't just get rid of it.

Qt is GPL and LGPLv3[0]; gtk is LGPLv2[1]. Is there that much difference?

0: https://www.qt.io/licensing/

1: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/COPYING

I think LGPLv3 has anti-tivoization provisions. That said, I don't see how Gtk's license has anything to do with The Qt Company's recent antics. I'm in no way advocating people choose Gtk over Qt.

And Gtk isn't a good option for non-Linux use. wxWidgets is LGPL (sort-of, modified) as well. wxWidgets is much more reasonable than Gtk for cross-plattform use, though can't compete with Qt Widgets in terms of features, API design, ease of use, stability etc.

It seems really weird to me how "but teh licenz" is brought up every time with Qt, when Qt itself is available under the same licenses as all the other toolkits like Gtk, wxWidgets etc.

This doesn't quite apply for embedded development (as LGPL's Tivoization clause might start to bite), but 1.) neither Gtk nor wxWidgets are viable in that space anyway 2.) considering that other people here found that Tesla manages to ship their car firmware with LGPL Qt - well. Can't be that hard to comply with it. Also, 3.) while we're used to free tools and libraries for desktop development, it's much more common to pay for tools in embedded development.

I tried to use wxWidgets awhile back and gave up. It was a mess. Macros everywhere.

I've only ever used its Python bindings, and wxWidgets was pleasant to use for my use case.

The design of wxWidgets is very familiar to someone who started on MFC. There were reasons (perf, mostly) to write code that way back when MFC was a thing, but we certainly have better ways now.

I've used Qt for several projects in the past, but with this latest news I'm looking at GTK seriously now.

Why would you say GTK isn't a good option for non-Linux use? And would you say that it is a good option for Linux?

> Why would you say GTK isn't a good option for non-Linux use? And would you say that it is a good option for Linux?

You need something like MSYS2 to even use GTK on Windows, and I've looked at what it takes to package and distribute GTK applications to Windows users without MSYS2, and it's headache inducing.

When it comes to Linux, it's pretty good. Getting its GObject Introspection dependencies compiled is another story, though. I've always had to rely on my distribution's package manager to install them.

Gtk isn't even a good option for Linux use. Outside of GNOME, it just does not even try to fit in and behave.

It there a good option nowadays?

FOX is really fast and looks OK, but I don't think it's very actively developed, and binding to C++ seems like a pain. And I'm not sure it supports CJK input methods.

I looked at EFL out of desperation, but that's pure style over substance and the complete opposite of what I'd want.

FOX is actively developed, but only by 1 person. Unfortunately it does not support CJK input methods.

Can you elaborate on exactly the lawyers are on about the 'sword'?

Theoretically, the LPGL should enable commercial use, right?

Are there specific barbs in the wire that Qt has placed, or is it merely a situation of lawyers afraid of grey areas?

How else do you fund such a horrendously difficult thing? There is a reason there are no other cross platform UIs that are QT’s equal. Creating a good looking cross platform UI that supports things like accessibility and provides a close to native app experience (or can) is a real slog of a programming project. It must also be constantly maintained as native APIs change out from under it, hardware advances (e.g. higher DPI displays, HDR), and UI trends change.

Pay for Qt or pay for developer time to maintain multiple versions of your UI. Your pick. Qt is probably cheaper in most cases.

I wish this comment could be moved all the way to the top of the thread, to preempt all licensing discussion.

I agree completely. If I made a commercial app I would pay.

My concern is that I don't trust Qt Company now to not change the rules on me later, or hike the price, etc. I would choose Qt for commercial solely because I already know it from building FLOSS apps. If I need to learn something else for FLOSS, I'm not going to stick with Qt. There's limited space in my brain for expertise and I want something that will meet all needs.

Qt is amazing and I love it, but an amazing thing I love but can't use/rely on isn't worth much.

The thing is, of course, that you don't need to trust the Qt Company. That's why we have the KDE-Free Qt foundation, and that alone makes Qt the best choice for anyone who developers software that can use LGPL libraries, commercial or open source.

That's why we end up with many Electron applications. I mean even big companies like Slack or Spotify use Electron.

Spotify is CEF (Chromium Embedded Framework) as is the Adobe CC desktop application.

CEF is geared toward native C++ and is probably more of a Qt alternative than Electron in that regard.

I can confirm Spotify GNU/Linux client appears to use libcef. I was surprised! I had read some old Internet posts that claimed Spotify GNU/Linux client was using Qt. (I have no idea about old versions of the GNU/Linux client.)

When I run command "ldd" on my Spotify GNU/Linux client binary, I see "libcef.so". And, I can see:

$ ls -l /usr/share/spotify/libcef.so

-rw-rw-r-- 1 root root 147980856 Sep 15 06:13 /usr/share/spotify/libcef.so

That's a big library!

Unlike most other dual licensed software, Qt Company has legally binding agreement with KDE related to LGPL licensed version.

What they have done in last year is to retreat to the minimum they need to do to comply. They can't stop distributing the LGPL version or alter the deal anymore.

Unlike what you hear you can make commercial closed source software and link LGPL binaries dynamically or statically, makes no difference. You just need to have to provide linkable object files to comply. Just stuff them into some /gpl_comply/ directory and be done with it.

Any idea where one could learn more about the legally binding agreement? Especially wondering (i don't expect you to answer these, just wondering if you happen to know or know where one could read about it):

1. When was this entered into

2. What there "good and valuable consideration" exchanged and what was it?

3. Are there any other projects in an agreement like this?

Edit: Great resource, still reading through it and the many links: https://kde.org/community/whatiskde/kdefreeqtfoundation/

Dealing with static linkage is a giant pita because you have to provide all the object files for your code basically. I don’t think anyone really bothers with statically linking LGPL Qt into a non-OSS executable.

> a giant pita

It's not hard at all. You can add them to some directory with your app, or they can be behind some url, or you can mail them physically in a USB stick to anyone who requests them by mail or phone.

You just have to be able to provide them if somebody wants them. In reality nobody ever wants them. It's just some directory with gpl-stuff/ you add to your software.

How hard it is to have some binaries lying around?

The complexity comes into getting that machinery going in your build system and hosting. Additional complexities arise very quickly once you start optimizing your build (cmake object targets, LTO). I’m not saying it’s infeasible. Just saying that usually it’s easier to ship the Qt DLL and be done with it. From my observation of the space I’ve not seen anyone really ship the “here’s the object file” approach (it had happened before I’m sure but it’s not the norm for a reason).

Just do your linking in a final build step that 1: Only reads in object files and resources (ie rejects source code); 2: Bundles up all the object files into an archive; 3: Outputs the final executable alongside the archive.

You mentioned LTO. Don't the LLVM and GCC LTO implementations currently involve outputting compiler IR to object files, then running the optimization passes against the full collection of object files prior to linking? So they inherently collect all the object files together in a linkable form.

(Of course, it's probably more efficient to just dynamically link Qt and pay for a license if you want to publish for iOS.)

It's actually quite simple: https://news.ycombinator.com/item?id=23321785

>"Qt is great"

Absolutely when one looks at pure technical side. Their licensing however progressed to the point that feels like extortion to me.

I would recommend waiting for Qt 6.1 before considering using QtQuick/QML. They are apparently fixing a load of the issues with QML in that release. As it stands QML is kind of a mess.

I've always had that impression. I've been using Qt for 10+ years (professionally for half that) and I've always used QtWidgets. QML always seemed flimsy to me, and all those futuristic UIs... Not sure how they work with the c++ qt libs.

The core idea is kind of ok. But they screwed it up in a few ways:

1. Using Javascript. It's not a good language, especially without Typescript. And it's type system doesn't match C++'s well at all. For example you can't really pass uint64s to QML very easily. Apparently Javascript will be optional in 6.1.

2. The scene graph. A good idea but I'm pretty sure there's still no way to make custom QML widgets that contain text because there's still no public QSGTextNode (at least last time I looked into it). Here's people trying to do it in 2013: https://forum.qt.io/topic/24179/how-to-draw-text-in-qquickit...

I think they've pretty much given up on letting users make custom QML widgets - instead you have to use QPainter and it copies the resulting image across, which seems like a step backwards.

3. The encapsulation is really bad. I honestly never figured out the rules around widget ID scope because it seems like they are all in a global scope so all widgets can refer to any other widget (e.g. children can depend on their parents) which encourages spaghetti. Not sure if they're fixing this.

4. It's really hard to do transient widgets like dialogs. This is kind of the same as in React but it still seems like a step backwards from QtWidgets.

5. Lots of the QtQuick widgets are really lacking features compared to QtWidgets. It's like they got to the MVP and then gave up.

I haven't tried it for a number of years so some of those thing may have improved but I haven't heard about it. I get the impression that 90% of their income comes from car manufacturers using Qt for their software, which is why there is such a focus on fancy 3D UIs.

Reply on news.ycombinator.com