Re: general policies

[Denis 'GNUtoo' Carikli]

On Tue, 19 Sep 2023 07:12:20 -0400
bill-auger <bill-auger@peers.community> wrote:
> there is an initial matter of classification to deal with - if the
> program is so tightly coupled to a specific OS, then that OS is
> effectively a dependency - probably, there is binary linkage to the
> platform libraries involved -so i would put those in the same general
> class
Usually yes. Though in the case of Windows programs made for
Windows, Wine can also be a dependency that replaces Windows (nonfree)
or ReactOS (not FSDG compliant, heavily promotes nonfree software).

> but note that the motivation of this thread was not related to the
> fact that f-droid is runs on a non-free OS or require non-free build
> tools - the motivation was its TPPM behavior, a distinct issue of
> another class
For that we have the example of phoronix-test-suite that is better
suited than the F-Droid client that raises a lot more issues.

> On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:
> > In another hand we already have firmwares inside the directory, and
> > sometimes firmwares have custom OS or depend on free software OS,
> > and in these cases the line between an OS and a library is very
> > blurred.  
> 
> i suspect that is a consequence of discussing and adding individual
> items ad-hoc, rather than defining general policies in advance
Right.

> as i understand mobile development, the application code is event
> driven, relying fundamentally on OS hooks - it is more like the OS is
> the sole application, and so-called applications are slave libraries
> to the OS - that is why i suspect they can not be ported in the way
> that a standalone C program can be ported from windows to any other
> system
Treating the OS or a replacement for it as a dependency works without
having to look at the details.

And it is also way more reliable. In some cases (like programs for
Windows) I think that it would be a good idea to require the user to
do the work of verifying that it builds and runs fine on GNU/Linux for
instance, else it opens the door to adding programs with hidden nonfree
dependencies.

A good example of known good programs are the programs shipped with
Wine like a notepad implementation.

> On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:
> > Maybe it's that complexity that makes it complicated to take a
> > decision.  
> 
> agreed; but i do not think the complexity is arbitrary - more likely
> that it is dictated by the manufacturers - probably that VLC example,
> once investigated, can be reduced to a general class, in which other
> examples could be found (EG: maybe that iphone-specific repo has
> non-free blobs or proprietary media codecs in it, and is kept
> separate for licensing reasons, or to comply with a developer's
> agreement)
If the "VLC for IOS" is a different programs, then it has nonfree
dependencies:

- Applications for IOS and MacOS require a nonfree SDK/compiler
  (Xcode). I didn't find any projects that used GCC directly without
  that nonfree dependency. The best I could find are projects that
  extract some headers and/or libraries from Xcode and use them with
  GCC.

- For IOS, users need to jailbreak their device to run free software,
  or to agree to terms and conditions and use nonfree software to
  compile software that at the end will only run on their devices and
  not on their friends's devices. Not all devices/OS versions have
  jailbreaks available.

Yet having some free programs run on these devices is important for
collaboration software (Libreoffice, GNU Taler, software reading file
formats).

> On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:
> > If we go too fast, we risk taking decisions that need to be changed
> > later on or too often, and that could end up in bad situations like
> > having to re-do a lot of the reviews, to remove lots of software,
> > ban perfectly legitimate entries, etc.  
> 
> that is how it should be done though, granted enough people-power -
> that would be time-consuming if changes were rapid and willy-nilly or
> repeatedly contradicting previous decisions which affect a great
> number of entries - ideally, policy changes should be gradual
> refinements, converging on the optimal, with each iteration requiring
> less work than the previous
The issue is that we can't magically make new contributors appear, and
in a lot of cases it just shift people around from one project to
another or ends up burning out people that contribute to too much
projects. And if people burn out more and more that creates an even
bigger issue.

So finding solutions that also work without necessarily having new
contributors magically appearing looks better. Otherwise the risk is
also that more and more inconsistent data will make the directory less
useful than it is now (because no one fixes what needs to be fixed).

