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

[Karl Napf]

1) The KDE (and likewise other Open Source, Qt-using) devs could do a fundraiser campaign (or start a Patreon for this specific purpose) to buy licenses for all their devs. This would be meant to cover licensing purchases every time it's necessary. And this would continue for the foreseeable future. The KDE fanboys, fangirls, and fanpersons of the world will simply have to put money where their mouth is, to finance their passion project which is KDE (or other Qt-using OSS project).

This is an option, but it means two things: First all users need a commercial Qt license or KDE needs a license that does allow for distribution. Second KDE needs to re-license all their code and needs to nag all their dependencies to also re-license for commercial use. The first is very impractical or expensive, the second (almost) impossible.

I would also like to point out that KDE is already putting the money where their mouth is. KDE developers were very active in Qt development since basically forever. The Qt community (which KDE is a big part of) provides about 30% of all patches to Qt each and every month according to the commit statistics. KDE people chip in at every part of the development workflow. Well, they used to... let's see how that will change: The Qt Company said they expect community contributions to dry up now and are prepared to shoulder the extra work. Looking at the commit statistics again, they have fewer and fewer devs doing commits/reviews inhouse. I wonder how they plan to compensate for a 30% drop in patches. Maybe now that all the Qt 6 work has been done, they feel they can kick out the community?

2) KDE officially gets behind copperspice, and officially adopts them. It will likely be such a long and painful transition, that once complete, people will probably realize that just buying the Qt licenses in the first place will seem to be the less painful thing to have done, in retrospect. You know, time being worth money.

I seriously doubt that KDE can port from Qt 5 with a lot of QML to Copperspice, a quirky Qt 4 fork with no developers backing it, no QML, limited Qt 4 compatibility. They even removed moc, adding lots of boilerplate markup to the code, taking a hit in compiletime as well as runtime and memory usage and made it impossible to have proper QML bindings.

Them doing their own maintenance branch of Qt is way more likely and way, way less work.

[esbeeb]

Maybe now that all the Qt 6 work has been done, they feel they can kick out the community?

That's gotta burn all those KDE contributors to Qt, to be sort of "dumped" like that.

Them doing their own maintenance branch of Qt is way more likely and way, way less work.

I hope they call it "BronzeSpice", "Silverspice", or "GoldSpice".

[Nth_man]

I will be explicit.

144Hz and Alexmitter.

A lot of times Alexmitter and 144 write one after the other. Coincidence?
- https://www.phoronix.com/forums/foru...org-server-git
- https://www.phoronix.com/forums/foru...iple-buffering
- https://www.phoronix.com/forums/foru...91#post1220191
- https://www.phoronix.com/forums/foru...10#post1229510

[mdedetrich]

GTK was made because of similar Qt license issues happened nearly three decades ago .

I know but it also doesn't invalidate what I said.

[ed31337]

I seriously doubt that KDE can port from Qt 5 with a lot of QML to Copperspice, a quirky Qt 4 fork with no developers backing it, no QML, limited Qt 4 compatibility. They even removed moc, adding lots of boilerplate markup to the code, taking a hit in compiletime as well as runtime and memory usage and made it impossible to have proper QML bindings.

Them doing their own maintenance branch of Qt is way more likely and way, way less work.

Agreed. CopperSpice != Qt. CopperSpice may have started from some Qt code, but CopperSpice is it's own framework at this point, largely incompatible with existing Qt code. I briefly looked at CopperSpice a while back and was just not impressed enough to migrate my code to it. Especially since CopperSpice was missing a lot of modules that I actually use (such as the Chromium based QtWebEngine).

By making CopperSpice incompatible with Qt, they've forced me to make a "Go or No Go" decision, which inevitably results in "No Go" since CopperSpice is less complete than Qt.

A real Qt fork should try to maintain compatibility with existing Qt code as much as possible. It should be whatever bone the Qt Company lets us have, plus whatever bug fixes or improvements the community has come up with on top of whatever the Qt Company gave us. Then the decision to use the Qt fork vs using the Qt Company's last open source Qt release becomes a no brainer.

Only when the Qt Company stops contributing to open source entirely should we start considering making changes that break compatibility with the Qt Company releases.

[mcallegari]

I've been using Qt for my open source project for many years now, and here's my humble opinion.
Raising money in open source is not an issue, if you have the proper reasons.

I proposed them a few years ago to do "crowfunded bug fixing". They didn't listen.
Crowdfunding in general could be the way. Let's say target 100000$ a year, means average 10$ a year for 10000 users. That would sound much more reasonable.
I would myself be willing to fund them with a small contribution every year. In the end they allow me to write my application.

But no. Their problem is a bloated infrastructure with 1000 managers and 10 developers. They should fix this first. Get rid of useless people in the company and crowdfund REAL developers that actually listen to who funds them.

[Ansel Sermersheim]

Especially since CopperSpice was missing a lot of modules that I actually use (such as the Chromium based QtWebEngine).

It is important that we clear up a few misconceptions. CopperSpice is a set of libraries which was derived from Qt 4.8 and it has matured, just like any other project. We have incorporated many of the classes from Qt 5 as well as adding new classes and functionality not available in their product. Our intention and motivation is to develop CS as a set of libraries which support C++ development.

We are dedicated to being a true open source project and welcome user contributions. If there is class or module you believe is missing and this is impacting your project, contact us.

Simply put, we did not add QtWebEngine to CopperSpice since the license is LGPL 3 and CS is LGPL 2.1, which is a conflict. Any classes or modules which are LGPL 2.1 (or more permissive such as BSD) are fair game.

We are happy to discuss adding a "QML" like library which is done well and supports C++ bi-directionally. Any developer who wants to be part of this endeavor should reach out to us.

The opinion of the CopperSpice team is that a fork should be done to advance a project, not keep it the same. Contrary to what someone posted, we have developers and companies supporting this project and more are joining all the time.

CopperSpice is royalty free, will never be closed source, and we offer a support policy for those companies who wish to help guide the development process.

Thanks to everyone who is looking at CopperSpice and we value this discussion.