Re: [GNU-linux-libre] Parabola packaging

[Denis 'GNUtoo' Carikli]

On Mon, 24 Jul 2023 21:23:39 -0400
Richard Stallman <rms@gnu.org> wrote:
>   > And to bring it back, we could for instance require the
>   > contributor(s) to:
>   > - Make a package with that free game that also builds ScummVM and
>   >   patches it with that game checksum (that's the way to do it in
>   >   Parabola).
>   > - Make it hard for users to interact with ScummVM directly, by
>   > removing it from the PATH, removing its .desktop file to make it
>   > disappear from the menu, and make a script that would launch the
>   > game, and make a .desktop that would launch that script. This
>   > easy to do.
>   > - Patch ScummVM to not run any other nonfree games if that's easy
>   > to maintain. If it's not easy to maintain we could also require
>   > it in Parabola nevertheless if people want that. Both look fine
>   > for me, though I'd of course prefer if it's patched to refuse
>   > nonfree games as this way we'd be sure that ScummVM would not
>   > steer users toward nonfree software and we'd avoid having too
>   > many discussions about that.
> 
> I guess we COULD do those things.  But it seems like a pain in the
> neck with no benefits at all.  People won't like these complex rules.
> 
> I think it would be MUCH better to do what I proposed, which is
> simply to _urge_ distro maintainers not to include ScummVM and tell
> them why.  Much simpler, and no rules.
I've argued in another mail why having the choice between "removing
the package" or "following that kind of rules rules" would in fact make
it more simple for distributions.

But if the issue is spending time on deciding on complex rules, then
another option would be to make it clear that there are still these two
options but that the person wanting to bring <foo software> back would
be the one that would need to interact with some instance (the
distribution, this mailing list, etc) to find together which rules to
put in place to bring back that package.

This way it would be clear that it's not impossible to bring back a
given package if it has valid free software use cases, and still give a
path to the people that want to do that.

For ScummVM we could probably do that already since we discussed it in
such extent that we now have enough insights to make these rules. This
thread already has almost everything and we only need to make small
adjustments or choices to what I proposed.

This way if another similar software is removed and that someone wants
to bring it back, there would already be some kind of blueprint that
would give a possible direction to follow.

And here you/we could even suggest to remove the software first to make
sure the process is not abused to keep software with the promise that
it would be fixed while it's not, and then suggest that if someone
really wants that software back, this mailing list for instance will
be open for discussions on what modifications would be required to
be able to bring it back.

We'd also need to add a justification like we already do in this page
(in Problem):
https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
this is to make sure that this mailing list is not flooded with
requests. Since the person would have to make the work to bring back
the package this would also limit the amount of mails.

So with very small modifications and a little more work, we can
probably end this thread with not only a situation that foster
more collaboration instead of wearing down people in heated discussions,
but this could also be used as a blueprint for further modifications
like with third party package managers. And all that is based on
existing practices, so the changes would really be minimal.

Denis.

pgp8keZyH9Y1f.pgp
Description: OpenPGP digital signature