More Open-Source Participants Are Backing A Possible Fork Of Qt

[ssokolow]

even better would it be if KDE and KDAB would unite with the gnome people and should start develop a gnome based KDE or a Knome version of KDE.

lets face it this is what these people need (the hard way)

Unfortunately, there's been a long history of KDE developing tech first and even being willing to offer C bindings, but GNOME being so rabidly anti-C++ that they instead reinvent the tech, which KDE doesn't want to use because it's a buggier, less featureful clone. (It took ages for GnomeVFS to stop being a crashy mess compared to KIOSlaves.)

[oiaohm]

This is certainly interesting, thank you for sharing. I do understand the frustration, but I didn't know that KDAB was actually that big, though, still significantly smaller than TQtC, but you're right about shifting operational expenses from licensing to employees (depending on license fees). Business side of things that shouldn't change that much for you though, you're a commercial customer of them. Besides having the "right" values at heart, you'll have reasons for not liking that 12-month open source delay even business whise, which I currently don't see.

There are many key reasons why 12 months does not work and will harm KDAB big time.

When the KDE agreement with TQtC(The Qt Company as you put) the delay on zero days being released to public was average of 18 months today its 90 days. 12 months was a valid number at the time the orgianl agreement beteween KDE and TQtC was done because that was 6 months before zero day information would be released. Today a 12 month delay on open source version today makes security fixes 275 late in best case. This is start of a bigger problem.

Let say KDAB is working on a product who code base has to be third party reviewed. Chosen third party may not have a Qt license so the time to this review end up delayed until the open source qt release. If the product is found to have known exploits that zero days come after 90 days you fail review.

If you are being practical about the max delay that is acceptable in the current environment it 60 days not a day more. 1 day more parties like KDAB are put in a position where they are forced 1 to threat to fork and 2 to really fork of TQtC does not backdown because the 12 month delay in current environment is a fatal checkmate to KDAB business and other business like it if they do nothing.

Serous-ally TQtC has done a really wrong thing. They are harming there commercial customers. A 60 day head start in development for commercial development is still worth paying for the problem is a 12 months head start is worthless today because it does not work practically any more.

[STiAT]

There are many key reasons why 12 months does not work and will harm KDAB big time.

When the KDE agreement with TQtC(The Qt Company as you put) the delay on zero days being released to public was average of 18 months today its 90 days. 12 months was a valid number at the time the orgianl agreement beteween KDE and TQtC was done because that was 6 months before zero day information would be released. Today a 12 month delay on open source version today makes security fixes 275 late in best case. This is start of a bigger problem.

Let say KDAB is working on a product who code base has to be third party reviewed. Chosen third party may not have a Qt license so the time to this review end up delayed until the open source qt release. If the product is found to have known exploits that zero days come after 90 days you fail review.

If you are being practical about the max delay that is acceptable in the current environment it 60 days not a day more. 1 day more parties like KDAB are put in a position where they are forced 1 to threat to fork and 2 to really fork of TQtC does not backdown because the 12 month delay in current environment is a fatal checkmate to KDAB business and other business like it if they do nothing.

Serous-ally TQtC has done a really wrong thing. They are harming there commercial customers. A 60 day head start in development for commercial development is still worth paying for the problem is a 12 months head start is worthless today because it does not work practically any more.

That definitely makes sense. I personally didn't even think they'd hold back bugfix releases, I took it for like minor/major releases providing the bugfixes. Keeping bugfix/security fix issues locked down and not backported is the worst thing they could do, but ye - cost effective (for them). And it even damages the framework, since you can't get certified anywhere.

I think I got you there and the issues you see. Thank you for elaborating / putting some detail to it. Very much appreciated.

[tildearrow]

tildearrow Lol, do you really think the KDE free Qt foundation has those rights at will? That’s just laughable. Another example why you shouldn’t do CLAs. It’s too complicated for most people.

well sorry to kill your dream. The foundation has no rights to do so unless Qt misses release deadlines. And they won’t do that.

I don't think. It does, pretty much, perhaps.

You must have a disgraceful brain. Look here, traitor.

The Foundation has license agreements with The Qt Company, Digia and Nokia. The agreements ensure that the Qt will continue to be available as Free Software. Should The Qt Company discontinue the development of the Qt Free Edition under the required licenses, then the Foundation has the right to release Qt under a BSD-style license or under other open source licenses. The agreements stay valid in case of a buy-out, a merger or bankruptcy.

Muwahahaha!

