FYI, the delay of source availability of future Qt releases is not clear.

Last public discussion about the subject, to my knowledge: https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...

It seems clear to me. Qt company considers that they might follow the legal agreement with the KDE Free Qt Foundation to the letter doe nothing extra.

> they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months. They are aware that this would mean the end of contributions via Open Governance in practice.

This is the minimum they can do, and they can't do legally anything less. If they don't release free edition within 12 months...

https://kde.org/community/whatiskde/kdefreeqtfoundation.php

> Should The Qt Company discontinue the development of the Qt Free Edition under the required licenses, then the Foundation has the right to release Qt under a BSD-style license or under other open source licenses. The agreements stay valid in case of a buy-out, a merger or bankruptcy.

KDE releasing Qt under BSD is IMHO credible threat.

I don't understand the rationale behind this. Why would a commercial company dupe itself into restricting the licensing of its product?

Funnily enough, this came up in a similar comment earlier today.

https://news.ycombinator.com/item?id=23319868

It's important to note that Qt is only talking about the commercial LTS release, and not the open source version of Qt.

All development of new code released in open source Qt is still released in the development branch, the open source community 'misses' the back ports into the stable (LTS) branch.

From the linked email:

  > As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months.
  > They are aware that this would mean the end of contributions via Open Governance in practice.

I'd venture to say this means: open-source repo will be kept public.

Will we be able to match a Qt release with the corresponding source?

Can anyone point me at a Qt-based Android app on the Play Store? Would like to find out how Qt's accessibility support is on Android these days, but not serious enough about it to build an app or contact the Qt company.

I have written a bunch of Qt android apps over the last few years (not all of them still on the app store though):

e.g:

https://github.com/ImageMonkey/imagemonkey-thegame

https://github.com/bbernhard/nextload-client

https://play.google.com/store/apps/details?id=io.imagemonkey...

Not the prettiest and somewhat older here's a Common Lisp REPL using QT: https://play.google.com/store/apps/details?id=org.eql5.andro...

(I am NOT the author.)

Thanks for the link. Unfortunately, this app doesn't work at all with the TalkBack screen reader. Not sure if the problem is with CL REPL or Qt. Apparently, according to the Git commit history, Qt introduced accessibility support on Android (and iOS) in 2014. I'll have to dig further when I have time.

Repaper Studio, a drawing application designed to be used with the Slate, a digital drawing tablet. I've been working in the company behind it and the app is Qt-based (QML/QtQuick).

https://play.google.com/store/apps/details?id=com.iskn.imagi...

AFAIK the MuseScore sheet music viewer / player app is written in Qt for both mobile platforms. https://play.google.com/store/apps/details?id=com.musescore....

In my personal opinion, it is insane to use qt for a Mobile or embedded environment based on the fact that the license for that kind of devices is quite shady and that they have a clear history to do major breaking changes at each major release.

If the license of the device is shady then it's not a qt problem. If they do major breaking changes then qt should abstract over them and alleviate the problem.

We should remember that "development frameworks" were not even allowed in the early days of iOS [1]. That we can use them now is a huge step forward. But at the same time, little prevents companies like Apple from throwing the switch back for new apps.

[1] https://www.apple.com/hotnews/thoughts-on-flash/

Quoting from [1]:

> We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

What many forget when quoting iOS victory about Flash, is that Adobe was quick to adapt and offer AOT compilation for Flash.

So many of the casual games in iOS kept being Flash, before Unity and Cocos got enough uptake.

This seems to be a quote taken out of context. Apple wasn't against third party frameworks as a rule — plenty of third party libraries and tools popped up, especially for allowing languages other than ObjC to be used effectively on iOS.

The message in Thoughts On Flash wasn't about third party libraries wholesale; it was refuting the expectation that Apple should special-case Flash, a technology that never ran acceptably on Android and was quickly deprecated, never mind on iOS.

> license for that kind of devices is quite shady

Would you please describe what exactly is shady in the licensing for someone looking at Qt?

My bigger issue is that they are inflexible with their licenses for small businesses. Either you use LGPL, which requires copyleft on bundled mobile apps (I believe) or you pay based on the total revenue of your business, no matter how small the app is, as told by Michael Dominick on the Coder Radio podcast. Can be quick expensive if you want to launch a new product line, as Mike did. He decided to rewrite his app in C# and AvaloniaUI for Windows/Linux cross platform support.

https://github.com/AvaloniaUI/Avalonia

> that they have a clear history to do major breaking changes at each major release

This is a major issue for me.

> Either you use LGPL, which requires copyleft on bundled mobile apps (I believe)

LGPL never enforced any copyleft to something linked on it. This is a wrong, unfortunately common misconception.

> LGPL never enforced any copyleft to something linked on it. This is a wrong, unfortunately common misconception.

Please read my comment carefully. I never said 'linked'.

> Please read my comment carefully. I never said 'linked'.

"bundle" does not change anything, you still do not need copyleft on your app.