Qt - SDK - Battle of the base apps - Extensions

1

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?

2

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.

3

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.

4


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.”

KDE is the only official OpenSource maintainer. As such you have to get them to package what you want.

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.

5

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
6

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

7

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
8

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.

9

With CopperSpice it could be done. That is a true OpenSource project.
KDE is the only official OpenSource maintainer of Qt and per the Flathub rules, KDE has to be the one to provide Qt. You cannot. Qt is not your OpenSource project.

What you have to ask yourself though is what do you want your flatpak to weigh in as? This?

or this?

Every package put into the base package will tag along for all including those who don’t use it.

I haven’t looked at the guts of flatpak. I don’t know if they are doing a Docker layer type thing so the 80,000 pound gorilla only has to be pulled down once.

When I started with Linux we used floppy disks and dial-up modems. A complete Linux system could boot from 1.2MEG floppy. A system with a 20MEG hard drive was a big system.

Linux rather quickly bloated past the download-with-a-modem size limit. “Live” systems with most of what you needed easily fit onto a 650MEG CD. Only a few scan versions of Ubuntu later and they needed a 4.7GB DVD for the “Live” disk. Adding insult to injury it doesn’t have much of what you need.

During the days of DOS people wailed at MS Bloatware. Linux is eating fast enough at the all-you-can-eat-desert-buffet to surpass it now.

In large part I see what you want. Qt can never be included in the base because it is just a monster and comes with severe legal jeopardy if bundled.

If everything is included in the base though, where do you stop? Just installing Flatpak would be a 4.7GB footprint.

Now, if they had some kind of layering and dependence system, theoretically the first pak to list CopperSpice, wxWidgets, etc. as a pre-req or dependency would pay the download cost of retrieving the 1200 pound gorilla. As long as it could be shared by all that wouldn’t be as bad.

Here’s the dirty little secret from someone who has developer software for nearly 40 years.

The first poor sap to package something like CopperSpice and put it into the repos as some kind of Flatpak component other components could use would never have a life again. They would constantly be dealing with versions and whiny emails from people who just gotta have that version upstream released 15 minutes ago.

So, you make each Flatpak builder build in what they need. Yes, we get a lot of 800 pound gorillas begin downloaded, but, a person can have a life.

I’ve done Debian and RPM packaging in prior lives. Just kicking the tires on Flatpak.

Why don’t you look into the doc to see if Flatpak can support a Depends-on concept then see how you would have to build the dependency and park it some place in the hub where all can use?

10

I feel you’re still missing the point. Qt for example is already being packaged as an Sdk and it’s fine, however it would be more flexible to package it as an Sdk extension and then use it in the flatpak Sdk runtime and make it available separately as well. That’s not that big of a change for the maintainer.

Maybe you should study how Flatpak works a little better, because it actually does work based on either OCI (“Docker layer type thing”, which is what the Fedora repo uses) or OSTree (which uses deduplication and is what flathub uses). So your analogy is incorrect.

Anyway, I’ve pretty much given up on getting any useful response, apparently there is no room for these kind of ideas and the Flathub admins do not seem willing to discuss this or suggest a policy on the matter of SDK extensions.

11

per Flathub rules, KDE is the “owner” of the OpenSource Qt project. They get to decide what is and is not packaged for flathub.

It is true that I do not know how the internals of Flatpak work. I’m just wading into it and there really isn’t much for documentation. It has the Linux “expert friendly” issue right now. I have spent almost 40 years in software development from PDP-11, to IBM Mainframe, to other midrange, to OS/2, DOS, and Linux when it used to fit on a single 1.2 MEG floppy. I create RPMs and Debian packages. Every 18 months a new solve-all-the-problems distribution method comes out. Thank God I didn’t waste much time on Snap.

No, I think I’ve got the point.

  1. It’s always just a little bit of work when someone else has to do it. Oceans too much when one has to do it themselves.

  2. You want someone to do it for you rather than do it yourself

  3. Many of the Qt modules “missing” from the KDE SDK are missing because they aren’t really OpenSource due to the licensing shenanigans going on or they have a different non-compatible OpenSource license. This last part is pretty rampant in later Qt features. WebEngine in particular is a dog’s breakfast of conflicting licenses. The “dual license” becomes a commercial-only license if you in any way make money or so the last interpretation I was given went. If you earn even a nickle with it you have to have a commercial license.

  4. There’s no good documentation on how to create an extension that uses C/C++. One has to thieve the OpenJDK one and hack it down to what you need. I’m actually investigating this right now to do it for CopperSpice.

  5. The people creating the stuff for Flatpak aren’t getting paid to do it. Many of the KDE team are actually being paid via Qt Corporation. They do actually “maintain” webengine libraries for Debian.

debian-webengine
debian-webengine990×275 61.3 KB

  1. The individuals working on the KDE project would be the proper place to push an extension request because they have already waded through the myriad of licensing issues. Keep in mind their focus is on promoting KDE and using it for Qt experiments. It’s not on bringing Qt to the masses. You might get them to add WebEngine to the KDE base but I suspect the reason it isn’t there is a licensing issue. See link above for the bushel basket full of licenses needed by QWebEngine.

  2. No new development is actually going on with Qt. People are maintaining “Legacy” products while porting to other libraries after the combination of licensing shenanigans at the end of Qt 5 and Qt 6 being mostly dysfunctional (especially QML) for desktops.

  3. I just followed your link and poked around to find this PR created by you. @Erick555 has valid concerns on their April 15 (tax day!) message. You should really have the KDE team add what you want. As far as wxWidgets, one of the platforms people are abandoning Qt for just because it is there, I didn’t see any valid concerns/issues with the PR. I did notice that there are only 15 people listed as being members of Flathub and wxWidgets is a 12,000 pound gorilla. It would be nice to not have to include CodeBlocks to get it, but . . . one has to make a good case for having it split off. (i.e. you have 8 other pull requests that will use it.)

After reading through all of the brew-ha-ha on several of the Extension PRs not yet in I suspect the philosophy is new RunTime.

How does one find an extension? Until I saw this message I didn’t know they existed. There are a tiny list of SDK in the doc, but it took an awful lot of searching with DuckDuckGo and other engines to actually find Flatpak Extension and have it be something close to what I was looking for.

Why don’t you build a new RunTime that can be listed here? You probably cannot call it the Qt RunTime due to trademark issues.

Otherwise beg KDE to add in the libraries you want. They are the ones maintaining the code you would need to use.

12

the-point-you-24487436