Why we applied for NLnet funding

As you probably know already, since several years already, none of the smartphones currently supported by LineageOS could easily be supported in future versions of Replicant without ruinous compromises.

This is because to officially support a device in Replicant, we need it to:

• Have a removable battery if it’s a smartphone (users should be able to swap batteries while walking), or a replaceable battery if it’s a Tablet (the tablet might be harder to open than the phone, but the battery should still be replaceable at home).

• Have an isolated modem.

• Not require any additional nonfree software either to install Replicant or to make Replicant work on the phone.

And while nowadays there are some devices supported by the latest version of LineageOS, that also support 5G networks, and that have removable batteries (like the Fairphones or the SHIFT6mq), making sure that the modem is isolated probably require too much work.

This looks doable in theory as there is some special hardware that is called IOMMU that can isolate the modem on modern smartphones. However this IOMMU needs to be configured properly and be active when the modem is powered on.

Since the configuration is not always easy to do or check, we would also need to rely on a community with expertise in this area, that is able to fix issues without relying on the hardware vendors, like the Linux kernel community. This would mean that the kernel we use would need to be based on upstream Linux, and as of today, this still requires more work than we did so far.

In addition, the smartphones currently supported by LineageOS all have long a list of nonfree software required to work, so the risk that we end up not finding a way to replace or avoid one of the nonfree firmware is higher than it was in the past.

So we came up with alternative plans. The first one was to add support for the Galaxy SIII in upstream Linux since a lot of the work was already done, people already had it, and that power management could work since it worked in Replicant 6.0 already.

Retrospectively a lot of work also remained and we didn’t manage to finish it all, and we also failed to predict that the removal of 2G and 3G networks was going to happen so soon in Europe.

So we subsequently came up with a second plan: add support for the PinePhone (which supports 4G networks) instead, by reusing GloDroid, adding modem isolation, fixing usability issues, etc. How this plan turned out will be addressed in a subsequent blog post.

All these plans required a lot of work, and so funding was the natural way to be able to do it.

While the Replicant project has some money and in theory can use it to pay for development, we went to use the NLnet grants instead.

This is because to use Replicant’s money we need to structure a bit better the project and the Replicant steering committee needs to decide how to spend the money: how do we verify that the work is done, what kind of work do we fund, etc. All that requires time and discussions.

What we know about NGI / NLnet

External funding often have conditions attached, and people or organizations who fund work typically have their own goals as well.

Since the NLnet conditions were really aligned with the Replicant project goals (release the work under free license, one time work with long term effects, upstream / reusability focus, etc) we applied twice for funding.

This also allowed us to spend Replicant’s money on things NLnet would not be able to pay for (like hiring a manager to help structure the Replicant project and do things the developers can’t do because they are too busy).

We had first hand experience with how funding from NLnet worked and to our knowledge the way it worked was really suited to free software, and we also discussed with people working at NLnet during various events so we could grasp a bit how it worked from within.

The way the funds were handled also enabled people with very diverse background to apply and get funded. For instance you didn’t need to setup a company, or even to have a stable home to live in for applying.

You could also apply for a small project that you do on the side and still have a regular job, or another occupation, etc. Some people also managed to get funding from NLnet and with the help of some non-profit still get a regular salary out of it.

It also didn’t discriminate people or projects with different political opinions and/or projects following these opinions as it funded sometimes people or projects with conflicting political opinions as long as the work is strategic for free software.

Once the work is done, NLnet verifies it and you get paid.

So while it didn’t work for all cases (that would be difficult to achieve) the way it worked enabled people that can’t use other existing funds to apply and in practice it managed to fund a lot of work .

This is also because the NLnet grant system was also designed to be extremely efficient: there was very few administrative overhead (for everybody involved). This was also made possible by relying on well established community practices and norms for accountability (the code is public, people do software releases, etc) and by getting help from people within the community that had very advanced knowledge on more specific areas of free software.

Being efficient is also important as this way we can fund more free software projects.

Origin of some of the funding NLnet manages

