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

[Denis 'GNUtoo' Carikli]

On Sat, 2 Oct 2021 11:15:01 -0400
bill-auger <bill-auger@peers.community> wrote:
> it seems like a flawed design decision to entangle the VCS with
> the build process, or to store them at all
Indeed.

The root cause of that is that the Android build system doesn't have
the notion of packages in their build system.

Programs made for GNU/Linux typically have a build system (like
autotools, cmake, etc) and then on top of that, GNU/Linux distributions
have another build system that uses package definitions to be able to
download source code, build it etc. Android doesn't have that
separation at all.

So for instance if you want to add wipe[1] to Replicant:
- As there are no git repositories for wipe you need to import the
  tarball in a git repository. This makes it extremely time consuming to
  verify that nothing was changed in the initial import of code.
- Then you need to convert the build system to ones of the build system
  supported by Android (either the deprecated Android.mk or Android.bp).
- And finally you also need to adapt a bit the code.

To fix that we would probably need to package Android in Guix, and
currently we don't have either the time to do that, or the ability to
build a community around that work to make sure that all this work
would continue to be maintained over time.

And not fixing it has consequences too:
- It makes it harder to reuse GNU/Linux userspace. In the future we
  would also like to reuse the hardware abstractions used in GNU/Linux
  (like the alsa library, oFono or Modem Manager, etc), but to be able
  to do that we also need to build them.
- It makes finding nonfree software harder.
- It's way harder to audit the changes made for Replicant.

> the upstream VCS history has no significance to users, nor to the
> distro's packagers - so i would consider that dilemma/chore (purging
> the VCS history), as artificial, and self-imposed unnecessarily -
> users should never need to see "how the sausage is made", unless they
> choose to "get their hands dirty"; and the FSDG requires neither
Thanks a lot, I wasn't sure if that practice was ok.

The advantage of this approach (when we depend on a specific VCS) is
that:
- The nonfree software is removed
- The removal is documented and so people can learn from it and it can
  be maintained too over time.
- You also have a correspondence between the upstream source and the
  source, so users are less likely to run nonfree software as they can
  rebase the change that remove nonfree software on top of the
  upstream version they want or need to use.

The approach taken by Parabola is way better but in the case of
Replicant it cannot really be used for now.

In general my idea when writing this mail was to learn about different
practices with removing bits found in code and along with the
tradeoffs in order to be able to choose the ones that are best fit to
the different situations that arise, especially the ones that we
encounter with Replicant or ones that affect several distributions
(that don't build and ship software in the same way) at the same time.

> On Sat, 2 Oct 2021 00:50:50 +0200 Denis wrote:
> > - What do various distribution do for former releases when nonfree
> > code has been found? Do they archive it somewhere else (like on
> >   archive.org) and stop distributing these releases?  
> 
> it a very good question - i can not recall anyone discussing
> this in the past, and i am not aware of any instance where this
> has occurred for parabola; so i do not have a general response
> ready - it is possible though, that some examples could be found
> in every distro, if someone were to dig deep enough to identify
> them
In Replicant 6, we have found several issues including nonfree code
added by CyanogenMod and firmwares without source code used in
factory testing. 

So while they are fixed in the source code, and that the next
Replicant 6 release is not ready yet (we have RCs, but we still need
to fix some regressions), we need to understand how to handle that at
least when the next Replicant 6 version is released.

At minimum we will probably warn users about it and urge people to
upgrade as users really need to be aware of it.

> unfortunately, the question opens a "can of worms" WRT the GPL -
> distributors of GPL software are required to offer complete
> corresponding source code for _any_ distributed binaries -  if
> one of those distributed binaries were later found to be built
> from sources which contained non-free bits, wouldn't the
> distributor still be obligated to keep and offer the sources? -
Good question. 

I'm not a lawyer but as I understand it is probably legal to remove the
nonfree bits from the corresponding source code that we provide.

> its a tricky question, because its not obvious if the GPL was
> ever legit for that program in the first place - it is further
> complicated by the vagueness of the FSDG in that regard [...]
Sometimes the GPL is completely legit: In several out of tree drivers
for WiFi adapters, I found that the firmwares were included as
hexadecimal arrays inside the C source code, and the file where that
happens even has a header stating that it's GPLv2 or GPLv2+.

In cases like that, the firmware is typically GPLv2(+) but lack the
corresponding source code. And since the hardware vendor who published
that firmware is usually the copyright holder, it won't sue itself.

However anyone getting a copy of that source code can leverage the
rights given by the GPLv2(+) to make it way easier to produce a free
firmware: In many jurisdictions, there are heavy legal requirements
around reverse engineering, decompilation, using (semi-)automatic tools
to reconstruct source code, etc, but as I understand the GPLv2(+)
removes many of these requirements.

So in cases like that it would also be a good idea to archive that
source release somewhere, ideally in projects like Archive.org or
Software Heritage, in order to have stronger proofs that that firmware
was indeed released as GPLv2(+) and enable people wanting to do that
kind of work to easily find that source (and be granted all the right
that the GPLv2 grants on the firmware being distributed in this way).

Beside the legal aspects, there are also very practical questions that
go with the removal of former releases, and they are probably more
visible in Replicant (and maybe some small GNU/Linux FSDG distributions
too) than self hosted GNU/Linux distributions.

In regular GNU/Linux distributions, you can probably remove older
problematic versions of packages somehow. With Android, you can't
update single system components. Instead you have to install new
images. So the only option here would be to remove complete releases.

And because of that, testing and bugreports also have the same
granularity (the specific Replicant release), and removing specific
releases would affect that.

So because of that I was wondering if some distributions already had a
similar issues and how they managed to deal with that.

Since linux-libre removed older releases recently, did some FSDG
distributions had to deal with that in some way? Though maybe in this
case the impact is minimal since as I understand, the older releases
were simply remade without the nonfree bits, and the affected hardware
and drivers are probably well known already.

References:
-----------
[1]http://wipe.sourceforge.net/

Denis.

pgpTojCql9Zr0.pgp
Description: OpenPGP digital signature