Deblob instructions, was: Linux-libre architecture and how to modify it for other uses cases?

[Denis 'GNUtoo' Carikli]

On Sun, 24 Oct 2021 12:27:39 -0300
Alexandre Oliva <lxoliva at fsfla.org> wrote:
> > I also made a Makefile.deblob (that I attached) that downloads
> > Linux
> 
> I can imagine why you'd want to have something like that, but I'm
> afraid that's not welcome here, because of the pointer to non-Free
> Linux.
I'll try to be more careful next time, as here I added that Makefile
without asking before. I should also have been more careful here because
I also didn't know the linux-libre community well enough to be able
assume that it was ok without asking before.

> IMHO a script with that link wouldn't comply with the GNU FSDG.
For the FSDG, I asked not so long ago about that in the gnu-linux-libre
mailing list (in the "Good practices for removing nonfree code found
in source code." thread[1]) and I understood from Bill Auger that
complete deblob instructions (with URLs) were acceptable[1].

Parabola has such deblob instructions (with the URL) in several
packages.

If Linux-libre didn't exist, in Parabola Linux would be deblobed in a
Parabola package instead.

Here the deblobbing instructions (that are in the package definitions)
would download the original Linux source code automatically and it would
produce a new deblobed source that would then be automatically uploaded
and hosted by Parabola when the resulting (binary and source) packages
are being pushed to the Parabola repository.

And once uploaded, that deblobed source would also be reused if people
wanted to build the linux-libre package from source.

So the Linux source code is only used when updating the package
definition to a new version.

In general, as I understand, the goal here is not to erase non FSDG
compliant FLOSS projects from the history (I'm not assuming that it's
the case here but the end result looks a bit like that), but rather to
do all we can to not steer users toward nonfree software. 

So I see two main aspects of that:
- Making sure not to steer users toward nonfree software by being clear
  about the limitations of the FSDG distributions or repositories. If
  users get smartphones just to run Replicant thinking that everything
  is free software then we have a problem because that would have
  steered these users toward nonfree software (all the devices
  supported by Replicant 6 have nonfree bootloaders).
 
  So we try to avoid that situation by informing users about the status
  of the phones and basically about the issues Replicant didn't manage
  to solve (like the tracking from the cellular network).

  With linux-libre repositories, some users may think that merely
  installing linux-libre on top of a non-fsdg compliant system avoids
  all the nonfree software. 

  Here too, the solution seems to be to inform the users, because if
  they were already using non-fsdg distributions it doesn't hurt to run
  linux-libre instead of Linux, and these repositories are extremely
  useful for Trisquel users for instance.

- The project documentations should also not directly steer users toward
  nonfree software, for instance by pushing people to install nonfree
  software. This is mostly what you were talking about here.

Beside misunderstanding that could arise from the project limitations
(like users thinking everything is free software when running
Replicant), I think that documenting nonfree software is also the key
in helping people switch to FSDG compliant distributions.

Many free software users don't get the point that nonfree firmwares or
small nonfree software is really dangerous for their individual
freedom, and that sometimes it even has impact on collective freedoms.

And the best way I found to get the point across is to explain it with
practical examples. 

So to explain the point of FSDG compliant distributions, I often use
the information I got precisely through reading the deblob instructions
of various packages, mostly from Parabola, and also with learning about
issues that could be found in the nonfree firmwares and/or in small
nonfree software.

For examples for the firmwares, the Raspberry PI has a nonfree
GPU firmware, and that "small nonfree GPU firmware" is in fact a
complete operating system that controls a lot of the hardware, and it
also boots the Raspberry PI. And having free software bootloaders
instead makes sure not to have any freedom issues at all and avoids
countless arguing and suppositions about how much damage running such
firmware could do to users.

Nonfree WiFi firmwares probably go beyond that. You have the usual
issues like if the WiFi cards can do DMA, then giving DMA access to
nonfree firmware is an extremely bad idea. Bugs also can't be fixed in
them (like latencybloat). The nonfree WiFi firmwares can't be improved
(to add mesh network support), and the list goes on and on. 

The biggest issue here is that the reliance on nonfree WiFi firmwares go
as far as dictating the architecture of several kinds of WiFi networks.
If you can't do mesh protocols because of the nonfree firmware it does
have an impact. So that in turn has big political impacts as well.

At the end of the day I think that in all that, what's important here is
also the context: If a distribution steer users toward nonfree software
with a link to install nonfree software, that's not OK at all. 
It defeats the point of FSDG distributions because most people will
think things are ok (as it's the distribution that tell users to do it)
and they will probably even forget they did something like that in the
first place. So again they'd think they run fully free software while
they are not.

However for me forbidding deblob instructions in the FSDG, that is
instructions not to get nonfree software *for practical use*[2] but
rather to produce FSDG compliant software out of software that is not
compliant and that might contain nonfre software, would be an issue
because it would directly prevent FSDG distributions from functioning
as they should and/or from sharing that information among them and that
information cound't even be reused for advocacy.

Since GNU[4] and the FSF[5] also have documentation on non-FSDG
compliant distributions and nonfree firmwares or bootloaders, I don't
see why having a little bit more precise information about them would
hurt, especially if that really doesn't really steer users toward
nonfree software in practice. In practice I think in the cases I
described it's quite the opposite.

Having information on what was deblobed is also interesting to
understand where we are at and to decide how to start tackling the
problem at a bigger scale (for instance by funding people to replace
nonfree firmwares with free firmwares).

References:
-----------
[1]https://lists.nongnu.org/archive/html/gnu-linux-libre/2021-10/msg00001.html
[2]“Information for practical use” includes software, documentation,
   fonts, and other data that has direct functional applications.
   [...]
   A free system distribution must not steer users towards obtaining any
   nonfree information for practical use, or encourage them to do so.[3]
[4]https://www.gnu.org/distros/free-system-distribution-guidelines.html
[5]https://www.gnu.org/distros/common-distros.html
[3]https://www.fsf.org/resources/hw/single-board-computers

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20211025/cd54ece5/attachment.sig>