Re: [GNU-linux-libre] Good practices for removing nonfree code found in source code.

[Alexandre Oliva]

On Oct  1, 2021, "Denis 'GNUtoo' Carikli" <GNUtoo@cyberdimension.org> wrote:

> What are the best practice to fix cases like u-boot or fix other
> nonfree code found in free software source code for the various FSDG
> compliant distributions?

IMHO the platinum standard to aim for, of not participating in the
distribution or promotion or endorsement of nonfree software, involves
not carrying the nonfree bits in our own source or packaged
repositories at all.

The way GNU Linux-libre used to deal with it was to publish cleaned up
tarballs, without history, and binaries built out of them.  More
recently, we've started publishing a git repository with cleaned up
sources, still without history: each one of our releases is an initial
commit.

These approaches have the advantage of ease of withdrawing releases
found to be problematic without affecting even subsequent releases that
are ok.  Without history binding them together, each release can be
handled independently.


OTOH, the loss of commit history, though acceptable from the FSD
compliance POV, is undesirable for various oher reasons.  So we're now
working on a git repository rewrite that carries history but removes
nonfree software and other objectionable bits from the point of
introduction.  It's a parallel-universe history, in a way, but with git
commit mapping, one could even use the rewritten repo for upstream
development.

We haven't quite worked out how this is going to work, but the goal is
that, as commits as added upstream, they can be incrementally verified
and integrated, in a mostly automated fashion.

If/when we find a freedom bug in a previously-accepted commit, we'd have
to re-rewrite that commit and all subsequent ones.

Given some script along the lines of deblob-check, the
checking-and-integration is mostly automatable.  Once I grow up code for
progressive integration of commits, I shall turn that into a free
software project so that others can use it to maintain freed-history
repositories of other blob-ridden projects.

In case anyone has already done anything along these lines, I'd
definitely be interested in having a look, and probably building upon it
and contributing to it.


All this said, it doesn't seem to me that this platinum standard should
be a requirement for FSDG compliance.  E.g., we don't seem to require
projects to withdraw all past releases upon finding a freedom bug.  For
compliance, fixing the bug and issuing updates with the fix appears to
be enough to meet the requirements.  More than that, though IMHO
desirable, appears to be beyond what could (should?) be considered as
mandatory, given what's reasonably doable with existing tools.

Maybe with newer tools that make the process of cleaning history more
convenient, we can eventually bump the requirements.


-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>