Re: general policies

[bill-auger]

On Tue, 19 Sep 2023 17:37:52 +0200 Denis wrote:
> > On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:  
> > i suggest generalizing as much as possible, so that
> > some rule, applying mainly to some large middle-ground, also extends
> > to cover each of those corners
> Isn't that what we have already?

i dont think so - AFAIK, the only criteria now is the license of the source
code - there is nothing like the FSDG criteria about recommending or
facilitating something else non-free, once the program is compiled and running -
Narcis's last question exemplifies that - "yes" TPPMs are libre, therefore
they are acceptable in the FSD, literally - but programs like
'flash-player-installer' although libre, are kept out of the FSD on principle
alone, because their non-free facilitation is so obvious and intrinsic; but
probably no explicit policy requires them to be excluded

by way of generalization, one should be able to draw the conclusion from
flash-player-installer being excluded for its blatant behavior, to excluding
anything which recommends, requires, or facilitates installing something else
non-free, for the same behavior, however obscure

more and more, applications are adding in-app plugin/add-on downloaders, even
those which did not have them before - it is rarely obvious though, unless
someone runs the program and checks all of its features - these often get
reported to the parabola bug tracker; but that information is never relayed to
the FSD - i would not propose an edit on that basis, because it is not clear if
those concerns are within the scope of the FSD - if they are, that would place
an extra burden on reviewers, to actually run the program and look intently for
certain behaviors - that would need to be done, even if the FSD would accept
programs with those behaviors, but required some standard "use at your own risk"
warnings - without a warning at least, it remains as a rather large blind-spot


On Tue, 19 Sep 2023 17:37:52 +0200 Denis wrote:
> As I understand users were discouraged from adding software that is
> complicated to decide on.

i think that is wise - a clear example is chromium - it is not in the FSD due
to the complexity of auditing it; yet some FSDG distros are distributing it - i
would like to prevent such blatant contradictions - if the FSD rejects
something, distros should reject it too, or be obligated to refute the decision
and/or do the complete tedious audit themselves (and share the findings) - we
are only confusing people by not coordinating the research efforts and
guidelines


On Tue, 19 Sep 2023 17:37:52 +0200 Denis wrote:
> If software requiring nonfree art work is added, it will
> likely be the most famous games in this situation, so it might be easy
> to check and raise the issue if some are found.

it may be easy to check and raise an issue; but i dont believe there is any
policy about that - so to raise the issue, is to request action based on some
subjective decision, after a usually very long disorganized discussion, decided
by _whoever_ is reading the list at the time

if common issues were decided in advance, to raise the issue would simply be to
demonstrate the conflict objectively, then to apply the prescribed treatment for
that class of freedom problem (eg: remove it, add a standard warning, etc) - no
discussion should be necessary in most cases

the only long discussions should be about the guidelines themselves, not any
individual programs - very few programs are so unique to require its own
discussion (eg: the recent scummvm discussion was an exemplary waste of time) -
i say, spend that time working out a general policy, then each example becomes
simply: "... and scummvm is one of those - treat it just like the others, as
prescribed" - that approach may sacrifice some precision, but is far more
efficient


On Tue, 19 Sep 2023 17:37:52 +0200 Denis wrote:
> I think it would be a better idea to have that done step by step with
> small steps, handling the easiest cases first.
> This could then pave the way for the harder cases.

that is more practical; but that approach tends to lead to a patchwork of
contradictions, inviting uncomfortable questions from users that i do not
want to answer, like "why did they treat program A with treatment T, but not
program B which has identical properties?" - answer: "because they (possibly
different people) did it ad-hoc and subjectively, without a uniform general
perspective"

as someone trying to give tech support and guidance for such a massive set of
software, it is quite irritating to need to apologize for a mess that i am
associated with, though i was not involved in making, and am not allowed to
straighten out - lack of contributors is not the cause of those contradictions
- it is caused by vague policies and a lack of coordination across associated
teams


On Tue, 19 Sep 2023 17:37:52 +0200 Denis wrote:
> [1] It works well without JavaScript and it's probably way more
>     accessible to people living in remote areas for instance than free
>     versions of GitLab.
>
>     Though having both a forge and email interface looks like a really
>     good idea as instead of exchanging a set of contributors for another
>     we might be able to easily accept contributions from both sets
>     assuming that it works seamlessly and doesn't force people to use
>     the mail or web interface because it works way better. That's what
>     some forges like Sourcehut do or are trying to do.

agreed totally - sourcehut is not the solution though - most forges (even
github) support email and CLI interactions very well - the reason why the vast
majority of potential contributors will not use savannah or sourcehut is their
_lack_ of javascript bells-and whistles - most are accustomed to github as
the de-facto gold-standard of forges - if a forge does not look and behave very
much like github, it is seen as foreign and intimidating - relatively few
people care about no-js support, in fact, most crave javascript - those same
people generally refuse to use email also - like it or not, most of today's
programmers want to use a lively (web 2.0) forge with gobs of JS and CSS, like
git-tea or gitlab, and matrix, discordapp, or slack instead of IRC or email

GNU is very good at giving people what is good for them, but not necessarily
what they want - we are selling veggies between a candy shop and a
drive-through mcdonalds, giving away the veggies for free, no doubt - still, it
is a tough sell - i think we need to put some caramel-covered apples on the
cart - sourcehut is like burger-king's new "plants-based" hamburger - it is not
obvious that many consumers actually want such a concessionary product