Ha, well, if my single-digit-downloads (all by me) NPM module is influential enough to set precedent, then I’d consider that a success.

Yeah I get that point, and so my point is that if the use case is important enough that they’d be able to justify allocating that personnel, I use the AGPL to give them that nudge. When it’s just some non-critical component, then I’ll just slap an MIT on it and be done with it.

My rule-of-thumb is: is the licence going to make things better for users? In other words, I try to predict whether a company would just not use my AGPL-licensed code, or would potentially contribute back. If they wouldn’t, I don’t really care and rather my code at least gets used to build something presumably useful.

No worries! Thanks for updating your comment :)

If you think you know what happened or the context, you probably don’t. Please don’t make assumptions. Thank you.

https://vt.social/@lina/114184253273866198

Someone might want to check that, because IIRC it was someone else’s alter ego.

No worries, thanks again!

Which Mozilla projects started out as free and are now non-free, i.e. no longer under an open source (or even viral open source) licence?

It was collapsed for me at first, and buried under a lot of other comments, but a workaround is mentioned here. Unfortunately, that didn’t seem to work for me, but deleting the Flatpak and deleting all associated data, and then reinstalling it, I think did the trick.

Although it does now show this warning, which doesn’t sound great.

Edit: actually, I think that was the reason I concluded the first workaround didn’t work, but looking at that URL, this might just have been introduced in Firefox 128, which is newer than the old version of Tor was based on. So it looks like both worked.

So… How do we do we’re running an outdated version, and what is the fix that requires manual intervention?

It’s a shame they changed the name.

Yes, but that amounts to the same thing. The restrictions that prevent you from manually overriding it are there to prevent any app from freely overriding it. There’s a way to only explicitly allow you to manually override it, and that’s the way that’s currently being built and requires ecosystem support.

Because if it is freely overridable (which it used to be, on X11), other apps can override it as well - including malicious apps. The portal adds an explicit path that ensures that the user is in control, but does need to see wider adoption first. Which will surely be helped by GNOME support.

There’s always talk about that (see alternative 2), but that could block packaging core apps as Flatpaks.

Ha OK, I don’t know what ozon is and I don’t think I’ve had to edit .desktop files so far, so I’m probably good. I’m on Silverblue, so I suppose they’re still doing system installs, or are looking at existing packages and following their lead.

Thanks for the clarification!

Wait, if I run flatpak list --system --columns=application, it looks like all my Flatpaks are system Flatpaks. Running flatpak list --user --columns=application shoulds just a couple of platform packages. What am I missing out on? What is this needed for:

like forcing crappy electron apps to use wayland

(Either way, thanks for writing up a detailed guide!)