If anyone breaks the law/licence its logically their right to call them out.
But the case is blurry if they dont even have a license
yes.
Documenting expectations is still useful.
Look I donât want to be interacting with upstreams in a way that is considered actively harmful, but I also donât want to be singled out for doing things that other rebuilders are allowed to do either. Being singled out like that is expressly prohibited by the OSI open source definition and the GNU four freedoms. So all I need a documented set of expectations that apply equally to me or anyone else when Iâm forking into github in my personal namespace, and when it applies to me or anyone else if Iâm a fedora packager.
2 Likes
Yes, my post addressed all three of those points. Please refer to it again.
However, Iâm still unsure what they mean with self-hosting builds, but I already addressed that above.
There is no policy to require source builds - itâs just, that the team is motivated and basically bugging all new submissions to do that. Mostly for selfish reasons, e.g. having arm devices etcâŚ
But as I stated in my earlier post, itâs just unreasonably hard to do for some languages and it wouldnât be fair to exclude apps in those languages from participating.
1 Like
Firstly, why was this comment flagged as inappropriate?
And secondly, FAQ - Fedora Discussion doesnât state anything meaningful in regards to appropriateness.
1 Like
This is the cruxâŚ
And there is a long history.
This discussion makes me think about the period of time when ooo-build patches were being used by some number of distributors (i forget which it was a long time ago) primarily because the upstream refused to take in some very useful features patches that users were asking for.
So in that bit of history the upstream was considered the vilian and the downstreams were considered the champions of user sentiment for patching things in a way that upstream didnât accept.
Anyways⌠so what resulted for a period of time were several different flavors openoffice, all using the same or similar branding elementsâŚacross the linux landscape.
Iâm not talking about that history to wax nostalgoic about the good old times when the distros reigned supreme. I actually think its a cautionary tale that is instructive both for distributors and upstreams now.
If flatpaks had been a thing thenâŚand openoffice.org was a verified thing at flathub and were refusing to take in patches⌠what would have been the recourse in the moment?
Iâm just saying it feels like there is a new cultural norm for behavior developing that is replacing a generation old cultural norm. I think documenting expectations iin a way that we can discuss the expectations more abstractly will help moving forward.
What patches are too far, what patches are not?
I doubt the new cultural norm will be that rebuilders canât include security fixes that havenât been blessed by upstream. In fact CRA compliance will sort of demand rebuilders take a much firmer hand on that specifically.
I can see flatpaks changing the game a bit with regard expectations around integration patches because the is an expectation developing that the runtime flatpak an application users defines the boundary of integration. Thatâs a significant change that we probably need to figure out a way to document more clearly. Fltpak runtimes are new distribution concepts to target. And this is probably where most of the Fedora patches end up being and the hardest discussion to have because there is a lack of perceived value in the Fedora runtime as a target.
Beyond that, getting into ooo-build like patch territory, whatâs the expectation on feature patches that have real utility for users?
See Terms of Service - Fedora Discussion for site guidance on post appropriateness.
A post can be flagged by anyone with a basic level of activity on the site. Moderators use their judgment in responding to flags.
1 Like
Thre is no roadmap.
I have been having discussions in private with as many people who will deem to talk to me that I feel are stakeholders in getting us to a better healthier more coopetition relationship.
coopetition⌠elements of both cooperation and competition.
These discussions are primarily right now about possible futures⌠what is not only achievable but what is actually valuable from different perspectives.
What is valuable from my perspective, is not valuable to other perspectives. I accept that Iâm trying to find the thing that is valuable to multiple perspectives so if and when I can use whatever actual authority this role has (if it has any at all) to bring that forward.
I also realize that this role is not a dictatorship. I think some people interact with me assuming that it is a dictatorship. But it isnât. I cannot snap my fingers have things happen just because I agree with their concerns. So even if I get to a possible future that makes sense, I canât manifest it on my own, nor can I direct people to work on anything. (Some of you are now asking yourself, why would anyone want this job..good question)
3 Likes
This is also something Iâve asked about with multiple people and I canât seem to get agreement as to whether its feasible or not. There are examples of GNOME nightly apps doing it, but there seems to be no consensus that this is a workable approach for a large collection of things. I agree with you that it feels like the right way to handle this.
I would like to try it and find out. But as its pointed out to me its work to do, and I wonât be doing that workâŚand whatâs needed is buyin from the people doing the work to try.
Here are the concerns that have come up in the discussions ive had:
- does it even work. opinions differ, Gnome nightly app examples point to an answer that yes in some cases it does.
- if we do it for the flatpaks⌠then why not the rpms? If we do it, we may need to do it as patches to the rpms and then the flatpak building mechanism just picks it up. (This is a fair point.)
- Weâd have to make additional changes to the .desktop file metadata that further differentiated to ensure users know which variant is which. because the application Id specifics are not surfaced in the UI application selector elements in any meaningful way right now.
- Taken together 2 and 3 represent packaging policy work.
This feels like something to test in copr and report back. I think its great thing for an exFPL with some theoretical free time to attempt.
Or in other words.. sounds like a matthew problem to me.
Note:
that last line is an in-joke between Matthew and myself, because up to this moment its been usually him telling me âsounds like a Jef problemâ when something FPL scoped comes up and we are both in the room. So Iâm teasing him a little with that as this is my first opportunity to turn the tables on him. I just want to clarify for anyone who was confused by that comment.
This is something we should explore, so if someone other than Matthew or I want to attempt it.. building some fedora applications rpms where the application-id is changed with a fedora namespace prefix.. and put them in a copr.. it would be reasonably valuable effort as a way to help us understand if this is broadly feasible or if it causes a number of other cascading issues because the application id changes.
2 Likes
Thank you for this.
I can start a new thread specifically for the a discussion around this if that would help bring more focus dsicussion just to the idea of attempting a fedora runtime distributed at flathub.
Right now we have one, built from rpms,.. and forms the basis of all the fedora rpm flatpaks.
We could publish it to flathub. There is nothing stopping us from doing that. But its not clear it makes a strong enough ABI promise to meet the expectations as a servicable runtime. Itâs something we need to explore figuring out how to do.
One of the things timothee had to beat into my head over the summer when he was patiently explaining some things to me was how critically important the ABI promise for the lifetime of the flathub runtime is as the core value that it provides application developers. I donât know if Fedora as constructed right now is constructed with that ABI promise at the forefront. It might be.. i donât know. We have to examine it. If application developers would use a Fedora runtime hosted at flathub.. then its worth spending some time trying to figure out if we can get there. But if the value isnt there, then its probably not worth trying to get the project aligned to produce it.
2 Likes
Hmm,
Yeah⌠so its probably not a good idea for flathub as a marketplace to flagrantly violate the spirit of EU legislation. So finding a way to do both would be advisable.
Iâm gonna be real honest, the entire ecosystem got real lucky with the open source steward carve out in the CRA legislation. Having stewards going out of our way to violate the spirit of what the CRA is trying to do is not going to be a good look for the open source ecosystem.
Now flathub in particular because its a distributor of open and closed things is in a more complicated spot than Fedora is at present. Understanding whether flathub is able to take advantage of the open source steward carve out in the CRA is something I have a compelling interest in understanding as a GNOME ADBoard member. Flathub does/did have a plan to starting taking in funding for operations as a spun out non-profit, and if they go forward with that, they may be a manufacturer under the CRA..which has even higher requirements. Iâm not thrilled about it, but weâre gonna have to figure it out and deal with it.
First.. I would say based on how the fedora flatpaks are constructed⌠they probably work as well as the rpm versions.. since the Fedora flatpaks are composed from the binary rpms. So yeah I think those 513 flatpaks probably work as well as the rpms they are composed from.
The fedora flatpaks are not recompiles of sources. they are just rpms installed in an image with a sprinkling of flatpak metadata. it would actually be weirder if they worked differently than their companion rpm versions.
That being saidâŚI do have concerns about the sustainability of the current fedora flatpak approach right now. Iâve had some good discussions just this evening in fact about some policy ideas that will help better align the maintenance burden around fedora flatpaks to make it similar to how some of the other packaging outputs are done. I think its prudent to make some policy changes based on some past lessons learned concerning some unrelated efforts. Thereâs work to be done.
3 Likes
hmm.
So Iâm assuming this wasnât patched because this was an EOLâd runtime issue. Iâm further assuming that If the runtime being used was still getting updates, it would have gotten the CVE patch as part of normal runtime patching policy.
The fact that a CVE patch is involved is definitely something we need to find a way to talk about.. more abstractlyâŚwithout referring to a specific application. Because its not an application developer issue and its not a runtime developer issue either, its a flathub policy issue around allowing EOLâd runtimes to be build targets for new buildsâŚwhich results in situations where CVEs arenât being addressed. Thatâs a problem that needs to get solved.
Why?
One of my overall concerns about the CRA right now is because it treats open source stewards so differently from manufacturers in terms of security vulnerability requirements.. its going to put immense pressure on manufacturers to frontrun open source projects or even open source stewards with regard to how CVEs are handled. Itâs also going to incentivize manufacturers to bombard open source projects with bug reports in an effort to get free upstream labor to fix CVEs so the manufactures can avoid violating the law. Its gonna get weird. Money will be spent on this because there is a new type of legal liability imposed by this law, and its going to get weird. The broadly âno warrantyâ environment that weâve been living under is going away.. and thatâs going to have impacts in the dynamics in the ecosystem concerning CVE handling. Seriously this is potentially a sea change of significant in the dynamics here.
âstewardsâ and âmanufacturesâ are terms loosely defined in the CRA..the distinction is grey unfortunately. if you are still reading this and this all sounds like word salad and is confusing you, youâre not alone, its confusingâŚand the lack of clarity is going to cause some friction over the next couple of years.
The CRA has already impacted Qtâs business model concerning the commercial support offeringâŚthe extended the commercial support timeline recently and their PR on that, at least to my reading, claims its an adjustment to better align with CRA requirements for manufacturers. But no corresponding adjustment for their community support lifetimes that I can find. Thatâs is problematic, because if Qtâs business model ends up depending heavily on the CRA, they are incentived to squeeze harder and shorten the community lifetime even more. Iâm not saying theyâll do that.. Iâm saying the legal teeth in the CRA give them new incentives to exploit in that business model.
Hey,
So this is probably the most difficult post in the thread to try to reply to because its relitigating history that I wasnât around for and it speaks to problems that are non-technical or even really policy in nature. I canât authentically offer you much in the way of meaningful atonement or absolution that is going to make you feel better at this point. And I need to be more cautious here with how I respond because youâve shown some vulnerability in your disappointing in your attempts to be an active contributor to the project⌠and that vulnerability needs to be respected.
First let me just make a speculation, if I had been an active Fedora contributor during that period, even as an external community member, I would have probably engaged with you because I too find the flatpak technology really interesting. Iâve read your linked blog, and while I donât think its fruitful for me to engage in constructive criticism of your historic thoughts in this moment, just know Iâve read them and youâve been heard. Unfortunately I wasnât here and we didnât connect at a time when I could have hopefully positively impacted your enthusiasm. I canât apologize for that, because life happens and I was doing my own different things for a while.
Your contributor journey wasnât my journey, and my journey ended last time with me needing to step away because I literally couldnât contribute any longer due to life. And when I stepped away I made it a point to step fully away and to not get embroiled in the politics of the project that for several years was very important to me. It was tough to do, but it was the right decision, because it let me let go and care about the things in my life I did have time for without feeling regret or frustration about where the project was going without my involvement. I donât know if that helps you to know that or not. But it was the right decision for me. But Iâm back now and the years away give me a very different perspective than the perspective of the people who stayed through the years.
What I can say that I as a previous contributor from the earlier days, I can sympathize with your frustration with your experience. It wasnât my journey, but I can sympathize. Iâm not sure I have policy ideas yet that would speak to your specific frustrations that would help the next community member who ends up feeling this way when they are trying to get involved and feel unseen.
But if I were going to try to say something, do something, it would have to come in the shape of re-envisioning what SIGs are and what the do and how we expect them to operate and give them a mission in cultivating their own membership and hold them to account in some way ensuring that are growing contributors in a sustainable manner. This is an area I think multiple people are trying to wrap their heads around.
If you would grant me some license to re-interpret what youâve tried to express here in my own evolving thoughts about SIG healthâŚI think part of the problem here is there was a mismatch in expectations around the ceremony of being or becoming a SIG member and what the means in terms of having a voice. It seems to me like you felt you needed to be invited to join as recognition, whereas in my now ancient experience, SIGs really didnât work that way at the start.. you just added yourself. The SIGS that I remember started as working groups of self-interested people and then maybe, eventually they figured out a governance model at some point..maybe..if they needed it.
Like I said I donât have much in the way of solutions to the problems. As you said the majority Fedora contribution seems to be working reasonably well. But when SIGs are unhealthy its frustrating. Itâs something Iâve already identify that needs work.
5 Likes
Thanks, Jef, I would actually prefer to discuss this in the abstract. 
While we have examples of applications using EOL runtimes, the use of EOL runtimes is not the core problem. The problem is that the upstream maintenance windows of components often do not cover the maintenance windows of downstream distributions (I am using this word in its literal sense: Flathub distributes software. It is a distribution.)
When a componentâs maintenance window is shorter than a downstream distributionâs maintenance window, one of three things must happen:
-
The distribution ships unmaintained code, and potentially puts user security at risk.
-
The distribution engages in software maintenance / development and effectively forks the release they ship. (Or, the distribution works with the upstream developers to extend their maintenance window to match the distributionâs.)
-
The distribution rolls to a new release series.
I have some illustrations to that effect here (but the document overall isnât as coherent as I want it to be, so donât spend time on the rest): Defining âDistributionâ
I use KDEâs runtime as an example mostly because it has fewer components, which makes it easier to illustrate this issue. QT Community Edition minor release series are supported for about 6 months. KDE minor release series are supported for about 4 months.
It is really very common for upstream components to have maintenance windows shorter than the maintenance window of a downstream distribution release (e.g. a release of Fedora, or a Flatpak runtime). If a distribution promises a maintenance window that is significantly longer than that of its components, and if the distribution does not allow minor-version updates within that maintenance window (and not actively maintaining a fork of those components), then the distribution will be shipping EOL and risky components.
In non-abstract terms, that means that an application could have been using a KDE runtime that was not EOL, but which included a QT release that had security flaws that werenât being addressed. And in that case, the statement that the application was only working because security patches werenât being applied remains true.
So, there is a problem that applications are allowed to continue using EOL runtimes, but thereâs also a problem that runtimes are allowed to continue using EOL components. Producing a secure distribution is going to be a harder problem than merely requiring app maintainers to use a supported runtime. I agree with you about the potential impacts of the CRA: We have to find a way to align the maintenance windows of components and the distributions that use them.
⌠which is why I keep suggesting a semantic branching strategy in project VCS, and creating the space (in upstream projects) for users to continue the maintenance of minor release series, if they want to build distributions with releases longer than the upstream maintainers want to work on a minor release series:
Speaking here as the lead project manager of https://eu-os.eu as a downstream project of Fedora Atomic: When governments insource their IT to reach higher sovereignty, they have to deal with complex infrastructure in-house. There is some experience/expertise when it comes to online services/cloud native environments. When those teams take over responsibility over the desktop following the Fedora Atomic/bootc approach, they may want to use Flatpak to manage provisioning/updates of applications such as Firefox/OBS on a more granular level than the OS.
In such corporate contexts, the applications are subject to many policies on security and privacy (taken from https://eu-os.eu/spec#non-functional-requirements):
- General Data Protection Regulation (GDPR) or for entities of the EU administration, the European Union Data Protection Regulation (EUDPR)
- Network and Information Security Directive 2 (NIS2)
- EU Cyber Resilience Act
- ISO 27001 and its national variants
- National Sovereignty Schemes
SecNumCloud (if applicable?)
- SLSA Level 3 for hardened supply chain.
- EAL 4 or higher
I acknowledge that for the many non-corporate laptop users in the Fedora community, this may not a prior concern. For organisations building on top of Fedora (Redhat, CentOS, Rocky, Alma, secureblue), Flathub is just another independent supply chain that must be managed on top of the Fedora rpm one. I am not an expert with Flathub, but my take-away from this thread is that Flathub has little experience with corporate requirements and so far no B2B offering.
So my conclusion is that Fedora Flatpak is simplifying compliance and security drastically by relying on RPMs that will need to be managed anyway.
I use Fedora flatpaks already in my personal capacity and file bugs as I encounter them. We fixed just this week an issue with Kmail. 
For the future, I hope that Fedora and its flatpak SIG can be the place where aforementioned organisations and the beneficiaries (think of intl. neutral organisations like CERN, International Court of Crime, but also sovereign governments) can collaborate to make 2026 the year of Linux on the desktop! 
2 Likes
Hmm.
What if Fedora flatpaks was organized more like EPEL. Would that make sense from your perspective as an institutional downstream? Iâm trying to figure out how we refactor how the work gets done to make a space exactly for these interests. We need to figure out how to repartition the work in a way that gets people interested in contributing.
I want to be clear, even if we get to a better footing with the general purpose user and we can get the illfated changeproposal reproposed again for F44 (I had a good conversation last week with a FESCO member about that in fact) thereâs nothing seriously in play about shutting the fedora flatpaks down. We need to restructure it, and find a way to make peace with the squishy and evolving trademark norms as they intsect with understood copyright norms.
As an institutional downstream user are comfortable having to make a tunable edit that disables the proposed filtering and lets you enable fedora flatpaks by default for your derived OS? Because that feels like a reasonable future to me.
1 Like
I do not know enough to understand the differences/implications. Is EPEL subject to different policies than Fedora? I understand EPEL is opt-in. Of course, this would not be an issue as organisations can opt in.
It would be a matter of policy changes that re-organize how the flatpaks are maintained to help make sure there are more people invovled and reduces risk concerning maintainer burnout or lottery factor considerations.
Hey,
One more thing.
Can you take a look at this PR
And see if this looks reasonable from your perspective as a downstream that wants to continue to make use of fedora flatpaks?
If the intent is to give downstream more flexibility, which I agree with, I want to make sure it works for both the downstream that want and do not want to use the fedora flatpaks.
-jef