8 ms·

We migrated away from Qt in large part because of the licensing uncertainty. The discussion always devolves into nitpicking about the license and pricing, becau

by nikanj 6y ago

We migrated away from Qt in large part because of the licensing uncertainty. The discussion always devolves into nitpicking about the license and pricing, because it's such a major handicap for Qt. 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

ReactiveJelly 6y ago
Yeah. I'm giving up on it for these reasons: - 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.
- jariel 6y ago
  "So how long will volunteers keep fixing the LGPL side, " 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?
  - spease 6y ago
    For the core and majority of the library, yes, but some specific features (eg Charts) have been released as commercial-only.
    - mroche 6y ago
      Charts and several other modules are released both under GPLv3 licensing and commercial licensing. For Qt6 some of these modules have not been released yet, but should be available by 6.2, the first LTS.
- jcelerier 6y ago
  > - 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 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
  - ptx 6y ago
    A lot of those commits are related to features some people might not care about. For example, I imagine a lot of work has been done on the JavaScript compiler for QML - but if only use QWidgets, that's irrelevant to me.
    - jcelerier 6y ago
      Actually I'm only talking about the qtbase repo (core, gui, widgets, network...) in the Qt case, while for copperspice since they forked before 5.0 it's still a monorepo and the commits encompass everything (eg same that for Qt, plus script, WebKit and a few others they kept).
- zelly 6y ago
  > 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 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?
  - rualca 6y ago
    > (..). and a ncurses one for Linux. Nurses as an alternative to a QtWidgets GUI app? I'm not sure you're serious.
    - zelly 6y ago
      Most Linux users would prefer a well-designed curses application over a GUI. You don't have to ask me, just look at what Linux users actually run and share screenshots of. I'm talking about real Linux distro users not Chromebook users.
      - rualca 6y ago
        > Most Linux users would prefer a well-designed curses application over a GUI. 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.
  - hermitcrab 6y ago
beojan 6y ago
I'd guess they really want to get rid of the LGPL option (which was introduced when Qt was owned by Nokia and presumably they were more interested in Qt as a platform to develop their own products on than as a revenue stream), but the KDE Free Qt agreement means they can't just get rid of it.
- shrimp_emoji 6y ago
  Qt is GPL and LGPLv3[0]; gtk is LGPLv2[1]. Is there that much difference? 0: https://www.qt.io/licensing/ https://www.qt.io/licensing/ 1: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/COPYING https://gitlab.gnome.org/GNOME/gtk/-/blob/master/COPYING
  - beojan 6y ago
    I think LGPLv3 has anti-tivoization provisions. That said, I don't see how Gtk's license has anything to do with The Qt Company's recent antics. I'm in no way advocating people choose Gtk over Qt.
  - formerly_proven 6y ago
    And Gtk isn't a good option for non-Linux use. wxWidgets is LGPL (sort-of, modified) as well. wxWidgets is much more reasonable than Gtk for cross-plattform use, though can't compete with Qt Widgets in terms of features, API design, ease of use, stability etc. 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.
    - spease 6y ago
      I tried to use wxWidgets awhile back and gave up. It was a mess. Macros everywhere.
jariel 6y ago
Can you elaborate on exactly the lawyers are on about the 'sword'? 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?
api 6y ago
How else do you fund such a horrendously difficult thing? There is a reason there are no other cross platform UIs that are QT’s equal. Creating a good looking cross platform UI that supports things like accessibility and provides a close to native app experience (or can) is a real slog of a programming project. It must also be constantly maintained as native APIs change out from under it, hardware advances (e.g. higher DPI displays, HDR), and UI trends change. Pay for Qt or pay for developer time to maintain multiple versions of your UI. Your pick. Qt is probably cheaper in most cases.
- mwcampbell 6y ago
  I wish this comment could be moved all the way to the top of the thread, to preempt all licensing discussion.
- freedomben 6y ago
  I agree completely. If I made a commercial app I would pay. 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.
  - boudewijnrempt 6y ago
    The thing is, of course, that you don't need to trust the Qt Company. That's why we have the KDE-Free Qt foundation, and that alone makes Qt the best choice for anyone who developers software that can use LGPL libraries, commercial or open source.
- langitbiru 6y ago
  That's why we end up with many Electron applications. I mean even big companies like Slack or Spotify use Electron.
