Some Fedora Flatpaks re-use Flathub app's manifests without crediting the authors

The Water Cooler
86

I think that Jef is on the right track here…

“Reputation” has been mentioned several times in this thread. When a project is concerned about their reputation, trademark is probably the context in which that concern should be addressed. Trademark exists specifically to address concerns about reputation.

Especially for the purposes of this discussion, trademark does not need to be registered. If a developer publishes a trademark use policy for an unregistered trademark, I would expect that policy to be respected. Trademark does not need to be something that requires money and time, beyond the time required to publish guidelines for the use of the trademark.

Mozilla’s trademarks are registered, but I think they still serve as a useful example: Mozilla Trademark Guidelines

In part, they serve as a useful example because Debian has demonstrated how distributions should handle trademarks when the conditions for use of the mark are incompatible with the requirements of a downstream user of the source code. Debian’s requirements, for a long time, included the ability to patch vulnerabilities in the package they shipped, independent of the upstream releases. Mozilla’s trademark policy does not allow the use of their marks on modified versions of the software, so Debian simply shipped a build with a different name and logo. That is the correct way to use Free Software in compliance with a trademark policy that does not permit use of the marks to identify a modified product. Publishing the build with a different name and logo protected Mozilla’s reputation, and communicated to the community that the build that Debian provided was Debian’s build, not Mozilla’s build.

This is another case of what I said earlier, that one of the things that’s valuable about Fedora is that it demonstrates how software development and distribution work. Debian also provides those demonstrations.

I don’t think it makes sense to publish source code and call it Open Source or Free Software, at the same time you tell people not to build and distribute it. But it does make sense to say (via a trademark policy) that the software can be used but not your name. That’s reasonable and common.

I am … mostly certain that is not true of trademarks. You can publish works that contain trademarks under a license that allows distribution, while simultaneously asking that your marks not be used for identification, via a trademark policy.

P.S.:

Asking Fedora not to publish Flatpaks would mean that Fedora cannot serve as an example of the right way to build and publish software, and I think that would be very bad… that’s one of the most useful things that Fedora does.

1 Like
87

I remember that thread. But that post was suggesting that Fedora ships a filtered Flathub with the existing filters in place (verified, non-proprietary etc) IIRC. I understand there are concerns that these categories are not fulfilling Fedora’s needs, policies etc (e.g. free software, yet not built from source, or with EOL’d runtimes etc).

So I was proposing that resources are shifted towards “manually” curating Flathub via allow-like filters. I know, I’m a dreamer.

1 Like
88

How would filtering apply to the underlying runtime environments that flatpak apps build on top of? it sounds like a hypothetical future situation where there is a major issue with one of these underlying layers is the main sticking point because any rushed changes (i.e. filtering a broken or noncompliant piece to limit liability) would be a lot more impactful and potentially damaging to the experiences of more Fedora users compared to fixing compliance with a single app.

It sounds like there may already be mechanisms to “route around” or enable fedora to patch issues with individual flatpaks, but I’m not sure whether similar tooling exists for flatpak baseapps or runtimes. I feel like I’d love to see flatpak as a packaging format start to gain features that allow it more flexibility in how it can be used, allowing it to be a common technical layer that gives users choice, even if different projects have different repositories with different inclusion policies.

That said, I have no horse in this race besides being a Fedora user who maintains two flatpaks on flathub. Hope i’m not missing any context or misunderstanding anything!

2 Likes
89

Your reply essentially reads to me “either trademark or nobody will listen to you”. This is not a great look. I thought FOSS was about collaboration, and this “we are gonna do whatever we want, coz license allows us” is not collaborative at all.

App developers shouldn’t need to use legal threats to make distributions listen to them. This is just abusing your position.

This is really sad and the fact that it happened twice is disastrous. This type of answer shouldn’t be made when someone is kindly telling you that your actions are hurting them.

1 Like
90

Matt mentioned several requirements earlier, including:

… reprocheck doesn’t address either of those things.

For that matter, Matthew linked to Rebuilding a Flatpak from published sources | Flathub Documentation which doesn’t address those things either.

That document uses the term “sources” in a misleading and confusing way.. It only means “inputs” to the build pipeline. There is no technical requirement that inputs are source code. I believe that policy requires it, but I can quickly and easily find packages that use pre-built binaries as “sources” for a Flatpak.

91

I have problems understanding, this reads exactly the same to me.