[tildearrow]

This is why I ask if Kt would keep the pesky Qt CLA. Obviously KDAB need that to upstream back to Qt.

Why do you ask when you know they obviously wouldn't keep it?!

[tildearrow]

tildearrow Mind your language.

I wish you would leave us in peace already.

And please read your own quotes. Read the precondition. Qt would never discontinue free releases. That would deteriorate their bookable asset (commercial Qt). So yeah, you are wrong.

“Should The Qt Company discontinue the development of the Qt Free Edition under the required licenses, then....”

Sorry but this is only the beginning. It can and may get worse. Nobody knows.

[tildearrow]

tildearrow So now your current plan is void. You can’t relicense current Qt. And KDAB want to keep the CLA.

So now what?

Oh wait come on really?
Are you just assuming KDAB will take over Qt so they give you a chance to keep the pro-GNOME crusade up?!

[tildearrow]

tildearrow Now you are just trolling. KDAB is not taking over anything. Qt got KDAB by the balls. KDAB insists on the current Open Governance model. This means Qt keeps CLA and ultimate power.

So no community fork with KDAB. Is it really that hard to get?

Yeah sure, I troll and troll and troll.

Can we stop talking about KDAB?

[oiaohm]

oiaohm Re-reading your answer I think I spotted the flaw in your reasoning. You wrote that “A full proper Open Governance Model does not use CLA instead just uses the License itself.” assuming that’s KDAB position.

KDAB said they wanted to use THE Qt Open Governance model. That’s the current way with CLA. So any fork backed by KDAB would be CLA.

Now what?

This is wrong because you have a critical thing wrong all the way along here.

https://wiki.qt.io/The_Qt_Governance_Model

The Qt Governance Model does not have the word Open in it. The first Nokia governance model for Qt had the word Open in it and did not mandate a CLA for contributing the word Open was removed when they put in the CLA on contributing. So I know only 1 word different but in this case it makes a big difference. Basically 144Hz you are mixing two different thing up that are critically different.

The big you missed KDAB does not have a business going forwards for 90 percent of there customer base with a 12 months delay on open source version of Qt. The ablity to upstream to main Qt is very small part of what KDAB requirements.

Basically your idea of what open government by KDAB means is wrong. KDAB wants to go back to the first governance model by Nokia,

[cipri]

Seems you don't know Wayland well either, because Wayland does not follow the server-client model. Just because there is communication between processes does not mean it is server based....

I was writing an own wayland client from scratch. When you do the same, I guess you will understand my point. I was expecting the same as you, but it was not like this. I was even contacting one of the main developers of wayland, and like this it turned out that I had to link against their specific library (or alternatively you had to copy a specific structure from the wayland server code), otherwise my client could not communicate with the default wayland server. This was a shock for me too, because I was expecting that you can write your own client and it will be able to communicate with any running server, but it was not like that. This limitation was discussed at length in other places, and I think I read that recently one *theoretically should be* able to write an independent client.
Since I wrote a client in c++ , with the idea of having a nice design, and hiding all the ugly stuff in a private implementation, I had to fight with the horrible design of this lib that i had to link against to make it work (I think it was called libwayland-client).
Being a fan-boy screaming "i love wayland" is not any help - these are the fan boys knowing wayland just from the slide sheets of presentations. When I first found the wayland documentation, I was thinking, it was just some kind of basic overview, and I was searching like crazy for the *real documentation*, till I was told that indeed there is no other, and if I wand more details I should check the source code of the reference implementations. How horrible! Like all implementations, all have bugs. How can you tell if you encountered a bug or if it is the right way? This is the future of linux desktop? Check real specifications and documentations and compare them to the one of wayland, and you will understand my point, that this wayland, is a joke, otherwise there would be a clear specification, that talks clearly about Datatypes etc.., and not just basic ideas.
It is the same with qt, there are so many fan-boys, that didn't get really to work with qt for real to notice all the horrible code that is there inside. Instead of fixing bugs they where constantly adding new features, very buggy ones, and then using the idiots (like me) as alpha testers. I was assuming that ... after alpha testing, comes beta and release and I will work fine.... which turned out to be completely wrong, the design was just horrible (qt3D), and it was absolutely too slow and too bugy, also years after.
It was easier for me to learn Vulkan, and to write my own game engine.
The open source world is so full of crap, I started to build nearly all the tools again by myself, yes, I write bugs too, but my own code, I can better understand, debug, and fix and maintain.

cipri