If you look at the list of projects being funded mentioned before the vast majority of them have “NGI” as the fund origin.

This is money that comes from the European Union as part of their Framework Programmes for Research and Technological Development program.

Our hypothesis is that funding free software makes sense for the European Union as in practice it makes alternatives to technological domination from foreign companies producing nonfree software more viable. This also develop technological and free software competence in the European Union which in turn also helps the local economy.

Given the current political context in the United States and the relationship of its executive government with some of the Tech Giants that produce nonfree software and/or software as a service substitute, free software can also be seen as a way to potentially resist pressure by such alliance by both states and people.

The effect of this funding is also that in practice it increase people’s freedom and autonomy, which also makes it easier to resist oppressive states.

Since free software does increase transparency, this can be beneficial to both states and people as it makes states more accountable and also prevent misinformation on what states actually do.

We have for instance an example with COVID Tracing Applications where people can actually understand what such applications really do, which in turn helps having an informed debate on what should be or have been done, and also provide information actionable information (should I install that application?).

While such funding, if kept, will probably not enable us to remove or replace all laws that are problematic for software freedom with ones that guarantee freedom (for instance banning DRMs, also known as Digital Restrictions Management, would be good, but this is probably outside of the scope of funding NLnet and people to work on free software), the fact that states fund socially useful work without too much strings attached and/or without being counter-productive is important as it can potentially help generalize this approach which is beneficial for everybody.

In contrast, going in the opposite direction will probably remove hope and in practice make the future look really bleak and violent as states that don’t serve their people bring dissent and repression, and if the repression is too violent, it ends up hurting everybody, including the very people that are involved in such repression (this has for instance been shown in the Truth Commission Special Report).

Replicant signing the Open Letter to the European Commission.

The open letter Replicant has signed was initially published in French by the Petites Singularités association , which is involved in the organization of the OFFDEM, a free software event around the FOSDEM.

The letter is under the Free Art License 1.3 and the rest of the this blog post is under either (at your choosing), the Free Art License 1.3, the Creative Commons BY 3.0 or the Creative Commons BY 4.0.

If you also want to sign this letter, you need to publish it on your website in your preferred language, then add yourself to this table .

This is why we also included the letter below.

We found the English translation of the letter on the blog of the postmarketOS project , who we also collaborated with as part of our first NLnet grand for our work on the Galaxy SIII (GT-I9300).

The “The European Union must keep funding free software.” letter

Open Letter to the European Commission.

Since 2020, Next Generation Internet ( NGI ) programmes, part of European Commission’s Horizon programme, fund free software in Europe using a cascade funding mechanism (see for example NLnet’s calls ). This year, according to the Horizon Europe working draft detailing funding programmes for 2025, we notice that Next Generation Internet is not mentioned any more as part of Cluster 4.

NGI programmes have shown their strength and importance to supporting the European software infrastructure, as a generic funding instrument to fund digital commons and ensure their long-term sustainability. We find this transformation incomprehensible, moreover when NGI has proven efficient and economical to support free software as a whole, from the smallest to the most established initiatives. This ecosystem diversity backs the strength of European technological innovation, and maintaining the NGI initiative to provide structural support to software projects at the heart of worldwide innovation is key to enforce the sovereignty of a European infrastructure. Contrary to common perception, technical innovations often originate from European rather than North American programming communities, and are mostly initiated by small-scaled organizations.

Previous Cluster 4 allocated 27 million euros to:

"Human centric Internet aligned with values and principles
commonly shared in Europe" ;

"A flourishing internet, based on common building blocks created
within NGI, that enables better control of our digital life" ;

"A structured ecosystem of talented contributors driving the
creation of new internet commons and the evolution of existing
internet commons".

In the name of these challenges, more than 500 projects received NGI funding in the first 5 years, backed by 18 organisations managing these European funding consortia.

