general policies

[bill-auger]

changed the subject to avoid stalling the specific f-droid issue

 
On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:
> In many cases building the software can be avoided because it's
> already packaged and built somewhere. In other cases looking at the
> dependencies gives enough guarantees.

yep, that is one point of overlap where the FSD and FSDG could feedback on each
other nicely - for some programs, the FSD relies on the debian package database
for licensing - that is a start; but it is a relatively small number of programs
- also that is done for the sake of growing the directory, not yet as a means of
dependency checking - for example, new and existing FSDG entries could be
cross-referenced against the debian non-free and contrib package databases, for
a quick indication of non-free dependencies


On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:
> For instance we can test how a rule would apply to F-Droid, to a
> software that runs only on a nonfree OS, to another software that has
> lots of dependencies, etc.

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

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


On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:
> > for example:
> > 1) may _any_ program suggest/recommend/utilize un-trusted third-party
> > repos?  
> That can easily be handled with requiring to list/add the dependencies
> of the program (and of the dependencies).

that was not the point (1) was addressing - simply, are TPPMs allowed? - ie:
should the FSD adopt the FSDG requirement "Nor should the distribution refer to
third-party repositories that are not committed to only including free
software;"


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

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

o/c fundamentally, most applications could be described as using the kernel as
a library; but that is why POSIX was established - it seems that mobile
development has preemptively side-stepped the possibility of cross
compatibility; because applications never interact with the kernel, only the
very specific platform SDKs - my ignorance is thick in this area though - i have
never tried to write a mobile application


On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:
> The Rockbox case is also interesting because at best it only works
> under GNU/Linux under certain conditions and at worst the GNU/Linux
> port could be unusable and highly incomplete.

also, rockbox works only in collaboration with the manufacturer's boot
partition - same as gnu/linux ports for game boxes such as nintendo, and
gnu/linux ported to run in the user-space of a mobile phone - regardless of the
licensing, the target hardware makes practical usage fundamentally
"almost-free", at best


On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:
> As I understand Windows applications are not necessarily an issue if
> they can run under GNU/Linux without any nonfree dependencies (with
> wine, mingw, etc).

over-all, its probably better than that - i suspect that most use the dotnet
platform these days - presuming that dotnet is libre as claimed (and if it
is complete enough), we could actually extend MS some kudos there - they allowed
their entire platform to be ported to other systems; and now they even maintain
the *nix port officially on github - if all windows applications used dotnet,
they could all be assumed to "runs on gnu/linux" without the compatibility
deficiencies of wine, and the resources required to maintain wine


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)


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

and o/c work need not be lost - in fact, it can not be lost on a wiki -
each existing entry with its legitimacy affected by policy changes could be
recorded - in case that a specific decision gets reversed at a later time, those
wiki pages can be easily restored


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

by establishing a checklist similar to the FSDG, it would be easy to identify
which programs would be affected by changes to specific rules

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

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

o/c all that takes perhaps more people-power than what is available - that is
why the FSF is in a sense, crowd-sourcing its board elections now - it is not
easy to keep such a large ouse clean and modernized; but there are consequence
to avoiding it


On Mon, 18 Sep 2023 16:37:42 +0200 Denis wrote:
> But in the case of Android software and/or software that pulls
> dependencies from programming languages packages manager to be built, I
> think that requiring the full and real dependencies could be a way to
> deal with that.
> 
> An example is matterbridge that I added in Guix that has about 500
> dependencies bundled inside its source code. I audited the license
> of most of them though. Here an easy fix could be to treat the
> dependencies as part of matterbridge and review their licenses along
> with matterbridge.

i tend to see all dependencies as an integral part of the program, whether or
not they are bundled in the source tree - source code is not literature - it
has no value unless it is running - with conventional software, often some
individual files may be useful in isolation; but that is because they are not
coupled to a specific platform or API, or that platform/API is libre - a
typical QT program for example, contains zero files which do not require QT; so
individual files may be useful in isolation (in freedom) only because QT is
libre, not due to their license alone

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

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:

https://wiki.parabola.nu/Degrees_of_Non-Free_Software_Tolerance

rather than remaining as the musings of a lone distro dev, that analysis could
be used as the basis of a wider discussion (eg: refine the categories, place
some markers (some well-known points of reference) where the FSD lies, where the
FSDG lies, where the DFSG lies, and so on)

obviously, this is not the first time ive thought of this topic - rather than
treat these example individually, i prefer to generalize topics like this and
subject them to rigor first, then to decide (more credibly and well-informed)
where individual examples or policies fit into that bigger picture - ie:
before drawing any lines, firstly conduct a reasonable survey of the topology,
so to minimize the number of lines needed to cover the map - that can never
happen by considering examples in isolation - o/c corner cases are critical,
but still best viewed in the context of the larger scheme (fairly, defensibly)

in this case (the general case of non-free tolerance), ive applied and
documented most of that rigor already - i would only need to ask now, where on
that spectrum does the FSD choose to tune its dial - policy would follow from
that more approachable decision - eg: say program 'foo' is shown to be in
category 'B' - non-technical people would not need to understand why 'foo' is
in category 'B', only the ramifications of that class of behaviors/properties -
the question to answer simplifies to: "what shall we do _uniformly_ about _all_
programs exhibiting the properties of category 'B'?", eg: "programs with TPPM
behavior" or "programs which require non-free build tools" - "keep them?",
"reject them?", "patch them?", "warn about them?", and so on - then each
category can become a checklist item of each entry's FSD or FSDG fitness for
reviewers to maintain - if some program ever must be removed, simply un-tick
whichever box is under conflict and hide the page from public view; _but_
preserve the data privately for possible future re-evaluation