3 ms·

Qt's corporate owners have been openly hostile to the community for a while, and have been trying to get away with shady stuff. The license terms for commercial

Qt's corporate owners have been openly hostile to the community for a while, and have been trying to get away with shady stuff. The license terms for commercial use are terrible, you need an active license to distribute existing software, not only develop new software, the prices are excessive and keep increasing, and once you get a commercial use license you have to keep it forever or you won't be able to distribute your existing work. Commercial license users are prohibited from contributing to the community version. They also made registration mandatory for all downloads, even of the GPL/LGPL licensed stuff, which information they use for Oracle-style license shakedowns. They keep delaying GPL/LGPL releases and have stated an intention to delay them by the maximum permitted amount (one year) meaning all community contributions are effectively blocked because contributors don't have access to the current codebase. While the contract with the Qt community does prevent the Qt Company from going completely closed, they're certainly not someone I'm comfortable with.

nly 5y ago
I can't add much to this really. The Qt Company obviously don't think app developers using slightly old versions of their software provide any value to their shareholders, even though you're helping to grow the broader Qt ecosystem (libraries available, product awareness, knowledge sharing, growing the job market, etc). As far as the Qt company are concerned if you're a FOSS app developer, and not on bleeding edge Qt 6 and actively contributing bug reports (i.e. acting as their outsourced QA), then you're just a worthless leech. The feeling is the Qt library is only FOSS at this point because their hands are tied contractually by the KDE foundation. This has lead the KDE foundation to create a surprisingly active fork of Qt 5.15: https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15 https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15 which is now the default Qt 5 base package on Arch Linux: https://github.com/archlinux/svntogit-packages/blob/packages/qt5-base/trunk/PKGBUILD#L31 https://github.com/archlinux/svntogit-packages/blob/packages...
- asddubs 5y ago
  Isn't it the case that the KDE foundation can basically just yank away Qt for any reason they see fit? Seems like the Qt company would be playing a dangerous game there
  - Kliment 5y ago
    No. Only if the Qt Company violates the terms of the agreement.
    - asddubs 5y ago
      Right, seems like I misremembered this part: >The foundation will control the rights to the Qt Free Edition and ensure that current and future releases of Qt will be available for free software development at all times. All changes to the Qt Free Edition license will have to be approved by the KDE Free Qt Foundation which will consist of two members of Troll Tech AS as well as two members of the KDE project. One of the representatives of the KDE project will have a double vote to be used in case of a tie. so they have full control (majority of the votes) over approving license changes but I guess that doesn't mean they can enact them on their own https://kde.org/community/whatiskde/kdefreeqt_announcement/ https://kde.org/community/whatiskde/kdefreeqt_announcement/
jcelerier 5y ago
> They keep delaying GPL/LGPL releases and have stated an intention to delay them by the maximum permitted amount (one year) meaning all community contributions are effectively blocked because contributors don't have access to the current codebase Qt 6.0 was released for both commercial and LGPL at the very same time. > https://www.qt.io/blog/qt-6.0-released https://www.qt.io/blog/qt-6.0-released Same for Qt 6.1 > https://www.qt.io/blog/qt-6.1-released https://www.qt.io/blog/qt-6.1-released Same for the upcoming 6.2 > https://www.qt.io/blog/qt-6.2-beta-released https://www.qt.io/blog/qt-6.2-beta-released so that's very much FUD. Sure, there's the LTS thing where some point releases past a given .z are kept private, but who actually uses that in the open-source world ? Even LTS distros that use LTS versions of Qt never upgrade their point releases: * Ubuntu 18.04 is on Qt 5.9.5 while the latest point release of the 5.9 LTS branch is 5.9.9: https://packages.ubuntu.com/bionic/qt5-default https://packages.ubuntu.com/bionic/qt5-default * Ubuntu 20.04 is on Qt 5.12.8 while the latest point release of the 5.12 LTS branch is 5.12.11 https://packages.ubuntu.com/focal/qt5-default https://packages.ubuntu.com/focal/qt5-default
- nly 5y ago
  All you're saying is that FOSS developers targeting Linux might[0] be able to lean on the generosity and hard work of Linux distro package maintainers. That's great, but if you're a FOSS (or free as in beer) app developer targeting Qt on macOS or Windows you're choice is basically between shipping a bleeding edge version of Qt 6.x that will almost certainly cause regressions for your users, or ship a version of Qt 5.15 that almost certainly has known security vulnerabilities. As an app developer bumping minor Qt versions on my users isn't something I want to do every other month, since doing so requires a lot of regression testing and user feedback. Most of the time I just want to roll in critical bug fixes (security issues, crashers, etc). [0] In reality shipping Qt apps for Linux is really horrible. As you noted every distro is using a different version, so the users of your app don't all get the same experience unless you go to a herculean effort to bundle your own Qt build.
  - jcelerier 5y ago
    I guess we have a different definition of herculean, I just have a script that builds KDE's 5.15 branch statically and run find_package(Qt5) in my cmake