Nokinside 6y ago
Unlike most other dual licensed software, Qt Company has legally binding agreement with KDE related to LGPL licensed version. 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.
- freedomben 6y ago
  Any idea where one could learn more about the legally binding agreement? Especially wondering (i don't expect you to answer these, just wondering if you happen to know or know where one could read about 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/ https://kde.org/community/whatiskde/kdefreeqtfoundation/
- vlovich123 6y ago
  Dealing with static linkage is a giant pita because you have to provide all the object files for your code basically. I don’t think anyone really bothers with statically linking LGPL Qt into a non-OSS executable.
  - Nokinside 6y ago
    > a giant pita 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?
    - vlovich123 6y ago

by nikanj 6y ago

ReactiveJelly 6y ago

Yeah. I'm giving up on it for these reasons: - 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.

jariel 6y ago
"So how long will volunteers keep fixing the LGPL side, " 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?
- spease 6y ago
  For the core and majority of the library, yes, but some specific features (eg Charts) have been released as commercial-only.
  - mroche 6y ago
    Charts and several other modules are released both under GPLv3 licensing and commercial licensing. For Qt6 some of these modules have not been released yet, but should be available by 6.2, the first LTS.
jcelerier 6y ago
> - 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 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
- ptx 6y ago
  A lot of those commits are related to features some people might not care about. For example, I imagine a lot of work has been done on the JavaScript compiler for QML - but if only use QWidgets, that's irrelevant to me.
  - jcelerier 6y ago
    Actually I'm only talking about the qtbase repo (core, gui, widgets, network...) in the Qt case, while for copperspice since they forked before 5.0 it's still a monorepo and the commits encompass everything (eg same that for Qt, plus script, WebKit and a few others they kept).
zelly 6y ago
> 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 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?
- rualca 6y ago
  > (..). and a ncurses one for Linux. Nurses as an alternative to a QtWidgets GUI app? I'm not sure you're serious.
  - zelly 6y ago
    Most Linux users would prefer a well-designed curses application over a GUI. You don't have to ask me, just look at what Linux users actually run and share screenshots of. I'm talking about real Linux distro users not Chromebook users.
    - rualca 6y ago
      > Most Linux users would prefer a well-designed curses application over a GUI. 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.
- hermitcrab 6y ago

beojan 6y ago

I'd guess they really want to get rid of the LGPL option (which was introduced when Qt was owned by Nokia and presumably they were more interested in Qt as a platform to develop their own products on than as a revenue stream), but the KDE Free Qt agreement means they can't just get rid of it.

shrimp_emoji 6y ago
Qt is GPL and LGPLv3[0]; gtk is LGPLv2[1]. Is there that much difference? 0: https://www.qt.io/licensing/ https://www.qt.io/licensing/ 1: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/COPYING https://gitlab.gnome.org/GNOME/gtk/-/blob/master/COPYING
- beojan 6y ago
  I think LGPLv3 has anti-tivoization provisions. That said, I don't see how Gtk's license has anything to do with The Qt Company's recent antics. I'm in no way advocating people choose Gtk over Qt.
- formerly_proven 6y ago
  And Gtk isn't a good option for non-Linux use. wxWidgets is LGPL (sort-of, modified) as well. wxWidgets is much more reasonable than Gtk for cross-plattform use, though can't compete with Qt Widgets in terms of features, API design, ease of use, stability etc. 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.
  - spease 6y ago
    I tried to use wxWidgets awhile back and gave up. It was a mess. Macros everywhere.

jariel 6y ago

Can you elaborate on exactly the lawyers are on about the 'sword'? 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?

api 6y ago

How else do you fund such a horrendously difficult thing? There is a reason there are no other cross platform UIs that are QT’s equal. Creating a good looking cross platform UI that supports things like accessibility and provides a close to native app experience (or can) is a real slog of a programming project. It must also be constantly maintained as native APIs change out from under it, hardware advances (e.g. higher DPI displays, HDR), and UI trends change. Pay for Qt or pay for developer time to maintain multiple versions of your UI. Your pick. Qt is probably cheaper in most cases.

mwcampbell 6y ago
I wish this comment could be moved all the way to the top of the thread, to preempt all licensing discussion.
freedomben 6y ago
I agree completely. If I made a commercial app I would pay. 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.
- boudewijnrempt 6y ago
  The thing is, of course, that you don't need to trust the Qt Company. That's why we have the KDE-Free Qt foundation, and that alone makes Qt the best choice for anyone who developers software that can use LGPL libraries, commercial or open source.
langitbiru 6y ago
That's why we end up with many Electron applications. I mean even big companies like Slack or Spotify use Electron.

Nokinside 6y ago

Unlike most other dual licensed software, Qt Company has legally binding agreement with KDE related to LGPL licensed version. 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.

freedomben 6y ago
Any idea where one could learn more about the legally binding agreement? Especially wondering (i don't expect you to answer these, just wondering if you happen to know or know where one could read about 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/ https://kde.org/community/whatiskde/kdefreeqtfoundation/
vlovich123 6y ago
Dealing with static linkage is a giant pita because you have to provide all the object files for your code basically. I don’t think anyone really bothers with statically linking LGPL Qt into a non-OSS executable.
- Nokinside 6y ago
  > a giant pita 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?
  - vlovich123 6y ago