[Replicant] Community Meeting Report

Fil fil.bergamo at riseup.net
Fri Feb 22 22:04:31 UTC 2019

Hello everybody!

With considerable delay, for which I apologize, here's the report of the
Replicant Community Meeting, held at FOSDEM 19.

The report has been written by Fil Bergamo, with the help and
supervision of Denis "GNUtoo" Carikli.

Comments are welcome!



-------------- next part --------------
This is a report of the Replicant Community Meeting, held on the 3rd of February 2019, at FOSDEM

This is only a summarized report about topics that been discussed and proposals/statements that have been made by attendees.
This report has been written after the meeting, based on memory and quick notes. Because of this some part of the report might not be completely accurate.
Any technical and/or legal information contained here MUST NOT be considered necessarily true and MUST be independently verified.
Any opinion and/or general statement hereby reported IS NOT necessarily officially endorsed by the Replicant Project.
Any objection to the contents of this report and/or any request for clarification can be addressed to Replicant's public mailing list.

List of Proposed Topics before the meeting:

     1) Replicant Administration: need for additional official "executive" members besides GNUtoo and PaulK.
     2) Funds Management: how can funds be spent, can GNUtoo be paid to work on Replicant even if he's currently the only active "executive" member? (related to 1.)
     3) Task Priority: what are the most urgent tasks to be funded/worked out. (related to 2.)
     4) The F-Droid Free Software Distribution Guidelines (FSDG) Issue: how can Replicant keep being compliant with the Free Software Distribution Guidelines (FSDG) while still bundling F-Droid?
     5) Wiki and Documentation: how should we handle access to the official Wiki pages? How to implement a more convenient/more refined way for community members to contribute to the official Documentation?

Summary of the actual Meeting:

	Between 15 and 20 people attended the meeting (some left before the end, some arrived after the meeting had begun)
	Names of participants are not reported for privacy. Only the names of "public figures" such as John Sullivan and GNUtoo are reported, together with the names of people that explicitly agreed to be named.

	The meeting begins at 11:00 AM CET

	GNUtoo briefly explains the topics that need to be discussed.
	A short conversation takes place among some of the attendees about the topics listed by GNUtoo.

Questions addressed to John Sullivan (FSF):

	Q: Can the FSF take care of hiring contractors on behalf of Replicant?
	John Sullivan says it's probably possible. Replicant would have to write the text for an announcement and the FSF can take care of publishing it.

	Q: Could the FSF host a rack-sized build server for Replicant? Could the FSF also host a test infrastructure made of smart-phones and test equipment inside a rack?
	[background: Replicant could probably benefit from having a build server with high network bandwidth, in order to make building the whole tree faster and more convenient for developing/testing purposes]

	John Sullivan doesn't know the specifics of the hosting infrastructures. We would need to talk to the infrastructure team. It also depends on the FSF's technical capacity. It's preferable to send an email to sysadmin at fsf

	Q: Galaxy S3 with Uboot: there still needs to be a non-free bootloader (BL1) how to deal with it if we ever get to ship uboot for Replicant?

	[quick discussion about the issue]

	John Sullivan proposes solution that *may* work (depending on the exact details) is to keep the non-free bootloader where it is and patch it.
	This would be analogous to Trisquel that uses the non-free BIOS that is already in place.
	Tiberiu suggests we could just document how to patch the already-existing BL1 to change only the signature data (that is, no software would be shipped, just data)

	John Sullivan comments that documentation about proprietary BL1 can probably be treated like guides explaining how to install Free Software on Windows / how to install a Free Operating System alongside Windows / how to make a Trisquel Image on Windows, so that would probably be fine on the FSF side.

	Q: What are the legal bindings between the FSF and the official Replicant representatives?

	John Sullivan explains that the official representatives are currently PaulK and GNUtoo. They signed a legally-binding contract with the FSF, that regulates various aspects of the project, but mostly the focus is on how the money can be spent by the project. The official representatives have the right to decide when and how the funds collected by the project (via the FSF) can be used. Both representatives need to agree on these decisions.
	Need to check how the FSF-contract defines a way to remove or promote designated representatives but a general advice could be to vote about adding new people to the official representatives, document that on the official documentation, notify the FSF the new names. (PaulK and GNUtoo are currently the only ones that can vote so they should both vote to add new representatives)
	For funds to be given to contributors, they must present a proper invoice describing the work they have done.

	GNUtoo asks John Sullivan for a copy of the contract to be sent to him.

	A proposal arises from the discussion: make a community call for candidates to the "board of representatives".

	John Sullivan remarks that it is only up to Replicant as a project, the FSF doesn't require that. The only requirement on the FSF's side is to know the names of the official representatives, and that the official representatives approve the paid work.

The 2014-53-EU "radio lockdown" directive:

       	It can probably affect both Replicant as a project and vendors of Replicant-flashed phones.
	The directive requires that vendors of radio-enabled devices undertake "adequate measures" to prevent the end users from being able to modify the TX part of the device, including via software means. [NEEDS TO BE CHECKED]
	This puts Replicant potentially at risk because locking down devices is a bad case of reducing users' freedom, which is something Replicant fights against, and it cannot be enforced with free software by definition.
	If vendors of Replicant-flashed phones are forced to comply to the directive, they break Replicant's principles and possibly some of the licenses.
	If vendors are not allowed to sell "unlocked" Replicant-flashed phones, Replicant suffers a big loss of potential users which is very bad for the project.

	Somebody in the room explains that the directive is currently not enforceable, because it depends on a specific document to define the list of affected devices and the details of the requirements. The document hasn't been published yet.

	There is a public call for comments on the EC website

    	GNUtoo says Replicant should contribute, at least by signing a document/petition that complains about the potential effects of the directive,
    and if some people want to work on it, by sending comments in the related public consultations.

