acknowledged…
i hate it when perfectly good turns of phrase get tainted though..
In the future, if you ask me to stop using a phrase.. I expect you to suggest an alternative that has less baggage.
2 Likes
an open environment maybe? Means the same but wasn’t used as an excuse to fund nazis
It’s actually the perfect analogy for the situation.
Jef if we want to talk about fixing relationships, can we get the systemd service that forces the Fedora Flatpak repo on users without asking permission in the base flatpak package removed and put into its own package?
It won’t fix any of the actual problems, but at least it looks better and makes it easier for downstream to relieve itself of this mistake for as long as Fedora chooses to make it’s users subject to it in it’s big tent.
5 Likes
Sorry for saying this personally, but I disagree with you on many things, however, I still respect you. And I take offence to you saying that I created this thread for the purpose of igniting a shit storm. I know it’s hard to believe, but I actively try to stop myself from even mentioning my views on Fedora flatpaks, to not make further shit storms. This time, however, the temperature of my blood reached too high of a level to ignore this. Yakov, who is the sole maintainer of Fedora flatpaks first throws shit at the entirety of the Flathub project, insulting it in many different ways, even saying THAT IT HAS NO REAL COMMUNITY, and then cowardly uses hard work of Flathub contributors to use for Fedora flatpaks, openly hostile alternative, without even mentioning it. This is impossible to ignore and this is spit in the face of many, including mine. This is disrespectful and I refuse to not talk about it.
2 Likes
Let me be very clear..
There are torches all around me.
Sometimes I feel like I’m the only person trying to build the bridge.
So don’t read this as me saying you are personally responsible for the temperature. If I thought that, I’d be very frank about it.
I’m not currently aware of particular statements you referring to. However, I am very concerned about the language you are using right now to describe you feelings about statements I’m not personally aware of. I will say there’s a lot of emotion around this topic and that doesn’t lead to clarity around the technical or policy issues that need to be addressed. Which is just more signal that I made the right choice to work on the compliance issues I found quietly to avoid inflaming things further with public criticism that would be used as fuel by some and considered hostile by others.
And to be clear I am very concerned that the flatpak effort in fedora right now was meant to be a SIG… a group.. and its now one person.. maybe two. That’s a problem that I need to address for everything that is suppose to be a SIG. That’s going to take time for me to address. The irony of this is that I’ve been told that flatpak infra is also basically 2 people at present, which if I’m remembering correctly, was part of the reason for the slow response to the compliance issues I found, we all live in glass houses it seems. I’m doing my best to not throw stones.
I did say right after I took the 3D printed scepter while wearing the hotdog costume at Flock… that there would be hard conversations coming. It was my hope that was going to be the most controversial thing said on camera that day… but sadly it was not. SIG health is part of that hard conversations I need to heave…but its larger than just the one SIG. I’m not coming at that discussion as pretext to solve this one problem, I have legit concerns about SIG health broadly.
Anyway…
let’s at least try to get to some agreement on what the reality is at present that my role as FPL as some scope over:
- Fedora flatpaks will have to exist to meet liability concerns for anything preinstalled
- Fedora flatpaks will have to exist for architecture gaps in flathub coverage
- The atomic desktop fedora contributors want more control over when fedora/flathub flatpaks are used when 1. and 2. are not latching items. This is an existing ongoing frustration.
- There are concerns about fedora application quality that afiact are more often than not bugs in the rpm packages and not usually flatpak specific issues. Everything I’ve looked at personally has tracked back to an rpm package issue at least. It’s just that the flatpaks seems to be revealing the bugs in ways that the rpm usage isn’t.
- I have concerns about flatpak SIG working as intended.
So that’s the fedora side of the bridge.
The flathub side of the bridge that I probably have the most influence over as GNOME Adboard member include trying to get flathub policy adjusted in a way that help address some specific things that would make relying on flathub as a trusted partner more palatable, but that’s a discussion I’m going to have to have with FESCo. And its probably the first sync I’m going to have with FESCo after the upcoming election. This is one of those discussions I was planning on having after I got back from GUADEC, but because I was sort of under a gentlemen’s embargo about the compliance issues I didn’t want to be put in a situation where I was having the conversation and holding information back until flathub addressed the issues and I was freed from my agreement to give them time. And now were so close to election I’d rather just wait so I can have a fresh start on this topic and figure out what the specific policy adjustments are that brings us into a better relationship. Hopefully one good thing that has come out of having to wait is that I have a modicum of credibility that I’m trying to build a bridge and my criticism when it comes has a constructive purpose and will be done in a way that is intended to get us to a better future.
7 Likes
so
-
I’ve no power of whethe that PR gets submitted, but it seems a reasonable adjustment to me without a lot of risk and if CentOS is already doing it meh.
-
I take issue with your characterization that this is a mistake.
I made efforts to notify impacted downstream who uses flathub runtimes preinstalled about the license compliance issues I found as part of my due diligence.
I have deep concerns about a linux distributor culture that just shrugged of the GPL license compliance concerns and were willing to wait 3 months for your critical upstream to fix their compliance issues. I think that’s a very big mistake. A mistake Fedora can’t afford to make.. because its legal liability and not user sentiment.
5 Likes
Can you link and quote where he said that, if it was written online?
If you and I are thinking about the same statement, I really think he meant something very different.
We might resolve some level of conflict by asking him to clarify his intent.
2 Likes
Hey Jef, I really appreciate the thoughtful response over the situation. While I’m not a part of Flathub, I’m also grateful that you were considerate when raising concerns to them.
I would like to point out that hostility can take in various forms, and can be performed by a small set of individuals within a large group. I sincerely believe that you and the majority of people in the Fedora community are amiable and want the best for everyone — emphasis on “majority”. This is unfortunately not the case for everybody, especially not in my experience with the Fedora Flatpaks developer(s?)
I will take this as an opportunity to share my involvement with Fedora Flatpaks in the past, especially as a former supporter of it.
4 years ago, I discovered Fedora Flatpaks, and developed a strong interest with the tech and approach behind it. After having a thorough understanding of it, I wrote two detailed articles about Fedora Flatpaks:
- An introduction to Fedora Flatpaks - Fedora Magazine (2021/12/22)
- Comparison of Fedora Flatpaks and Flathub remotes - Fedora Magazine (2022/02/09)
Mind you, I also designed the banners (just highlighting how much I cared about promoting it back then).
I also asked to open a Matrix room (2022/01/01), which was rejected:
As time went by, I started losing interest, because there wasn’t much progress with the project, and it was duplicating effort that could have otherwise heavily benefited Flathub and every party involved (GNOME, KDE, elementary, freedesktop.org, Endless Foundation, etc.), which would have benefited Fedora, too.
This realization led me to write “Where Fedora Linux Could Improve § Only Ship Unfiltered Flathub by Default”, which criticized the lack of progress with it, as well as addressing one of the “legal concerns” (2022/12/06):
(Side note: I’ve also heard from Flathub folks that they received legal advice in regards to these issues.)
This led to some community members to react and start the Flatpak SIG project, to accelerate development — 2 days after my blog post (2022/12/08):
Then, a Matrix room was (finally) created and publicly available (2022/12/10):
By the way, I was never reached out or invited to join the SIG, despite putting in so much effort and time to accelerate development.
However, despite that, I still tried to participate in the project, and added myself to the SIG as well:
Any of my suggestions then were either rejected with no proper explanation, shrugged off, or sent to /dev/null. And whenever I asked for source for obvious misinformation, it would be dismissed.
I tried to push Fedora Flatpaks in a direction that would have been less controversial and more productive by limiting its scope, which would also enable us to allocate more resources on other stuff. However, once again, I wasn’t really taken seriously; at least I personally don’t feel like so.
Eventually, I lost every last bit of interest and removed myself from the SIG (2023/02/20):
All this to say, I tried really hard to keep my opinions to myself, and communicate diplomatically with them; I even wrote articles after doing several hours of researches in the span of weeks to show my interest, but I was treated extremely unfairly in return. So this naturally led me to one conclusion which I still hold today: they’re not looking for diplomacy; they just want to do whatever they want, even if it ends up upsetting/hurting people and projects’ image — I have the same sentiment with RPM packagers, too.
Once again, I really appreciate your amicable approach to raise legal concerns to Flathub, and I also want to publicly express my gratitude for raising legal concerns for Bottles too. Allow me to clarify that when I refer to “Fedora Flatpaks”, I don’t mean to rope you into it personally.
Fedora’s infrastructure is massive: “donating” these resources to Flathub would have opened up so many possibilities, especially with increasing the number of available runners that we can use to build our apps. Flathub would have probably benefited from the legal team as well. And all this would have in turn benefited Fedora and thousands of projects.
8 Likes
Having been involved in this process as someone having to deal with your concern: This is a distortion of the truth. Flathub is a volunteer organization. People busted their ass over this. And instead of a positive, ya’ll have once again turned it into a footgun.
- Some licensing files were missing in runtimes
- Flathub addressed the issue by fixing the problem with a January timeframe to finish the job.
- After rebuilding the entire thing then they had to go back and check it again.
What’s the problem? People run into license compliance issues ALL THE TIME all over open source. Those are identified, corrected, and fixed. The volunteers who did this work deserve the praise. You should be taking credit for helping out.
You’re making it sound like a Free Software developer was wronged. This is dumb paperwork that means flathub needed better licensing tooling. They fixed it. Situation over.
Really disappointing responses here all around. This very issue has brought nothing but negativity towards a bunch of other open source projects:
I’m trying to build a bridge so we can be in a more coopetition relationship than we have now… it sure would help if everyone else holding the torches would take a break from setting fire to the supports.so I could spend more time building instead of putting out fires.
This really reads more like “Project with known documented problems working within the rest of the community wishes everyone would get along. It’s the only way to work together to implement Fedora’s policies in your projects.” You’re not the center of the universe and Fedora’s insistence of enforcing application policy on other projects is just not going to work. Or at a minimum stop sucking the oxygen out of the room for the rest of Fedora? Seriously you can’t even help Timothee Ravier, who has nearly single handedly proven that users LOVE THIS STUFF when it is implemented according to his vision.
The man is asking for a simple policy that doesn’t even affect any of the people voting against it. Something users want that costs you nothing to let him do. So that he can help rescue a product that has been flailing for years, on his own time as well.
Seriously Jef. GPL paperwork is what you’re pissed at the most? See you at the next “rah rah bootc” thread!
12 Likes
At no point was a january timeframe communicate to me. I checked back in pretty regularly with Rob because I was specifically asked and agreed to keeping it under wraps for the duration. So whomever told you it would take till january, didn’t communicate that to me. And I just checked with Rob and he’s not aware that a January timeframe was communicated.
I certainly wouldn’t have agreed to be embargod from speaking publicly about it for 6 months.
That’s a ridiculous ask of me.
So that’sfun right… different comms depending on whose talking to whom… super fun…all back channel.
One of the things I’m going to suggest with my Gnome ADBoard hat on is some sort of downstream comms list specifically for this sort of thing. I can now make that suggestion because I’m no longer embargod from talking about why its needed.
Fun fact in the same month I found that problem, I found another possible compliance problem with bottles.. and like within 3 or 4 days..they addressed it without much fuss and I was able to confirm the downloadable runtimes included the missing files mere days later. Wasn’t even a thing worth mentioning it was fixed so fast. So while I’m sure people worked hard to address the compliance problems, the time it took to address it is concerning.
It’s weird that you cast it as both a small thing.. but also something that people busted their ass to fix and gave themselves 6 months to address. Which is it… a small thing.. a big thing.
I think it was big thing. I think the time scale needed to address it supports that.
Again you and I assess the relative risks differently. I stand by my concerns that it is a mistake for a downstream to rely on an upstream as a liability shield for license compliance and be in a position where you are asked to wait 6 or even 3 months to clean up compliance issues that could be fixed downstream with a patch. As I said I need an out that lets me address the compliance issues at the speed that matches my risk assessment.
3 Likes
While this is definitely speculation on my part:
I don’t think that Fedora could have donated those resources to Flathub unless Flathub had committed to the same kind of legal guidelines that constrain Fedora.
If Fedora (or Red Hat) were hosting infrastructure that built and distributed software that implemented patent-encumbered processes, they could be liable, even if those resources had the Flathub name on them.
Likewise, Flathub allows pre-built binaries as inputs to a build process (even if their policy document says they do not), and that makes license compliance very difficult.
I understand that it is frustrating, especially when basically everyone not a distribution (e.g. GitHub, GitLab, NPM, PyPI, RubyGems…) are very lax about compliance issues, but one of the things that I think is actually valuable about Fedora is that it demonstrates how software development and distribution are supposed to work.
We (software developers) choose licenses that lay out the conditions for the use of our work, and when those publishers don’t provide any tooling to ensure compliance, they contribute to license infringement. I think that’s bad. I’ve worked with commercial software developers, and having done that I’ve seen that many developers have no idea how to comply with licenses. And one of the reasons for that is that all of the modern software publishing platforms completely disregard it.
I’ve heard a lot of people express frustration with Fedora’s policies directed at rpm (sometimes phrased as “though shalt rpm”), but I think rpm isn’t really the thing people find frustrating. Instead, the frustrating thing is that everything must be built from source, and that often means duplication of effort, because the release processes encoded in heterogeneous CI pipelines have to be written again in a set of homogeneous CI pipelines (which are RPM specs). And so one of the things that I think people like about Flathub is that it’s .. permissive of pre-built binaries. Developers can use build artifacts from various systems as input to a Flathub build, and they don’t have to re-write it to build stuff from source.
And if that’s true, then donating resources to Flathub would probably have been conditional on requiring builds entirely from source, to ensure license compliance, and even if that were the only condition, I honestly think that would have severely limited Flathub’s adoption.
5 Likes
I distinctly recall it taking 3 months (and a legal threat) from request to actual implementation for Fedora to stop dragging OBS’s name through the mud with a broken-by-choice and broken-by-design version of their package that took preference over their official repo even when manually added by the end user. Similarly, that is far outside of what my risk assessment allows of an upstream.
Jorge is still on cooldown but he said he had no inside information on Flathub. I checked and sure enough their own announcement of this had that timeline, publicly:
End-of-life runtime transition: To focus our resources on maintaining high-quality, up-to-date runtimes, we’ll be completing the removal of several end-of-life runtimes in January 2026.
6 Likes
I’ve had discussions this week about possible futures… like I have had nearly every week since guadec…
And my current understanding is we have to be very very careful with how mutual aid resourcing is done exactly because of the the need to ensure that all the things that make flathub more attractive to users can continue to be done and we don’t inadvertently create a situation where flathub can’t do the very things users prefer it for because of how infrastructure is obtained or controlled.
So yes its a concern.
1 Like
Remind me, does OBS have a published trademark policy?
I’m definitely aware of its published copyright license.. but I’m not aware of a published trademark policy. Can you point me to it, I’m having trouble finding it at the moment. I want to make sure I respond in an informed manner. I’m pretty confident we arent violating the copyright license, which is easily found in the github repo.. with build instructions…but until I see a documented trademark policy to refer to I don’t want to mispeak about whether there was a mistake made there that I need to review.
In the meantime, I think I can safely say It’s always unfortunate when the rights to modify and redistribute software come into contact with either trademark or patent rights. There is always inherent conflict there. It’s always good to have documented policies when individuals attempt to use the rights granted in the copyright license and run up against restrictions associated with the other IP rights like trademark.
Having a documented trademark policy well communicated helps prevent unpleasantness later on when people attempt to use the rights permitted by the copyright license.
But what really helps, is having a default set of build instructions that produce binaries devoid of the trademarked materials…to make it very clear to any rebuilder for any purpose that the trademarks are for official builds only. Constructing the default build rules in such a way that merely forking and building doesn’t result in a binary that causes trademark problems is a great great way to make the intention clear that you plan to hold the logos in reserve for official builds.
Fedora introduced the generic-logos back in 2007 as our approach to help ensure respins could make use of fedora packages, both srpms and binary rpms. without having to do all the work necessary to rip out the fedora-logos deps to meet our trademark guidance. I think generic-logos still works for that purpose to this day. Dang it I just looked up the change proposal for that… and it had Seth’s name on it.. now I’m sad. I miss Seth.
1 Like
I’m confused why this continues to come up in the context of Flatpak conversations, when it wasn’t a Flatpak problem.
The bug that affected the OBS build was a regression in QT. According to the bug reports I’ve read it also affected the RPM package, and for that matter, it also affected macOS and Windows builds of OBS with QT 6.8.
So the problem there, which really seems like the most frequently cited “Flatpak” problem, is that QT Community Edition is a rolling minor release, upstream. Because it is a rolling release AND because it’s a security-sensitive component, protecting user security requires it to roll in Fedora as well, and that is the thing that caused the OBS Studio issue.
Now, Fedora might have some wiggle room. Fedora could potentially defer updating QT within a release (that is, continue to ship 6.7 after 6.8 ships upstream) until a CVE is published (but that does fairly significantly increase the maintenance overhead of the package.) And if Fedora did defer updates in that fashion, it would also allow Fedora to build Flatpak runtimes with different QT releases (e.g. a f41 runtime with QT 6.7, and a f42 runtime with QT 6.8). And if Fedora had runtimes with different QT releases, that would actually give Fedora a way to ship a working build of programs like OBS Studio to users regardless of what release they were running. (A flatpak of OBS Studio on a f41 runtime with QT 6.7 could be used by users on either Fedora 41 or Fedora 42.) Or maybe it wouldn’t. Maybe the hypothetical 6.8 release would include a fix for a security flaw, and Fedora would have to update QT on both releases immediately, and the application would simply be broken until the QT maintainers fixed the regression. That’s kinda the deal with rolling release components.
I know that this problem is mostly ignored in Flathub, but I don’t think ignoring security issues is a good solution. I think a much better solution would be nightly builds of applications (especially ones that target rolling release components), and that’s something I’d like to do in Fedora, using Flatpaks.
From my point of view, Flatpaks are the solution to the problem that we saw with the OBS Studio application, not the cause.
2 Likes
I agree with you, which is why it’s so mindblowing that Fedora’s Flatpak repo was the only one with the problem, and for months on end.
OBS’s officially supported repository is Flathub, clearly Flatpak is not the problem.
2 Likes
It was a fedora flatpak problem.
All your ‘rolling’ suggestions is the exact issue we have with fedora flatpaks. Breaking apps for your own goals, against upstream’s wishes, leaving them to deal with a huge influx of issues caused by your actions and then refusing to stop unless legally threatened. It’s difficult to build bridges when one side is quite aggressive and dismissive.
It’s even more difficult to build bridges when, even in this very thread, we have to deal with exact same exhausting conversations and misinformation over and over again.
I’m sure the legal issues surrounding flathub are very important to fedora, but there are many options between “shipping (broken) fedora flatpaks for official flathub apps” and “shipping flathub” that have already been discussed to death.
Again, this whole “bridge building” conversation has quickly become “allow us to do as we please with no pushback”. OBS asked nicely, Bottles asked nicely but they were met with “we are legally allowed to do this, we don’t care about your wishes”. Unfortunately, most of us don’t have the money and time needed to trademark every single thing we make to stop this.
6 Likes
People don’t have the time to publish a trademark policy or make sure the build system defaults to builds that don’t include trademarked logos? Hmm.. interesting.
It helps set expectations to have a written policy.
it helps set expectations that the default build rules create binaries with generic trademarks..if the intent for upstream is to have official builds using the marks while still letting others make use of the codebase under the copyright license.
If the output of the default rules in github which encourages forking and building into namespaced repositories to distinguish unblessed variants from official variants results in binaries indistinguishable from the official builds in the official repo… that sets an expectation that unblessed variants are free to use the marks. And it actually makes it much tougher to successfully enforce if you have have to, because the uncontrolled use via the forking may have have impacted your ability to enforce. How many github repo forks of bottle right now? 300+. If I forked and built into my personal github namespace and published a release does the build I would produce end up making use of the marks your concerned about? Are you going to get upset at me if my personal github namespace fork includes a set of patches that aren’t officially blessed even though that’s exactly what github is designed to allow nearly frictionless as a platform?
We don’t have to get to enforcement, we just have to set some norms. If you want to hold the trademarks like logos for official builds or licensed builds that meet specific requirements, have a process that defaults to builds when people fork that don’t use the marks… Make sure the tarballs you release with the intent for people to consume and rebuild… don’t have the marks. and if you can have the logos are in separate repo licensed under a restricted copyright license. The tademarked logos as content don’t have to be licensed the same way as the codebase itself. Having the logos licensed the same as the codebase without a written trademark policy sets an expectation about your interest in letting the marks be used by rebuilders.
You should look at the fedora-logos package versus the generic-logos package that I hinted it. We found a way to use copyright licensing to help structure this in a way that made sense for us and helped set an expectation that still let our downstreams and users use and modify our outputs our stuff, in accoradance with the copyright licenses for the bits, without dragging our trademarked logos around or making extra work for the downstreams to pull it out our marks. Personally I prefer the generic logos package… but that’s just my personal opinion. Luckily for me I can quickly switch fedora-logos out with generic-logos on a traditional rpm based system and bask in the warm mustardy glow a friendly smiling face in the corner of my desktop background.
The problem specifically is QT’s release model as it intersects with flathub’s runtime EOL policy.
I really don’t want to pick on OBS, because I know they are in a bind on this and I had a good conversation at GUADEC over breakfast about it with one the developers.
The flathub flatpak was making use of an EOL’d runtime to avoid the jump to a newer Qt and the regressions inherent in the jump. Qt’s split between community and commericial support business model really pushes open source projects that use Qt to have to move quickly to stay on a supported release.
And so far flathub policy has allowed building against EOL’d runtimes which gave OBS a way to avoid the jump in their officially supported build. But I am of a firm belief that the spirit of the CRA that we’re all going to have to figure out how to abide by to some extent makes it much tougher for flathub to continue to allow building against EOL’d runtimes. It’s a tough position for OBS upstream to be in. I think its going to get tougher. I just don’t think the policy to let applications build against EOL’d runtimes is something that can continue and feel confident that the intent of the CRA legislation is being fulfilled, even as an open source steward.
1 Like