The Qt Company Is Tomorrow Moving Qt 5.15 To Its Commercial-Only LTS Phase

[phoronix]

Phoronix: The Qt Company Is Tomorrow Moving Qt 5.15 To Its Commercial-Only LTS Phase

As part of their fundamental shift to restrict Qt LTS point releases to commercial customers, The Qt Company is closing the Qt 5.15 branch to the public tomorrow with future Qt 5.15 LTS point releases to be restricted to paying licensees...

http://www.phoronix.com/scan.php?page=news_item&px=Qt-5.15-LTS-Commercial-Phase

[leo_sk]

So can't FOSS developers just branch of the most current lgpl licensed qt5.15 version and add patches to it as long as they see fit before qt6 deployment?

[Michael]

So can't FOSS developers just branch of the most current lgpl licensed qt5.15 version and add patches to it as long as they see fit before qt6 deployment?

That's what the "-free" branch would be as outlined at the end of the article, albeit would be without any patches from The Qt Company's releases.

[BraindeadBZH]

To me it makes some sense that LTS is commercial only but why so early? Qt 6 is far from being production ready.

[Snaipersky]

Fork it and f*ck it (Qt6). I know Krita devs are unhappy about Qt6 dropping ANGLE, and many other things are still missing. The graphical backend being unable to take advantage of vulkan's predilection for multithreading is a travesty, and Qt6 largely feels like a simplification with some modernization. If maintaining useful features is too hard for the Qt Company, maybe the software would be best served in the hands of someone else.

[Setif]

The community should fork their own and make it LTS

[ddriver]

The absence of competition in the "portable C++ app development frameworks segment has enabled the company to raise to an unprecedented level of community-unfriendliness.

[royce]

Flamewars in 3, 2, 1...

[CommunityMember]

That's what the "-free" branch would be as outlined at the end of the article, albeit would be without any patches from The Qt Company's releases.

And, while there are external contributors, The Qt Company programmers are likely the biggest origin of fixes, and reproducing those fixes is a distraction from useful work (doing things twice, perhaps in different ways, is a problematic future merge conflict). And that presumes that there are enough external contributors that know the Qt code(s) well enough to be able to result in good fixes to a potential Libre-Qt fork.

I suspect that the first step is likely going to be to determine if some external company will be willing replicate the infrastructure that the Qt Company has built for bug and CI work such that existing external contributors will feel comfortable working in that alternative space (if you have to change your entire workflow, and do your own regression testing, few are going to be willing/able to do so). KDE.org is the obvious choice here if a trigger needs to be pulled.

[ddriver]

I am sure that inconveniencing people into purchasing the poorly tiered commercial licenses will work out great.