Task Priority:

	[Background facts:	
	- We got 200 000$ from Handshake
	- The FSF takes 10%
	- We had about 20 000$ of donations
	- That's a total of about 200 000$]

	GNUtoo explains the 3 tasks we applied for funding at the NLNET foundation:
	- Port Replicant to a newer Android version	  
	- Implement the missing features of Samsung-RIL
	- Graphic acceleration (Improve graphics speed without having to rely on the GPU, improve OpenGL (ES) completeness to improve application compatibility, and investigate free software GPU drivers)

	[References for the tasks:]

	There are severe issues that prevent Replicant to be used altogether, or at least make it very hard to depend on it: e.g. "Metallic sound when calling" and "SIM card not recognized".
	There is also the intention to work on a "Replicant 9.0" release. This could probably also fix some of the ongoing issues and can probably allow for Replicant to be built on an FSGD-compliant GNU/Linux distribution. It won't fix issues related to libsamsung-IPC/Samsung-RIL.
	Support for mainline Linux at least on i9300 and n7100 is another proposed task.

	Tiberiu remarks that in his opinion the severe usability issues should have the highest priority, because they render Replicant devices less usable as phones, as mobile networks upgrade worldwide, so that fixing those issue is more important than Replicant 9.0. In his opinion, part of the funds should be given to GNUtoo as soon as possible to allow him to start working on modem-related issues. Also, given that GNUtoo is already doing management work for the project, Tiberiu thinks he should be paid for that, so that he's not forced to leave the project to sustain himself.

Discussion about GNUtoo being paid to work on Replicant:

	GNUtoo prefers to have more official representatives first. This is for transparency so that there is at least one other person deciding about money, to avoid conflicting interests.
	Putti prefers to do the community call for candidate-representatives before allowing GNUtoo to be paid, and leave time to the broader community to possibly pose objections to candidates.
	Federico suggests that at least a clear schedule of when to start and when to end the consultation should be decided now.
	Putti calls the task upon himself. The call can be prepared during the upcoming week (4-8 Feb) and can be held during the following weekend(9-10 Feb).
	Tiberiu asks for PaulK and GNUtoo to both sign to approve GNUtoo's work before the community consultation, so that some of the money can be given and the work can begin immediately. Could start by paying GNUtoo for 4h/day for development and management work.
	Putti disagrees and remarks that we should at least discuss that on the mailing list before anybody gets any funding.
	Fil agrees with Putti. It seems hard to define an implicit consensus, so Fil proposes to vote by raising hands.
	The options are:
	1) Before funding GNUtoo: complete the community call for candidates to the "board of representatives", nominate the new representatives and leave time for possible objections to be raised.
	2) Allow GNUtoo to be funded immediately, before the nomination of new representatives completes.

	3x people raise their hand for option nr. 1.
	9x people raise their hand for option nr. 2.

F-Droid/FSDG issue:

	 Fil explains that Replicant is currently released with F-Droid pre-installed in official images. This poses some compliance issues with the Free Software Distribution Guidelines (FSDG) for Replicant, as the F-Droid repository also includes applications that (even if they are free themselves) are problematic to freedom. F-Droid marks applications that may bear undesired features with specific tags called "AntiFeature" warnings.

	 John Sullivan reads the list of "AntiFeatures" aloud and points out the specific "AntiFeatures" that are to be considered problematic from a Free Software Distribution Guidelines (FSDG) perspective are:
 	 - suggesting non-free add-on
	 - using "non-free" network services
	 - depending on external non-free software (like Google's services/APIs)
	 The F-droid case can be deemed similar to the Debian case, where even if the distributed software has a free license itself, it can convey freedom issues in different ways.

	 GNUtoo brings up the example of Yalp (Yalp Store) that is a very clear violation of the Free Software Distribution Guidelines (FSDG), because if is free software in itself, but it allows for non-free software to be installed on the device.

	 Fil explains that Replicant aims to be compliant with the Free Software Distribution Guidelines (FSDG) so this needs to be worked out. He explains a possible solution/mitigation that is currently being evaluated by Replicant and the FSF. This proposal involves patching F-Droid to let distributions like Replicant decide a list of "AntiFeatures" to be filtered out, so that applications that are marked with them are hidden in the f-droid user interface and cannot be searched and/or installed.

	 GNUtoo points out that if we put up our own F-Droid repo we will need to sign applications with our own key. This can lead to usability issues for the users.
	 Android applications are signed. If for some reasons the signing key changes, Android won't let you install the application with the changed signing key.
	 If the application name is the same, you then need to uninstall the previous application, and install the new one.
	 The issue is that the data of the previous application is then removed while uninstalling. It's also not possible for an application to access other application's data unless it has root permissions.
Documentation and Wiki management: There is not any time left to discuss it.

The meeting ends at 13:00 CET
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20190222/7f2d328c/attachment.asc>

More information about the Replicant mailing list