Qt - SDK - Battle of the base apps - Extensions

Hi,

So I’ve noticed there is some controversy going on regarding SDK extensions or it would seem so anyway. I recently opened a PR to add SDK extensions for the Qt framework, personally I think it would be very useful to have Qt available in SDK extensions, however the common consensus so far seems to indicate that the flatpak/flathub community seems to disagree and prefers the KDE SDK in combination with Base apps.

I’ve also noticed that the SDK and Base apps unfortunately in certain cases do not suffice. I guess that methodology is not the most flexible and comes with a set of challenges, for example when a package needs Qt WebEngine (for which a Base app exists) but also needs the python bindings (for which another Base app exists).
Another example is when a package requires other Qt modules that are for whatever reason not available in the KDE SDK, in this case the flatpak docs state that it would be better to bundle the modules with the package manually instead of using the KDE SDK (Qt — Flatpak documentation). However that will produce long build times and just adding the modules in the app package and still using the SDK makes it harder to keep the exact versions of the modules in sync (when you want to use the external data checker in your app package there is no guarantee that the SDK is already updated and uses the same minor/micro version).

So if we want to save (build) time and not build the same things over and over again (and maintain building those parts as well) for different apps we can use a Base app if we’re lucky enough to be in such a situation where we just require one, otherwise it doesn’t work for some part of it (in the case where we require multiple dependencies like that).

To me it seems very similar to a polymorphism paradigm that we come across in Object Oriented Programming, especially in languages that do not support multiple-inheritance. As that is exactly what we’re facing here. We can only inherit from 1 source.
Now in software development we often solve this issue by using the composition over inheritance principle, which works quite nicely there, however in the case of flatpak we end up with losing out on disk space as we’d be copying things out of SDK extensions into our packages (although if we build/include it as modules it would be similar). It does provide much more flexibility that way though. As even the Base Apps and SDK’s could be composed using SDK extensions.
It’s also common practice when building containers with Docker for example using COPY --from=...

It would be great if there was some nice way to inherit (parts of) SDK extensions, but it seems we can only inherit the extension points and not so much the actual content of an extension or define a dependency on an SDK extension (for an app package, to have it available in a runtime), so we can only copy things from it at this point in time.

I would like to propose for flathub to provide some sort of policy or guidelines when it comes to this, as what is currently happening seems messy and doesn’t always provide an adequate solution.

What are your thoughts on this?

Nobody wants to register with Qtc to pull down the “OpenSource” version which really isn’t OpenSource anymore. The sales team will continually badger you to buy a license once you do.

There are no Ubuntu/Debian Qt maintainers anymore. Distros use what KDE has or they simply don’t include Qt and Qt based apps.

Many of us with many years of Qt have moved on to other libraries. In particular many/most desktop applications are migrating to CopperSpice.

I’ve even ported Scintilla to CopperSpice. I call it CsScintilla.

Currently redeveloping RedDiamond to use CsScintilla instead of the QPlainTextEdit widget the original port from Diamond used.

There are huge political and licensing issues with including Qt. The definition of who needs a commercial license seems to change by the hour. It appears that Qtc is not on sound financial footing given the licensing hi-jinks that went on over the past year. The Debian/Ubuntu maintainers stepped away at the time all of the licensing issues cropped up. The “official” reason was lack of time. The reality is they didn’t want to be the registered user drug into court for payment.

Qt isn’t an OpenSource project. The community does not determine the contents, Qtc does. The community is barred from maintaining an LTS version at their own expense. Qtc wants the community to work for free donating code then to turn around a buy many licenses. You can’t even get a perpetual license anymore.

CopperSpice on the other hand, is 100% OpenSource. It’s a fork of Qt 4.8 with all that nasty QML stuff removed. Long ago it moved to CMake. They’ve already made many of the container and other changes Qt community claims to want to make.

They do not currently have an ARM release, but they do have Linux, Windows, and non-ARM MAC.

A great many packages/companies are making the jump to CopperSpice.

Oh, I may have misspoke. According to the timeline they added M1 Arm support January 2022.