This is the same as if someone said that GNOME/KDE have no community, because every app also have its own community.

92

I’m not saying that, at all. I’m saying that software developers can eat their cake (publishing software under an open license) and have it, too (requesting that their name not be used on something they did not publish, themselves).

I’m not saying that downstreams will not listen to requests, I’m saying that I don’t think a request has been made yet, other than one that contradicts the license. The license specifically grants everyone the right to modify and distribute the source code. Asking anyone not to do the thing that the license specifically grants is confusing.

Jef has suggested an option that resolves the logical conflict inherent in asking users not to do the thing the developers have told users they can do. I think it’s a good suggestion. I believe that his intent is specifically to listen to the requests that the developers have made, by offering a solution that might satisfy both parties. That’s definitely my intent as well.

1 Like
94

(post deleted by author)

95

Reputation can also mean projects being widely labelled as “buggy” and “crashy” purely due to incorrect downstream packaging. Likewise, it’d be unfair and demoralizing if Fedora or its package maintainers were blamed for a buggy Fedora-based distro.

then it’s not a “trademark use policy” but a simple request which will be ignored like any other non legally-backed requests that have been done to fedora.

I feel like one of us is misunderstanding what a trademark is.

Times have changed.

… Then don’t distribute it broken. Sure, the license allows you to distribute it however you want but once again, upstream’s wishes are ignored and fedora’s relationship with them is shuttered. Nobody has a vendetta or hidden agenda against Fedora, we are asking to stop shipping broken software on purpose and instead of reading this as something to improve on, we are getting “we will do whatever we want”, “then you can’t call yourself FOSS”, “just make a special generic branded build for us”, “just trademark your name and logo”.

Cheers to that. “The right way to build and publish software” maybe is not “right” when the software comes out broken. Who is Fedora even serving at this point? Package maintainers?

3 Likes
96

The problem with OBS was a communication problem — they filed the request in what looked like a perfectly legit place in Gitlab, but that wasn’t actually being monitored by anyone, so it languished. The fix for this has nothing to do with Flathub or Flatpak — it’s moving all of our official repos and trackers to https://forge.fedoraproject.org/ and making it much more clear where to report things and what responses to expect, and how to escalate when there’s a problem.

Once we actually talked, everything is fine, and the OBS upstream is actually perfectly[1] reasonably happy for Fedora to be packaging the software as RPM and Flatpak and whatever. They just wanted it to not be broken (fair enough!), and we worked together to get it fixed.

  1. edited — see reply 103 ↩︎

8 Likes
97

Free Software developers publish their source code with a license, grants certain rights to users, under specific conditions. The license is a legal document, but no one describes is as a “lawyer demanding things.” A trademark use policy is the same; it describes the conditions under which trademarks (including unregistered trademarks) may be used.

Honestly, I think trademark policies should be as universal as licenses. This should be the norm.

One of the things that users tend to believe about Flathub (particularly about verified Flatpaks) is that it provides a way for software developers to publish software directly to users. The source of the software is the upstream developer. Users typically don’t believe that about packages that they get from a distribution. Users typically believe that the distribution, not the upstream developer, is the source of packages included in the distribution.

In other words, users tend to believe that a verified Flatpak is the work of the upstream developers, not of the Flathub community at large. But that doesn’t mean that Flathub doesn’t have a community. Right?

2 Likes
98

Sure. If it were a risk to Fedora’s reputation, Fedora would probably direct them to the trademark policy:

I think it’s unfair to speculate about what Fedora might do in that case.

As I said earlier, Fedora’s build of the application was broken because Fedora applied the security patches provided by the vendor (QT). In this specific context, the only way to not “distribute it broken” would have been to distribute it without applying the security patches that the vendor (QT) provided.

1 Like
99

Thank you. As much as I appreciate your comment, I no longer feel comfortable exploring solutions with Fedora packagers, especially when the underlying problems with hostility towards upstream projects have not been addressed, let alone acknowledged.

Upstream projects should not be the ones to go out of their way to get their branding trademarked just to disallow Fedora packagers from breaking their app, especially when most of these projects originate from indie developers who contribute their spare time to develop them, who don’t have the capacity or even finances to seek legal advice. Would you or even Fedora provide these projects the means to trademark their brand(s)?

