KDE Now Maintaining Their Own Set of Patches For Qt 5

[phoronix]

Phoronix: KDE Now Maintaining Their Own Set of Patches For Qt 5

The KDE project and the open-source Linux community has been in a sticky situation with The Qt Company having moved Qt 5.15 LTS to its commercial-only phase while most free software hasn't even been ported yet to Qt 6 let alone a number of modules and other features still missing from the Qt 6 tool-kit. So until the KDE project has fully transitioned to using the Qt 6 tool-kit, the project has taken up maintaining their own collection of Qt 5.15 patches...

https://www.phoronix.com/scan.php?page=news_item&px=KDE-Qt-5-Patch-Collection

[ddriver]

Why not contribute directly to the neglected fos version of qt?

[Alexmitter]

A fork without calling it one. Its non the less a fork as it moves away from the official code from the Qt company due to the proprietary nature of the Qt Toolkit.

I hope it will open some more eyes in the KDE community for a proper and final split away from the Qt Company and its commercial product.

[Alexmitter]

Why not contribute directly to the neglected fos version of qt?

There is no fos repo of Qt. To contribute to the repo on qt.io, you have to sign a "I give all my rights on that code away" letter and give them the code on the base of no license. It is also unlikely the Qt company would merge any PR for a Qt 5 series repo now.
That is why they want to maintain it as a patch set, because it otherwise would be a proper fork with its own name and repo and that would likely make their god-like lords at the Qt Company very angry.

[ddriver]

At this point I wonder how much kde might be willing to shell out on a viable framework alternative they could actually switch to.

[Charlie68]

As I said in several discussions .... this was to be expected. Once you have switched to Qt6 there will be no more problem. This problem exists only in the transition period to a higher version.
I don't think this is a big deal, it's just about patching any security issues or bug fixes.
Usually the latest version of a cliclo (4,5,6 etc.) is always in good condition, so there won't be much to do.

[gojul]

I guess they should simply fork Qt and rebase from time to time to the new Qt version... While I understand the need of the Qt company to make money GPL'ing the library could be a solution rather harmless to KDE.

[Slartifartblast]

A fork without calling it one. Its non the less a fork as it moves away from the official code from the Qt company due to the proprietary nature of the Qt Toolkit.

I hope it will open some more eyes in the KDE community for a proper and final split away from the Qt Company and its commercial product.

More of a spoon then ?

[Raka555]

Here is something worthwhile for the rust people to rewrite ...

[Alexmitter]

Alexmitter Sorry but this is the anti-fork. KDE pulls from upstream Qt so patches effectively needs to be CLAed. In other words KDE just validated Qt’s current actions and future actions. KDE also invalidated true Free forks and claims like “Qt doesn’t require maintenance” and “The KDE Free foundation prevents any malicious actions from Qt”.

Qt won again.

Of course Qt Company won, for now. But the KDE Community gets more open to a fork over time now. It will still take years before the KDE community is truly liberated from that abusive company. Those are just first and very small steps.

But the later one is incorrect. Qt wont release its patches to Qt5 in code form as GPL from now on, so the KDE people have to write those themself. They can maybe use some parts of the Qt6 patches and updates, maybe backport some stuff but not everything.