Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Qt commercial-only LTS phase starts (qt-project.org)
46 points by sjmulder on Jan 12, 2021 | hide | past | favorite | 50 comments


All the Qt Company has accomplished here is to put another nail in the fast, native cross-platform and desktop software coffin, hinder Qt 6 adoption, and push more developers to Electron.

The FOSS world will take Qt 5.15.2 as the last official version and maintain distro compatibility patches. The last Qt 4 release, Qt 4.8.7 released in May 2015, is still available in Arch AUR with 32 distro revisions and a dozen community patches.

They're playing with fire gambling that the FOSS community ultimately won't fix bugs in Qt 5 faster than they do (once they switch all their energies to Qt 6)


This seems overly dramatic.

The concept of LTS was relatively new. Qt users have gone ages without LTS. Nothing here prevents you from using older Qt versions where needed.

You're not being stopped from using newer Qt versions, just that LT support is now gated behind commercial licensing.

Can you expound on exactly what about this is so inflammatory to you?


The LTS aspect is all marketing misdirection. All Qt 5 versions are now LTS, including the latest.

This means FOSS releases from the Qt Company are effectively subject to a 1 year delay, and as such they are now being as hostile to the FOSS as they can be under their legal commitments.

Whatever they say, I wouldn't bank on any further public updates to Qt 5.12 or 5.9 either.


Can you provide sources for your claims?

Per Qt [1] the only major difference is that open source users only get patch updates for a specific version till the next minor update is out. Only commercial users keep getting patch updates to older minor versions.

No where can I find mention of a year delay.

[1] https://www.qt.io/blog/qt-offering-changes-2020


The problem is that at the start of a major release cycle (Qt 6) the new one is not very viable, but means the old one (5.15.x) isn't the latest anymore. So anyone who can't use 6 but relies on the open-source version now isn't getting patches.

