Qt 6.4
qt.io
qt.io
This.
Regardless of Qt's technical merit, it's licensing automatically takes it out of the table of most of all potential projects.
From their site <https://www.qt.io/download-open-source>: LGPL – Any modification to a Qt component covered by the GNU Lesser General Public License must be contributed back to the community. This is the primary open source Qt license, which covers the majority of Qt modules.
If you're not familiar, in practice, the difference between GPL and LGPL is that LGPL does allow dynamically linking a library with a closed source program, without requiring that the program also becomes GPL/LGPL. This is compatible with most development as long as you either don't modify Qt, or are ok with those modifications becoming open source.
The anti-tivoization clauses mean you need to provide a way to install user-built Qt libraries on the target device. You might think that's not a big deal until you go to work for an automotive or medical company and meet up with the massive wall of lawyers that tell you no fucking way.
The problem is typically people not bothering to understand the L in LGPL.
You're missing the whole point.
It's irrelevant whether projects should have a budget or not.
The whole point is that there are plenty of alternatives that do not require thousands of dollars per year*developer, nor do require lawyers to audit releases.
On the desktop you can go Electron, but you then pay penalties in performance that not everyone is willing to endure.
In the embedded space there is little or no alternative.
The actual LGPLv3 text has zero instances of the word "commercial" or the word "consumer" so interpretation is all we can go by.
> A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.
The FSF felt that consumers needed protected from tivoization but commercial users did not since they had the financial resources to fight for themselves with contract law.
The FSF felt that consumers needed protected from tivoization but commercial users did not since they had the financial resources to fight for themselves with contract law.
No, LGPL also excludes projects from most commercial software.
Also, keep in mind that this is not a choice between Qt with a paid license or Qt with LGPL. It's a choice between Qt and any other framework, and licensing alone makes Qt a very poor choice.
e.g. if I look at what I can find for docking widgets (and I have hardly ever seen an actual useful software for content creation without a whole set of dozens of docks): https://caduandrade.github.io/docking_flutter_demo/#/ like, is this a joke?
Like, it was certainly a very shitty move given how much they make but if fucking Tesla managed to use the LGPL Qt in their car dashboard, surely your app can do it too
Electron is not just a joke but a fat pig.
Truth is there's nothing comparable to Qt in the cross plataform world today, unless you are willing to take the risk of Flutter, JUCE, some web technology (which would be regarded as obsolete by the time you ship your product), etc.
https://www.st.com/content/st_com/en/campaigns/touchgfx-adva...
maybe consider licensing that "potential project" under a license that allows you to use the OpenSource Qt version?
It's ok for activists to feel that free software is the solution to every problem in the world, but back in the real world there are projects for which open source is not an option and parroting activist mantras is not helpful.
You'd have to provide a way to relink.
I seriously can't see a judge ever being able or willing to understand what's at stake here in case this ever gets to court.
When I want to get paid for stuff I develop with the work of Qt devs, then like in other profession, I pay the creators of tools I get money to put bread on the table.
They also need to buy bread, so it is only fair we share the same conditions.
For me, it seems like Jetbrains vs. Borland/Inprise/Codegear/Embarcadero. Jetbrains always had reasonable prices, but a huge amount of customers. Embarcadero tries to milk the few customers that remain.
Qt is like Embarcadero.
When everyone wants free beer, in the end they get Electron.
Which uses webkit, which is LGPL :D
It seems all the people here who complain about QT's license never bothered to read the license of anything else.
Qt on the other hand is used a lot and new projects are started with Qt everyday. Qt is not Embarcadero.
C++/WinRT is a joy to use for anyone whose maximum of productivity was using Visual C++ 6.0 for COM development, exactly the same Visual Studio tooling. /s
So plenty of enterprises do new projects in C++ Builder, and Delphi comes for the ride.
https://entwickler-konferenz.de/
I know of a company in Belgium that does laboratory automation software in Delphi, because they don't want to use languages like C and C++, and .NET lacked the low level coding and native compilation that they want.
For them it isn't legacy, rather from their point of view the alternatives suck, and they will keep at it as long as they can.
It then proceeds to install 20+ gigabytes (yes) of stuff, including their ide that you can't actually uncheck.
No thanks, i'm out.
We don't bother going near the LGPL version for small things. Too many threats.
You can download sources and build them yourself. Which is what linux distributions do.
(QT is more than linux-only. In fact, that's the whole point. They could simplify it greatly if it was linux-only.)
But i'm also really not that interested in using a library specific IDE at that level.
Because QT is not all i do, etc.
For folks who do, i'm sure it's great.
For C++ IDEs on linux, CLion works great. VSCode is reasonable too.
Otherwise, Clion would be dead by now in favor of it!
Also, for your complaint about the size of the SDK: most people download the Python bindings (often through conda) and don't do compilation at all (I write interactive applications using QtPy, python slowness isn't an issue). But also: you're not the target audience.
So yes, i know you can download sources, and many years ago, i even built them once!
Does it occur to you this is maybe not what i want out of a developer experience? That if this is the experience the company wants to provide me, that that is a good sign i am not who they want or target? (Or that they suck at business, which is possible)
First impressions matter a lot.
I can surely make it all work, but why would I? There are plenty of great alternatives where i don't have to any time trying to make it work, and where the company is not making it annoying for me.
So i just go use those.
Or the one-two punch of "Contact our sales", followed immedietely by "What is your budget?" ... which is a common wording for "How much money do you have? That is what this will cost!"
If the cost is reasonable for what you're getting, most companies wouldn't think twice about paying for a library or a dev tool if it'll help them ship faster or better products... and if they didn't have to think about it much anymore after that decision. You can see this by the willingness of companies to shell out for SaaS tools like GitHub paid accounts and commercial CI/CD services. There isn't really much lock-in there. If you need to abandon GitHub you can move to GitLab or stand up your own instance of something like Gitea. Might lose some meta-data but your main code (product) is intact.
Instead the nature of licensing means that the license of the library you're incorporating contaminates your project and you have to get legal involved. Even having to contact legal is generally the kiss of death.
It also raises questions about whether the vendor can rug pull you in the future and kill your product. To be fair this can sort of happen in open source if you rely on a complex project that gets abandoned and don't have the resources to adopt it, but at least there you have some recourse and you can keep using what already exists until you have a long term solution.
This complexity is really why we can't have nice things, since things as powerful as Qt really do require funding in one form or another.
In addition to this, I have exactly zero interest in any licensing model that requires a per-device fee. First of all, the fee, at least last time I looked, is completely opaque. My guess is they try to squeeze you for all they can. Second, and often more important, I have zero interest in Qt having an internal view of our business --which is what they get when you have to account for how many devices you made, sold and when.
I don't mind the per-developer or site licenses. Per-device licenses are intrusive. They also get to tap into your profit margin. No, thanks.
We have subscriptions with JetBrains for their excellent tools. If JetBrains turned around and said "You have to pay a fee for every unit sold", we would drop them like a hot potato. Everyone understands that example, yet somehow people don't recoil at this idea of per-device licensing. Hardware is hard enough as it is; adding a blood-sucking vampire to the equation doesn't make it easier.
Think about it. Is the work Qt does more complex than what JetBrains do? Not at all. I can actually see JB's work being massively more difficult, particularly when you consider the array of tools they have to evolve and maintain. Why is it that Qt think they are entitled to poke a needle into your arm and suck blood out of every device you make?
Even better, the open source license demands contribution of any enhancements back to Qt. They, in turn, take those advances and sell them through their commercial licensing program. Do the contributors get a piece of the action? Why not?
Also, I believe that, until recently, if you stopped paying your developer licenses you were prohibited from selling your product. In other words, if I created a product using Qt five years ago and never touched it again, I'd have to pay them a developer's license for the life of the product. Once again, blood-sucking vampire behavior. That said, I believe I read something about this policy changing. Since I have not found a way to care about Qt, I didn't bother to read that article in detail.
Another analogy: It's like what's going on with modern "smart" TV's. You go buy a TV and the manufacturers somehow feel entitled to harass you with advertising and all sorts of data gathering. Intrusive and wrong.
How could Qt change my mind?
I don't have a problem paying a reasonable per-developer annual license fee. What's reasonable? A few hundred dollars, say, $300 or so. After that, no per-device fees, get your microscope out of my ass and the license isn't tied to released products in any imaginable manner.
I very much doubt this will happen.
I would love to pay Qt a reasonable license fee once my product that uses it starts generating some decent revenues. I want them to succeed and keep building better versions. But I also don't want to have to shell out outrageous license fees when I am just getting started. This goes for any tool or library I choose to use.
From the page:
"Your business has a combined revenue and funding equal to or less than two-hundred and fifty thousand ($250000) USD"
(revenue + funding) < 250000 ?
That's not a business, that's a hobby.
You have to do that process if you use electron… except that there you have 30000 libraries and each one of them has to be vetted and approved.
Your legal costs estimations is way off.
With mobile platforms, I can imagine the same is true: you can save a ton of development time money.
I've said it before and i will say it again. A good gyi toolkit and that too cross platform is an incredible amount of work. Rust would be better off funding qt support than trying 20 different things because somehow anything less than "pure" rust is filthy.
I’m not saying it’s necessarily a bad idea, Apple enables the same nowadays with Catalyst (iOS APIs on macOS). But it doesn’t seem very popular. Just curious why you want to go this way.
2. I am a solo developer and want one framework to write once, run everywhere (still looking for which will do the best job for me).
So... Qt's C++ framework then?
Late edit: as an afterthought there are other languages that provide similar functionality. Xojo comes to mind as having capability to write once and run everywhere. It doesn't have the performance of C++ though and comes with a bunch of its own baggage.
Although performance is nice to have, it obviously is not the most important thing for me. Low verbosity (as little code necessary to write a functional and reliable UI as possible) and fast learning curve are the most important things.
Qt and Xojo are both real contenders on these points. I would argue that Xojo has a faster learning curve if you already know BASIC but is perhaps much less expressive if you need any sort of complex computer science algorithms or data structures which is where C++ really shines.
Qt's learning curve is "pretty quick" but it of course comes with having to know a decent amount of C++, and possibly javascript, to utilize effectively.
> I just heard you don't really have to use any language other than the Qt's internal ones any more.
Yup absolutely. If it were me and I were building a UI, I would seriously consider Qt's framework. I don't particularly like Qt's framekwork (it still holds a lot of baggage from pre-C++11 days) but I must admit that it's fairly extensive, certainly cross-platform across desktop and mobile operating systems, and has a fairly quick learning curve to use.
Widgets are still supported (because they work, and they are used by lots of faithful Qt customers), but QML is where they've put pretty much all their development focus since the late 2000s.
New projects are typically encouraged to use QML I think
I wasn't wondering where they were putting their development time.
Rust works fine but with qml technically there is very little programming code except the in app js-logic
The only way for Qt to compete with Electron is to become Electron.
Now we can have broken accessibility, usability, broken theming, and bad integration on both platforms, yay!
regarding the how.. Qt provides a CMake wrapper which sets up the relevant flags automatically so with CMake/Qt projects it pretty much just works. Here's my build scripts:
- https://github.com/ossia/score/blob/master/ci/wasm.deps.sh
- https://github.com/ossia/score/blob/master/ci/wasm.build.sh
It makes sense, from the perspective of shops who invested heavily in upskilling on Qt, to reuse the knowledge to build web apps.
All of them already have some kind of support in WebAssembly.
Not that I'm satisfied with the current state of browsers mind you. I just think not being forced to install someone's binary blob to look at web content is a net benefit.
Now you can enjoy Flash like ads using WebAssembly + WebGL, making it all a Phyrric victory.
Chromium-based: --js-flags=--noexpose_wasm
Firefox-based: about:config javascript.options.wasm = false
Webassembly is clearly an improvement over the old plugins. For one thing it's a full virtual machine and was designed with sandboxing in mind.
Those browser flags aren't something Joe and Jane users are capable to be aware of, can disappear at any time anyway, and are not a thing on mobile devices.
A sandboxing that isn't bullet proof and can still be exploited by triggering memory corruption on the linear memory segment, thus changing decisions based on the data contents.
As long as you don't modify the Qt source (or you modify and re-distribute it per LGPL) you should be safe (IANAL obviously)
Nice idea but the problem is that these literally run as a foreign app in the browser. You can't cut and paste or highlight text. They are not web pages.
There is a niche for this, probably in business and industrial uses or for making legacy apps available over the web, but it's not something I'd consider for a new system that had to in any way be "web-like" or that was primarily used over the web.