An upgrade is important for people who want to develop native app for SFOS ( at least for me ) , developing apps with an up-to-date framework would gives both developer and user great experiences.
I know it’s a topic that has been discussed in the last few years. I decide to ask again now just because it’s important, and I love SFOS
Agree, the fundamentals of this OS in some cases are ancient, needs to be streamlined to modern days.
There are so many threads even in this, not just the old forums with endlessly IRC meeting logs where you could have gotten all information about this immedeately. No, there isn’t a plan. Please use the forum search next time.
this is bad reply, guess what result is the first one right now when I tried to search for ‘upgrade qt’?
It was this topic! And your answer which tells the user to…use search search function.
It’s better to provide a link to valid post instead of directing one to the search engine, because never post will much likely be higher in the result.
So, can you please provide link describing this? As I’m unable to find one.
Here’s one:
Some more discussion:
https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-02-25-08.00.log.html
Thank you, I didn’t find the irc logs when I was googling around.
Now I’m looking forward to see the discussion on this topic again in 2023.
Ooops, the Qt 5.6.3 on SailfishOS was released 2016-03-16 and had its end-of-support three years later, on 2019-03-16.
SailfishOS community meeting IRC-log entries dealing with this topic, which a quick search yielded:
Qt 5.15 LTS as the final Qt 5 release is continued to be maintained (by the Qt company and separately by the KDE community), the recent OSS-release of Qt 5.15 LTS is 5.15.6: Qt 5.15.6 LTS Open-Source Version Released - Phoronix
For KDE’s Qt 5 Patch Collection, see Qt5PatchCollection - KDE Community Wiki and update Qt 5.15 LTS using KDE patch compilation repository · Issue #2685 · mxe/mxe · GitHub. As an application example, see e.g., Show openSUSE:Factory / libqt5-qtbase - openSUSE Build Service.
The discussion was done so many years, but the legal side doesn’t change. So as long as you 1st understand the 2 licenses since 5.7, the legal problem ahead & bring in something new except the version is very old, the 1212311247th time, don’t. We, as a community need a solution, wich could be:
Founding a non-profit, which buys a part of Jolla & uses it to push community topics. Some people made an incredible effort for this hopefully becoming reality.
Someone out of the community writes a Silica & lipstick replacement that works with latest Qt5, possibly Qt6. Apps then would still needed to be ported, but it would raise the pressure if other Linux mobile distros could run a hardly changed Sailfish application.
I don’t see any other solution that do involve the community. So please, bring in something new or let it, the whole thing is so tiring & we could have discussed things with achievable goals instead.
Both ideas sounds great, while I prefer the second one.
Is that using the LGPLv3 licensing Qt library, has a conflict with Jolla’s business ? As a new user to SFOS, I feel the current SFOS is just like a demo of ‘integrating app-support to existing Linux-based systems’, which runs really great.
Maybe we can start it from building a OSS version SFOS
QtWayland is GPLv3, not LGPLv3. To my knowledge, that’s the problem.
looking to the QtWayland licensing part at github it does have LGPLv3 as an option: qtwayland/LICENSES at dev · qt/qtwayland · GitHub
anyway, what I understand the original plan was to upgrade to Qt5.15.x but as the porting process was so slow and Qt6 is now more mature they seem to have moving to it instead …(at least when looking on some of the work at their github, they did start port stuff to 5.15.x and now there is work towards 6.x)
There are a number of 5.9 bugs in components that are LGPL that we could start gathering a list of. Those one could backport fixes for without issue. I’m thinking of the OSM geoservices plugin fail as an instance. I’m working on a non-violating patch, but have a bunch of stuff to do.
Maybe a wiki page?
I don’t know why the License is there, but this is the official blogpost from Qt: Change in open-source licensing of Qt Wayland Compositor, Qt Application Manager and Qt PDF
Maybe the option is not allowed in some cases, I’m definately not a lawyer that read all Qt license files to exhamine the acutal situation. Sony also moved away from Qt on their mp3 player interface afaik.
They told long ago when 5.12 still was the latest LTS, that they already run it internally. The issue is not technical, it’s definately a legal one.
Doesn’t Jolla already accept patches submitted to their Qt fork?
Yes, they do. The question is whether we start gathering bugs in one place to focus the effort to improve what we’ve got.
Interesting. I wonder if QtWayland reverted back to allowing LGPL silently. GPL-only there would indeed have been a potential blocker (but the ~5.9 effort surely was aborted before that license change).
Although it is not clear to me that the existence of such a license file necessarily means it applies to the whole project.
My best-guess was always that the anti-tivolizarion in LGPL3 was a big risk for being able to lock bootloaders and sign stuff in commercial projects. This was somewhat corroborated by abr’s recent talk, iirc.
My memory fails me on where exactly that was… i’ll see if it comes back to me later and edit that in.
Those 5.15 and 6.x patches are not from Jolla that i have seen, but from other projects using these components, or wanting to try them out. I.e. the likes of PostmarketOS, Nemo/Glacier and so on.
Indeed as soon as I saw it I shared the idea with the others. Also to reply to @oroesler , everything is going fine and it will come to reality soon.
Very nice to read that. I’m not coming to do it before xmas & I doubt the load will outgrow my wallet that fast. But once we can estimate how much the load will be in the long-term, it’d be nice to hand financial & legal aspects over to the coop.
… since QT 6.4, but not before that if you look closely.
Can you please provide specific pointers (i.e., web-links) to what you mean / saw: I cannot find any newer Qt-version imported there by sailors after their long stalled Qt 5.9 efforts at SailfishOS@GitHub.
Looking at the Qt’s official documentation there is no “licence change” for QtWayland in Qt 6 (and sure not for it in Qt 5).
See also Qt company’s nicely parametrisable licensing overview for all Qt components, which states just the same: No license change for QtWayland, it is GPLv3-only since Qt 5.7 for all non-commercial licenses.
Which abr’s talk where? Any reference / link?
BTW, the whole topic was discussed in depth at TMO in October 2020 in the thread Qt “stuck” at v5.6 in SailfishOS. Core excerpt:
[…] because [the *GPLv3 licenses] consistently use 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).