This may require working with @yselkowitz to figure out how such a process should work. And it needs to be documented so we can leverage it in the future.

I've been informed by @yselkowitz that there's not actually a way to do this right now, but he intends to push an EOL build update with a message about its more limited functionality.

I would still like a process figured out to remove the flatpak, though. So please let's figure out one. :wine_glass:

We did delete some containers that had secutiry issues in the past... that was just skopeo delete/garbage collection.
I don't know if flatpaks will be much different?

I don't think it would be different, since they are OCI bundles, but I don't know much about how the metadata things work for this.

I wonder if this is something the Flatpak SIG could help with. If not in guidance, maybe in creating a process for the future.

If we remove the flatpak from our registry, will users just stop getting updates?

I'm afraid so. Users who have the app already installed will need to manually remove it and install it from another source. There is no nice way to handle this.

But our choices are remove or rebrand. Removing is surely the nicer outcome for users.

There is no nice way to handle this. [...] Removing is surely the nicer outcome for users.

Then we do our best by removing. The tactical question here is "what happens with the metadata when we remove the container". If we can confirm what must be done to properly remove the flatpak let's get that information shared here.

Edit: We are getting guidance now as to how to properly remove the flatpak without causing metadata problems.

But our choices are remove or rebrand. Removing is surely the nicer outcome for users.

Rebranding is much harder for us, but I find it very difficult to believe that it's worse for the users. At worst they can do their only option if we remove (move to use upstream instead).

Also ... those are not the only choices available to us. Off the top of my head:

1. We provide an "upgrade" that just brings up a message to the user explaining the situation and how they can solve it. Cons: Upgrades that intentionally break things aren't fun. Pros: User doesn't have silently unmaintained software that may cause problems in the future.

2. We (quickly) provide an "upgrade" which is the current flatpack plus some kind of message to the user, and then remove it just before the deadline. Cons: Only helps people who upgrade in the next 4 or 5 days.

3. Rebrand in the cheapest/easiest way possible (Eg. grey boxes) and give a message to the user ... likely also say "this horrifically ugly version will stop being updated after N weeks from now"

I don't think there's any precedent for this kind of problem. The closest thing I can think of, with the same intent, is the rpm key signing change in Fedora ... and we tried very hard to get the message out there (and it was obviously broken). We have just droped packages from release to release, but we've had tools to help the user understand it (Is there something similar to yum list (distro-)extras in flatpack?) ... and kind of hand wave it away due to not really supporting release to release upgrades in that way.

Also seems like we'd want to look at how we'll have better options in future, if it happens again, and/or somehow make sure it can't.

@james I don't think we want to start playing games with "technical compliance". We expect others to respect our IP rights - e.g. we assert that you can't just make any Fedora derivative you like and call it "Fedora", you have to give it a different name (you can additionally call it "a Fedora remix" if you like, but you can't call it "Fedora" or "Fedora Foobar").

Since we think we should be allowed to do that, we should obviously respect the same from obs-studio. If they don't want us to distribute a flatpak with the obs-studio IP, we should respect that properly, and as promptly as we can. Not try and do some kind of technical minimal compliance, as late as possible.

While I am not quite prepared to rescind the request entirely, as there are still a lot of unknowns about the long-term plans of the Fedora Flatpaks repo that we have concerns about, I will consider the EOL notification "good enough" to distance the package from upstream for the moment. There is no danger of any litigation or further action at this time.

We were given a very clear "No." by certain members of the Fedora community, and felt there was no other option or room for discussion. However, that discussion has begun in earnest now with the appropriate parties, which is all we ever wanted in the first place.

@adamwill If they gave us 6 months, then I agree the suggestion that we wait until the last couple of days would be acting in bad faith ... but when they give us 7 days, I think it's more than fair for us to take an extra couple of days to help anyone that installed it from us. I would also be disappointed if we didn't think it was fair for someone else to take a couple of days to inform/help their users if we asserted our rights in a similar way.

But, to be clear, my main point was that we don't have a binary choice (at least for a couple of days) ... although a lot of those choices are going to be more work/pain for "us" with the uncertain/unknown rewards going to our users.

I will keep this comment brief, as there will be more context and ongoing discussion over here, but this request is no longer necessary and may be closed. We had a good conversation today, and there is a hopeful path forward that does not require the OBS Project distancing itself from Fedora Flatpaks.

Thanks @fenrirthviti, I'm closing this request, though the overarching policy questions do need to be handled at the Flatpak SIG level.