At Bottles, we have the resources to trademark and even seek legal advice, but I’ve explicitly been against it, because these social problems literally cannot be fixed with legal solutions; and being one of the most popular apps on Flathub, we also want to stand up with small(er) projects. While a trademark enforcement would stop Fedora packagers from packaging and breaking Bottles, they will continue to break other apps. Just because you’re allowed to break people’s apps and are legally allowed to avoid accountability by making it upstreams’ problems, there is no excuse for damaging their projects (and even burning them out). Fedora Flatpaks and many Fedora packagers have only been burning out indie maintainers.

This thread has once again devolved into something completely meaningless due to more hostility. I think I will disengage from this thread because it’s the usual unproductive “discussion”, sorry.

1 Like
101

Wouldn’t that be great.

I think that would be a great bridge.

I’ve had a numbe of discussions around figuring out the shape of that and similar possible futures in fact. Unfortunately those discussions have made it clear that while It would be possible for Fedora as it presently stands to have a runtime published at flathub, few see the value in it. So that particular future would take some work.

1 Like
102

so if i understand correctly, the roadmap for a bridge is there, and following it would give Fedora the required control over the runtime layer to be able to respond fast enough to any issues faced, and now the main barriers are more about how to make it practical/how to incentivize/make it attractive for flathub maintainers to build against this runtime and/or submit their packages for consideration in Fedora (in some form, whatever that takes)?

103

Hi, just wanted to jump in and clarify on this point from the OBS Project side of things. While the issues that lead to us invoking our trademark were resolved, I wouldn’t consider us perfectly happy.

  • The OBS Studio Fedora Flatpak still uses an identical app-id to our official package, which has the potential for causing confusion. As far as I understand it, however, this is a “genie out of the bottle” situation, but highlights the lack of care to upstream. It’s unclear if this point has ever come up in internal discussions at Fedora, but I’ll raise it again now as a consideration for future packages.
  • As far as we know, the behavior and attitude that seems to be chronic around Fedora’s own methods of packaging (i.e. we know better than you, and we aren’t going to listen to anything you say, and insult you if you disagree) has made no progress, seen no disciplinary action, and as far as we are aware, members of the project (or representatives) are not holding themselves or community members accountable for such things.

It’s disappointing to see this conversation once again devolve in to “well open source says we can do this, why are you so against open source?” instead of having a real conversation about the process and people that these decisions are affecting. It’s a disingenuous argument, that feels pretty gross to constantly read as a fallback to any real criticisms the Fedora ecosystem receives, and serves only to dehumanize the projects involved and the efforts they spend.

While we are currently fine with the OBS Studio version being packaged with Fedora Flatpaks as the critical broken issues are fixed, calling us perfectly happy with how things turned out isn’t exactly accurate.

9 Likes
104

That is a question that would need answering at a later stage, if there was real interest in such an approach, but, as others have suggested, there isn’t ATM.

Things might change though, as there is an open discussion in the Workstation WG around making changes to the the Flatpak repo provided by Fedora Workstation (i.e. providing only a limited set of apps) and even possibly enabling a FLOSS subset of Flathub by default (should Flathub be able to provide such a subset with only OSS built from source). No decision taken yet though.

105

I doubt my voice has any weight as a relatively smaller voice in this discussion, but I’d be willing to at least try to build the flatpaks I maintain on whatever future fedora runtime. If it builds fine I’d be happy to at least try and submit my flatpaks for use in fedora (or the ones under eligible licenses and presuming its not crazy hard to do).

I suspect this isn’t really the target usecase if the discussion is focused more on stuff that would ship by default though.

Overall I’m open to helping with the aforementioned bridge-building, I’m just unsure how I can contribute productively.

4 Likes
106

I’ve edited my post.

To me personally, it seems reasonable that the Fedora-packaged flatpaks use a org.fedoraproject namespace, but there may be technical reasons to not do that which I don’t understand.

Insulting upstreams is NOT okay, even during disagreements. Please make Code of Conduct reports when you see that. Those are always taken seriously, although outcomes are not always public (the ideal is corrective, not punitive).

Working constructively with upstream projects is our policy: Upstream First: A Core Fedora Principle :: Fedora Docs. I am now just some guy in the project with no special say, but I don’t see any reason anyone working on packaging would be exempted from this principle.

6 Likes
107

Hmmm…

First let me say I agree with you.

I’m not expecting app developers to have to make legal threats, I’m expecting them to accurately document the expected terms under which their codebases are allowed to be used…so we can abide by a documented set of expectations.

3 Likes