What version of Qt are we on?

Platform Development
#1

In the latest release notes there did not seem to be any comments on this, it seems one API was upgraded to Qt-5.6.

According to this wiki page of which it’s up-to-date-ness is unclear we’re on a mix of 5.2 and 5.6.

Official support for Qt 5.6 ended in March 2019 while there are TJC topics discussing Qt 5.12 for SFOS 3.x support on 5.12 will also be ending by the end of the year (Qt version history).

What is the long term plan here? There are a ton of features in newer Qt versions that us developers are dying to leverage and surely maintaining an old stack without support from any company/community will waste far too much time for a small company like Jolla.

8 Likes
[Strategies] Bringing more sailors to SFOS
ProtonMail Bridge on Sailfish
#2

As long as Jolla has customers that don’t like the new Qt license I think we will be stuck on 5.6 forever.
Sadly because of the license we cannot even backport fixes from newer Qt. That leads to an outdated and even insecure base that hopefully will be updated. Otherwise we end up like BB10 that stucked forever on Qt4

13 Likes
Community meeting on IRC 25th Feb 2021
#3

If the customers don’t like gpl3 or jolla cant afford a commercial one -assuming this doesn’t have any limitations- the only way out of this is to change the toolkit.

With SFOS4 i was hopping that we would hear some news regarding the Qt situation but nothing thus far. Which is sad.

2 Likes
#4

How can we claim security & privacy focus if we can’t backport security fixes and can’t move forward?

Back to GTK? :innocent:

2 Likes
#5

Best way to get an answer on that and what the future holds is ask it in the meeting.

2 Likes
#6

What exactly is the problem with the new Qt license? Afaik Qt 5.6 (currently used version in sfos) is licensed under LGPLv2.1. New QT versions (Qt 5.9 LTS, Qt 5.12 LTS) are released under LGPLv3… LGPLv3 should be completely OK for a library like Qt?

Or is the problem the new requirement in LGPL v3 which requires/enforces that users need to be able to rebuild/replace the Qt library binaries, which might be problematic for “locked down” installations of (corporate customer) phones? Even that should be completely OK for sfos distributions like SailfishX where the user has root access anyway…

How to Comply with LGPLv3
When you use Qt under LGPLv3, you have three main obligations.

- Your application should link the Qt libraries as shared libraries.
- You must make the Qt sources – including your modifications to the Qt sources – publicly available. For example, you can make available the Qt sources on your website or on GitHub for download. You can keep the source code of your application closed.
- You must enable users to build the Qt sources for the target device (e.g., an infotainment system in a car or a washing machine), deploy the Qt libraries on the target device and run the original application using the modified Qt libaries on the target device.

The first two obligations are the same as for LGPLv2.1. They are well-known and well-understood. 
The third obligation is the so-called “anti-tivoisation clause“, which is Section “4. Combined Works” of LGPLv3 . 
It actually forbids to fully lock down a device using software under LGPLv3. 
A full lock-down was possible with LGPLv2.1 and was widely used.
3 Likes
#7

When you go to:
https://www.qt.io/product/features
And select only LGPL features, you can see that QtWayland is not offered. That one is only under GPL. There is more stuff that is not available under LGPL. That would simply mean that all software built on top of QtWayland needs to be GPL too.
Other option is to use the Commercial License, which is quite costly. Every year that Jolla has to not pay that license fee is a nice saving.
Plaese be aware, I am not a lawyer :slight_smile:

1 Like
#8

I may not understand this properly and please correct me if I’m wrong (and I’m also not a lawyer) but - QtWayland is the lib that allows Qt to be “drawn” on wayland, applications/Silica use QtWayland when Wayland is the Display Server but not directly so why would that even be a “threat”?

/Edit - come to think of it maybe Silica is a screen compositor in and of itself and does use QtWayland directly so I guess that may be the “problem” though given the amount of “we don’t have enough manpower” it might not hurt to go to a more OSS model.

#9