nly 5y ago

I can't add much to this really. The Qt Company obviously don't think app developers using slightly old versions of their software provide any value to their shareholders, even though you're helping to grow the broader Qt ecosystem (libraries available, product awareness, knowledge sharing, growing the job market, etc). As far as the Qt company are concerned if you're a FOSS app developer, and not on bleeding edge Qt 6 and actively contributing bug reports (i.e. acting as their outsourced QA), then you're just a worthless leech. The feeling is the Qt library is only FOSS at this point because their hands are tied contractually by the KDE foundation. This has lead the KDE foundation to create a surprisingly active fork of Qt 5.15: https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15 https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15 which is now the default Qt 5 base package on Arch Linux: https://github.com/archlinux/svntogit-packages/blob/packages/qt5-base/trunk/PKGBUILD#L31 https://github.com/archlinux/svntogit-packages/blob/packages...

asddubs 5y ago
Isn't it the case that the KDE foundation can basically just yank away Qt for any reason they see fit? Seems like the Qt company would be playing a dangerous game there
- Kliment 5y ago
  No. Only if the Qt Company violates the terms of the agreement.
  - asddubs 5y ago
    Right, seems like I misremembered this part: >The foundation will control the rights to the Qt Free Edition and ensure that current and future releases of Qt will be available for free software development at all times. All changes to the Qt Free Edition license will have to be approved by the KDE Free Qt Foundation which will consist of two members of Troll Tech AS as well as two members of the KDE project. One of the representatives of the KDE project will have a double vote to be used in case of a tie. so they have full control (majority of the votes) over approving license changes but I guess that doesn't mean they can enact them on their own https://kde.org/community/whatiskde/kdefreeqt_announcement/ https://kde.org/community/whatiskde/kdefreeqt_announcement/

jcelerier 5y ago

> They keep delaying GPL/LGPL releases and have stated an intention to delay them by the maximum permitted amount (one year) meaning all community contributions are effectively blocked because contributors don't have access to the current codebase Qt 6.0 was released for both commercial and LGPL at the very same time. > https://www.qt.io/blog/qt-6.0-released https://www.qt.io/blog/qt-6.0-released Same for Qt 6.1 > https://www.qt.io/blog/qt-6.1-released https://www.qt.io/blog/qt-6.1-released Same for the upcoming 6.2 > https://www.qt.io/blog/qt-6.2-beta-released https://www.qt.io/blog/qt-6.2-beta-released so that's very much FUD. Sure, there's the LTS thing where some point releases past a given .z are kept private, but who actually uses that in the open-source world ? Even LTS distros that use LTS versions of Qt never upgrade their point releases: * Ubuntu 18.04 is on Qt 5.9.5 while the latest point release of the 5.9 LTS branch is 5.9.9: https://packages.ubuntu.com/bionic/qt5-default https://packages.ubuntu.com/bionic/qt5-default * Ubuntu 20.04 is on Qt 5.12.8 while the latest point release of the 5.12 LTS branch is 5.12.11 https://packages.ubuntu.com/focal/qt5-default https://packages.ubuntu.com/focal/qt5-default

nly 5y ago
All you're saying is that FOSS developers targeting Linux might[0] be able to lean on the generosity and hard work of Linux distro package maintainers. That's great, but if you're a FOSS (or free as in beer) app developer targeting Qt on macOS or Windows you're choice is basically between shipping a bleeding edge version of Qt 6.x that will almost certainly cause regressions for your users, or ship a version of Qt 5.15 that almost certainly has known security vulnerabilities. As an app developer bumping minor Qt versions on my users isn't something I want to do every other month, since doing so requires a lot of regression testing and user feedback. Most of the time I just want to roll in critical bug fixes (security issues, crashers, etc). [0] In reality shipping Qt apps for Linux is really horrible. As you noted every distro is using a different version, so the users of your app don't all get the same experience unless you go to a herculean effort to bundle your own Qt build.
- jcelerier 5y ago
  I guess we have a different definition of herculean, I just have a script that builds KDE's 5.15 branch statically and run find_package(Qt5) in my cmake