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
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.
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 :)
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)?
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 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.
(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.)
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.
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?
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.
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.
Speaking of which, if eventually Google ends up buying them, lets see how much love is left.
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.
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.
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.
It's annoying how many dump efficient UI design to chase the latest fads. We Vulcans cry.
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
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.
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
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.
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/
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?
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.)
- 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.
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
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?
Nurses as an alternative to a QtWidgets GUI app? I'm not sure you're serious.
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.
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?
Pay for Qt or pay for developer time to maintain multiple versions of your UI. Your pick. Qt is probably cheaper in most cases.
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.
CEF is geared toward native C++ and is probably more of a Qt alternative than Electron in that regard.
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!
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.
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.
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.
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?
Absolutely when one looks at pure technical side. Their licensing however progressed to the point that feels like extortion to me.
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.
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.