> An application using Qt Commercial must not communicate with any another application using Qt LGPL-3.0 or Qt GPL, if both applications run on the same device.
This seems crazy to me. How could you ever enforce this? If I buy some Software which uses the Qt Commercial Variant internally, you would have to make sure that it doesn’t support any standard IPC Protocol, that a potential LGPL Qt program could use too.
The default answer to the question if you should use LGPL or commercial should always be LGPL. Unless you really really have to use Qt on an embedded system. Otherwise the Qt Company will come for you…
Edit: One of the bigger Problems with Qt6 is, that there are no more non-commercial LTS Versions. This forces some bigger companies to buy out of fear and/or policy. Even if they don’t build embedded systems. And if you bought in once it is very hard to get back to the LGPL variant.
> Qt for MCU [..] seems like a big advantage over Qt LGPL-3.0. I have my doubts. MCUs powerful enough to run Qt GUIs smoothly are more expensive than, say, an i.MX6ULL with a Cortex-A7 application processor and Linux. It’s a lot easier to find developers for an embedded Linux system ...
This is a very convincing argument. A Linux embedded system is also more flexible and the degree of code reusability is usually higher; it's also easier to develop and debug, and one can profit of a huge ecosystem (e.g. OTA update and the like).
What's linux FOTA like? It's dirt simple for most M-class devices, and most use MCUboot with two banks. I've not used it on Linux, but I can't imaging updating the kernal/distro OTA since it is so big, but I'm guessing just the application gets updated???
rauc, swupdate, even docker/balena are all tools that handle the FOTA problem really well.
We used rauc and swupdate in my last job as they came with yocto/buildroot (our build system for generating custom distro images).
It is always these 3 basic partitions + a boot script to check if the boot is successful and if it isn't roll back the update or boot from a recovery partition: root A (usually around 500GB), root B (500GB), common application data (usually mounted as /home/app and is around 500 MB). The distro + application usually takes up about 50-100MB. We usually left at least 10X that free space to not worry about the future..
It depends on what you are trying to build/update and how you are trying to deliver the OTA.
Typically the rootfs (kernel + libs + applications) of a similar app (think lvgl + some kind of gui) of a linux system is around 5-10MB higher than using a microcontroller (kernel - 5-6MB, uboot, busybox, libc etc.. another 1-2MB). But nothing is preventing you from static linking everything and just running your single app as init on top of the kernel. Except licensing. (Statically linked qt = you need to be open source or have a commercial license).
For typical wireless router kind of use case (read: Openwrt), the whole firmware is around 2-4MB squashfs, and used to fit in a 4MB flash chip. (These days they recommend 16MB or higher iirc..)
For automotive infotainment systems which have to play a dozen audio/video formats, have to show various engine information, have to have smooth animated menu and high quality icons/images, the firmware was around 50-60MB.
We typically didn't bother with delta updates because these updates only happen when connected to wifi or in some cases via. a USB drive with firmware in it. So I can't give you the exact numbers on how big the delta updates usually can be. In android world, delta updates let us update a 1.4GB system partition with an OTA blob of 20-30MB I think.
The economics are also different. It is cheaper to buy a 4GB emmc instead of 2GB emmc which you need.
> We must not use [...] Qt Creator [...] to build software using Qt LGPL-3.0 or Qt GPL. It doesn’t matter whether these tools are also available under a non-commercial Qt license.
This is the weirdest part of Qt licensing for me. An IDE is an IDE, you should not care what I develop with it. I don't even understand how is that possible, since Qt Creator is GPL3.
> I don't even understand how is that possible, since Qt Creator is GPL3.
very simply because it isn't possible and the article is just wrong. You can entirely use LGPL Qt Creator to develop proprietary apps. What you mustn't do is e.g. ship a modified version of Qt Creator as part of for instance an embedded SDK and not ship its source.
The part quoted is explicitly about the QT commercial license. Apparently, you can't use QT commercial with non-qt commercial (and Qt Studio non-commercial).
And probably this is done to be able to sell the IDEs, maybe based on n. of users, etc. Never bought Qt so I don't know how they license "users".
They obviously want you to pay for the whole development duration and for all developers; they don't want you to use the GPL/LGPL licensed stuff during development and then to buy a commercial license ony for deployment, or to buy just one commercial license and use GPL/LGPL for the other developers.
This is btw not the only trap in the license agreement; if you sign that, you are significantly less well off than if you can do everything with LGPL.
Every time I've been involved in a design process that involves choosing a GUI framework, QT is brought up, and ruled out due to licensing confusion. I love working with QT, but it's a tough sell when other frameworks check all the requirements boxes (at least on desktop, web, and mobile). I usually check in once in a while to see if it's gotten any better, but looks like it may be going the other direction.
The Qt company sales team tries to create confusion to scare potential customers into paying - but the LGPLv3 isn't all that confusing. Comply with it and you're fine.
I was the lead on a cross-platform desktop application developed using Qt. I do not find the author of this article's segregation quite accurate.
He seems to call all commercial Qt usage "Qt for device creation." That's slightly backward. Qt's "device creation" category is for embedded software. All use of Qt for embedded applications is "Qt for device creation" and requires a commercial license. But not all commercial Qt usage is for device creation.
There is also commercial Qt work for desktop and mobile apps. If you want to sell software made with Qt, that too requires a commercial license. When you're negotiating a license purchase with Qt reps, they will try to categorize your work as "device creation" if they can. They did this with us, simply because we were building an application to control other devices. But I disabused them of this notion, because the devices ran no Qt runtime or any software developed with Qt. They did not pursue the matter further, and we bought a couple of commercial licenses.
This article does reveal the ridiculous nature of Qt licensing, however. It would be interesting to know how many times the Qt Company has pursued action against license violations, and what the nature of said violations was. I'm not sure their reps understand the licensing.
Also, Qt's licensing fees for embedded products are laughably high. The article cites something like $8 per device, which is even higher than what we were quoted. But any price measured in whole dollars per unit is ridiculous, and we told them as much. I can only speak for my company, but they will never be a candidate with rates like that.
For desktop applications, you can just dynamically link Qt and still sell your closed source applications.
For Mobile apps, LGPLv3 is a little tricky. You need to allow the users to replace the bundled Qt libs with their own, and on iOS that is a pain iirc. It is do-able but a lot of companies just buy Qt commercial license instead.
We could do away with that assumption. It's not descriptive of the reality, as plenty of commercial stuff isn't closed, and neither is plenty of sold stuff.
As a prescriptive position, that's not the future I want.
And still you can make closed source apps that link against LGPLv3 Qt (or LGPLv3 anything as long as your end user has a way to patch the LGPLv3 parts) and sell them without issues?
I can't tell if that's really meant to be a question, but this rules out mobile and I wouldn't attempt to sell a product on any platform that has to be rebuilt by the end user.
The rebuilding is not a compulsion, but rather a required option. You're only ruling it out if that option is impossible (which is definitely not the case on Android).
I don't really understand. The immense majority of your customers will never look at the build procedures, just like almost no one looks at the Linux kernel sources & build instructions that you can get from Sony from your smart tv. It's not like it makes the software harder to use for anyone.
How are they going to rebuild the software without looking at build procedures (in environments where dynamic linking isn't available)?
And even in an environment where dynamic linking is available, something like the Qt runtime is not comparable to the OS itself, which is obviously already installed on all target systems. It's another component that must be installed for the software to work, and as far as I know you're not allowed to distribute it willy-nilly.
I don't understand, if someone wants to build the software of course they would look at a build procedure just like I look at a recipe when I want to cook. But that will be the 0.001% of your users who want to do this. Just like if I buy a moddable car I don't expect mods to happen by magic on their own, I know that there'll be some elbow grease involved, and I'm still making this tradeoff because moddability is more important to me.
If you are using the commercial version of Qt, then probably yes. The license is rather expensive, and intended for companies who use it to make commercial software. And when you are doing that, hiring a lawyer to make sure all your licensing is right is a good idea, and not just for Qt.
If you are using the open source version of Qt, you just have to understand the GPL and LGPL licenses, which is a must anyways if you are working in the software industry. But if your livehood depends on your understanding of software licenses, hiring a lawyer may be a good idea anyway.
Not every commercial software is multi-million (or billion) business. There are perfectly fine niche markets where less than 5 developers produce a viable product. Qt company does not seem to care about them and probably the only safe choice is not to touch Qt. Which is a pity because they used to have good software. (Haven't used it for many years because my employers can't afford the lawyers.)
Replying to myself: Another commenter mentioned that there is a small business license. That sounds OKish, but the limits are really small. $250,000 turnover. Your business cannot be very successful if it stays under that. Even with 20% profitability the owner would only make $50,000.
So this seems a typical drug dealer pricing: You start cheap but as soon as you are a little bit successful you will have a massive increase in license fees.
If that were such a simple decision the blogger in the submission could not live from his licensing consultancy. And nobody would buy commercial Qt licences so Qt wouldn't be a profitable business.
The decision of Qt to only make some binaries available to commercial customers is controversial, but they are a commercial entity and they need to make enough money to survive.
This seems crazy to me. How could you ever enforce this? If I buy some Software which uses the Qt Commercial Variant internally, you would have to make sure that it doesn’t support any standard IPC Protocol, that a potential LGPL Qt program could use too.
The default answer to the question if you should use LGPL or commercial should always be LGPL. Unless you really really have to use Qt on an embedded system. Otherwise the Qt Company will come for you…
Edit: One of the bigger Problems with Qt6 is, that there are no more non-commercial LTS Versions. This forces some bigger companies to buy out of fear and/or policy. Even if they don’t build embedded systems. And if you bought in once it is very hard to get back to the LGPL variant.