A “trademark policy” implies a registered trademark. That’s what I’m referring to by “requiring money and time”.
Your reply is once again from a legality POV when most of us here have the “goodwill”, “bridge”, whatever you want to call it, POV. Sure we can make generic branded builds, we can also maliciously block fedora ourselves, but that doesn’t solve anything and doesn’t stop fedora from ignoring the generic branding (since we don’t have registered trademarks).
Honestly, I feel like we will go in circles if I reply with multiple paragraphs on things you already are well aware of. No, github forks are not the same as a distribution package that end users will use by default. No, asking fedora to not ship broken packages that end up ruining both our (fedora - upstream) relationship and collective reputation for fedora’s own ideological or legal reasons is not the same as being upset over patches. No, copyright is not the same as a trademark, a trademark is expensive and time consuming that most projects don’t have the resources to do. A stricter copyright license on the logos doesn’t solve the name part of the branding. No, a logo being modified downstream is not equivalent to shipping broken software.
And this is the main difference.
Frankly, I don’t think that anything any of us will say will change your mind, that working software is far more important than CRA compliance. I just don’t understand this insistence on shipping software in a way that neither users nor upstreams want instead of just not shipping it at all, as requested. The result is everybody being upset and having constant discussions over it.
Hmm. I look forward to having discussions at FOSDEM specifically about the CRA impacts.
You’ve made a false dichotomy proposition in your logic.
You can have working software and CRA compliance… it just means you find a way to have runtimes with longer support lifetimes for application developers to build against.
As said previous FPL, I regret saying “lax” because it implies a moral judgement. However, Flathub really, simply, actually does not address things we need to care about:
Everything built from source, always — including all dependencies.
Self-hosting builds: that is, not just offline during the build-process itself, but we have and distribute copies of everything you need to build the project.
Packages must be built for all of our primary architectures, except when there’s a specific reason not to.
Flathub is very strict about how things are packaged. They’ve got awesome automation which we could learn from. But Flathub doesn’t care as much about the details of what. That’s basically “trust the developer”. Again, this isn’t necessarily wrong, just different.
When I spoke to Flathub folks about it, the response was basically: of course that’s out of scope, because it’d be totally impossible for us to scale to all of that. Well… we need to care about it.
As I human being, I sometimes don’t have all my facts straight, and I do make mistakes. But I’m never going to intentionally lie about another open source project (or anything else). If I’ve got something wrong, tell me, and I’ll correct it.
Why not?
Explain why one rebuilder gets more leeway than another in terms of threading the needle with being able to do things with the codebase without permission? Because undocumented preferential treatment for one rebuilder versus another feels wrong to me. My personal sense of ethics would prefer a set of expectations that can be equally applied to all rebuilders. We are able to do that in Fedora with the generic-logos.
I’m pretty confident you don’t actually need to register the trademark to set an expectation, you can use proprietary copyright licensing on the logos and ensure the default build instructions that you publish result in binaries that don’t cause confusion. That’s a pretty strong signal to me about intent.
True, it’s not like Flathub doesn’t want that - it’s just, that nobody took the time to solve that problem (mostly for npm, electron etc). So invest in better tooling would go a long way.
I’m not sure I get that. You should only need flatpak builder, flatpak and the correct sdk to build? Why would we put that into the flatpak again?
I don’t think you can expect primary architectures from flathub to match primary architectures from fedora - would be a happy coincidence? The flathub team itself pushes hard on people sending builds, that are architecture specific. But see 1. for cases where this breaks.
All Fedora packaging is part of a single community. […]
There were a couple more statements done by him, but I personally do not have the need to search and link all of them. This single blog post is an amazing display in and of itself.
There’s however one thing I’m really curious about:
There currently around 513 Fedora flatpaks. Flathub have 3264. I severely doubt that all of Fedora flatpaks work as intended and that the sole maintainer of Fedora flatpaks have the capability to manage all bugs that would be architecture specific. Why not just go to app developers themself and ask them to start supporting other architectures? This is the actual solution, instead of just side-stepping the whole problem with badly maintained remote. At this point it should be more than clear that Fedora flatpaks were rejected by the community, which chose Flathub.
And to make it clear: I do appreciate what you’re doing and I sincerely respect you. Please do not interpret my words any other way.
To be clear: Flathub is good on this for most packages, but doesn’t guarantee it. And, since I last looked, there’s some nice documentation on rebuilding exact Flatpak packages: Rebuilding a Flatpak from published sources | Flathub Documentation. The caveats at the bottom are mostly a matter of resources (and in this case mostly storage resources, not people time).
The point I’m making is that this isn’t actually true. Any built that used QT 6.8 had the same problem.
The difference between the Fedora build and the Flathub build, at the time, was that the Fedora build had security patches applied, and the Flahtub build did not have security patches applied. The Flathub build had high-sev security vulnerabilities that weren’t being addressed:
It’s a bit annoying to be addressed but only allowed to reply every 2 hours
Also looking forward to the Fedora-maintained LTS runtime for Qt that will totally be CRA compliant and application developers will want to target just for Fedora /s
Are you asking me why Fedora is treated differently than a random github fork? You have hundreds of thousands of users and are responsible for how and in what condition they get software. Is that not enough?
If anything, the undocumented preferential treatment is towards Fedora. Everyone has been very charitable and any other distribution that would antagonize upstreams as much as this, to the point they have to threaten with legal action to make it stop, wouldn’t have heard the end of it.
It’s just that Fedora is the only widely used “rebuilder” that keeps doing this. The correct answer to “can you stop shipping our software” is “sure” and maybe “can we somehow fix it?”, not “we are allowed to do whatever we want” nor “please spend your free time creating a special generic build for us instead, while we keep shipping it broken”.
This really only applies for new projects or projects willing to change their branding just for this. Projects with established branding can’t just relicense logos they don’t exclusively already have the rights to.
We should be thankful so many FOSS artists dedicate time to draw icons for free and not demand even more rights and work from them.
As mentioned previously, this wouldn’t solve the issue. We can’t “copyright” an app name. A soda can next to “Bottles” doesn’t solve anything.
You are asking too much from volunteers. Blocking fedora is easier than having to go through this maze to satisfy fedora’s refusal to just stop shipping it broken.
The discussion has derailed a lot with all the generic branding and trademark talk. The point is that fedora keeps shipping (rpm and flatpak) packages that you know they are broken, users know they are broken, upstreams know they are broken and the main suggestion is to register trademarks, have logos under restrictive licenses and a generic branding buildtype instead of trying to find an appropriate solution (one of which is ceasing shipping these packages) without propagating the results of these (in)actions to upstream volunteers that are already spread thin.
and, once again, the fedora flatpak was broken. Your users might not be able to use the software you give them, but at least they know it doesn’t have any vulnerabilities
So, with that in mind, the only broken flatpak was Fedora’s flatpak.
Which wouldn’t be a problem (minus your build being labeled a hostile fork) if you weren’t shipping it to all of your users with a higher priority than the repo OBS officially supports even if the end user adds that repo themselves.
We’re back to the same problem now, Fedora Flatpak is a hostile repo and the people that can actually fix it do not seem to be interested in the slightest based on the content of this thread.
If we were in a world where it wasn’t being shipped to every Fedora user by default I don’t think we’d be having this conversation because it would have no success whatsoever, but because it’s in a position where it’s forced upon your unsuspecting users it has to be addressed. It’s harming user experience, it’s causing drama with downstream, it’s causing internal drama among your own team, it’s damaging flatpak as a technology by ensuring no Fedora user has a good experience with it, and it’s not benefiting your project in the slightest.
My opinion is that Silverblue would do better by shipping with no flatpaks than shipping with Fedora flatpaks. I would rather a empty system than a systemically broken one.
I personally think a lot of this can be resolved by giving the user a choice of where they wish to get their software from maybe even during the first-boot setup prompts.
Edit: This wasn’t meant to be a direct reply to you Kyle - I just pressed the wrong button.
That’s not my point, nor was it relevant to anything I expressed. “donate” is in double quotes by virtue of being used loosely.
Either way:
This is all the more true given that everything else I wrote was ignored. No sympathies towards my experience and absolutely no effort in addressing these poor behaviors, especially considering that this was the beginning of the downfall of my involvement in Fedora, but also the source of upstream projects taking hostile stances against Fedora. If anything, I am convinced that you folks only care about your public image and are willingly ignorant about upstream projects.
Sure, Fedora Flatpaks has reasons to exist, be it for different architectures or legal concerns.
But this does not excuse or justify the hostility towards upstream projects or Flathub. Nor does it excuse the unwillingness to limit the scope of support to something more sustainable, uncontroversial, and helpful. Nor does it excuse the obvious attempts at bikeshedding in this thread and in general discussions centring around Fedora Flatpaks by cherry-picking random parts of comments. And it certainly does not excuse you making your problems our problems.
Your hostility and unwillingness to cooperate is the reason why we respond with hostility.
I’m sorry you had a bad experience. I care about upstream projects and I care about Flathub and Flatpak. I’ve never intended to be hostile and I’m sorry some of my off-the-cuff comments came out that way.
I’d be happy to be in a world where Flathub covers everything Fedora needs as a project and for our users. Can we work together to get there?
Hey all. I’m taking this thread out of slow mode for now so that people don’t feel impaired in communicating. But, please, let’s keep the conversation constructive and all work to turn down the temperature as much as we can.
We all want a good experience for users and an awesome, healthy desktop Linux application ecosystem. We’re all on the same side.
Wouldn’t it be less resource-intensive for Fedora (as in those who need to care about it) to perform the review on Flathub’s Flatpaks and set a filter of “Free, built from source and using up-to-date runtimes” Flatpaks, as a downstream[1] item, which would then be enabled by default on Fedora’s desktop images as a filtered Flathub repo, than the current status quo: spending resources on Fedora Flatpaks? And in the meantime work with Flathub to reach some of Fedora’s other goals, not yet fulfilled?
I thought that might be the statement you were referring to. I asked Yaakov what he meant, and he confirmed that he did not mean that Flathub “has no real community.” He wrote that Flathub applications, individually, have communities, which is a contrast from distributions which generally have one “systemic” community that manages the entire collection of software.
It’s a statement about the model associated with Flathub, where applications are seen as the work of individual “owners” (who might be the upstream developers), vs the model that’s associated with distributions, where users see the distribution as the entity managing applications. It was not intended to be a derogatory remark about Flathub, nor dismissive of the community that undeniably exists around Flathub and Flatpak.
Correct, but that proposal of Timothee was to filter Fedora Flatpaks to preinstalled apps only and let the users add the unfiltered Flathub remote, whereas I was suggesting that Fedora filters Flathub (curated list of apps and runtimes which fulfill Fedora’s policies) and provides such filtered repo as primary Flatpak source.
