6 ms·

Using Qt 6 under LGPLv3

90 points by synergy20 4y ago

Rochus 4y ago
> 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). > Shall we use Qt LGPL-3.0 or Qt Commercial? LeanQt (https://github.com/rochus-keller/leanqt/ https://github.com/rochus-keller/leanqt/) is still available under LGPL v2.1. I will not switch to Qt 6 with my projects.
- mdaniel 4y ago
  > Instead of qmake the BUSY build system (see https://github.com/rochus-keller/BUSY https://github.com/rochus-keller/BUSY) is used It must be a rite of passage to make(!) one's own build system, damn
  - Rochus 4y ago
    > It must be a rite of passage to make(!) one's own build system Rather a liberating blow; actually, the goals were not achievable with the existing systems.
    - mlvljr 4y ago
      [dead]
- FatActor 4y ago
  > (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???
  - Rochus 4y ago
    Have a look at e.g. https://sbabic.github.io/swupdate https://sbabic.github.io/swupdate, which is also available in Buildroot; kernels and rootfs can be configured to be rather small.
  - saidinesh5 4y ago
    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..
    - FatActor 4y ago
      Are we talking about the same thing? An OTA firmware update of 100MB seems about 100X what I'm used to in the Cortex-M space.
      - froh 4y ago
        you should use a differential binary updater. SUSE introduced differential rpm updates quite a while back and others have it too these days. the really tricky part is making the update robust against power outage or, much more probable, manual power off "ThE UpDaTe TaKeS So LonG"
      - saidinesh5 4y ago
        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.
fmntf 4y ago
> 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.
- jcelerier 4y ago
  > 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.
  - mk89 4y ago
    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".
- Rochus 4y ago
  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.
- varajelle 4y ago
  > I don't even understand how is that possible, since Qt Creator is GPL3. Because doing so would be violating the terms of the commercial Qt license you paid for.
amelius 4y ago
Do we have to hire a lawyer to use Qt now?
- GuB-42 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - usr1106 4y ago
    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.)
    - jhasse 4y ago
      Why not use LGPL Qt then?
      - usr1106 4y ago
        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.
    - usr1106 4y ago
deutschepost 4y ago
> 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.
deleted 4y ago
[deleted]
gkhartman 4y ago
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.
- ahartmetz 4y ago
  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.
BuckyBeaver 4y ago
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.
- rhn_mk1 4y ago
  > If you want to sell software made with Qt, that too requires a commercial license. The GPL allows commercial use including sales, BTW.
  - saidinesh5 4y ago
    I think he just means closed source mobile apps. 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.
hermitcrab 4y ago
I develop commercial desktop apps for Windows and Mac using Qt. I recently switched from LGPL to a commercial license for a small business because: 1. I wanted access to the latest releases. 2. I wanted access to some of the commercial modules, such as Charts. 3. I wanted to support Qt. The small business license is reasonably priced: https://www.qt.io/pricing/qt-for-small-business https://www.qt.io/pricing/qt-for-small-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.
donedealomg 4y ago
[dead]

90 points by synergy20 4y ago

> 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). > Shall we use Qt LGPL-3.0 or Qt Commercial? LeanQt (https://github.com/rochus-keller/leanqt/ https://github.com/rochus-keller/leanqt/) is still available under LGPL v2.1. I will not switch to Qt 6 with my projects.

mdaniel 4y ago
> Instead of qmake the BUSY build system (see https://github.com/rochus-keller/BUSY https://github.com/rochus-keller/BUSY) is used It must be a rite of passage to make(!) one's own build system, damn
- Rochus 4y ago
  > It must be a rite of passage to make(!) one's own build system Rather a liberating blow; actually, the goals were not achievable with the existing systems.
  - mlvljr 4y ago
    [dead]
FatActor 4y ago
> (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???
- Rochus 4y ago
  Have a look at e.g. https://sbabic.github.io/swupdate https://sbabic.github.io/swupdate, which is also available in Buildroot; kernels and rootfs can be configured to be rather small.
- saidinesh5 4y ago
  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..
  - FatActor 4y ago
    Are we talking about the same thing? An OTA firmware update of 100MB seems about 100X what I'm used to in the Cortex-M space.
    - froh 4y ago
      you should use a differential binary updater. SUSE introduced differential rpm updates quite a while back and others have it too these days. the really tricky part is making the update robust against power outage or, much more probable, manual power off "ThE UpDaTe TaKeS So LonG"
    - saidinesh5 4y ago
      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.

fmntf 4y ago

> 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.

jcelerier 4y ago
> 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.
- mk89 4y ago
  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".
Rochus 4y ago
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.
varajelle 4y ago
> I don't even understand how is that possible, since Qt Creator is GPL3. Because doing so would be violating the terms of the commercial Qt license you paid for.

amelius 4y ago

Do we have to hire a lawyer to use Qt now?

GuB-42 4y ago
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.
- deleted 4y ago
  [deleted]
- usr1106 4y ago
  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.)
  - jhasse 4y ago
    Why not use LGPL Qt then?
    - usr1106 4y ago
      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.
  - usr1106 4y ago

deutschepost 4y ago

> 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.

deleted 4y ago

[deleted]

gkhartman 4y ago

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.

ahartmetz 4y ago
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.

BuckyBeaver 4y ago

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.

rhn_mk1 4y ago
> If you want to sell software made with Qt, that too requires a commercial license. The GPL allows commercial use including sales, BTW.
- saidinesh5 4y ago
  I think he just means closed source mobile apps. 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.

hermitcrab 4y ago

I develop commercial desktop apps for Windows and Mac using Qt. I recently switched from LGPL to a commercial license for a small business because: 1. I wanted access to the latest releases. 2. I wanted access to some of the commercial modules, such as Charts. 3. I wanted to support Qt. The small business license is reasonably priced: https://www.qt.io/pricing/qt-for-small-business https://www.qt.io/pricing/qt-for-small-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.

donedealomg 4y ago

[dead]