https://www.copperspice.com/docs/cs_overview/timeline.html

The bottom line is the legal liability. With Qtc changing the definition of who needs a commercial license on a whim, the only safe harbor is to let KDE be the legal shield.

Thanks for responding. Currently packages can and are distributing Qt modules besides the KDE fork anyway, so I’m not sure that the Legal shield is working. Also the question really isn’t about licensing, but about the preference of a SDK runtime build on it’s own, over having a SDK extension that can be used to create the SDK runtime, but can also be used separately and thus providing more flexibility (using KDE or not).

In response to some of your other comments:

You don’t need to register to get the Qt source code if that’s what you mean. It’s available on their publicly accessible git server or through github.

That’s great, but this question isn’t about CopperSpice.

I’ve heard rumors about the licensing, but from what I can tell it’s pretty much up to the app developer to figure that out and use it or not. Anyway the question is really not about that.

There is a big difference between a community ran project and an Open Source project. Given there is a company behind it, they need to have some sort of business model and make money to keep the business running. I’m not here to debate their choices in how they do that.


Thanks for responding. Currently packages can and are distributing Qt modules besides the KDE fork anyway, so I’m not sure that the Legal shield is working. Also the question really isn’t about licensing, but about the preference of a SDK runtime build on it’s own, over having a SDK extension that can be used to create the SDK runtime, but can also be used separately and thus providing more flexibility (using KDE or not).

Like it or not, with Qt it is ALWAYS about the licensing and the whack-a-mole definitions of what does not qualify as “OpenSource use.”

The shield is working perfectly right now. Flathub is simply providing a medium. KDE combined with the fake OpenSource project for Qt is providing what, at the point in time when they released it was deemed the OpenSource version. If a developer chooses to bundle Qt in their App Flathub is once again immune.

The instant the Flathub organization puts a Qt package up here all shielding is gone. They can be held responsible for all non-qualifying uses.

This is no longer true. It was completely true back in the day before Qt got into obvious financial trouble given the licensing roulette. On the Qt-Interest mailing list there were vicious howls about how all of the latest Qt 5.x releases that became part of the commercial LTS were pulled. Many of the older versions are pulled now. They are deliberately making it harder and harder to download anything other than the worthless Qt 6 releases without registering.

The question is really about that, you just don’t want it to be. The financial liability and exposure Flathub will have by putting its own Qt packages together cannot be overstated. I had a client that chose not to fight the legal battle like all my other medical device clients had. They paid north of $600,000 U.S. for five developer seats as a result.

Because of these legal and financial issues you will find many Linux distros have dropped KDE and removed all pieces of it from their repos. A growing number aren’t including Qt or anything that uses it in their “default” install.

I get it.

You “just wanna use it” and you want Flathub to make it easy.

Qtc made certain you couldn’t do that without Flathub placing itself at immense financial risk.

I realize you don’t want this to be about the licensing, but when Qtc is involved it is always about the licensing. That’s why CopperSpice exists. They forked Qt 4.8, the last true OpenSource version of Qt.

Sorry, but I don’t think it has anything to do with the problem 4c0n has raised. I would rather you to take this discussion elsewhere.

1 Like

It does, but that won’t change your belief. Go ahead, put Flathub at legal peril.

Qt is just an example I used in this case. The same discussion applies to the GNOME SDK or any other SDK should they become/be available.

The point is that by using an SDK extension as the root it would be possible to compose a SDK, base app or just bundling required parts with an app package, allowing for the building of those dependencies to be done only once instead of separately for each one of those components and as such providing more flexibility/re-usability/efficiency.

In short: Why not provide SDK extensions to allow composition in addition to inheritance?

1 Like

In the meantime several PR’s for SDK extensions are just sitting in limbo. No single admin response.
https://github.com/flathub/flathub/pull/3077 being one of them.

Having these kind of things available as extensions could prove very useful, but if no one is willing to even have a serious discussion about it… It’s a little disappointing when you invest your time and energy into something and it is just ignored. It is also very much possible to close the PR by denying it, or at least expressing that a policy is yet to be determined.