Qt company would like to pretend that is forever (and thus doesn't mention it), but actually the community contract (which exists to prevent Qt company from ever keeping parts of core Qt closed) forces them to release the patches after one year, because withholding any patches to core Qt for more than a year triggers a safeguard clause in that contract that forces relicensing of Qt.

FWIW, your tone does not feel appropriate, especially when you suggest "conspiracy theories".


> All Qt 5 versions are now LTS, including the latest.

Source?


Qt 5.15 will be the last Qt 5 release. It's also LTS, ergo all further patches eleases from Qt Company are for LTS branches...

They have to make these changes public under their agreement with the KDE foundation after no longer than 1 year. If it wasn't for that agreement Qt 5 would be abandonware from a FOSS perspective, much like Qt 4


> It's also LTS, ergo all further patches eleases from Qt Company are for LTS branches

Time will show. Don't forget that there are many community contributors. As far as I've understood the LTS branch is closed for community contributions which makes sense since it would not be desireable to wait one year until these contributions would be accessible to other FOSS users; but this only applies to the LTS branch; the other branches are not affected.

> Qt 5 would be abandonware from a FOSS perspective, much like Qt 4

Well, I still have many active projects using Qt 4.4, 4.8 and 5.4; didn't see any added value in upgrading. Maybe people using QML can profit of more recent versions, but I'm using the C++ API only with work mostly done by Trolltech and Nokia.


What do you mean subject to a 1 year delay?

Qt 6 is available right now.


Qt 6 is less than half the size of Qt 5 in terms of modules/size. I'd also consider it alpha quality software at this point.

I don't see KDE adopting it Qt 6 anytime soon given the tone. Qt have already approached KDE to try and renegotiate their agreement.

It's likely that 6.1 will see 6.0 become LTS, and we will never see a FOSS stable branch again. For hobbiest developers, small enterprises, FOSS developers and LTS desktops this is pretty disastrous


Please provide sources for your claims. This is starting to verge in to the realm of conspiracy without them.

Edit: yes I know Qt 6 is only a partial release. I'm asking the poster to provide sources for their claims so they're not being editorialized to seem sinister.


Not a consipiracy. There are many modules that haven't been ported to Qt 6, but are planned to be ported by 6.2: https://www.qt.io/blog/add-on-support-in-qt-6.0-and-beyond https://wiki.qt.io/Checklist_for_Qt_6.0_inclusion

Personally, I can't migrate to Qt 6 because it lacks the location module.


Basically nothing prevents them from declaring 6.2 LTS on day 0, only releasing sources for most modules to commercial customers and only under the LGPL up to a year later (under the KDE agreement)


That's not in their favor, though. The point of moving open-source off of LTS is to move open source onto the bleeding edge to provide testing, not to just withhold 6.2 entirely.

> Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.


Why should I alpha test their bleeding edge versions if any issues I report result in a patch that I myself, and others like me, can't access for at least 12 months?

I'd be better off reporting a bug on GitHub to some FOSS fork, because at least when it's fixed I can benefit from it immediately. Likewise any contributions I made would be welcome (Qt Company are now closing patch contributions)

They're already doing the work of cherry picking and testing LTS. They're saving themselves a git merge and a git push because they falsely believe this will drive further sales.

Maybe it will, but they're still throwing the FOSS community using Qt 5 under the bus.

It would have been better to go back to GPL, and had just had timely FOSS releases, since a small business license for the library is only $500/year.


They already refer to 6.2 as LTS in their blog posts, so it's going to happen


5.15 is also LTS but it's treated the same as 5.14 for open-source.

Likewise, 6.2 will be LTS but it's the support that is gated, not the release.

Or is this not the case?


That's entirely up to them. They've blogged that 6.2 as LTS and announced that LTS branches won't be public until they're a year old.

Why would they make 6.2.0 a public FOSS release and then withhold 6.2.1 for a year? And even if they did, would you want to use a .0 release on your project?

No, it seems likely to me that 6.2 will effectively be closed source when it's announced, and open source releases will follow after a year.


They'd make 6.2.0 a public FOSS release and not release 6.2.1, they'll make 6.3.0 a public FOSS release.


So FOSS users will be caught hopping between .0 releases full of bugs and regressions? Sounds fantastic.


That's fair. However, I guess I'm trying to get the poster to provide sources in general for all his claims in this thread.

There's a big difference between: - modules not ported yet - modules ported and being held behind a commercial license where they weren't before.

One is more nefarious than the other, but by omitting context, the initial poster is alluding to the more sinister option based on the dramatic context of their posts.


It's literally in the official release planning and announcements that many modules are not part of the initial release.


> and push more developers to Electron

Qt has huge market share in embedded apps, where Electron is a non-starter.

I'd love to see more open-source alternatives to Qt in the embedded systems GUI space, but it's going to be a long time before anything reaches similar levels of maturity and optimization.


How does GTK fare in the embedded space?


Bad enough to spur corporate investment in EFL



> and push more developers to Electron

Or Flutter, if cross-platform desktop becomes first class compared to mobile.

There's also Haxe. The language is great (inspired by AS3) but last time I tried it there were too many moving pieces (eg: OpenFL depending on Lime and both moving at different pacing). That was some years ago though. Anyone is using it for desktop gui?


Aren't you fine if you stay on the latest release? LTS releases are good for industrial or commercial applications were you need to rock solid stability... and should be paying to support development. For end users latest release should be fine.

The way I see it you either pay for the library through money or by constantly moving forward with your APIs and doing updates to work with the latest version. If you are anchored to an old version and not paying, you are deadweight. While I'm not clear on the details of Qt's plan, but in the JDK space it makes perfect sense where you have a large contingent of vocal non-contributing that holds back large libraries for updating which slows the evolution of the platform.


The only way to stay on Qt 5.x (as Qt 6.x is not yet ready for production use since the ABI is not stable and many modules like QtWebEngine are missing) would be to fork it, since they will no longer accept patches from the community. Either that, or get every Qt distributer (e.g. Debian, OpenSUSE, Manjaro, etc) to accept your patch.


> LTS releases are good for industrial or commercial applications were you need to rock solid stability...

from what I could see corporations just buy LTS contracts to be able to ask for bugfixes if the need arises - I've seen products where Qt 5.12.2/3 was used even when the latest was 5.12.8


Most users want stability. If I shipped an app with Qt 5.12 dlls I would to bump to 5.15 and force potential bugs on users in a minor release.

Qt's track record on user facing bugs just isn't good enough


I don't know.

I have always preferred wxWidgets.

People's aversion to well designed C style macros is just overreacting IMO.


Does anyone know how this is compliant with the QT Company's agreement with the KDE Free Qt Foundation?

I was under the impression the Qt company was legally obligated to release all updates under the LGPL, and failure to do so would result in the latest release of Qt being relicensed to BSD.

Specifically, section 3.2 in this agreement. https://kde.org/community/whatiskde/Software_License_Agreeme...

I understand they have 12 months from now until that clause kicks in, but based on their announcements it looks like the Qt company has no intention of ever releasing these 5.13 updates as open-source.


They probably don't want to advertise that, because it might persuade people to wait instead of pay. Hopefully they'll release the patches quietly after a year instead of trying to lawyer out of it (which I'd expect to be unlikely, but who knows)


Fixes having a delay of multiple month is enough for many companies relaying on Qt to pay for LTS ;=)


As someone who is relatively new to coding but has a small Qt project, can someone explain what LTS is? I’m thinking it means you get security updates but don’t have to change api versions that might break your app?

For example, my app compiles with Qt 6 and I wrote it as such. But I’m guessing when 6.1 comes around, there may be a chance that something will break.

I guess I’m wondering if bigger projects avoid trying to update because it makes for complicated debugging if something does need to be changed, or if maybe something else contributes to it.


LTS = Long Term Support

It means that a specific qt version will get support for a "long" time. Support can mean direct customer support but it also can mean that e.g. security & bug fixes get back-ported (if someone with LTS support runs into them). It also can mean that proprietary extensions e.g. payments systems support the version of the software longer.

The reason why to use LTS is because you don't want frequently port your software a newer major version of the library/framework does not only cost you but in case you highly customized the library/framework or depend on a lot of very specific behaviour might go from costly to monetary unfeasible. (I mean consider you havily depend on a feature dropped in the new major version.)

As such if you sell software/hardware with software and you need to support it long enough because your customer expects it it always is a good idea to see if there is a LTS version which has as long or longer support then you need to provide.

Oh and due to longer usage LTS versions tends become less and less buggy over time as bugs are fixed but (view) new bugs are introduced as no new features are added and not parts are rewritten (beside bug fixes).


Does anybody know how KDE is (planning on) dealing with these changes to QT?


It doesn't seem to be THAT bad as LTS phases were introduced in the first place only very recently. See: https://old.reddit.com/r/linux/comments/kqi1v8/qt_515_commer...

Also, some distros haven't even updated to the latest FLOSS version of the LTS release, so it seems to not be that important to the maintainers.


Right. Never saw a benefit in switching to the most recent version. Still very satisfied with Qt 4.8 and 5.4.

Apparently they closed the LTS branch for community contributions which is reasonable because otherwise the community would contribute to a version which would only be accessible to other community members a year later.


> Right. Never saw a benefit in switching to the most recent version. Still very satisfied with Qt 4.8 and 5.4.

if you have any users with a hidpi screen it makes a huge difference to them


I have indeed; macOS is no issue; Windows needs a couple of ifdefs, no big deal.


there are plenty of hidpi bugs that were only fixed in 5.12 ... 5.15 though. Even 5.12 is still a big mess with e.g. 125% scaling on windows - text will scale but not images, things like that


Yeah, just today i noticed top-right-corner icons in QMdiArea are an absolute mess in the build I have, they get so tiny then big on cursor hover then tiny again...


I have been able to work around issues as far as necessary.


Please change title from QT to Qt (I am an ex-Qt developer).


Ok, done.


There is always CopperSpice


What's the core benefit? Are there any notable applications that use this?


CopperSpice does not have LTS either, does it?




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: