[bug#51737] [PATCH v3 1/8] gnu: Add linux-libre-waydroid.

[Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>]

[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]

On Tue, 13 Dec 2022 19:23:06 +0100
Julien Lepiller <julien@lepiller.eu> wrote:

> I managed to build bionic in the time frame I envisionned, but I have
> some issues with recursive module imports when trying to define the
> base inputs for the gnu-build-system (and ultimately the
> blueprint-build-system).
> 
> One concern I have is that Lineage OS includes some non free
> components, though I'm not sure what exactly (at least non-free
> firmware in the kernel, probably drivers too).
Part of the work of making an FSDG compliant LineageOS derivative can
be really easy:
- The kernel can be removed as it's not needed here. I'm not sure where
  the kernel headers are but they are most likely separate.
- Most of the device repositories (in device/<vendor>/<product>) contain
  scripts whose only goal is to download (from the device) the required
  nonfree software.
- All hardware related HAL that depends on these nonfree software can
  be removed.

Here in practice it means forking the LineageOS manifest and removing
the offending repositories.

The hard part is with the rest of the code: With Android, knowing the
license of the repositories is not easy because you don't have package
definitions and you probably don't have very strict copyright
requirements (like in Debian). 

There are empty files like LICENSE_APACHE2 in some repositories, and 
that is used to indicate the license (it's the closest we have to a
license field in a package definition), but I've no idea how precise
they are. These are used by code that generate the list of licenses
displayed in the phone settings, but I didn't look yet how it works.

So if we want to do it right we'd probably need to review at least the
usual suspect ourselves (like libraries with fat code, AAC related
code, try to look if there are nonfree binaries left, etc).

If people want to use LineageOS as a base, they need to check the
DivestOS project as they have a script that can partially deblob more
recent versions of LineageOS (they also informed Replicant of some of
the blobs Replicant missed). They don't remove all the blobs though, so
it might be a good idea to check with them what blobs still need to be
removed.

Replicant 6.0 is based on LineageOS 13.0 which is based on Android
6.0.1, and over time we found and/or were notified of freedom and
privacy issues (that both conflicted with the FSDG). And none of these
issues were present in AOSP. At least some of these issues came from
CyanogenMod, so maybe they are not present anymore.

Another option is to use AOSP instead of LineageOS. This could make
FSDG compliance easier as there won't be any potential issues with
LineageOS additions.

It will also enable to share more work because several Android
distributions using AOSP and kernels based on upstream Linux started to
create a community[1] to share work. So for instance the vibrator HAL
of Waydroid could be replaced by the "Force Feedback haptic hal" that
is generic. Replicant has applied for funding through NLnet to improve
the sharing of work through that community. So for the long term
maintenance of such a project, using AOSP might be a better bet,
especially if distributions like Guix start packaging more and more
AOSP components (this way we'd share more and more work on reviewing
licensing information).

As for linux-libre-waydroid itself, if the only change is to enable
Android drivers, maybe the kernel could be renamed to something more
generic like linux-libre-android.

And if for instance we package for instance userspace tools to test the
binder driver, and with that we might already have a use case and be
able to test this kernel anyway. And I've not reviewed the patch but
the maintenance here could be completely automatized (so when somebody
updates linux-libre, linux-libre-android gets updated automatically).

PS: To all readers: I'm not a Guix maintainer, so I can't decide if
    patches get in or not.

References:
-----------
[1]https://aosp-developers-community.github.io

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]