maemo.org - Talk - Qt "stuck" at v5.6 in SFOS

maemo.org - Talk (https://talk.maemo.org/index.php)

- SailfishOS (https://talk.maemo.org/forumdisplay.php?f=52)

- - Qt "stuck" at v5.6 in SFOS (https://talk.maemo.org/showthread.php?t=101127)

Qt "stuck" at v5.6 in SFOS

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.

Re: Qt "stuck" at v5.6 in SFOS

Dear @olf,

thank you very much for your letter as well as sending it open. I am very well aware of GPLv3 issue that Jolla has. Maybe not in full detail, but at least partially. Indeed, it is interesting that this time they did not mention any legal issues. Their reply has been polished over some time:

As stated also before, this is something we constantly evaluate. The current plan is still to proceed step by step, but we are not announcing any schedule for the update.

This step-by-step was refereed later from technical POV, but we don't know what is it referring to in practice. Although, I presume it is hard to update license to GPLv2.1, 2.2, ... :)

Going with GPLv3 version may require opening many (all?) SFOS closed components. We are talking about applications and libraries. That is another aspect they probably consider.

In general, I guess we have to keep asking and also look for whatever other solutions we can come up with.

Not sure that installing newer Qt in /opt (as I suggested) is such a great idea. I suspect there will be quite some packaging work involved in "breaking packages" in terms of removing all kind of "provides" to avoid clashes with the system-installed ones.

Cheers,

rinigus

PS: Note that for visibility on Jolla's side, we should have this correspondence on their forum. As far as I have seen so far, Jolla's folks don't comment over here, unfortunately.

PPS: Feel free to copy-and-paste the original letter at the new forum and I will paste the reply :)

Re: Qt "stuck" at v5.6 in SFOS

Maybe you have read this about the QT subscrition model - it is written in German though

Re: Qt "stuck" at v5.6 in SFOS

Not sure if Qt6 has anything to do with the original post, but Qt subscription model is inherently flawed. JetBrains, since the article mentions them, offer subscriptions, but with each payment, you get a perpetual license until that point in time, so if you stop paying - you only stop getting updates. When JetBrains tried to switch to the subscription model, there were similar problems with their clients, before coming up with that solution, so I hope Qt get sensible and don't do that or they would lose more than they would gain.

Re: Qt "stuck" at v5.6 in SFOS

Dear @rinigus,

thank you for your reply.
Let me address some points:

Quote:

Originally Posted by rinigus (Post 1569972)

[...]
Going with GPLv3 version may require opening many (all?) SFOS closed components. We are talking about applications and libraries. That is another aspect they probably consider.

Well they shall not be afraid of this "aspect", but probably they are by "considering it".

This idea (license proliferation across well defined APIs, in contrast to using a library you technically link to / a "link time dependency") is repeatedly propagated by the FSF (even before the GPLv3, with the GPLv2) to fulfill their (day)dream (or IMO: nightmare) of most Free Software (FLOSS) automatically becoming GPLed software sooner or later (and some proprietary software, too) by "this legal mechanism".
Unfortunately stating this loudly multiple times (and over decades) made many even more afraid of the GPLv3, the *GPL* family of licenses and the FSF, especially in commercial environments. I can comprehend that well.

TL; DR: There is no license proliferation across well defined APIs.
Think of Database Applications becoming automatically licensed as the DBMS they use (e.g., Oracle) due to the SQL API, but at the same time licensed as the OS they use due to syscalls, and concurrently licensed as .... this is nonsense leading nowhere and no reasonable court will follow this.

Quote:

Originally Posted by rinigus (Post 1569972)

In general, I guess we have to keep asking and also look for whatever other solutions we can come up with.

Yes, this is also my impression.
Thank you again for pursuing this.

Quote:

Originally Posted by rinigus (Post 1569972)

Not sure that installing newer Qt in /opt (as I suggested) is such a great idea. I suspect there will be quite some packaging work involved in "breaking packages" in terms of removing all kind of "provides" to avoid clashes with the system-installed ones.

Yes, unfortunately this sounds probable.

Quote:

Originally Posted by rinigus (Post 1569972)

PS: Note that for visibility on Jolla's side, we should have this correspondence on their forum. As far as I have seen so far, Jolla's folks don't comment over here, unfortunately.

PPS: Feel free to copy-and-paste the original letter at the new forum and I will paste the reply :)

As stated, I started writing a personal letter, then decided to make it an public one, reformulated it a bit for this purpose plus added "P.S." & "P.P.S.", and posted it; basically to make the thoughts I repeatedly had WRT the "ancient Qt issue" more widely known.
I initially did not think about "confronting" Jolla at their forum with this open letter, but this would definitely address my goal "increasing pressure for Jolla to make a decision ..." better. So while I know that some sailors are reading at TMO, they usually do not post here, so posting at FSO makes sense, even though I still do not really expect a (substantial) reply there, either.

But I feel that will need to be done properly to have a slim chance of achieving something:

Enhance some sentences (i.e., their "wording") to sound nicer (towards Jolla).
Maybe it is better to address Jolla directly, instead of you. I still would mention your recent inquiries WRT the "ancient Qt issue" as the trigger for the letter, so you are directly invited (per @mention) to comment.
Search for and link to sources of Jolla's former public statements WRT the "ancient Qt issue" at TJC, FSO and the "SFOS community IRC meeting" logs.
What shall I conclude with?
1. A plea to finally do any practical step towards a newer Qt (technical and practical)
2. A plea to finally make a decision and communicate a plan WRT upgraded Qt releases for SFOS (organisational)
3. A plea to seriously reconsider the "GPLv3 ban" for SFOS (license strategy)
  While this might have resolved Jolla's non-technical issues with newer Qt releases a while ago, the current conditions for commercial licensees (i.e., who is defined as such) may counter that. Another point to research.
4. A combination of above
  IMO, rather not, this overloads the letter, and allows to diverge into a question, which is easy to answer, while ignoring the other ones.
5. Demanding any of these points, instead of asking kindly, will probably raise the chance of no reply to 100%, but OTOH the wording shall not be too soft, because the "ancient Qt issue" has become a serious and strategic one, technically and WRT licensing, by Jolla not addressing it for years and "the Qt company" winding up their licensing scheme repeatedly.
6. Something else to conclude with?
Other ideas?

Re: Qt "stuck" at v5.6 in SFOS

This has been an intersting read so far!
Now let me ask a provocative question:
What's wrong with staying with this "ancient" Qt version for - ever, maybe?

Re: Qt "stuck" at v5.6 in SFOS

Quote:

Originally Posted by nonsuch (Post 1570107)

[...]
What's wrong with staying with this "ancient" Qt version for - ever, maybe?

Security
It is unmaintained upstream, for years in case of Qt.
Functionality
Well, I think @rinigus and others could write long lists of functions in newer Qt versions, which would make programming for it much easier, plus the loss of interoperability of software not specifically for SailfishOS, because all other Linux distributions are on a way newer Qt.

Both aspects were the main incentives for Jolla to update most of SailfishOS' basic tools and utilities (GCC & Co., GNU-utilities / Busybox etc. etc.) over the past two years.
This is why it is obvious that they have to resolve this, and I wish this would happen rather sooner than later (even better: long ago!), because the severeness of the impacts of this issue are permanently increasing (until on a Qt version, which is maintained upstream).

Re: Qt "stuck" at v5.6 in SFOS

Dear @olf:

sorry for missing your reply - it somehow slipped. Hence the delayed reply.

Re FSO: yes, please address it to Jolla, as the target would be different. I think it makes sense to contact them regarding it and get engaged in constructive discussion. If we manage to pull them out from this comfort zone with "soon we will decide".

Re GPL and APIs: As you have to link to Qt, I expect that GPL will infect your code through it. This is in contrast to SQL and other ways of process separation allowing you to mix licenses. GPL has it's purpose and we just have realize it when the license for your code is selected. In case of Qt, it is a way to ask for commercial licenses for non-free software. So, if Jolla goes for Qt update, there maybe a problem with mixing non-free Silica with GPLv3 Qt. While with the apps they can use proprietary licenses as software is built in-house, I don't know whether it extends to SFOS API distributed for all.

Cannot add much to your list, though.

As for why we need to update: @olf addressed it well. In addition, if we are in sync with others (Plasma Mobile, for example), we can work together on browser, email clients, and so on. Right now we are in isolation and have to choose the platform. While Flatpak helps, don't expect it to be working that well for all the software. And, in the end, we, as the developers, will have to choose whether work on ancient SFOS Qt or switch the platform.

Re: Qt "stuck" at v5.6 in SFOS

Sorry in advance for my negativity.

The way I have got to know Jolla as a company is not the best.
(just two latest examples: a) breaking overlay compatibility, b) they claim to be open and do SFOS with the community and then change the answering UI out of the blue - coming up afterwards that this decision was due to a huge end customer querying - without any interaction/information of this community beforehand. Not that I say it is bad, just the way it was done.)