> On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:
> > And that is probably less perfect than if we had more specific
> > rules, but these rules also requires us to know about these corner
> > cases.  
> 
> that is agreeable - but i would not suggest very specific rules to
> cover each corner - that is probably why you see this as so tedious
> and brittle - 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 - then only those corners may or may
> not need further refinement
Isn't that what we have already?

> naturally, there is pain involved whenever introducing a new
> criteria, across a large existing data-set - the only way to avoid
> that, is to have no criteria, or no new criteria - ie: if major
> changes are avoided only because of the accumulated technical debt,
> that is already an indication of the typical "lagacy" problem - the
> usual solution is a very painful full reboot
As I understand users were discouraged from adding software that is
complicated to decide on. So that limits the issue. But once we decide
something that might open the door for way more contributions on
different type of software. And if we then revert the decision, we have
an issue.

> there are many facets of the FSF/GNU that are suffering from similar
> technical debit, which as painful as they may be, really must be
> addressed - the FSF appears to be focused currently on the
> accumulated "social debt" - that is there too; and the FSF is
> handling it admirably - it is endemic of anything which has been
> around for 30 years - just one clear example, that savannah is seen
> is an antique to most programmers under the age of 40 - that
> discussion can not be postponed indefinitely - the proper time to
> address that was 5-10 years ago - how many potential GNU contributors
> are already being lost for that one reason? - whatever that number,
> it will only decrease over time
I don't see the issue with Savannah[1].

> o/c, opinions differ on that point - i put in the same category,
> games with non-free artwork data, or say a reverse-engineered machine
> emulator which does nothing interesting without the original
> manufacturer's patented/copyrighted ROM blob - that is plainly
> because source code has only "literary" value (in freedom) unless it
> can be used in freedom - but surely, no one would want that source
> code for reading pleasure or private study or for historical
> preservation (the common defenses)
> 
> AFAIK, the FSF would accept such programs as libre, simply because
> they do not include the non-free parts in the source tree, regardless
> that they are fundamentally useless without the non-free parts, or
> their non-existing libre replacements - i say, replace those the
> non-free parts, _then_ it becomes libre, for all intents and purposes
Here I think it depends on the cases. Software that are incomplete
without other nonfree software would effectively steers users toward
that nonfree software. I'm unsure if we have such programs in the FSD.
In the case of artwork, I'd also strongly prefer if they were free.

But here it probably doesn't make sense to add incomplete software to
the FSD. 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.

> so yes, i think there could be better policy on the FSD, the FSDG,
> and the FSF/GNU about "non-free toleration" in general; but we are
> not the one who gets to draw those lines - similar to the issues i
> have been raising with the FSDG, only the FSF can define the policy;
> and the FSF is likewise absent from this discussion - until then, all
> we can do is plant seeds of rigor, such as this one:
The issue is also that each time we discuss that it ends up in
discussions with a scope that is way way too big, and so they become
extremely long and nobody has the time for that and so it ends nowhere.
Repeating the same discussions will probably not improve things either.

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.

And maybe trying to add a few very useful software with corner cases to
the directory would be a better idea to advance things, trying to
define very easy cases that are simple enough to be reviewed and to not
create issues later on.

Here trying to add phoronix-test-suite and specific firmwares gave way
more infos on the potential direction to follow than discussions that
are too long.

Rockbox also looks interesting to discuss but it would require someone
to review its source code and also u-boot/barebox source code to see
if there are devices that work with 100% free software (with free
bootloaders).

References:
-----------
[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.

    And "fixing" Savannah is not the only option here as GNU has a
    criteria for hosting repositories and other repositories (like
    Sourcehut and notabug) are also allowed.

    And note that Linux/u-boot/barebox, etc also mostly use mailing
    lists for code review, and one argument for that is that it more
    accessible for people living in less connected parts of the world.

    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.

Denis.

pgpD66E2OqYPZ.pgp
Description: OpenPGP digital signature