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.)
Sorry, I’m off topic 
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 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
I’m not familiar with Qt, but the site says for LTS version 5.15 (May 2020) that it is compatible with older Qt 5 versions. Maybe we’ll get the update soon.
Source: https://www.qt.io/blog/qt-5.15-released
I should, for fairness sake, have mentioned that QT is also stuck between the rock that is Google and the hard place that is Apple (Vulkan vs. Metal 3D stuff).
Oh, and for a bit, I had completetly forgotten about Corona . Sigh.
1 Like
I just read the comments after the release. They all point in directions Hard fork. Hmmm. That WOULD probably be good for Jolla
All SailfishOS devices are Android-devices flashed (in the factory) or reflashed by their owner, no matter if “officially” supported or a community port.
They all use an “Android vendor kernel”, hence the kernel version(s) the device vendor is distributing.
SailfishOS is actually designed to run on an “Android vendor kernel”. And while it technically also runs on an stock Linux-kernel, AFAIK no such mobile device exists.
More important from that statement - KDE is going to use Qt6 they are the biggest OSS consumer of Qt6 and the only party that would be able to hard fork.
That does not alter the fact that I’m running a 4.4 kernel (the android base system image is android 9) and the claim was 3.9 is standard for the sony’s?
My uname output is clear. And I’m running a ‘debug’ kernel from piggz, so it’s more ‘on the edge’ presumably.
I don’t think they are the biggest consumer by far. That would be the large video and FX studios that use QT. For instance, Maya (formerly silicon graphics) and companies like autodesk:
https://mail.kde.org/pipermail/kde-community/2020q2/006162.html
I hadn’t seen that KDE is going Qt6. Thanks!
KDE is the biggest OSS (Open Source Software) consumer and the only party with the resources/capability (and the mandate given to them by some clause in the licensing) to do a hard fork since they are also major contributors to Qt and understand its inner workings better then most other parties.
Maya OTOH is a commercial license taker and probably could not care less about the FOSS status of Qt they pay and get support and don’t need to change internals of Qt.
1 Like
Sorry, I misunderstood what you meant. KDE seems likely to be the biggest single FOSS consumer.
The commercial users, however (had you read the mail I linked?), very much care about the FOSS version. That is one reason I posted the link.
However, having looked at the patch page above, it’s clear KDE is mooching up to QT6. The language is dripping in marketing ooze… quote …
… but to be ultimately made obsolete by the adoption of Qt 6 when Qt 6 enables superior Open Source product development.
But, that is just the way it is. I don’t like it, but I’m commited to Silica. Free Software. Damn it. Not OSS software. Sigh.
As much as I’d like to respect all opinions… I can’t believe some people actually think a fork would turn out cheaper than paying for Qt licences.
Which, by the way, is far from certain: as far as I can tell by https://talk.maemo.org/showthread.php?t=101127, the only problem with LGPL v3 seems to be some “wording”. Well, it might be, but I highly doubt it: v3 was designed to combat Tivoization, not corporate usage. But there’s no need to even guess: the FSF has lawyers which would readily give any clarification. If it turns out that there’s no significant difference between “licensee” and “user”, it would mean Sailfish can sa(il)fely use a newer Qt including 6.
1 Like
I don’t know how much it would cost Jolla but I also never understood Jollas fear to be more OSS it is actually frustration with Jollas way too closed processes that makes me seriously consider moving to other platforms every once in a while.
The community was chomping at the bit to be involved 7 years ago and I think a lot of that momentum has been lost, now there are a ton of more open platforms out there and it’s a genuine waste that we keep having to have these discussions about outdated toolchains, outdated stacks security issues etc.
Granted there is still a very loyal core community but sometimes I really ask myself how long can this last.
7 Likes