On the 1st and 2nd of February 2020, 4 Replicant contributors (FilBerg, GNUtoo, GrimKriegor and dllud) attended FOSDEM 2020 in Brussels.
FOSDEM (Free and Open source Software Developers' European Meeting) is an annual conference organized by volunteers, to enable users and contributors to meet and promote the widespread use of free and open source software. This helps communities take decisions and also enables various communities and people to collaborate together.
Part of this comes from FOSDEM allowing projects to book rooms in order to have meetings and presentations (dubbed as a BoF, Birds of a Feather). Replicant contributors held such a BoF, and also gave a talk at another room and wandered around the exhibition's rooms talking to people at the stands of relevant projects.
As it is a conference, the FOSDEM also features talks by various members and contributors of the free software and open source communities which range across many different projects and areas. Listening to the talks (which are often recorded as well) is a way to get the latest news of what's happening in the free software world.
This is a (late, sorry for that) report with the relevant information that Replicant contributors leaned during the event, alongside with a summary of the discussions that took place during the BoF. This report is published both here in the blog and in the mailing list. Comments are gladly welcomed on both mediums.
Technoethical is a store that sells devices pre-installed withofficial versions of Replicant and also Replicant merchandise. It is featured at Replicant's website and donates a percentage of its sales to Replicant.
We went to the Technoethical stand to discuss the idea of only requiring a percentage of the sales for bigger companies, which wouldn't include Technoethical. According to Tiberiu from Technoethical, Technoethical didn't agree toformally give any percentages of the sales to Replicant, but they instead do it voluntarily.
We had a discussion with someone involved in Wikidata about how to describe hardware like smartphones in Wikidata.
For instance there is an entry for Replicant in Wikidata, and we want to be able to more precisely express that a given software, like Replicant 6.0 0004, or the Lima Linux driver, is compatible with a given smartphone or GPU.
Right now this seems to be done through the Platform property. Unfortunately, this property by itself cannot tell precisely which version of Replicant is compatible with say the Galaxy Nexus (GT-I9250). We were told to look into the qualifier to see if we can find a way to express that.
After looking at it we found that it's possible to add a platform qualifier for a given version, for instance to tell that Replicant 6.0 is compatible with the Galaxy SII (GT-I9100). However, after this, it is not possible to add an extra layer of qualifiers to tell for instance that the Galaxy SIII 4G (GT-I9305) is compatible with Replicant 6.0 except for its modem.
The goal here is to be able to use Wikidata as a database for storing information about hardware and software. This way we could reuse that information easily in various tools and/or in MediaWiki after having migrated to it. We already have a very rough tool to experiment with that and print some information about Replicant versions and the devices they support.
Like last year we also had a Replicant BoF this year.
This year we improved the organization of the Replicant BoF:
Most of the people in the room seemed really engaged and interested in it, whereas last year we got the impressions that people were less engaged and interested.
While things were more organized than last year we still need to improve on it. For instance we lacked a precise schedule for the BoF in order to properly cover all the topics we needed to. The consequence is that we usually try to rush at the end in order to cover some topics we didn't have covered yet.
We also had the ability to remotely listen to the BoF through Mumble and participate through IRC. At the beginning we tried a setup that was too complex, with speakers, to enable remote participants to speak. This setup took too much time, so when enough people were in the room, we started without that and fell back on IRC for participation instead. As we were late to start, and were rushing to make the more complex setup work, we also forgot to record the meeting.
Properly organizing a BoF is not that easy as we typically are short on time and also need to organize many other things in parallel such as the talks we give in other rooms.
For next year, we need to decide on weather or not we could fund or reimburse travel costs for someone from the Replicant community, like Kurtis Hanna, that has a deep enough knowledge of what is going on in Replicant, to help us with the organization of the BoF.
During the BoF, we did a quick presentation of the issues we were having with the Android build system. More details on the issues are available on the “Android's build system is messier than your distro's” talk that was presented at 36C3.
We also did a quick presentation of the freedom issues we were having with WebView. As with the build system, more details are also available in a presentation (“The Chromium mess meets Android”) that was held at 36C3.
We then got questions and ideas on how to solve that issue.
One of the ideas was to go for the lowest hanging fruit and implement the easiest part of the WebView API with GeckoView, which should suffice for some applications.
Once this is done we would still have the problem of making the F-Droid applications use it: the application developers will probably not include GeckoView in their applications as it would increase the size of the package by around 20M (which is a lot).
But even if they do, it would still be an issue as each package using WebView (and there are many) would have its own GeckoView, which would probably increase RAM consumption.
There are kernel features like CONFIG_KSM
which reduce the RAM usage by
finding duplicate regions and making the duplicated pages point to the same
region until the data is modified. However, this may not be a proper solution,
especially if the GeckoView builds shipped with each app are not exactly the
same. It may also increase CPU consumption as CONFIG_KSM
has to scan the RAM
for duplicated pages.
Several solutions were proposed by Replicant contributors and people attending the BoF:
Make Replicant ship a GeckoView that is ABI compatible with WebView (even if not all of the WebView is implemented).
Use F-Droid to build and distribute GeckoView.
Develop software that would automatically recompile all the F-Droid applications that link against WebView to link against GeckoView instead, and automatically publish the result in a dedicated F-Droid repository.
Applications could potentially be tagged with supporting or not supporting a given incomplete WebView implementation implemented through GeckoView.
Replicant only wants to supports devices that reduce the amount of harm for users freedom, privacy and security. For instance all device supported by Replicant 6.0 and onward have some form of modem isolation.
However some people might still want to support devices that attack users freedom, privacy, and security more than the ones already supported by the current Replicant release. So we explained that while such devices could not be supported by Replicant, the Replicant project is open to collaboration with other projects like LineageOS to add support for such devices.
This is relevant to Replicant because Replicant 9 uses a Linux kernel that has very few patches on top of the upstream Linux. So while Replicant 9 is not ready yet, when it will be, most of the Replicant 9 code will probably be reused to support smartphones and tablets that have good support in upstream Linux. So, even if for smartphones with different modems, more work would be needed to support the modem, there will probably be some people interested in reusing the Replicant 9 code.
This means that we would need to work with other upstreams to find the best ways to deal with it and share the maintenance of the code. Unfortunately there weren't any contributors from other Android distribution in the room.
As ChronoMonochrome is also working on porting the Galaxy SIII to LineageOS, we collaborated together when it was possible, as we were both trying different approaches.
On Replicant 9 we were focusing more on the 2D graphics, and on the modem, which doesn't work yet with LineageOS.
Once we have something usable on Replicant 9, it would also be very interesting to find time to work on upstreaming the modem driver as well:
In several cases the kernel maintainers refused patches for drivers lacking free software userspace for using them.
As Replicant has a free software implementation, it shouldn't be a problem.
Similar modems are already supported by the Linux kernel, like the N900 modem, but the kernel interface is different from the one exposed by the kernel shipped by Samsung.
As LineageOS functional requirements to support a device are more strict than Replicant, if the Galaxy SIII modem driver is merged upstream, and LineageOs wants to use libsamsung-ipc (and libsamsung-ril) to use that driver, they would probably have some interest in helping to complete the libsamsung-ipc implementation as well.
We have already removed F-Droid from Replicant 6.0 after the 0003 version. This is due to the F-Droid repository not being compliant with the Free System Distributions Guidelines, because of applications like Yalp.
If there were no means for users to collaborate on workarounds, each user would need to review by themselves each application they are considering to install.
So we created the F-DroidAndApplications wiki page to share the work on reviewing F-Droid applications that meet or don't meet the Free System Distributions Guidelines.
We started reviewing some applications. Unfortunately, even when the source code should be fully free, we are not sure if the resulting builds meet the guidelines, as we would need to make sure that it's possible to compile the same application with a distribution that meets the FSDG guidelines.
We need to look more into it and/or to write to the licensing team at the FSF.
We briefly talked about the rationale of migrating the wiki from Redmine to MediaWiki. The main advantage is that it will avoid duplication of information. For instance, the fact that the Galaxy SIII has a MAX6673 chip is mentioned in many different wiki pages such as:
This happens because that chip is involved in many different things, ranging from power management to managing the switch behind the USB connector which enables to get access to the serial port.
It is therefore relevant to know about that chip in many different contexts.
MediaWiki has ways to avoid the duplication of some information through templates, and it's also possible to interface it with Wikidata in various ways.
Someone mentioned that Sphinx handles such requirements. However, as not everyone that contributes to the wiki knows how to program, and as the contributions of such people are quite substantial (many edits, creation of pages, etc), and that we do want to enable people not knowing programming to edit the wiki, we will probably consider switching to MediaWiki instead of tools like Sphinx.
Someone pointed out that upstream Android continuously gets security updates. To keep up with that, we would need to do Replicant 9 releases very often.
While some people pointed issues with rebasing our work, it's probably still achievable to do that, as porting our work forward from Android 9 to the next Android versions is supposed to be easier.
Someone also pointed out that, for a given Android version, LineageOS was backporting security fixes longer than the Android Open Source Project (AOSP).
This information made us reconsider some design choices in Replicant: once Replicant 9 has been released, the fact that LineageOS doesn't have stable tags for releases becomes less relevant as we will need to find ways to rebase and release often, in order to have the latest security fixes.
Someone mentioned that the Vulkan graphics API will become mandatory after Android 10. This would mean that the graphics stack we're developing for Replicant 9 would no longer suffice. Both Lima, the free software driver for the Mali GPU present on the Galaxy SIII (GT-I9300), and llvmpipe, the software rasterizer planned to be used as fallback on all other devices, only support OpenGL ES.
A possible workaround would be switching the fallback software rasterizer from llvmpipe to SwiftShader, or using it just for apps that need Vulkan support. We are actively making sure that SwiftShader works on Replicant 9, therefore this should be doable without much effort.
Note: someone suggested using a translation layer that runs Vulkan on top of OpenGL ES, but that does not exist and probably never will. Vulkan is a lower-level API than OpenGL, with finer-grained control of the GPU memory and likes, making it really hard to implement OpenGL on top of it.
A nice tip we got is to keep using a compositor (SurfaceFlinger) that works with OpenGL ES. Current SurfaceFlinger still doesn't have Vulkan support. Acceleration is still done through OpenGL ES or an hardware composer. As such, compositor performance and compatibility won't bean issue for the time being.
We found that Fil Bergamo, who is part of the Replicant Steering Committee, didn't receive emails from the Replicant contact address.
We need to setup a new email infrastructure in order to properly address this issue. Currently the contact address is hosted at PaulK's personal email server. Paul no longer has time to maintain it and thus we must transition to a new server, hosted in a VM at the FSF servers, that can be administered by several Replicant contributors, in order to avoid a single point of failure.
The FSFE is helping NLnet by giving legal advice to the people beingfunded by NLnet to work on free software.
After the Replicant BoF, we met Lucas Lasota from the FSFE who offered legal advice, probably through the ifrOSS institute, to the people being funded by NLnet to work on Replicant (or the Replicantproject at large?).
The Replicant project is already getting legal advice through the FSF, and the FSF also has a very big expertise on compliance with certifications like the Free Software Distribution Guidelines, but the FSFE legal team and/or ifrOSS legal team probably also have some very interesting knowledge about European law.
For instance Till Jaeger who is/was involved in the ifrOSS institute made a very interesting talk years ago on what constituted derivative work under the European laws and directives.
After the the Replicant BoF, we discussed a bit with someone from Necuno. They were supposed to make a device that could be used with only free software. The hardware only had the following issues:
On the I.MX6 System-On-a-Chip they chose, the firmware for the audio/video decoding offload is nonfree, but in many cases that can simply be ignored as that kind of thing is done by default on the main CPU.
The I.MX6 DMA engine probably had a nonfree firmware but it was completely optional, as the Linux kernel knows how to use the builtin DMA engine ROM instead.
So the device would have been completely usable with fully free software. They also stated in several places on their website that it would have been possible to run fully free software on the device.
This was also made possible because the device wasn't a smartphone and would not have any modem or WiFi chip.
But they are now are planning to add a WiFi chip, and to ourknowledge, all the WiFi chips made for smartphones and tablets require a nonfree firmware.
While Replicant is not redistributing any nonfree software, it still loads the modem firmware into the modem. In addition, all the devices currently supported have many more freedom issues, from forcing users to run nonfree software at boot, to having their location tracked by the network, at all times, with a precision of 10 or 20 meters.
In the long run, for the WiFi firmwares, it would be a good idea to have people working to get free WiFi firmwares and really solve the issue for good, instead of finding workarounds that don't solve the problem.
In the mean time, the workarounds still have the benefit of making clear what is free software and what is not; this clear separation enables us to claim at the same time that Replicant itself is fully free software while the devices it currently supports do not respect users freedom, and do run nonfree software as well.
Necunos also told us that they had some underlying issues because their devices would be “dual use” devices. This is related to the fact that they are also targeting some markets like the Finish defense or secret services, but we didn't understood what it meant practically speaking.
We discussed with Michiel from NLnet the issues we were having with the Android build system. He pointed again to us that NixOS is working on being able to build Android components.
At some point we would need to look more into it as we want to mix Android and GNU/Linux components together. If we want Replicant to scale and be able to support more devices, it would be a good idea to be able to reuse some GNU/Linux userspace components that make hardware work, like oFono, BlueZ, etc. This would also allow us to share more work with GNU/Linux.
There are more details on the Replicant wiki about issues GNU/Linux distributions are having for packaging Android components like adb, which depend on the Android build system and libc.
On the last day we also met someone from Maemo Leste. At first when hearing of Maemo Leste, we feared that nonfree components from Maemo would be reused, as Maemo had a lot of nonfree components. However, according to the people we met, only the free software ones werere used. Still, nonfree software not coming from Maemo, like thenonfree WiFi firmwares or nonfree GPU drivers for some phones, were still used.
We also saw Maemo Leste on a PinePhone. On this device, the graphics stack was using the free software Lima driver and the graphics were fast enough. We can't remember if Lima was stable enough for daily use but it looks really promising at least, because the whole graphical interface used it, and we saw no rendering artifacts while briefly testing it.
GitLab was first built upon a framework that did most of the work on the server side, but at some point they switched to a framework thatdoes client- side rendering with JavaScript.
As we had an opportunity to talk with people from the GitLab team, weasked them whether they would be open to accept patches that fix this. They explained us that such would require to double the UI work for everything, but that it might be possible to do server side rendering with the same JavaScript that's used on the client. The issue is that it cannot make requests from buttons like that, so in addition to the page rendering that could happen through server-side JavaScript, introspection could be used to rewrite the buttons.
In Paris (France), last year, batteries for phones compatible with Replicant could easily be found in second hand shops, and in a chain of shops specialized in replacement batteries. But we got a more recent report that it was not the case in similar shops in a smaller city.
This talk was held at the Hardware Enablement devroom.
It quickly introduced Replicant and the smartphones ecosystem, and then proceed to look at what affects smartphones' and tablets' lifetime and how to increase it by making Replicant more sustainable.
There was also a small, satirical play in the middle this talk. Its goal was to show how the current market trends in smartphone design and construction severely impair those that look for privacy, software freedom, and reduction of electronic waste.
Video and slides are available at the talk's page in FOSDEM's website.
Fil Bergamo started making a song about Replicant.
If you enjoyed reading this report, you may wish to take a look at the reports from previous conferences that were (only) published on the mailing list:
There's also a wiki page that lists all talks about Replicant that happened in several conferences throughout the years.
Edit1: Fixed “ssupported” typo
Edit2: Fixed the “onthe” typo
GNUtoo and dllud