On Tue, 13 Dec 2022 19:23:06 +0100 Julien Lepiller 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//) 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.