I would assume this letter would just not be answered or as you already wrote answered with the same wordings as the last 7 years.
Of course there are internal company decisions not meant for the folks but ...

Nevertheless, I do appreciate your efforts in realizing and writing this. And you should post it to FSO!
But at the same time include/invite the CEO/CTO, press/community official via e-mail to this open letter!
So they see the need to answer. And hopefully join a fruitful discussion!

--
and yes, keep it friendly, asking (not demanding) but in an insistent tone

Re: Qt "stuck" at v5.6 in SFOS

Not sure how that could change Jolla's answer, but Qt is not only GPLv3, but also LGPLv3 for most of its modules : https://www.qt.io/product/features#js-6-3
Some useful modules like QtCharts or Qt Wayland Compositor, Qt Quick WebGL would still be under GPLv3 only, so that doesn't change much the problem, and I don't know if you could have core modules as LGPLv3 allowing closed source app, and at the same time the GPLv3 additional module requiring open sourcing only for the app that uses them ?

Another point is that the Qt Project is currently releasing Qt6, which will break some API, whereas the Qt5 minor versions where intended to keep binary compatibility between them.
The first Qt6.0 will not be feature complete, but really soon probably all other platforms will switch to it, so that will widen the gap with sailfish and make it even harder to keep compatibility between platforms (you don't only need to not use or backport the new functionality, you also have to change the code to compile on both versions).
Also, the work to upgrade the full OS to a new major version would be harder than updating a minor one, which hasn't been done for several years.

My 2 cts...