NGI contributes to a vast ecosystem, as most of its budget is allocated to fund third parties by the means of open calls, to structure commons that cover the whole Internet scope – from hardware to application, operating systems, digital identities or data traffic supervision. This third-party funding is not renewed in the current program, leaving many projects short on resources for research and innovation in Europe.

Moreover, NGI allows exchanges and collaborations across all the Euro zone countries as well as “widening countries” 1, currently both a success and an ongoing progress, likewise the Erasmus programme before us. NGI also contributes to opening and supporting longer relationships than strict project funding does. It encourages implementing projects funded as pilots, backing collaboration, identification and reuse of common elements across projects, interoperability in identification systems and beyond, and setting up development models that mix diverse scales and types of European funding schemes.

While the USA, China or Russia deploy huge public and private resources to develop software and infrastructure that massively capture private consumer data, the EU can’t afford this renunciation. Free and open source software, as supported by NGI since 2020, is by design the opposite of potential vectors for foreign interference. It lets us keep our data local and favors a community-wide economy and know-how, while allowing an international collaboration. This is all the more essential in the current geopolitical context: the challenge of technological sovereignty is central, and free software allows addressing it while acting for peace and sovereignty in the digital world as a whole.

[1]As defined by Horizon Europe, widening Member States are Bulgaria, Croatia, Cyprus, Czechia, Estonia, Greece, Hungary, Latvia, Lituania, Malta, Poland, Portugal, Romania, Slovakia, and Slovenia. Widening associated countries (under condition of an association agreement) include Albania, Armenia, Bosnia, Feroe Islands, Georgia, Kosovo, Moldavia, Montenegro, Morocco, North Macedonia, Serbia, Tunisia, Turkeye, and Ukraine. Widening overseas regions are Guadeloupe, French Guyana, Martinique, Reunion Island, Mayotte, Saint-Martin, The Azores, Madeira, the Canary Islands.

Replicant current status:

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.

Identified issues:

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:

Replicant has not enough people:

• 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’s too difficult to contribute to Replicant:

• 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.

Plan forwards:

Very short terms plans:

• 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.

Medium term plans:

• 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).

Long term plans:

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.

Other advices for medium/long term:

• 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.

Other area of work:

Android SDK:

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.

Conferences:

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.

37C3 talks and interesting people:

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.

OFFDEM / FOSDEM 2024:

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.

Edits:

1. Refrased Technoethical paragraph.

Since yesterday, December 27th, the 37th Chaos Communication Congress (37C3) is taking place in Hamburg. Replicant is present as part of the Critical Decentralization Cluster (CDC).

Replicant’s assembly is the place to come by if need help installing Replicant or general advice regarding software freedom on smartphones and tablets. You can also take the opportunity to verify the release signing PGP.

Location: G5, Hall 3, Level 0
DECT: 8652

As Replicant is struggling with structural problems, first and foremost lack of contributors on key areas (development, sysadmining, communication, coordination, documentation), we are looking to onboard new people with fresh ideas. Please drop by if you feel keen to help on any of these field.

There will also be a few talks and gatherings about Replicant and related topics in several spots around the congress:

• Short introduction to Replicant as part of the CDC – December 27 16:30, Saal E
• Introduction to Replicant – December 28 10:00, Saal D
• Replicant struggle: past and present successes and failures – December 28 14:00, Saal 3, CDC, Round Table
• Smartphones freedom status in 2023 – December 30 12:30, Saal E
• Replicant Meetup – December 30 14:00, Saal 3, CDC, Round Table

This year the FOSDEM will take place in Brussels the 4 and 5 February.

This year there will be a talk about Guix evaluation and usage for/by the Replicant project: How Replicant, a 100% free software Android distribution, uses (or doesn’t use) Guix, by the current Replicant maintainer.

As not everybody is familiar with Replicant or free software on smartphones, it will also have some background information on hardware and software of freedom in smartphones with a focus on FSF certified distributions.

We hope to also use this occasion to build collaboration with other projects, especially other Android distributions that use kernels based on upstream Linux.

We may update this blog post if there are last minute changes (if the talk is moved) or if we have new interesting information (like interesting talk to attend, other events, etc).

