Originally I intended this to become a private message, but ultimately decided for an "open letter" which can be discussed openly, because this topic is of common interest.

Hello @rinigus,

I appreciate that you repeatedly query Jolla about upgrading Qt in SFOS at Jolla's "IRC community meeting", the last time yesterday (2020-10-29).
But reading the "answers" from Jolla over the years when this issue has been brought up at TJC, by others at the "IRC community meeting" before and lately multiple times by you there, their two basic statements were always the same: "We will upgrade Qt from v5.6 step by step (i.e., not "jumping" to a very recent Qt version)" and "This will take some time to be come", sometimes spiced with mentioning some technical hurdles.
Both "answers" only address procedural aspects. The licensing aspects have only been addressed by community people and Jolla did avoid to say anything specific on that topic.

IMO the specific licensing scheme of Qt (basically dual licensed: commercial, plus (L)GPL with a CLA), which has been altered by "The Qt company" (formerly Digia) several times, is the crucial point:

• Jolla strictly avoids *GPLv3 licensed software for packages, which are part of a basic SailfishOS installation.
  Examples: GnuPG is in SFOS in its last GPLv2+ version, various other GNU utilities also were, but most of them are migrated to busybox (due to their current license, not the size reduction!) and so is Qt (v5.6).

  Side note:
  I can understand why Jolla and its primary SFOS-licensee are afraid of the *GPLv3, because it consistently uses the term "user" (instead of "licensee" etc. as all other FLOSS licenses do, including the *GPLv2s), plus one must provide the "user" with full control over the GPLv3 software (the "Anti-TiVO paragraph") including the ability to alter it anytime at free will.
  This renders *GPLv3 licensed software unsuitable for devices which are not user-controlled, e.g. MDM-managed devices in a company or government office, and generally any device, whose user is not its owner (specifically when the right to use and the right of possession are both transferred to a user). IMO, the proper, general wording is "licensee" and specifically for the "Anti-TiVO paragraph" the term "device owner"; with this wording the *GPLv3 would have nicely achieved its announced goals, without causing broad collateral damage. But the FSF refuses to acknowledge that wording for decades and so the *GPLv3s have become what they are: troublesome nonsense.
  But Jolla is not Google, who can avoid *GPLv3 software (also for these reasons) at all costs (usually by re-implementing software components under a different, most often "permissive" FLOSS license). All the classic (desktop) Linux distributors do not seem to have an fundamental, legal issue with the *GPLv3s, although they also have paying customers, who run these Linux distributions on computers, which are owner- but not user-controlled. Hence I am unable to comprehend why Jolla does not handle this in the same way these big Linux distributors do.

• "The Qt company" has increased prices for commercial Qt licenses multiple times and recently switched from a "perpetual license" to a subscription model, plus plans to restrict the FLOSS releases by delaying them and releasing only selected versions in order to make them less attractive, because they are so successful with Qt, tools for it and customising it, that they feel they can further increase their revenue this way (seriously!).

Ultimately Jolla either has to pay a lot for a commercial Qt license or accept the use of *GPLv3 software. My impression is that this management decision is pending, for years and still.

IMO Jolla does not really have a choice, because they are a small company, the costs and conditions of the commercial Qt licenses are becoming worse and worse, and avoiding *GPLv3 software causes ever increasing work for Jolla by substituting more and more components in SFOS. They should have made that decision long ago, which would have saved them a lot of conversion, maintenance and technical trouble (e.g., GNU-tar vs. busybox-tar incompatibilities breaking the GUI backup / restore function).
And specifically for the future of the (L)GPLv3 Qt releases: The KDE community is committed to handle that somehow (trying to convince the Qt company to alter their plans for the GPLv3 releases or to "soft-fork" Qt), Jolla could contribute to these efforts and make use of them.

HTH,
olf

P.S.: Why am I writing this up?

• I see (at TJC, FSO and Jolla's "IRC community meetings"), that many people believe the ancient Qt in SFOS primarily has technical reasons, while that likely originates from licensing aspects.
• This enables Jolla to evade further discussion by replying with their aforementioned "two standard phrases" each time.
• I also sense that crucial aspects of the licensing situation (especially the properties of the *GPLv3 licenses and their consequences) are not fully understood by many.
• I would like to raise understanding in the SFOS-community for the difficult decisions Jolla has to make here (Qt, plus *GPLv3 software in general).
• I would like to see the pressure rising for Jolla to finally make these decisions, to create a plan based on them and to communicate this plan (fuzzy and without timelines, of course ). May this write-up help to shape more pinpointed questions.

Adding all this up, I do not believe that an upgraded Qt will be deployed for all per SFOS release soon (e.g., within half a year).

P.P.S.: This text is licensed CC BY-SA 4.0 (by olf, 2020-10-30), please reuse it.
Feel free to discuss the topic and its various aspects, ask "checks & balances" questions etc.