Hmm, Checking for QT 5.12 LTS: https://doc.qt.io/qt-5.12/qtwaylandcompositor-index.html

“Qt Wayland Compositor and the Qt Wayland integration plugin are available under commercial licenses from The Qt Company. In addition, they are available under the GNU Lesser General Public License, version 3, or the GNU General Public License, version 2.”

So Qt Wayland seems to be available (at least in Qt 5.12) under LGPLv3 aswell.

#10

Lipstick is the compositor and uses Qt Wayland as a library.

And great, in Qt 5.12 it is still LGPL. In Qt 5.15 it is GPL and not available under the LGPL anymore.
Not sure if there is more stuff that might have been switched in Qt 5.12 already. If not, the request for Qt 5.12 is not that unreasable :slight_smile:

It would be nice if people from Jolla would talk more about what is holding this back. That might help against too much speculation by us as mere mortal users.

3 Likes
#11

TBH I find it quite the contradiction, on the one hand Jolla prizes SFOS as security and privacy oriented on the other hand basic updates don’t happen or happen too slow (eg. OpenSSL, GnuTLS, Qt, the kernel).

On the one hand we always hear the excuse “we are a small company we don’t have enough hands” on the other hand they don’t actually allow the community to take a part in a lot of the process.

Qt 5.12 would be better then nothing but it’s support will end by the end of this year and it would be nice if there was a clear path forward maybe even into Qt 6.x.

4 Likes
#12

So it would only be a problem for the lipstick part of the stack which is probably also the part of the stack no competitor really cares about because compositors are a dime a dozen making it LGPL too would probably be the easiest step and I think would allow using the GPL stuff while also still allowing Jolla to hold the Silica cards close to their chest (though again I can’t for the life of me understand why Silica is not the killer feature that others would want to copy).

1 Like
#13

The kernel part is problematic because of the HW. Qt is probably a licensing/money issue, the rest i have no idea. And with the small community we are not everyone has the knowledge/time to hack on the OS and add features. Some do however.

#14

We know that Sony OpenDevices has at least kernel 4.9 for the Xperia X yet we are still on kernel 3.10.

I don’t know what the situation is on the XA2 and the 10 but both have even newer kernels available.

1 Like
#15

I think moving to a new kernel goes together with a new android base which is like porting the phone again. Technically you can run newer kernels on an older base but the sony open program doesn’t support it (read if you have bugs you are on your own). At least that is the case with the tama port afai understand.
HW and kernels will always be an issue unless someone develops a phone with linux in mind. In the last few years the only attempt on something like that was samsungs tizen phone which more or less run on an open stack with a few userspace blobs. But that was $$$$$$$$$$$$$$$$amsung. And it didn’t go that well commercially.

1 Like
#16

Not upgrading to recent Qt release is problematic. Porting to Sailfish existing Qt Applications is difficult since current Qt release in Sailfish is quite old. This is also sending a negative message for the future of Sailfish. There is no mystery: nothing is free and you may pay for third party technology especially if you are making business with.

#17

This answers the question of why the Xperia X is not supported anymore from Jolla. I still use it on a daily basis and noticed the oreo image is available for it. Luckily the only android app I use is ankidroid and it needs a minimum of android 4.1 \o/

#18

The Xperia X is still fully supported by Jolla, the only thing they have not done is update the kernel/android version, the claim as to the reason for this is that it would require re-flashing the device and that this is too big a hassle to ask of the users.

The only device that has so far gone out of support is the JP1.

2 Likes
#19

A version of Qt this old (5.6) is extremely worrisome. It’s a direct threat to the future of the platform. Could a developer of Sailfish OS itself please step in and answer when Qt 5.12, 5.15 and 6+ are going to be supported?

#20

@ddobrev,
Please read the whole thread, your question has been answered.

Short story, newer versions of Qt are under GPL or LGPL which is not liked by the commercial customers of Jolla, who bring in the most money. Getting a commercial license is quite expensive.
This is a business situation that seems not to have been made, and we have no real vote here. We will hear it Jolla Time.

1 Like