The last Replicant release is still based on Android 6.0.
In the previous years, a lot of work was done to make the Galaxy SIII (GT-I9300) usable with an upstream kernel, both on graphics and on the modem.
While working on this report we also found that the removal of 3G networks was more a serious problem than we originally understood.
As we understand from the Wikipedia article on 2G, GSM networks are also being removed in Europe as well (where most Replicant users probably reside). If somehow we understood it wrong please contact us on the Replicant mailing list as this has big implications for Replicant.
This means that none of the currently supported devices will continue to work on non-community networks in most areas of the world.
About a year ago, the current Replicant maintainer talked with someone that knows well European regulations and that person told him that there was no chance to stop 3G from being removed (for instance through legal activism) due to the low number of users still using 3G. Since we didn't ask about GSM at the time, we have no idea if that can be blocked or not or how much effort that requires.
In any case it means that the only way forward for Replicant is to make sure it (also) supports devices that work on 4G networks.
Furthermore such devices should also have VoLTE (Voice over 4G networks) ; otherwise, although they would be able to get Internet over 4G networks, they could not to make regular calls or send SMS.
Unfortunately even the Galaxy SIII 4G (GT-I9305) which is a Galaxy SIII (GT-I9300) with a different modem doesn't support VoLTE. So we cannot reuse most of the Replicant work we did.
Even if in some areas of the world (like some European countries), the devices currently supported will continue to work for very few years, and there was a big amount of work done to make these devices usable with more recent Android versions, a lot more work is needed to make that work usable daily (making power management work, debugging complex issues, etc).
The majority of recent devices (like newer Samsung smartphones) have too many freedom issues, making them unsuitable for Replicant.
Remains the PinePhone:
The hardware already works under GNU/Linux.
The battery life (in hours) is now almost good enough. Furthermore, it is possible to buy an additional keyboard that has a builtin battery to extend it more.
There is an Android distribution (GloDroid) that supports the PinePhone. It has some usability issues that need to be fixed: modem disappearing on some models, no cellular data, no modem isolation, etc.
The PinePhone Pro and Librem 5 could also be supported but they are not high priority right now due to incomplete power management (PinePhone Pro) and high cost (Librem 5).
In light of this, the current Replicant maintainer applied for funding through NLnet (again) to fix some of the PinePhone's issues and support it in Replicant. This application was accepted but he ended up being sidetracked by another project instead of working on that.
He got involved in what became GNU Boot and planned to have the project in good state by the end of the last summer, in the hope the work could be reused to ship a bootloader for the PinePhone in the next Replicant version.
See the GNU Boot 0.1 RC3 announcement and the NLnet funding application for more details.
Unfortunately the work on GNU Boot took way longer than anticipated, being unfinished yet. Because of that the work on the PinePhone didn't even start.
In addition to that, the main Replicant maintainer was also demotivated (he did a lot of work that turned out not to be that useful) and he thought that the project was poorly managed by him. He was trying to understand what went wrong and how to fix it. Going to the 37C3 to find help was part of the fixing plan.
Discussions between GNUtoo, dllud (both Replicant contributors) and several people we met during the 37C3 or on the train going to it converged to the same points and together we identified several issues:
A diversity of profiles helps solving issues and not be stuck. It also helps keeping the motivation as different people are good in different areas and thus people can more easily work on what they are good at and like to work on.
We cannot expect a single person to take care of the community, help new contributors, handle project management, keep relationships with other communities, keep track of what work is getting done elsewhere to improve collaboration, manage the infrastructure (servers) and modernize it a bit, and at the same time work on the code towards new releases. So far the current maintainer has been switching from a set of tasks to another but that didn't really work out.
It requires computers that are not commonly available among people: to build Replicant you need a lot of free space (200+ GiB), a fast internet connection to download more than 50 GiB, 32 GiB of RAM or more (for recent Android versions), and sometimes run specific versions of distributions.
It requires specific hardware like a Galaxy SIII (GT-I9300). People can't help with commonly available emulators or single board computers.
There is extensive documentation but it's scattered around. Documentation is also lacking for the tasks that are the most important for Replicant (porting Replicant to newer Android versions). Though we can also have people helping new contributors again to compensate for documentation issues.
We have a list of tasks and required skills for them but we lack information about the importance of the tasks. We also need to organize a bit how to assign tasks to people according to their skills and will. We were also advised to break the important tasks in more details.
Write this report: As we were not always discussing with the same people at the conference this should help us share information between ourselves and also with all the people that helped Replicant at the conference, to better organize the next steps.
Setup a Replicant meeting online at a fixed time, on IRC/Big blue button/Jitsi/Mumble. If new people come we would do a short introduction and people would present themselves (especially what they are interested in).
Re-run the call for the Community Manager. We will run almost the same call as before so the work will be less than last time. We will be looking for a candidate that can do a subset of the tasks in the call. As we were told multiple times that "Community Manager" was not describing the job well, we are also looking for a better term but so far no one found one that would feel right.
Amend the NLnet proposal to include GNU Boot work as well to solve our dilemma.
Find a way to get a build server. A KGPE-D16 would be a good idea. The FSF can probably buy it and host it for us.
Work on the PinePhone (and on GNU Boot as well).
While discussing with NLnet we were also told that it might be useful to collaborate more with DivestOS as part of our goals are similar. So we will need to evaluate again if there is enough proximity in our code to collaborate.
In the past people from DivestOS were really helpful as they found nonfree software inside Replicant and reported it to us.
Apart from that we don't have long term plans yet. Once we have a Replicant release that supports the PinePhone, we will need to decide where to go next.
For instance we could support more devices, reduce the amount of work for adding support for newer Android versions, reduce the differences between GNU/Linux and Android, or simply keep Replicant up to date by supporting more recent Android versions with minimal work.
Right now we also didn't spend much of the Replicant money and beside paying for a "Community Manager" we don't have precise plans yet.
We have about $200 000 and so far we relied on funding from NLnet to bring Replicant back on track as it was easier not to mess up this way.
Money goes away fast and spending it all in the wrong direction would prevent Replicant from using it to become more sustainable. Very few projects have an opportunity to use money to grow or achieve more.
Instead most of the ones that want to grow and become (bigger) non-profits are stuck in a chicken and egg issue as they need more money (that they don't have) to achieve more, which in turn leads to a greater need for donations.
As such, getting the project back on track before even starting to evaluate how to use the money to do big changes to the project seems a good idea, as many projects were destroyed after getting too much money and failing to properly use it.
One person also told us that businesses have interesting methodologies like "tracer bullets" in Agile methodology, or "Business model canvas" or some emotional approaches to tasks that might be worth looking at as they can work for non-commercial projects as well and can be adapted to a wide variety of cases.
One of the people we talked to insisted on the importance of finding a good team and finding ways to divide tasks between people. For that person it was also important to find people that could work well together and that agreed on the same goal (to avoid infightings).
We could also delegate more sysadmin work to the FSF: It would require less time from our side without compromising on freedom and with minimal extra work for the FSF sysadmins if we don't require custom things.
We were also warned that delegating tasks among ourselves still require time to organize. According to that person, in many cases if a person delegates a task, only 50% of the time is saved.
The main advantage of Replicant over other GNU/Linux distributions certified by the FSF is that it can run Android applications, but that is only relevant if there are 100% free software Android applications.
Somewhat recently we found out that it was no longer possible to know if Android applications shipped by F-Droid are really free, as F-Droid now uses the nonfree Google SDK to build the applications. As such we don't know if they build with another SDK on FSF certified GNU/Linux distributions. We want to help fix that to make sure the solution really suits our needs.
If there were fully free drop-in replacement SDKs that also build on a 100% free distributions, that issue could be fixed for both F-Droid and Replicant. F-Droid may have further requirements as they probably have higher security demands than Replicant. For instance, they probably won't like to depend on the (free software) binaries shipped in the SDK source code that are used to build it, and would rather build everything from source.
In the times of Replicant 4.2 (based on Android 4.2) Replicant produced its own SDK. After that several GNU/Linux distributions (Debian and some Debian derivatives) started shipping a fully free SDK for Android 6.0 so Replicant stopped producing newer SDKs.
Nowadays Debian and PureOS still package an Android 6.0 SDK but don't support more recent versions of Android. They also don't support the NDK that supports languages like C. F-Droid probably used these SDKs for a while, specially because they are completely built from source from well known distribution(s), but many Android applications don't build anymore with these old SDKs.
After that, free SDKs for various Android versions started being released at https://android-rebuilds.beuc.net, but the main author of this work at some point moved on.
After that several people tried to continue that work somehow and published source code that can build SDKs but none published the SDK binaries.
In the GNU 40 conference in Switzerland, the current Replicant maintainer met the person behind SDK rebuilds (beuc.net) and also someone interested in giving resources (like server space) to build an SDK.
In the 37C3 we met additional people:
Starfish, that wrote potentially 100% free Android applications and that also publishes source code to build a free Android SDK. His applications build with this free SDK.
Starfish doesn't publish binaries in order to avoid dealing with license compliance in case something is wrong in the SDK binaries. Replicant is happy to do that.
Starfish can also accept contributions and bug reports for supporting FSF certified GNU/Linux distributions and for removing nonfree software from the SDK if any if found.
As a bonus we also reviewed the applications that Starfish wrote so if the SDK works on 100% free distributions we'll also have 100% free applications to promote to people without any freedom caveats.
Another person (wizzard) jumped in to automatize the builds, making them run unattended on each new release.
So thanks to all these people everything is now in motion to get the SDK problem fixed once for good and in a better way than before: one that makes sure people can actually build Android applications with 100% free software.
At the 37C3 we managed to understand Replicant issues and a way forward probably because we started discussing the project issues in advance, which allowed just enough understanding to be able to ask for help. If we didn't do that we probably would not have managed to get help that is that useful.
While we (GNUtoo, dllud, and the people that helped us) did a lot at the congress (and even too much since we missed our own lightning talk due to too much cognitive load) at the end we managed to achieve the most important goal: finding a path forward for Replicant.
Alongside our main goal of putting the project back on track, we found time to host a variety of talks and events:
We had an official Replicant assembly where people could meet us.
We did a presentation named Smartphones freedom status in 2023 which looked at smartphone hardware and operating systems available in 2023. It wasn't recorded. The slides are available as PDF and source code.
At the end of the presentation, after the questions, we also got some feedback:
We were told that there are more applications for GNU/Linux that work on smartphones than what we assumed. They are referenced in https://linuxphoneapps.org and they also list applications available in PureOS landing (a rolling release version of PureOS) and Guix. Still they probably have less applications available than on F-Droid but things are progressing in the right direction.
We also did a talk presenting the Replicant as part of the Critical Decentralization Cluster. Unfortunately it wasn't recorded due to a technical issue, but we re-did it again the day after on a longer format. The slides source code and PDF are available.
We did a presentation on the status of Replicant. It wasn't recorded so if you want to know what was said, the slides are available, but you also need to read the presentation.txt to understand it.
As a follow up to the presentation on the status of Replicant, we also had a meetup on the last day where we had discussions with the people attending the talk.
We met someone repurposing smartphones who told us that on some Samsung smartphones/tablets, erasing the PARAM partition (with dd if=/dev/zero) sometimes removes restrictions that prevent the phone from booting custom distributions.
Among those helping us, there was someone interested in using Replicant for education. The most problematic issue found is that the current requirements to work on Replicant are too much for students. Supporting single board computers or emulators would be a first step to help here. In general this would help finding new contributors.
The main maintainer of Replicant had already planned to go to an event of OFFDEM (an alternative conference to FOSDEM) on Friday night, and also to FOSDEM 2024 on Saturday and Sunday. Train tickets were already bought before Replicant took the decision to go to the 37C3, so he kept the plan.
As expected it was not as useful as the 37C3 for Replicant (it was way more useful for GNU Boot) but still some interesting things happened:
He met Hans-Christoph Steiner from F-Droid and explained the status on having a fully free Android SDK. He detailed our work to provide binaries by setting up an automated build system that reuses the maintained scripts to build the SDK and that runs on a FSF certified distribution (Trisquel) to make this solution also work for Replicant.
He was introduced to people working on CalyxOS by Michiel from NLnet.
Before that he thought that CalyxOS was deeply problematic because even if on paper CalyxOS had the same freedoms as LineageOS, its security system removed users control of the devices (users don't have root, etc) and didn't have access to their data.
But in reality CalyxOS uses SeedVault, a backup application that enables users to backup their data and restore it on any other distribution that may not have the same security model. SeedVault is also used by most Android distributions. It is therefore a good idea to see how it can be integrated into Replicant, as it seems to be made with user's empowerment in mind. It can backup data (encrypted) to an USB key, so users don't need a server or external services.
In addition he was told by a CalyxOS contributor that it is relatively simple for users to build CalyxOS with their own keys, and so be in full control of the device.
He was also told that newer Android versions don't need F-Droid privilege extension anymore due to the inclusion of an API for stores inside recent Android versions (thanks to some European regulations).
He met someone who is working on understanding the European regulations that aim to standardize digital identity papers and the way to store it. He already met that person at the 37C3 but this time there was more understanding and more time to discuss the issue more in depth. The regulation has requirements for smartphones so it will most likely affect smartphones distributions that use free software drivers (like Replicant, various GNU/Linux distributions, etc.). If done wrong, it would prevent free software users from storing their identity papers in their smartphones with free software (for instance because it could be stored "securely" in areas of the phone inaccessible to users and free software). One of the issue is that this person looks for help to understand the technical parts, and also for some associations to help in the fight to modify the laws to fit free software. Since Replicant has very little time to look at this now, he referred her to the Osmocom project that already analyzes somewhat similar designs like eSIM.
He also met with Tiberiu from Technoethical, a shop that sells FSF certified hardware and Replicant compatible smartphones (that aren't certified by the FSF due to nonfree bootloaders and other issues). Technoethical will be negatively affected by Replicant's decision to drop support for the current Samsung phones in future versions, as PinePhone will become the major focus.
The main maintainer of Replicant also met with Paul Kocialkowski. Before that meeting he thought that on GNU/Linux the eg25-manager program for the PinePhone only did simple things like setting up udev rules and had simple hacks to make the modem work fine. He thought that all stability issues were to be handled by Modem Manager. However the EC 25 Manager may also be monitoring the modem and restarting it when it crashes. This could explain modem stability issues with Android/GloDroid on PinePhones with 3GiB of RAM. The fix may be to port/reimplement that feature to make this model usable.