Project

General

Profile

GovernanceResearch » History » Version 11

Denis 'GNUtoo' Carikli, 07/01/2020 12:54 AM
add legal risks of redistributing nonfree software

1 1 Denis 'GNUtoo' Carikli
h1. GovernanceResearch
2 8 Denis 'GNUtoo' Carikli
3 7 Denis 'GNUtoo' Carikli
{{toc}}
4 1 Denis 'GNUtoo' Carikli
5
h2. Introduction
6
7
The Replicant project sometimes needs to take decisions. The decisions are currently taken by the [[SteeringCommittee|steering commitee]].
8
9
It would be better if this is made more horizontal:
10
* It would remove the single points of failure
11
* The decisions would be better and less horizontal
12 2 Denis 'GNUtoo' Carikli
* Potential individual bias could be smoothed out by having more people taking decisions.
13 1 Denis 'GNUtoo' Carikli
14
h2. Challenges
15
16
The main issues with a more horizontal governance in Replicant are:
17
* To ensure that the decisions being taken are informed decisions
18
* The Replicant project doesn't become a nonfree distribution
19
20
h3. Examples
21
22
Project governance can work in completely horizontal way, however to do that projects typically need to implement some rules[1].
23
24
Examples:
25
* Some free software projects require to follow meetings or pay a membership to be able to vote. The goal behind that is to avoid taking uninformed decisions.
26
* Events organization projects do manage to take very well informed decisions in a very efficient and fast way[2].
27 2 Denis 'GNUtoo' Carikli
28
h3. Good practices
29
30 3 Denis 'GNUtoo' Carikli
h4. Explain any project decision
31 2 Denis 'GNUtoo' Carikli
32 3 Denis 'GNUtoo' Carikli
The decision we take impact the whole Replicant community and potentially beyond as well. So it's a good practice to explain why a decision was taken.
33
34
For instance if we decide not to support devices with non-replaceable battery we need to explain the rationale behind that very clearly, this way people can understand the rationale and challenge it if necessary. For instance the [[TargetsEvaluation#Minimal-requirements|Minimal-requirements]] explain why this choice was made.
35
36
Not doing that could be very violent for people directly affected by the decision, as they would probably feel that the decision is imposed on them in an arbitrary way, when in reality the Replicant had to do it for the reasons stated (which can be challenged).
37
38
It's also a good practice to add the rationale with the decision as people are sure not to miss it and understand the decision better.
39 1 Denis 'GNUtoo' Carikli
40 4 Denis 'GNUtoo' Carikli
h4. Having ways to publicly review and/or challenge decisions.
41
42
Since we took the decision on not supporting devices with non-replaceable battery we explained the decision at several occasions, such as the report from the Replicant conference in Paris, the FOSDEM BoF meetings, on the mailing list, on the IRC. If we had found interesting argumentation challenging that decisions we would have been forced to take it into account and document it.
43
44 5 Denis 'GNUtoo' Carikli
For instance, if many new smartphones with non-replaceable batteries are added in Linux (that situation may or may not reflect the reality), we could add: "Complete support for many new smartphones were added in Linux and could work in Replicant if we support devices with non-replaceable battery, however despite that we still decided not to support them due to the increased difficulty to support them for a long time, as we expect to support devices for years after they started shipping."
45 4 Denis 'GNUtoo' Carikli
46
In a case like that, we could also encourage interested people to fork Replicant to collectively maintain them for as long as possible, and see how well it worked for them, and see if their experience in doing that could be taken back into account in such policy to potentially change it. In a case like that it could also depend if maintainers could all be willing to work on and/or use devices with non-replaceable batteries as well.
47
48 6 Denis 'GNUtoo' Carikli
h4. Try to use tools and process that include people
49
50
h5. Not requiring extra skills for things that don't really need it
51
52
We cannot expect all Replicant users and contributors to know git or programming, and enabling as much people as possible to participate as much as possible is a good thing.
53
54
In order to fix specific issues in the documentation that is on our wiki (duplication, no automation, no integration with Wikidata), we decided to migrate to Mediawiki and not to documention systems like Sphinx in order to make sure that people that were already contributing to the wiki, and other potential contributors weren't excluded.
55
56
With mediawiki we can use both programming (through various ways) and simple wiki syntax in the same system, which enables both users that don't know git nor programming to participate, while trying to keep the maintenance cost low enough by automatizing many tasks and not duplicating information.
57
58
However if we want to enable people to be paid to work on projects as part of Replicant, and that they need to be able to send patches as part of that, we could ask them to send a specific project description as a patch, as they are already expected to know how to send patches, or at least to learn that for the occasion.
59
60
h5. Tools and human interfaces
61
62
Another area of inclusion would be to use tools that offer several interfaces. For instance if some people are used to forums, while other are used to mail, if that's not too much work, it would be a good idea to have tools that bridge both by exposing a forum interface to the mailing list.
63
64 9 Denis 'GNUtoo' Carikli
h5. Hardware and infrastructure speed and resources
65 6 Denis 'GNUtoo' Carikli
66
Ideally we should enable people without ultra powerful computers and ultra fast Internet connection to also be able to build Replicant. However while some effort on our side is made to keep the requirements as low as possible (for instance #2056), we still depend on the design choices made by Android which doesn't make that easy. To radically improve in this area, we would probably need to do a huge amount of work by packaging all the Android components in a GNU/Linux distribution in order to enable people to not have to download and build the whole source code just to modify one library. While this could be done, we would also need to have more people involved in such project to maintain it and adapt it to newer Android versions.
67
68
As for the Internet connection, we can increase the speed of the fetch by using clone bundles, however we still need to find how this was made to make more clone bundles.
69
70
We can also host some repositories for contributors working on Replicant or project closely related to it.
71
72
h5. Hardware and software
73
74
People should be able to contribute to Replicant with laptops and desktops that run fully free software, and that run fully free software distributions.
75
76
In practice that means that we should be able to only use FSDG compliant distributions on RYF hardware.
77
78 10 Denis 'GNUtoo' Carikli
We should also work toward using system that don't force users to run JavaScript even if the code is free software, as forcing people to run code through arbitrary execution of code in a browser is not a good idea. The "GNU ethical repository criteria":https://www.gnu.org/software/repo-criteria.en.html also stated that not forcing users to run JavaScript is a good thing: "All important site functions work correctly (though may not look as nice) when the user disables execution of JavaScript and other code sent by the site. (A0)"
79
80 6 Denis 'GNUtoo' Carikli
h5. Laws
81
82
Contributing to Replicant should not require people to break any laws as everyone is not necessarily in position to take legal risks.
83
84
Replicant has access to FSF lawyers to help the Replicant project and its contributors to stay away from legal risk.
85
86 11 Denis 'GNUtoo' Carikli
The fact that Replicant is fully free software also limits the liability risks as we don't have to redistribute any nonfree software.
87
88 1 Denis 'GNUtoo' Carikli
h2. References
89
90
fn1. https://en.wikipedia.org/wiki/Elinor_Ostrom
91
fn2. https://media.ccc.de/v/Camp2019-10204-participatory_art_event_tools_co-creation_and_silk_road_networks