Replicant 6.0 0004 is now officially released. If you want to upgrade from Replicant 6.0 version 0003 or earlier you need to follow the data migration procedure that is documented in the Release notes page on the Replicant wiki.

Even if we released the images back in January 2022, we didn’t announce it officially at the time because the data migration procedure wasn’t complete yet.

What is new in this release

Replicant is in the list of distributions that are recommended by the FSF. As such, Replicant needs to follow strict criteria that ensures that the distribution does its best not to violates its users’ freedom.

However fixing the issues and making new releases can sometime take a long time. The last Replicant 6.0 release was from December 2017.

This new release fixes some very serious freedom and privacy issues:

• We found an issue within the phone application: it was leaking the phone numbers of both inbound and outbound calls to third parties as part of a feature called phone lookup providers. More details are available in the bug report. Even if it was not trivial to reproduce and find the bug it’s now fixed as the feature has been completely disabled with 3 patches ([1], [2], [3]).
• F-Droid has been removed as many applications shipped in it are not compliant with the guidelines for distributions recommended by the FSF. It was kept so long because we expected to get it fixed upstream fast enough, but that didn’t happen for various reasons. We have setup a wiki page and a forum section for more information about the issue and how to deal with it.
• Several binary firmwares (without source code) related to the back and home “touch” buttons were found and removed with 4 patches ([1], [2], [3], [4]). The firmwares seem to have only been used for factory testing, so the buttons should still work on the devices that have them.
• The touchscreen firmware for the Galaxy Note 8.0 was also lacking any corresponding source code (bug #2194). That was fixed by removing it ([1]).
• On all the currently supported devices with a modem, when users set the device in flight mode, the modem is only asked to go in low power mode. Because of that the modem is probably still on and its OS is probably still running. Because of that we fixed the wiki and added scripts to disable (and enable back) the modem to the new Replicant images. They work by preventing Replicant to load the modem OS.
• We also got a report on the mailing list that a nonfree ambient SDK was added in CyanogenMod and was not removed either by LineageOS 13 or Replicant 6. So we removed it as well.

This release may also fix several bug(s) which made some SIM cards not recognizable by Replicant 6.0: we have now merged a fix for one of the bug (#1909) but as we don’t know if all the “SIM card not recognized” bugs are related. We would highly appreciate if those that opened the original bug report could confirm if it also fixes their issues as well.

Several issues still need to be fixed, but we didn’t want to delay even more this release, as that would prevent users from getting the fixes mentioned above:

• It’s still not possible to build Replicant 6.0 from a distribution that is recommended by the FSF (bug #1861).
• While removing the firmware of the Galaxy Note 8.0 touchscreen driver, many more firmwares without corresponding source code were found in the driver/touchscreen directory in the kernel used by most of the devices supported by Replicant 6.0. However they weren’t removed yet. Help is more than welcome to help with that.
• While investigating if it was possible to upgrade WebView, the Android builtin web browser component (bug #1786) we also discovered that, because Android build system doesn’t use a package manager, finding the license of each repository wasn’t trivial (bug #1973).
• More investigations are needed as well to replace WebView with a free software and up to date implementation (bug #1786).
• The bug related to a bad sound quality during calls in some circumstances (bug #1773) is not fixed yet, but there is a workaround that works for some use cases.
• The Let’s Encrypt certificates probably stopped working in Replicant 6.0 the first September 2021. Some browsers like IceCat should normally continue to work fine. See the Standing on Our Own Two Feet blog post by letsencrypt for more details.

As the internal WiFi doesn’t work with free software, some new network related features improving usability were merged :

• RepWiFi has been removed as it’s now possible to use the stock Android menus to handle the WiFi. This was done by patching Android to also accept external dongles. It is less reliable than with RepWiFi because in some cases reboots are needed for the WiFi to be recognized, and enabling the WiFi most probably also powers on the Internal WiFi chip as well, increasing the power consumption. However it should reduce the probability of applications like F-Droid being broken in the future, as it’s better integrated in Android. In the event that Replicant 6.0 stops being maintained and that Replicant 11 doesn’t get support for all the Replicant 6.0 devices, this patch should increase the lifetime of the affected devices.
• Ethernet support has been added but it doesn’t work on all the devices.
• The USB networking scripts were also been added to the devices.
• Support for some rt2500-usb dongles that don’t need the OS to load a firmware has been added to the Galaxy SIII 4G (i9305), which is an uncompleted device. It wasn’t added to the other devices to make the release happen a bit faster.

Other improvements were also made:

• llvmpipe is now the default OpenGL renderer. On devices with an Exynos CPU / System on a chip, this allows running many applications that weren’t working before. Unfortunately llvmpipe significantly slows down some system components used in the graphical interface. This has been catered for by patching Android to use the old libagl renderer for those system components.
• Scripts to switch between OpenGL implementations globally have been added to the image as well. Thus, if you want to revert back to the old behaviour, just run “graphics.sh faster” in a root terminal. To switch back to the new behavior you can instead use “graphics.sh compatible”. Note that “graphics.sh compatible” will still keep the old OpenGL implementation for the system components mentioned above, so there is little risk in trying the scripts.
• It’s now easier to build Replicant as there is a new script that wraps part of the building process. It’s also more convenient as it stores build logs. The script has been used to build the release, and the build instructions also use it now.
• It has became easier to modify the installation instructions as they now apply to all devices, and were split into parts that are reusable. This way if the instructions needs to be modified, it requires a single modification instead of 10 or 30 modifications like before.
• Instructions to backup the modem data partition have been added. The modem partition can become corrupted in some conditions. As it can be very difficult or impossible to recreate that partition, and that it’s required for the modem to work, we very strongly advise users to do a backup.
• A new wipe command has been added to wipe partitions, however it is not very well suited for wiping files. To efficiently wipe files another application or utility would need to be integrated.

Many of the improvements and fixes were also made possible thanks to the work of new contributors.

Replicant 11 status and policy changes for supported devices

Work on Replicant 9 has now shifted to Replicant 10 and then Replicant 11, and has been ongoing in parallel. As it will use a kernel closely based on upstream Linux, it has some implications:

• The work on Replicant 11 is made with the Galaxy SIII (i9300), so it should be supported.
• The Galaxy Note II (N7100) is very similar to the Galaxy SIII but requires a bit more work to be supported.
• The Galaxy SIII 4G (I9305) and Galaxy Note II 4G (N7105) could also be added if work is done to add support for their modem in Replicant.
• We don’t know yet how much work is needed to add support for the other devices that are currently supported by Replicant 6.0, so we don’t know yet if they will be compatible with Replicant 11 or not. We would need to find or get more information on the upstream status of theses devices before having a rough idea.
• It will be easier to add support for devices using a mainline kernel.

We also take advantage of this release to announce some policies changes:

• As Replicant 6 only supports devices with somewhat isolated modems, subsequent Replicant versions will also only support devices with isolated modems.
• As Replicant 6 only supports devices with replaceable batteries, subsequent Replicant versions will also only support devices with replaceable batteries.

The Replicant developers chose not to support these devices officially in Replicant for good reasons.

Supporting devices with non removable batteries ourselves has a lot of challenges:

• As Replicant 11 requires more work and working to upstream devices support in Linux takes more time than adding devices in Replicant 6:
  • if we start adding support for a device, we want to be able to spend the time required to do it right and to work with upstream projects like Linux to add support for it in theses projects as well. The advantage is that it makes Replicant and the device being added more sustainable. However if the device has a battery that is not replaceable by experienced users, developers, repair shops, or repair café, the device would have a very short lifetime which is incompatible with making Replicant sustainable.
  • Users would need to buy the device new in order to make sure that the battery lasts enough for a daily use. Buying the device second hand would be way more complicated as users would need to make sure that the battery last enough time. Developers would still be able to work on the device for a very long time, assuming that they are not users as well that want to use the device. But their work would not be very useful without usable devices.
  • In addition, being able to remove the battery of a device increase trust: for devices with a single battery, it’s easy to understand that without a battery, the device is really off. For devices with an additional backup battery, some background information on chip energy consumption is enough to understand what the device cannot do with such backup battery.

As for non isolated modems, if Replicant only support devices with isolated modems, it’s way easier for users and developers to remember that the devices they are using have a somewhat isolated modem.

However, as Replicant 11 is using a kernel closely based on upstream Linux, there is already some interest in adding support for devices already supported by Linux which have a non-isolated modem and/or a non-replaceable battery, and it would be sad to not be able to leverage all the work done in Replicant with these devices.

So practically speaking we are willing to help people and/or projects that are willing to support such devices. We are also accepting contributions in the Replicant source code for such devices provided that we can maintain the code without too much effort without having the devices.

So while anybody could test if the code still compiles fine, It will then be up to the people that have such devices to test if the code is still working over time. The code quality of such contributions may also have to be high as we want to keep maintaining that code over time without having the devices. The Linux kernel is already using a similar approach to be able to maintain support a lot of devices (including devices that the maintainers don’t have) without removing support for older devices.

We could even provide access to the Replicant infrastructure (for instance by creating Redmine sub-projects, opening new git repositories namespaces, and so on) to the people wanting to support such devices, but they would at least need to:

• Find a name that is different from Replicant for the project (to not confuse both projects, else it defeats the point of having some separation).
• Stay compatible with the strict FSF criteria as Replicant doesn’t want to host projects that are incompatible with such criteria. Though we already collaborate with other projects (which we don’t host) that aren’t compatible with such criteria.
• Take care of users support (as Replicant developers will probably not have these devices, so they won’t be able to test things to properly support users).
• Take care of the releases (as Replicant developers will probably not have these devices, they would not be able to test the releases).

As for the details on what constitute a “replaceable battery”, all the smartphones currently supported by Replicant 6.0 have removable batteries, so the batteries are very easy to replace. Compatible batteries can still be found in several cities and/or countries.

And for the tablets supported by Replicant 6.0:

• They all have batteries that are not removable in the usual meaning, but they can still be replaced by opening the device.
• It is easy enough for experienced users, developers, repair shops, and repair café to open the device and remove the battery, so it is probably possible to replace it as well.
• It would be interesting to know more about the availability of compatible batteries.
• It might also be possible to use tablets with batteries that last way less than when the device is new, as many people have them off most of the time. But even in that case it still shortens a lot the lifetime of the device, as they probably still needs a working battery to boot.

Over the years, none of the Replicant contributors have been able to find the time to add support for this chip,and at the time of writing this chip is still not supported by Replicant despite being relatively easy to add support for it compared with the Broadcom GPS chips that are present in the other supported devices.

Over time, contributions from other people and projects made it easier to add support for the GSD4t chip.

There is now some documentation of that protocol in the form of some Perl source that can probably decode the protocol, and there has also been some people doing research on it.

In addition it’s also easier to do some tests on GNU/Linux: there is now some support in upstream Linux for the Galaxy SII (GT-I9100) thanks to the postmarketOS contributor(s) who worked on that. The nonfree bootloader of the Galaxy SII (GT-I9100) might requires some patches on top of that, but we also maintain patches for the Galaxy SIII (GT-I9300 and GT-I9305) bootloaders in our kernel_replicant_linux repository that might also work on the Galaxy SII (GT-I9100).

The Replicant developers are mostly available on the Replicant mailing and on IRC (#replicant on the hackint, libera.chat and OFTC networks). See the CommunityAndContacts wiki page for more details.

As for how to integrate the work, we already have an example of GPS library that was used in Replicant 4.2 for the GTA04.

As postmarketOS is also interested in making this chip work with free software, it might be a good strategy to also consult them to see how that work could also benefit GNU/Linux distributions.

edit1: removed duplicated title.

License: CC-BY-SA 3.0 Unported