What version of Qt are we on?

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.

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

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

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

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.

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

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

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.

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/

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

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?

@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

Current QT 5.6 in sfos is under LGPLv2 license. Later versions are under LGPLv3, which Jolla (and/or their customers) sees as a problem.

I’ve read the thread and no, it hasn’t. Your explanation is also incorrect because Qt had been GPL/LGPL/Commercial at the time of 5.6 too. The link you’ve provided, https://www.qt.io/product/features, only checks the latest version of Qt. Qt Wayland, as @pasik has pointed out, is still LGPL in 5.12. In addition, Qt Wayland cannot be the problem to begin with because it was introduced in Qt 5.8 which means they don’t depend on it at present.
The above means the actual issue is what again @pasik says, v2 vs v3. Which makes me insist on my request for an answer by a Jolla developer because I genuinely don’t understand what challenge v3 poses. All it does is forbid non-code obstacles, such as API keys for services or licensing codes, to users building and using the code on their own.
So, to any and all Jolla employees out there and in here: please let us know when you’re going to update our developer platform.

@ddobrev, this has been discussed in depth at the TMO thread “Qt stuck at v5.6 in SFOS”, you may re-read that, which dives into the details of consequences and effects of *GPLv2 vs. *GPLv3.
(That is, unless you are javispedro, because there is no reason to iterate through all that again.)

They sure will, don’t be afraid of that.
But as you correctly pointed out, not deciding how to proceed and hence not updating Qt has become an issue on its own over the (many) years.

1 Like

@olf thank you for this link, I wasn’t aware of it. I perused it and I believe I still have grounds to argue but I’d like to read in depth before I do.

Jeez, I wasn’t aware. I’m using a community kernel:
Linux VollaPhone 4.4.146+ #16 SMP PREEMPT Sun Nov 22 10:20:28 UTC 2020 aarch64 GNU/Linux

It’s also a bit old, but I’m happy with 4.x (I run a bunch of linux vservers that are still 4.9.)

@poetaster: Qt!?!

Sorry, I’m off topic :slight_smile: I was asking, why a 3 kernel when a community device has a 4.4 kernel.

QT: I’m quite happy with Qt 5.6 :slight_smile: But I’m also doing ‘WAY’ too much in python which is just something I inherited. The one project where I have C responsibility (tidings), doesn’t benefit from newer QT as far as I can tell. Look at https://github.com/poetaster/tidings

For all intents and purposes, we’re all stuck between Scylla and Charybdis (sic). QT’s new licensing is extortionate (I mean future 6), and the LTS promise (and then bragging about fixing 5000 bugs. why did you have 5000 bugs!!!) is empty, and, and. This is just my 2 bits.

But I really don’t know the advantages of newer libraries from QT. The multimedia stuff I want to do has NOTHING to do with QT. There QT seems woefully inadequate. I’m going SDL for that stuff (for C++).

Oh, and when I say ‘we’ and refer to Scylla and Charybdis, I’m actually talking more of the predicament that Jolla is in. They have invested heavily in QT with Silica (which I’m really happy about cause it’s what I want !) but are now stuck with the expense problem.

I need to look into how KDE is dealing with this. I suspect the KDE community also has significant problems with the future of QT (but will probably fork.).

I’m for HARD fork :slight_smile: