Qt 6.2 Enters Feature Freeze With More Qt5 Modules Ported To Qt6

[skeevy420]

skeevy420 So what about KDAB and Blue Systems? They just validated Qt’s actions. The chances of a free fork is now nonexistent.

What about those claiming the KDE Free Qt foundation would stop anything like this? They also knew it was a lie.

Technically it doesn't violate anything. KDE is still free to use the upstream Qt Stable release. The problem is the transition time to get KDE off of 5.X and onto 6.X. I say 6.X because we're at 6.2 and apparently it still isn't ready for 1:1 5.X porting.

There does seem to be a lot of grey area where when 5.15 LTS was released 6.X wasn't production ready leading to KDE (and anyone else) not being able to transition to 6.X in a timely manner and how that breaks good faith. I think a good lawyer could make an argument around that.

Also, Qt is so big that you'd have to be Google, Tesla, Apple, Amazon, etc to be able to fork it and upkeep it for the long term. There are something like 65 Qt modules. If each one has 2 developers then that's $100K to $200K per year per module (50-100K per dev per year); 6.5 to 13 million per year paying low-ball developer costs. Unless you have about $100M+ to cover the next 10 years development costs as well as a way to make it back and then some to cover the 10 years after that you probably shouldn't think about forking Qt.

[DanL]

IMHO they should have waited until now and did the LTS freezing stuff with this release. I don't have an issue with the paid LTS freeze itself, but how and when they did it was a real dick move.

The timing was bad, but there was a pandemic last year...
Anyway, the situation with LTS releases is not ideal, but KDE and open source has found a way to deal with it like intelligent, mature adults, with their own patch collection relevant to open source projects. A full fork of Qt is not necessary. It would be a drastic overreaction and a monumental waste of time/effort/$$. Now if Qt tried to close the source completely, that would be the time to invoke the GPL fork clause (i.e. the nuclear option). Until then, all this nonsense about a full fork because of the LTS policy is just a bunch of FUD, drama, making a mountain out of a molehill, etc.

I don’t care about Qt6 porting. Do you have an opinion on KDAB, Blue Systems and those who claimed the free foundation would prevent anything like this?

We do care about Qt6 porting. That should be what this thread is about, instead of asking irrelevant rhetorical questions to create a false narrative and further the trolling agenda.

[skeevy420]

skeevy420 I don’t care about Qt6 porting. Do you have an opinion on KDAB, Blue Systems and those who claimed the free foundation would prevent anything like this?

No, because there is no technical violation and they agreed to this scenario in 2015. That's the latest Agreement between The KDE Free Qt Foundation and The Qt Company. The agreement is in the gibberish between pages 5 and 10. Upstream Qt is still technically FOSS. As long as that stands then there is no violation. Outside of that and what's Here I have no idea what anyone has said on the matter.

All The Qt Company has to do is keep a subset of Qt as FOSS and they're good to go. If KDE and others use more than that subset then that's on them.

Was it a dick move pulling 5.15.X releases out from under them? Yes. That's obvious. They could have waited, should have waited, until 6 was ready. Yanking bug support like that in the age of SpectreMelt with two all beef patties is fucked up.

So now that we've addressed that it can only be seen as a violation of spirit but not a violation of contract; that this was an unfortunate scenario that was agreed to years ago -- Does it make sense to fork Qt 5.15.X permanently like yourself and others keep suggesting or does it make sense to get the remains of 5.15.X over to 6.X while keeping a temporary 5.15.X bug fix fork like KDE's doing now?

And if you post links to what they've said I might read them. I'm not gonna go off on a wile goose chase for comments I don't think I've read from places I may or may not have been to.

[Vistaus]

What's the point? AFAIK no Linux distribution or software uses Qt LTS so there's no reason to fork that branch..

Qt 5.15 is the current Qt LTS and Deepin 20 uses it.

[skeevy420]

Qt 5.15 is the current Qt LTS and Deepin 20 uses it.

Every distribution uses FOSS Qt 5.15; potentially with KDE patches. Qt LTS 5.15 is a different thing and is what you get with a commercial license.

AFAICT, Deepin is using 5.15.1 which is a FOSS Qt 5.15 release. There's also 5.15.2. Qt LTS Commercial starts at 5.15.3.

See here and here.

[skeevy420]

skeevy420 It’s pretty impressive how you are NOT answering I asked for your opinion on KDAB and Blue Systems. They clearly add pressure to keep keep things CLAed.

I already told you that I don't know their opinions on the matter and that you need to provide links if you want my opinion on their opinions. I'm not gonna wild goose chase stuff on Google that you're apparently already keen on.

[Nth_man]

[...] the age of SpectreMelt [...]

I wanted to quote here what a Qt and Intel developer [wrote](https://mail.kde.org/pipermail/kde-c...q1/006679.html):

Let me be very clear so there's no mistake: all security issues will be dealt with
in all branches, to the extent that we are able to reproduce them and
confirm them. We usually identify down to the point release where security
issues apply and will continue to do so.
-- Thiago Macieira

[Jabberwocky]

Has anyone tried using https://github.com/copperspice/copperspice for your projects?

I looks like it's actively being worked on for many years.

My biggest question would be Webkit compatiablity.

I would not mind listening or reading meeting minutes on QT6 vs QT6-fork vs copperspice. I'm sure people have considered it.

[bug77]

skeevy420 It’s pretty impressive how you are NOT answering I asked for your opinion on KDAB and Blue Systems. They clearly add pressure to keep keep things CLAed.

Nobody answers that because really, nobody cares.

[DanL]

Nobody answers that because really, nobody cares.

I was going to, but I spent my time in a more productive way.. talking to a brick wall.