# Note of intent ## **Ensuring free, fair and sustainable use of software tools contributing to the Common Good.** This [white paper](https://en.wikipedia.org/wiki/White_paper) aims at increasing the quantity and viability of digital services operated as commons, that is, as resources shared and exploited in a sustainable way by a community. To do so, it **clarifies the vocabulary**, describes the **minimal constraints** without which digital resources can never reach the status of commons, and proposes **concrete guidelines** to make their development easier. This document describes the main categories of mutual commitments and required behaviours that ensure the free, fair and sustainable use of digital services benefiting the general interest, especially when these services are co-produced by public actors. Beyond these categories, it offers good practices to build real commons wherein users are at the heart of the decisions. ![](/files/JZAvQEFdDVlN5Iu8JO8e) ## Target audience The target audience is primarily "innovators\[^1]" \[Rogers, 1962] who have the opportunity and intention to organise the commons. The aim is to help them confirm their intuitions, communicate with a clear and referenceable vocabulary, and convince their peers. By this I mean that if you already have experience in operating commons, you or your organisation will probably have specific practices that are more appropriate to your context. The recommendations provided here are good practices to avoid the usual pitfalls that come with an open strategy based on good intentions but failing at implementation; it is not the only way to bring about commons. All types of structures are involved in these issues, from large companies to individuals, from non-profits to government agencies. A subset of these recommendations is specifically aimed at public actors, which are subject to more constraints than others and yet possess the largest pool of existing services that could be shared. \[^1]: As defined by the [innovation adoption curve](https://www.lescahiersdelinnovation.com/la-courbe-de-diffusion-de-l-innovation-selon-roger/), that is, the 2% who take a risk to adopt a new behaviour within an organisation. # Concepts Prior to unfolding the reasoning, I have to clarify the vocabulary and concepts that are necessary to understand it properly. Even if you think you are familiar with terms related to the commons, public policy, and the digital world, I recommend a quick read of these chapters because these terms are often used ambiguously, while I use them here with a precise meaning. In any case, feel free to come back to them as you read! If the importance, issues and questions raised by the commons are still not clear after reading this section, some metaphors are available in the appendix. # Common(s) The complexity of the vocabulary of the commons stems primarily from the use of the same word which, depending on the context or whether it is singular or plural, will designate concepts that are fundamentally distinct from each other. We will therefore make a distinction between: * *the* common, often associated with the term "good". It is a political principle of egalitarian democracy in the access to shared resources, which can be broken down into... * *a* common, for each set of rules of access and use determined in a democratic way that embodies the common, and that generates... * commons, which are bodies of shared resources on which is applied a common determined by... * communities, which are the set of actors gathered around each of these commons. Over and above their functional properties, the commons are therefore political objects in the first place \[Dardot, 2017]. It is only their rules of use and the reality of their application that give them this title. # Public action Commons must be distinguished from public goods, from both economical and ownership standpoints. Public goods can indeed most often be considered as the private good of the public administration\[^1] \[Coriat, 2017]. Without rules that establish a shared governance with its users, goods or services cannot be commons. However, through their mission of defending general interest, public bodies are legitimate to have policies towards commons when these have public value\[^2]. ## Contribution First of all, public entities can have a role as investors who support the creation of commons. This investment can be financial, but can also take the form of expertise and of provisioning of resources that public actors hold exclusive access to. By sharing these resources, the public entity becomes a community member rather than a mere funder. ## Guarantee Public power\[^3] can be used to ensure the respect of the common that the community decided to follow, in particular regarding rules towards access and non-reenclosure\[^4], thus preserving their statute. Public actors are usually regarded as guardians of ownership models that differ from private property, and are thus likely to ensure this non-reenclosure. In aprticular, preventing a shift towards private ownership can be part of their legal attributions when they have contributed to the commons and thus hold responsibility towards the usage of the public resources that were invested. Nevertheless, it is important to keep in mint that commons differ from public management just like they differ from private managemnet, and that a public actor is not more legitimate than any other actor to govern them alone. ## Non-systematicity In the same way that not all public buildings are intended to be common buildings, not all digital public services are intended to become common digital services. Therefore, this paper is not intended to suggest that all digital public services should become commons\[^5]. On the other hand, it is not necessary to meet all the criteria set out in this document to start building digital commons. As we have seen, since the common is a political principle, software can become a common even *after* it has been fully built. ——— \[^1]: "\[The qualification as public good] applies only when the State or its subsidiaries seize a resource, acknowledge it as having a collective purpose, and ensure its production and/or maintenance. Therefore, its dynamic does not apply to all elements that could imply a concern for common use, conservation or transmission. Moreover, it does not imply 'governance' by the members of the community but on their behalf' in Le retour des communs, Coriat, Zimmerman et al, pp 204-205. \[^2]: The legal definition of this aspect does not exist (yet?) for digital objects. Thus, the evaluation of this aspect is not standardised. Note that, by symmetry, this would make them [public property](https://en.wikipedia.org/wiki/Public_property) items if they were material and administered by the public power. \[^3]: Public *power*, not public action, that is, all the means available to the administration and the government to enforce laws and regulations. Thus, justice can be called upon to enforce a licence. \[^4]: Reappropriation means reintroducing exclusivity in the use of resources that were commons, that is, restricting their exploitation - either in total or in part - to a specific actor. \[^5]: On the other hand, it should be noted that the law for a Digital Republic stipulates that source codes and public data are subject to a principle of open access by default. # Numérique ## Spécificités des objets numériques Les objets numériques sont qualifiables de *communs* au même titre que peuvent l’être des ressources matérielles non-exclusives\[^6]. La condition principale reste la même : le respect d’un commun. Néanmoins, deux particularités sont à noter en ce qui concerne les communs numériques. D’une part, les pratiques qui prévalent dans le domaine du logiciel tendent vers des gouvernances facilitant la constitution de communs, là où les lieux physiques sont plus facilement par défaut des biens privés. D’autre part, les coûts de la duplication et de la transmission de l’information sur support numérique étant extrêmement faibles, les communs numériques sont a priori non-rivaux \[Verdier & Murciano, 2015], c’est-à-dire que l’usage de leurs ressources par un acteur n’en prive pas d’autres acteurs. ## Communs numériques Le terme de « commun numérique » se répand largement. On l’a beaucoup usité pour désigner des bases de données contributives telles qu’OpenStreetMap ou WikiData. Il est aujourd'hui souvent utilisé pour décrire le code source d’un logiciel libre. Avec son appropriation plus large, il tend à désigner à la fois un code source et une instance exécutable gratuitement par le grand public de ce code source. Par exemple, « [Framatalk](https://framatalk.org/accueil/) » pour désigner une instance du logiciel libre [Jitsi Meet](https://meet.jit.si) administrée et hébergée par l’association [Framasoft](https://framasoft.org/). Cette dernière acception est porteuse d’espoir pour la diffusion du concept dans la mesure où elle est beaucoup plus tangible que la désignation d’objets purement techniques, et recouvre une réalité d’usage plus à même de fédérer une communauté. ## Services numériques communs Ce document se focalise sur les *services* numériques, c’est-à-dire des systèmes socio-techniques rendant un service à des humains et comprenant des interactions avec un logiciel. D’autres types de communs numériques existent en effet, à commencer par les bases de données (comme évoqué plus haut : OpenStreetMap, Wikidata…). Un sous-ensemble des éléments décrits dans ce document leur est applicable, mais nous ne traiterons pas explicitement ces cas. On ne peut réduire les services numériques communs à leur code, pas plus qu’on ne peut réduire des services de distribution d’eau potable communs à un réseau de tuyauterie, et on ne peut donc pas non plus considérer que chaque exécution de ce code soit régi par un commun, même si l’une de ses instances l’est. ## Commun contributif Si le code est effectivement une ressource non-rivale, certains des constituants (tels que décrits dans la section suivante) des services numériques communs peuvent, eux, être rivaux. Et en premier lieu, la capacité de contribution active de leur communauté, directement corrélée au temps investi par ses membres, est une ressource rivale\[^7]. C’est sur la base de ce constat que je distinguerai deux familles de services numériques communs : d'une part, ceux qui peuvent exister sans contribution active et continue de leurs usagers, et qui nécessitent une gouvernance qui garantit simplement la prévention de la réappropriation de ressources informationnelles stables ou autonomes (capteurs disséminés sur un territoire, capacités de calcul excédentaires\[^8]…). D’autre part, ceux dont la valeur informationnelle ne peut être maintenue que par l’investissement continu d’une multitude d’acteurs (encyclopédie, recommandations subjectives, agenda d’événements amateurs…), et qui nécessitent une gouvernance qui prévient la réappropriation non seulement des données consolidées, mais aussi de la capacité à contribuer de sa communauté. \[^6]: La non-exclusivité signifie que l’usage ne peut en être empêché. L’air, par exemple, est une ressource matérielle non-exclusive. Les objets numériques pouvant être dupliqués à un coût tendant vers 0, ils ne sont pas intrinsèquement exclusifs, même si des restrictions arbitraires peuvent leur être appliquées. \[^7]: Par exemple, le temps investi par un contributeur pour noter un hôtel dans le silo de données de TripAdvisor est du temps qu’il ne peut pas investir dans la rédaction d’un guide de voyage sur wikitravel.org. \[^8]: Pour exemples, respectivement : la [Base adresse nationale](https://adresse.data.gouv.fr), [Pioupiou](https://pioupiou.fr/fr/) ou [QuakeCatcher](http://qcn.stanford.edu/index.php), [RenderFarming.net](http://burp.renderfarming.net) ou [World Community Grid](https://www.worldcommunitygrid.org). # Components Digital services need to have sharing rules so that the resulting governance can bring them to be considered as digital commons. Instead of giving a set of rules ready to be applied systematically, I split digital services into a set of components and define constraints that frame the type of rules that apply to each of these components. This is a meta-methodology: it is impossible to provide ready-made rules for every situation, but it is possible to determine which constraints these unique rules have to meet so that the resulting governance can qualify as digital common. I therefore break down digital commons services into the following components, listed by level of abstraction: source code, terms of use, user-generated data, statistics of use, means of communication, brand, and evolution strategy. This analysis grid highlights aspects of digital services that are often considered secondary. However, if one of these components is not shared, this opens up loopholes allowing the re-appropriation of information that is necessary for operating the service over time, medium or long-term. > For example, a digital service which source code is under free software license but which brand can only be used by a single structure cannot be considered as a service under common administration. Beyond the basic constraints to be applied on the sharing rules to guarantee the sustainability of each of these components, I also define additional constraints for services for which the value depends on the capacity of their community to actively contribute. Indeed, in this case, the contribution capacity is directly correlated to the time invested by its members, and is therefore a competing resource. These constraints are summarised in the grid below, and are explained and detailed in the following pages. | Component | Constraint on rule | If value is contributive | | :---------------------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------: | :-----------------------------: | | [Source Code](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/1-code_source/README.md) | Free software license (ex : MIT) | Copyleft clause (ex : AGPL3) | | [Usage Rights](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/2-usage/README.md) | No condition other than protecting other users’ rights | Availability warranty (SLA) | | [User Data](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/3-donnees/README.md) | Free content license (ex : CC-BY) | Copyleft clause (ex : CC-BY-SA) | | [Usage Statistics](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/4-statistiques/README.md) | Free database license (ex : LO) | Copyleft clause (ex : ODbL) | | [Communication](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/5_communication/README.md) | Community representation in sending the message or distribution of the possibility to send messages to the community | | | [Brand](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/6-marque/README.md) | License and charter for branding elements (name, URL, logo…). | | | [Strategy](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/7-strategie/README.md) | Transparency on available resources and definition of functional priorities by community members | | Note that at this stage we have not specified the methods of organisation that will make effective the rules determined on the basis of these constraints. Thus, for these common rules to be fully effective and part of a complete governance, it is also necessary to determine *who* acts and within what framework in situations of infringement, for example in the case of non-compliance with licenses granted on shared resources. This is the subject of the \[next chapter].(../3-roles). # Source Code Digital services are primarily software. Even if by definition they cannot be reduced to this technical essence, their primary nature is the execution of computer code. This code, in a readable and executable form, is therefore an obvious component to share. ## Free License The rules applicable to a source code are set out in licenses, that is to say contracts by which the copyright holder defines the conditions under which this program may be used, distributed or modified. Certain types of licenses, such as free licenses, guarantee rights to the public: reading, duplication and redistribution. These rights therefore prevent the re-appropriation of the existing material. **A minimum constraint is that the source code be made available under a free license\[^9].** **Operational recommendation: use an EUPL license or one of the licenses mentioned in article** [**D323-2-1 of the Code des relations entre le public et l'administration (CRPA)**](https://is.gd/rYk7h7)**. These licenses are adapted but not limited to a european context.** ## Copyleft Clause Nevertheless, the digital commons cannot be reduced to software. As we have seen, their specificity comes from the existence of a *community*. It is this community gathered around the software that must be preserved in order to avoid re-appropriation, either active or by desertion of the community except by one actor. Active re-appropriation can only be prevented by the implementation of a copyleft clause \[Aigrin, 2002]. Such a clause ensures that improvements to the software are made available to the community, by making it mandatory to publish changes to the source code. In the absence of such a clause, simply taking the source code of software that are part of digital commons and adding a feature attractive to users without sharing the code that adds said feature \[Aigrin, 2002] is enough to move the community to this new version \[Verdier & Murciano, 2015]. The new version, no longer governed by a commons, thereby deprives the original commons of its substance. A copyleft license is therefore the most suitable license for the contributory commons. **For contributory services, the license includes the provision of source code with a copyleft clause.** **Operational recommendation: use an Affero GNU Public License 3.** ## Integrating Solicitation Beyond usage, the ability of users to contribute to the service must be preserved. The use of free licenses guarantees the right to modify the code, but contribution also means the systematic evaluation of these modifications and their integration whenever relevant. Without this ability to contribute, open source software are just another form of monologue. **A minimum constraint is to provide a means of soliciting the integration of changes made by a contributor into the original code base.** **Operational recommendation: use tools that specialise in collaborative development, which provide a consolidated platform for both code availability and contribution of code, and suggestions for improvements, such as** [**Framagit**](https://framagit.org/)**,** [**GitLab**](https://about.gitlab.com) **or** [**GitHub**](https://github.com)**.** ## Commitments on Integrations As with usage, the "contributability" of the commons cannot be measured solely by the technical capacity to request the integration of modifications. A contributor whose requests are never answered will quickly become frustrated and stop contributing, and the public visibility of this lack of response will discourage others. **It is useful to commit to a time frame for processing\[^10] integration requests and to a communication charter\[^11] with potential contributors, to ensure an open and engaging atmosphere.** **Operational recommendation: establish and publish rules of procedure describing how to handle requests for integration of modifications\[^12].** ## Documentating Operations Also with this objective in mind, the technical methods that allow the service to be operated, in terms of its system administration, should be documented and shared in the same way as the source code. Indeed, if just a single person (natural or legal) knows about the infrastructure needed to operate the service, there is a risk of re-appropriation. **A minimum constraint is to provide documentation on the technical operation of the service.** **Operational recommendation: document in an executable way through a** [**configuration management system**](https://fr.wikipedia.org/wiki/Gestion_de_configuration_logicielle)**, which allows the infrastructure to be defined as code.** \[^9]: Exhaustive list available at [opensource.org/licenses/alphabetical](http://opensource.org/licenses/alphabetical). \[^10]: "Processing" does not necessarily mean integrating, but at least making an initial evaluation of whether the contribution is welcome, or justifying the rejection of its integration by providing references for improving future contributions. This delay should be as short as possible: beyond a few days, the feeling is no longer one of discussion, and the community is lost. \[^11]: Such charters are generally referred to as *code of conduct*. \[^12]: See also "How to acknowledge contributions" in the appendix. # Terms Some services may be provided by simply running the code (e.g. image compression on a personal computer). In these cases, the usage regime is derived from the source code access regime. In other cases, the duplication of the source code does not allow the duplication of the service provided, for example in the case of interfacing with private resources such as an API or in the case of a service applying a platform strategy (Colin & Verdier, 2013). In this second case, the prevalence of the value of network effects over the value of the code itself makes it extremely difficult to replicate the service\[^12]. ## Permissive Terms of Use The fact that it is potentially impossible *de facto* to provide an alternative to the terms of use of the digital service, even if the source code is *de jure* duplicable, shows that the right of use is a full-fledge component of the shared resource. It is not a systematic instance of this resource, each variant of which could impose its own right of use\[^13]. **A minimum constraint is that the terms of use should allow usage without conditions other than those strictly necessary for operating the service and preventing acts aimed at reducing the capacity of other uses.** **Operational recommendation: transform legal constraints into a source of information for users, using clear and readable language that classifies terms of use according to their concerns (**[**example**](https://mes-aides.gouv.fr/cgu)**).** ## Contribution budget In addition to legal guarantees, technical guarantees are appropriate to ensure effective freedom of use. In the case of a minimal commons, a poor quality of service can be solved by creating an alternative service based on the code. But in the case of a contributive commons, the instance through which the community collaborates must be functional. If the service is under permanent maintenance, even the most open TOS will not enable its use. **For contributive services, there is a constraint to commit to a rate of availability of the service for its users (SLA\[^14]). In order not to hinder the evolution of the service, this SLA must evolve over time and be interpreted as a "contribution budget\[^15]".** **Operational recommendation: determine the SLA according to the number of users and the capacity of human agents to handle anomalies, ensuring the easiness and quality of this process, by applying a formula such as `SLA = 1 - (number of files that can be handled manually ÷ number of users over the same period)`.** > For example, if I have a community manager who can efficiently support and debug 10 users per day, with a service used by 1,000 users per day, my error budget is 10 / 1,000 = 1%, which sets my SLA at 99%. \[^12]: For example, Wikipedia's engine, Mediawiki, is an open source software that can be, and is, widely duplicated. However, duplicating the service provided by Wikipedia would be extremely complex, as users - and therefore contributors - are all familiar with "Wikipedia". A duplicate offering exactly the same functionality would have no chance of competing efficiently with the service provided. \[^13]: This is why migrating from a service like Twitter to an alternative like Mastodon is unlikely: even if the algorithm allowing network distribution across multiple instances is more advanced than a monolithic service, the value of the service comes primarily from the contribution of its users. The return on investment for each individual user is in favour of continuing to use the service that has the most users, as the cost (becoming isolated) is not worth the benefits (better functionality). \[^14]: A [SLA](https://fr.wikipedia.org/wiki/Service-level_agreement) can be expressed as a percentage of requests processed per time unit. For example, one can commit to an availability of 99.9% per month, which means that 99.9% of the requests are processed without any errors by the system. \[^15]: In [this view](https://landing.google.com/sre/interview/ben-treynor.html), inspired by the Site Reliability Engineering movement, instead of interpreting an availability commitment of 99.9% per month as a minimum standard that should aim at 100%, one considers that one can implement upgrades that include an operational risk up to a maximum of 0.1% of the requests being processed with errors. # User Data The data generated by users interacting with a digital service has a high potential value. This value can be provided directly, especially if the main purpose of the software is to make information provided by its users available\[^16]. To this direct value can also be added the value of network effects when the software connects several users. Its worth, then, comes as much - or even more - from the community it has already consolidated than from its algorithmic essence\[^17] \[Verdier]. To ensure that there is no re-appropriation, it is therefore fundamental that this value, which may be greater than that of the code, is not held by a single stakeholder \[[Maurel](https://scinfolex.com/2016/01/15/eriger-le-reseau-des-donnees-personnelles-en-bien-commun/)]. ## Publication The idea is to set up the network of data constituted by the interactions of users as a common good in its own right, given that the value that can be extracted from it is greater than the sum of the values that can be extracted from each of the individual points. At the same time, it is important to respect the right of the individual to control their personal data \[Bellanger]. **A minimum constraint is that the exploited data must be made available under a license that allows re-use.** **Operational recommendation: export regularly (and at least weekly) to data.gouv.fr the database of the service, while making it impossible to re-identify its users\[^18], under** [**Open License 2**](https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf)**.** ## Copyleft Clause The reusability of these data is sufficient to guarantee the status of digital common to software that collects them. Nevertheless, re-appropriation becomes possible if an ill-intentioned operator makes them available in a poorly readable format and keeps the exclusive right to use an analysis chain to extract value from them. Furthermore, those who contribute to a service may be discouraged from participating if they feel that their contributions can be reused by proprietary stakeholders without compensation. Indeed, the choice to contribute to a commons is often a form of activism. **In the case of contributive services, the license under which the data produced by users is made available includes a copyleft clause.** **Operational recommendation: in the previous recommendation, use an ODbL license instead of an Open License.** \[^16]: For example, a social network like diaspora\* or Facebook, or a collaborative resource like [wikitravel.org](http://wikitravel.org). \[^17]: Again, social network, but also linking services like TrustRoots or AirBnB. \[^18]: Many techniques are applicable depending on the type of data handled: [anonymisation](https://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf), [pseudonymisation](https://www.cnil.fr/sites/default/files/typo/document/FICHE10_PackConf_LOGEMENT_SOCIAL_web.pdf), [differential privacy](https://fr.wikipedia.org/wiki/Confidentialit%C3%A9_diff%C3%A9rentielle)… # Usage Statistics Beyond the data willingly provided by users, value can be extracted by simply monitoring interactions with the digital service. A descriptive statistical analysis can indeed improve the value provided by the service as it can help to determine which features should be strengthened, improved, or abandoned. Expanding digital commons without knowing how they are used is like expanding a road network based solely on its map, without ever getting to see how people use it. Moreover, if this data is not shared, a specific actor can make money from it without necessarily paying back the community that makes the service work. ## Publishing Service usage statistics, if collected, should therefore be made available under a license that allows their re-use. **A minimal common should make available the usage statistics for each feature of the service under a license that allows re-use.** **Operational recommendation: display a public instance of the Matomo (or Xiti) tracking service,** [**configured**](https://www.cnil.fr/fr/solutions-pour-la-mesure-daudience) **in compliance with CNIL regulations (or a similar institution of regulation). Specify that the data offered by this instance is available under an open license.** ## Copyleft Clause Nevertheless, re-appropriation becomes possible if an ill-intentioned operator makes them available in a poorly readable format and keeps the exclusive right to use an analysis chain to extract value by cross-checking them with proprietary databases. To prevent this, if the database contains detailed information, it can be provided with a copyleft clause. Thus, any product derived from the database should also be made public and therefore accessible to the community. **It is useful to have a copyleft clause in the publication license for usage statistics.** **Operational recommendation: in the previous recommendation, use an ODbL license instead of an Open License.** # Communication Users can be engaged in other ways than their standard use of the service. For example, they can be called upon to contribute to the digital commons for which they are part of the community, to promote them, or to carry out a referendum arbitration\[^19]. The capacity of representation towards contributors, users and the public, largely determines the capacity to contribute and thus the type and intensity of the value that is collected. Therefore, this capacity of representation should be considered as a component of digital services which, if re-appropriated by a subset of the community or by a third party, could compromise their operation as a common\[^20]. ## Contact with the community **A minimum constraint is to provide all contributors with the means to send information to the community, while limiting the amount of solicitations in order to maximise the potential value.** **Operational recommendation: allow users to submit their email address, register them in a mailing tool compatible with European law on personal data such as** [**SendInBlue**](https://fr.sendinblue.com) **or** [**Framalistes**](https://framalistes.org) **and commit to a maximal frequency of mailing (once a month, once a week...). Provide contributors with a collaborative writing space such as** [**Framapad**](https://framapad.org) **to prepare the mailings.** ## External communication In addition to direct messages, the broadcasting tools that are social networks can make it possible to reach a large audience, which can go beyond users and contributors. Again, the ability to reach this audience must be shared. **A contributive commons should provide contributors with means to contact the public, while ensuring that the broadcast messages are highly relevant.** **Operational recommendation: draft an editorial charter (**[**example**](https://github.com/betagouv/aides-jeunes/wiki/Notre-ton)**), use an account delegation system for each social media used by the service (TweetDeck for Twitter, Business Manager for Facebook...) and have the social account certified by the network operator.** \[^19]: These include [CarbonVote](http://v1.carbonvote.com), the \[Ethereum DAO hard fork] vote(). \[^20]: Although outside the specific case of the digital commons, the example of the means of communication retained by the former president of the association Objectif Train de Nuit, following a renewal of the board by a contested general assembly, leads this structure to have two competing governance bodies, each claiming to be the official one. # Brand Besides the contributors and the community of users, there is a third circle of interaction for digital commons with the general public. These interactions do not take place directly with the service (otherwise they would be users), but with a brand, which can be a name, a logo, a domain name, a graphic design… Brands represent reputational assets for the digital commons. To be consistent with this status, their benefits must therefore be shared and protected without re-appropriation, like other kinds of assets. ## Availability Providing the elements that make up the brand is particularly important in the case of contributive commons, since the contributions will be oriented in the first place by the use of these elements. If an actor has control over them, he will be able to re-direct the contributions towards his own service which may not be operated as a common. **In the case of a contributive commons service, the elements making up the brand are legally protected and freely available, provided that they comply with a charter aimed solely at protecting the reputational capital of the commons and not a particular actor.** **Operational recommendation: provide all trademark elements on a web page, register them with national patent office\[^20] and adapt the** [**Wikipedia Trademark Policy**](https://meta.wikimedia.org/wiki/Trademark_policy/fr#policy) **to define recommended and prohibited use cases. The prohibited cases should be justified by highlighting the potential danger to reputation assets.** \[^20]: This registration is not necessary to protect against a competing registration as the service is publicly available and anteriority will therefore be easy to demonstrate. This registration deters ill-intentioned parties, facilitates the transfer of the intellectual property to another structure, and enhances the value of the registering structure which is more likely to consider the service as a capital to be maintained. # Strategy As well as limiting the risks of re-appropriation of the means of producing value, there is the question of how to engage resources already shared. ## Publishing Improvement Requests In the context of democratic governance, the general roadmap of the service is theoretically based on the needs expressed by the community. However, arbitrations must be carried out on the basis of available resources. If these arbitrations systematically favour a certain type of stakeholder, there is a *de facto* re-appropriation of the shared resources in the sense that, over time, the digital service will bring increasing value to certain users at the expense of those for whom the investment could not be made. The way in which strategic orientations are defined should therefore be considered as a component of the service and subject to appropriate governance. **A minimum constraint is the publication of users' requests for evolution.** **Operational recommendation: consolidate user feedback either directly into the software forge through "tickets" or "issues", or through a dedicated tool**. ## Publishing Available Resources In order to allow the community to participate properly in the arbitration between needs and means, limited and measurable resources must be accessible at least to the community, as for example the financial means of the structure which operates the service. **A minimum constraint is the publication of the means invested and available for the evolution of the service.** **Operational recommendation: publish a budget document of the past and planned means invested in the service.** ## Documenting Arbitrations The arbitration procedures based on this information may be synchronous, such as a general assembly, delegated to elected representatives, or based on asynchronous and shared decision-making tools. In all cases, they must be described publicly and, if the entity operating the service has formed a legal structure, in a statutory or regulatory document. **A minimum constraint is the description of how the available resources are to be invested.** **Operational recommendation: to maximise participation without geographical or time constraints, favour asynchronous and shared decision-making tools such as** [**Loomio**](https://www.loomio.org) **and information meetings that are at least recorded and broadcast.** # Roles In the [Components](/2-constituants) section, I have defined the minimal constraints that must be applied to the rules of operation for digital services to qualify as digital commons. Without these constraints, the risk of re-appropriation would be far too high. However, meeting these conditions is not enough to guarantee that they will be effective. How they are made available to the public is in fact only one aspect of the commons status. Let us remember that the operational and strategic governance of the commons cannot be anything but democratic\[^21]. > For example, if the source code of a digital service is licensed with a redistribution clause but no stakeholder ever calls an infringing reuser to order, this constitutes a loophole for reappropriation just as if the original clause did not exist. We must now define the methods for exercising and balancing power between the various actors involved in the digital commons. The aim is not to establish territories but to guarantee the sustainability of the tool and its values. Thus, governance must necessarily be transparent: the different roles and decision-making methods must be described, and the latter must be traceable and publicly verifiable. The different parts of this section present the necessary roles to be fulfilled, ordered by distance from the service usage itself. For each role, I will present the associated tasks and suggest forms of retribution and associated legal forms. Just as constraints can only be expressed on the rules of the components and not ready-made rules, the concrete implementation of these roles will depend on the stakeholders gathered around the commons to be governed. For example, some stakeholders may hold several roles, especially at the beginning of the service's existence. \[^21]: This is because the commons exist through their community of users between whom there is no difference in status, and because democracy is the most appropriate means of collective decision-making for any given number of equal individuals. # Community The community of users of the digital commons is always the ultimate decision maker. The ways in which the community expresses itself are to be determined by each commons. The various roles that enable the common to be applied must themselves be subject to scrutiny to ensure that they apply it. The most legitimate body to scrutinise is the community as a whole. ## Risks addressed by the role ### Non-abiding by the common If the different stakeholders described in this section overstep their roles or conversely do not fulfill them properly, only the community can (and must) replace them. Therefore, all roles must be held transparently for all members. ### Uselessness of the service Without community, the digital commons is but an empty shell. The community and its involvement is the first measure of both health and usefulness of the digital commons. ## Legal Form The community is always to be considered as a multitude \[Colin & Verdier, 2015], and not as a legal person or a class that can be represented by a subset of its members. # Contributor ## Risks adressed by the role ### Operational stagnation In the absence of contributors, the common digital service does not evolve. This may be appropriate if it continues to fulfill its role towards its [community](/3-roles/1-communaute), but it can be a problem if no one in the community is able to drive change. There is a risk of switching to a proprietary model where a small number of entities take control of developments and create a market for them. ## Legal Form Contributors are primarily [users](/3-roles/1-communaute) of the service. A contributor can only be a natural person. A legal entity can only contribute to the commons indirectly, through the affiliation of individual contributors, for example its employees; or by being a [sponsor](/3-roles/5-sponsor) of the contributors' activity through financial, logistical or reputational support... ## Retribution In most cases, the primary reward for contributors is their benefit from using the common digital service. There is therefore no need for a specific retribution. However, if contributions are not properly acknowledged, the motivation of contributors may decrease. In the case of a contributory commons, this can lead to its disappearance. To perpetuate the community, contributors must feel welcome as users, but also acknowledged and even rewarded as contributors. This can of course be done through financial retribution, for instance in the form of compensation, salary or a service contract. But acknowledgement can also come through reputation, for example by putting the name of the contributor forward, or through extended decision-making powers within the boundaries of the commons. The attribution of these rewards can be done automatically, for example by highlighting the most assiduous contributors as [Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:List_of_Wikipedians_by_number_of_edits) does or as [GitHub](https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/viewing-a-projects-contributors) allows. # Operator This role aims in particular at organising and bringing together the contributions. To differentiate the role of the [contributors](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/3-roles/2-contributeur/README.md) from that of the operator, the list of [components](/2-constituants) can once again serve as a basis for describing the actions carried out by each of these stakeholders. | Component | Contributors' actions | Operator's actions | | ---------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | Source Code | Pull request, peer review. | Gatekeeping (sorting out, feedback, validation, integration). | | Terms | Software usage. | Support. | | User Data | Software usage. | Promotion (competition…). | | Usage Statistics | Software usage. | Analysis and publishing overview. | | Communication | Workshop facilitation, content creation, network registrations... | Product management, community management. | | Brand | Public promotion (advertising, presentations, articles...). | Setting up contacts, finding promotional spaces, financial support for local initiatives... | | Strategy | Feedback on anomalies, suggestions, vote. | Workshop, user research, RFC. | ## Risks addressed by the role ### Inaccessibility Resource sharing can only be effective if the resources are accessible. Who guarantees the availability of the commons? By what means? **A role of operational responsibility for the commons must be held, with access management and temporary suspension rights to ensure continued access for all members of the community.** ### Stagnation The service's general roadmap is based on the needs of the community. However, arbitrations have to be made on the basis of available resources. How can the [strategy](/2-constituants/7-strategie) be arbitrated, or at least facilitated, if the community is not able to do so, without coming to a deadlock? **A role of product ownership must be held, with a right to make final arbitration on implementing functionalities which are incompatible in terms of effects or resource consumption.** ### Illegality of contributions In the case of contributory commons, it may happen that content is made available outside of the law. How to handle and extinguish complaints? Who takes the decision to withdraw the contributions? Who bears the legal and potentially criminal responsibility for making the content available? **A role of organising the contributions and legal representation of the commons must be held.** ### Criticism Like any service, the digital commons can be criticised. Some criticism can go so far as to jeopardise their reputational capital, particularly when it questions their probity or cost rather than their usefulness. Who addresses these criticisms? How to decide which ones should be addressed? **A role of representation of the commons must be held.** ## Legal Form In emerging or small-scale digital commons, this role may be held directly by some contributors. However, mixing roles is tricky and rarely sustainable as it leads contributors with this additional responsibility to an additional workload, often different from the one they usually carry out, and which can put them in situations of difficult arbitration between their own contributions and those of others. In terms of structure, a good stakeholder for this role has the economic capacity to make expenses and adjust quickly to needs. Matching of management and objectives is supervised by the [guardian](/3-roles/4-garant). For example, it can take the form of: * Co-op. * Association with commercial activity. # Guardian ## Risks addressed by the role ### Non-abiding to the commons We have described a set of legal mechanisms limiting re-appropriation (licence, general terms of use...). Who activates these mechanisms in case of suspected infringement? What are the procedures: formal notice, filing a complaint, etc.? **A role of guardian of the commons must be held, with a clear list of sanctions to be applied in the event of non-compliance with the rules it describes.** ### Discrimination of contributors If some contributors are not welcomed in the same way as others, there is both a risk of reducing contributions, and of misdirecting the service to serve only the subset of the community represented among the contributors. **No conditions can be required to consider a user as a contributor other than contribution, that is, adding value on one or other of the components, in respect of the associated commons.** ### Mismanagement of financial capital Financial capital is the most versatile. It can be used in a relatively interchangeable way for many purposes, including indirect ones. It can be used for funding improvements to the commons, for legal defence, for promotion, etc. How are the strategic orientations transcribed in the distribution of investments? Who is responsible for the sound management of financial capital? **A role of financial guarantor must be defined, with the responsibility of making sure that withdrawals from common resources are proportional to the objectives determined by the community.** ## Legal Form The ideal stakeholder will profit, with the sole objective of guaranteeing the application of the common good and its adequacy to reality. Indeed, as the search for financial profit increases, so does the risk of re-appropriation, since the sharing of resources is opposed to the privatisation of the benefits that can be derived from them. It can, for example, take the form of: * Association. * Board (of an association, of a co-op…). * Public entity. # Sponsor Some organisations may support the digital commons without contributing directly to it, for example financially through a donation or grant, or through reputation by promoting the tool's uses. ## Risks addressed by the role ### Lack of means If the digital commons does not have its own business model, the absence of sponsors can be fatal since the role of [operator](/3-roles/3-operateur) is difficult to fulfill without financial remuneration. In the case of contributory commons, the absence of an operator makes the structure extremely fragile since the availability of the service is not guaranteed. This puts at risk the capture of value by the [users](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/3-roles/1-communaute/README.md)' contributions, and therefore ultimately the provision of the service itself. ## Legal Form These organisations can be of different natures: * [Public stakeholders.](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/1-concepts/2-action_publique/README.md) * Non-profit stakeholders under private law (associations, foundations, etc.). * Profit-making stakeholders under private law. ## Retribution As with contributors, it is useful for the sustainability of their support that sponsors feel acknowledged for their participation. In all cases, they can be rewarded in terms of reputation by having their name and logo put forward. They can also be rewarded with decision-making power through participation in certain governance bodies. In this case, care must be taken to respect the commons to ensure that the support does not outweigh the contribution. # Exemple : Wikipédia Wikipédia est une encyclopédie universelle multilingue dont le contenu est rédigé par ses lecteurs. Wikipédia a pour objectif d’offrir un contenu librement réutilisable, objectif et vérifiable, que chacun peut modifier et améliorer. Chaque instance nationale pouvant disposer de ses propres règles, cet exemple sur focalise sur la version française, accessible à l’adresse fr.wikipedia.org. Le commun de Wikipédia France est résumé sur sa page d’accueil : > Wikipédia est définie par des [principes fondateurs](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Principes_fondateurs). Son contenu est sous [licence Creative Commons BY-SA](http://creativecommons.org/licenses/by-sa/3.0/deed.fr). Il peut être [copié et réutilisé sous la même licence](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Citation_et_r%C3%A9utilisation_du_contenu_de_Wikip%C3%A9dia), sous réserve d'en respecter les conditions. Chacun peut publier immédiatement du contenu en ligne, à condition de respecter les règles essentielles établies par la [Fondation Wikimedia](https://wikimediafoundation.org/wiki/Terms_of_Use/fr) et par la communauté ; par exemple, la [vérifiabilité du contenu](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:V%C3%A9rifiabilit%C3%A9), l'[admissibilité des articles](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Crit%C3%A8res_d%27admissibilit%C3%A9_des_articles) et [garder une attitude cordiale](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:R%C3%A8gles_de_savoir-vivre). On voit l’importance accordée à la communauté, mais aussi aux principes politiques qui la gouvernent, avec une hiérarchie de normes (principes, règles, recommandations) édictées et évolutives (à l’exception des principes, qui sont le fondement du commun). ## Code source Le logiciel principal qui permet la publication et la modification du contenu de l'encyclopédie est MediaWiki. Son code source est disponible sur plusieurs plateformes, et [on peut voir](https://github.com/wikimedia/mediawiki/blob/master/COPYING) que la licence associée est la GNU *General Public License* version 2. Cette licence est une licence libre classique avec une clause de repartage\[^24]. Les suggestions de modification sont traitées par le biais d'une *pull request* et d'une revue par les pairs sur gerrit.wikimedia.org. Ce fonctionnement répond donc bien aux contraintes listées dans le chapitre précédent. ## Usage Les conditions générales d'utilisation de Wikipédia sont les mêmes pour toutes les variantes linguistiques. Voici un extrait du résumé en français : > Vous êtes libre de lire nos articles et autres médias, gratuitement ; réutiliser nos articles et autres médias sous licences libres ; contribuer à et modifier nos différents sites et Projets sous licences libres. > > Sous les conditions suivantes : > > * Responsabilité — Vous êtes responsables de vos modifications (puisque que nous ne faisons qu'héberger votre contenu). > * Courtoisie — Vous restez poli, courtois et respectueux, et vous ne vous livrez pas à des attaques contre les autres personnes. > * Comportement régulier — Vous ne violez pas les règles sur le copyright ou le droit d'auteur, et ne commettez pas d'actions délictueuses ou inappropriées. > * Pas de nuisance — Vous ne cherchez pas à porter préjudice à notre infrastructure technique. > * Conditions d'utilisation et règlement — Vous adhérez aux Conditions d'utilisation ci-dessous aux règlements applicables de la communauté quand vous visitez nos sites ou que vous participez à nos communautés. Ces conditions générales répondent donc exactement aux contraintes exprimées dans le [chapitre associé](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/2-usage/README.md) : pas de limitation d'usage autre que celles nécessaires à l'opération du service et à la prévention des actes visant à réduire la capacité d'autres usagers. ## Données fournies par les usagers Toutes les contributions des usagers sont mises à disposition sous une licence Creative Commons imposant l'attribution des contributions à son auteur et le repartage sous conditions identiques (licence [CC-BY-SA-3.0](https://creativecommons.org/licenses/by-sa/3.0/deed.fr)). Les [contraintes](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/3-donnees/README.md) sont remplies. ## Statistiques Les statistiques de fréquentation sont publiquement accessibles sur [stats.wikimedia.org](https://stats.wikimedia.org/#/fr.wikipedia.org). On peut notamment y voir la répartition géographique des accès, les évolutions du contenu, du nombre et des types de contributions… Les données sont mises à disposition sous une licence CC0 (domaine public). Les données détaillées, qui peuvent contenir des données personnelles telles que l'adresse IP, [sont accessibles](https://wikitech.wikimedia.org/wiki/Analytics/Data_access) uniquement à certains mandataires de la communauté authentifiés. Les [contraintes](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/4-statistiques/README.md) sont donc remplies. ## Moyens de communication La communication au nom du service est assurée par la Wikimedia Foundation (organisation de bienfaisance régie par le paragraphe 501-c-3 du code fiscal des États-Unis) et Wikimédia France (association loi 1901 de droit français). Des pins, badges, et autocollants sontpar exemple édités et distribués par Wikimédia France. Cette structure étant régie par le droit des associations, son fonctionnement est régi par des [statuts](https://www.wikimedia.fr/documents-officiels/statuts-de-lassociation/) publics et son conseil d'administration est élu. De même, les administrateurs de la Foundation sont [élus par tiers](https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/Board_elections), par l'ensemble de la communauté. Ces personnes ont donc accès aux moyens de communication pour représenter la communauté et agir en son nom. Les [contraintes](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/5-communication/README.md) sur la représentativité des messages passés est ainsi assurée par l'aspect démocratique de l'élection et du renouvellement du mandat. ## Marque La Wikimedia Foundation est dépositaire de la marque Wikipédia, et la [met à disposition](https://foundation.wikimedia.org/wiki/Trademark_policy) sous une politique de marques publique. Le droit d'usage est acquis lorsque l'objectif poursuivi est : * Représenter sincèrement un site Wikimédia. * Documenter factuellement des actualités liées à Wikimédia. * Créer des œuvres artistiques, littéraires ou politiques. * Créer des liens vers les sites Wikimédia. Et inversement, l'usage est interdit lorsqu'il s'agit de créer des contrefaçons ou de tromper d'une quelconque manière. Ces contraintes d'usage de la marque sont donc au bénéfice de la communauté, qui est protégée légalement d'un détournement de ses contributions et d'un mésusage du capital réputationnel accumulé. Les [contraintes](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/6-marque/README.md) sont donc remplies. ## Stratégie Les « résolutions » prises par la Wikimedia Foundation sont des orientations stratégiques majeures. Elles sont publiques et [documentées](https://foundation.wikimedia.org/wiki/Resolutions), et sont prises par le conseil d'administration élu selon les conditions décrites plus haut. Les modalités de prises de décision en vigueur sur la Wikipédia francophone sont elles aussi [publiques](https://fr.wikipedia.org/wiki/Wikipédia:Système_de_prise_de_décision) : un changement de règle peut être demandé par n'importe quel contributeur, et la prise de décision est faite au consensus, et au vote à défaut de consensus. Par la publicité des comptes rendue obligatoire par les statuts juridiques des structures opérant le service, par la possibilité laissée à tout contributeur d'ouvrir une discussion menant à une décision, et par la documentation des règles de décision, les [contraintes](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/2-constituants/7-strategie/README.md) applicables à la stratégie d'évolution sont remplies. ## Synthèse L'application du cadre d'analyse sur l'intégralité des constituants du service numérique fr.wikipedia.org permet de caractériser ce en quoi sa gouvernance relève des services numériques communs, au-delà de la simple analyse du code source. Ces conclusions peuvent être résumées dans un tableau : | Constituant | Règle | | :----------------------------: | :--------------------------------------------------------------------------------------------------------------------------------: | | Code source (de Mediawiki) | Licence GPL-2. Pull request, peer review sur gerrit.wikimedia.org. | | Droit d’usage | CGUs autorisant l’usage tant qu’il n’empêche pas les autres usagers. | | Données créées par les usagers | CC-BY-SA-3.0. | | Données d’usage | Statistiques publiquement accessibles. | | Moyens de communication | Élection des personnes pouvant représenter le service via Wikimedia Foundation et Wikimedia France. | | Marque | La Wikimedia Foundation est dépositaire de la marque Wikipédia et l’offre sous une politique de marques qui protège la communauté. | | Modalités d'évolution | Résolutions publiques du conseil d’administration élu. Consensus et vote à défaut pour les évolutions de règles. | ## Modalités d'action Par ailleurs, les modalités de contribution et d'animation sur chaque constituant peuvent également être décrites. | Constituant | Actions des contributeurs individuels | Actions des [administrateurs](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Administrateur) | | ------------ | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Usage | Connexion sur wikipedia.org. | Page « actualités », [article labellisé du jour](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal)… | | Code source | Pull request, peer review sur [gerrit.wikimedia.org](https://gerrit.wikimedia.org). | [Traitement (tri, orientation…) des sollicitations d’intégration](https://github.com/wikimedia/mediawiki/pull/66). | | Données | Lien « éditer » sur chaque page. | [Suspension de compte, annulation de modifications](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Administrateur#Fonctionnalit.C3.A9s_suppl.C3.A9mentaires_qui_lui_sont_accord.C3.A9es). | | Statistiques | Usage | Opération de stats.wikimedia.org | | Communauté | Pages [Premiers pas](https://fr.wikipedia.org/wiki/Aide:Premiers_pas). | [Concours annuels](http://wikilovesmonuments.fr) et [événements](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:WikiCheese) organisés par [Wikimedia France](https://www.wikimedia.fr). | | Marque | Recommandation d’usage, citation, hyperliens. | Pins, badges, autocollants édités et distribués par Wikimedia France. | | Stratégie | [Consensus et vote à défaut.](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Syst%C3%A8me_de_prise_de_d%C3%A9cision) | | \[^24]: On notera que le choix de la GPL plutôt que de la variante Affero GPL ne semble pas le plus adapté pour un logiciel visant à exposer une interface web : en cas de modification du code, la redistribution de la version modifiée n’est pas rendue obligatoire tant qu’elle reste sur un serveur. \[^25]: Bien que le contrôle de leur application soit laissé à la communauté, ces règles font parties des principes fondateurs et sont donc sous la responsabilité principale de la Wikimedia Foundation. # Exemples contribués Ces exemples prennent la grille d'analyse décrite par ce document, et l'appliquent à des cas réels pour en vérifier et en démontrer l'utilité. Tous ne sont pas des communs numériques complets, mais ont fortement travaillé à l’ouverture et la transparence de leur gouvernance. L'application de la grille d'analyse permet d'ailleurs de poser la question de l'existence de communs comme un spectre plutôt que comme un type d'objets numériques à part entière. Ces analyses sont des contributions tierces dont le contenu n'est pas confirmé par l'auteur. # Docker Docker est un logiciel libre de gestion de paravirtualisation qui permet d’isoler et d’allouer dynamiquement des ressources physiques. Il garantit la portabilité d’application et de leur dépendances à l’aide de containers et s’impose comme un standard de facto. Docker n’est pas un commun : la société commerciale Docker Inc garde les rôles clef de la gouvernance des différents produits et services, même si elle est ouverte et transparente. Cette positione est assumée, comme l'illustre le rôle du Benevolent dictator for life (BDFL) assuré par le fondateur Solomon Hykes. ## Produits et services ### hub.docker.com Service propriétaire de Docker Inc qui regroupe des contributions de la communauté. Il existe au moins [une alternative](https://github.com/nathanleclaire/tarzan), mais qui perd l’intérêt du service centralisé. * Images communautaires : possible pour tous avec inscription au préalable. * Images officielles gérées par docker.com avec un processus d’habilitation et une équipe de [mainteneurs](https://github.com/docker-library/official-images/blob/master/MAINTAINERS) (à noter, d’une société tierce : [infosiftr.com](http://www.infosiftr.com)). ### Le logiciel libre Docker * Une gouvernance du projet, non démocratique, mais transparente et ouverte à des extérieurs de Dockers Inc via GitHub. GitHub est l’outil de collaboration et de travail, pas d’un simple dépôt de code ouvert a posteriori. * Une gouvernance générale de tous les projets avec un [*governance advisory board*](https://docs.docker.com/opensource/governance/dgab-info/)qui reprend 6 principes d’une gouvernance ouverte. * Un détail des rôles et une [consolidation automatique](https://github.com/docker/opensource/blob/master/MAINTAINERS) des mainteneurs des différents projets. ### La communauté Docker La communauté gère essentiellement la documentation, les forums, et le site [github.com/docker/docker.github.io](https://github.com/docker/docker.github.io) avec code et contenu disponible sous apache 2.0 ## Analyse Pour appliquer la grille de lecture proposée dans ce document (version 2017) : | **Constituant** | **Modalités de contribution** | **Modalités d’animation** | **Commun** | | --------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | **Usage (hub.docker)** | Utilisation du hub : docker pull | Images officielles vs personnelles | Plateforme mise à disposition par Docker Inc et gouvernance partagée sur les images officielles | | **Code source (docker CE)** | Pull Request | Fichier MAINTAINERS | Hébergé sur GitHub | | **Données (hub.docker)** | Création de repository sur le hub | | | | **Communauté** | Documentation rédigée par la communauté | | Contrôlée par Docker Inc, mais sous licence apache 2.0 | | **Marque** | | La commande docker pointe naturellement vers le hub docker propriété de Docker Inc | Propriété de Docker Inc | | **Stratégie** | | | MAINTAINERS.md : Docker Inc garde le dernier mot | | **Acteur** | Individus | | Docker Inc | # Node.js **Cet exemple n'est pas complet.** Votre contribution pour appliquer la grille d'analyse est bienvenue ! *Node.js est un moteur d’exécution du langage de programmation JavaScript.* *En tant que logiciel libre, il a rapidement été utilisé par une large communauté de développeurs. En 2014, une polémique éclate puis enfle autour d’un manque de réactivité de l’entreprise détentrice de la marque Node.js. Un groupe des contributeurs principaux décide de « forker », c’est-à-dire de dupliquer le code et de créer une plateforme alternative, io.js. Cette alternative va jusqu’à* [*créer une identité graphique*](http://designhooks.com/case-study-building-logo-brand-indentity-io-js/) *forte et indépendante. La communauté est rapidement divisée entre un logiciel qui évolue rapidement mais qui a une base d’utilisateurs plus faible et peu de visibilité et un logiciel avec un historique mais avançant au ralenti. Les inquiétudes sont fortes sur le futur du produit. Il faudra plusieurs mois avant qu’un commun soit* [*proposé*](https://github.com/nodejs/node/issues/978)*. Ce commun comprend la création d’une nouvelle entité, la* [*Node Foundation*](https://nodejs.org/en/foundation/)*, qui est dépositaire de la marque Node.js. Seule la mise en œuvre de ce commun permet la* [*réunion*](https://github.com/nodejs/node/issues/1664#issuecomment-101828384) *des deux projets. Aujourd’hui, Node.js est l’une des plateformes de développement les plus populaires, en* [*passe de dépasser Java*](http://blog.builtinnode.com/post/node-js-will-overtake-java-within-a-year-analysis)*.* # Mozilla La gouvernance de nombreux projets portés par la Fondation Mozilla est mutualisée et explicitée sur une [page dédiée](https://www.mozilla.org/en-US/foundation/licensing/). # Métaphores Ces métaphores ont pour objet d'aider à comprendre les enjeux et tensions des communs numériques à travers l'exemple de communs matériels. ## Potager partagé Soit un potager partagé. L’espace est mis à disposition par la mairie à l’ensemble des résidents du quartier. L’objectif annoncé et clair est l’autosuffisance alimentaire du quartier, avec toute latitude laissée aux résidents pour gérer le potager. L’un des résidents, au lieu d’utiliser son espace pour se nourrir, utilise des engrais et vend sa récolte à d’autres résidents. Ceux-ci, n’ayant pas la main verte, lui offrent leur espace. Le jardinier obtient ainsi une superficie grandissante, et vend de plus en plus de fruits et légumes. Tant, en fait, qu’au bout de deux ans il cultive 95% de la surface du potager « partagé », et que seules trois autres résidentes ont appris à cultiver. Alors, l’autosuffisance alimentaire du quartier est-elle garantie ? La mairie est-elle légitime à reprendre le contrôle du terrain ? Les habitants des autres quartiers qui voient ainsi leurs impôts financer un jardinier qui, certes, nourrit son quartier, sont-ils pour autant fondés à lui demander une contrepartie ? ## Chemin de randonnée Un chemin de randonnée balisé par la FFRandonnée sur lequel personne ne marche pendant deux ans devient inutilisable pour tout le monde. Un cafetier décide d’établir une buvette sur l’un des embranchements d’un sentier entretenu depuis 20 ans et l’autre sentier, qui mène à un lac, est progressivement déserté. Le cafetier est-il responsable de la perte d’accès au lac ? Et s’il construit une piscine payante avec l’argent gagné par la buvette pour démontrer que le lac n’a aucun intérêt ? Est-il acceptable que la FFRandonnée doive investir en entretien et en promotion de l’autre sentier pour compenser l’intérêt du cafetier qui n’a pu, en premier lieu, s’installer à cet endroit que grâce au travail continu et en grande partie involontaire des marcheurs ? # Références Les publications suivantes sont référencées tout au long de cet ouvrage : * Aigrin, 2002 : [A framework for understanding the impact of GPL copylefting vs. non copylefting licenses](http://flosshub.org/system/files/aigrain2.pdf) (traduction : [Cadre de reflexion pour comprendre l'impact des licences libres du type “copyleft”](http://www.univ-paris1.fr/diplomes/master-droit-du-numerique/bibliotheque-numerique-du-droit-de-ladministration-electronique/tic/informatique/logiciel-libre/cadre-de-reflexion-pour-comprendre-limpact-des-licences-libres-du-type-copyleft/)). * Bellanger, 2014 : [Principes et pratiques des données personnelles en réseau](http://pierrebellanger.skyrock.com/3231110655-Principes-et-pratiques-des-donnees-personnelles-en-reseau.html). * Colin & Verdier, 2015 : [L'âge de la multitude](http://www.armand-colin.com/lage-de-la-multitude-2e-ed-entreprendre-et-gouverner-apres-la-revolution-numerique-9782200601447). * Coriat et al., 2015 : [Le retour des communs](http://www.editionslesliensquiliberent.fr/livre-Le_retour_des_communs-9791020902726-1-1-0-1.html). * Coriat, 2017 : [Conférence Le commun et le numérique](http://www.sciencespo-aix.fr/agenda/?date=2017-05) du 31/05/2017 à Sciences Po Aix. * Dardot, 2017 : [Conférence Le commun et le numérique](http://www.sciencespo-aix.fr/agenda/?date=2017-05) du 31/05/2017 à Sciences Po Aix. * Maurel, 2016 : [Ériger le réseau des données personnelles en bien commun](https://scinfolex.com/2016/01/15/eriger-le-reseau-des-donnees-personnelles-en-bien-commun/) * Rogers, 1962 : [Diffusion of Innovations](https://books.google.fr/books?id=v1ii4QsB7jIC). * Verdier & Murciano, 2015 : [Les communs numériques : éléments d’économie politique](http://events.chairefdd.org/wp-content/uploads/2016/04/CAHIER_FDD_69.pdf). ## Bibliographie Ces ouvrages sont une lecture recommandée pour aller plus loin : * Dardot & Laval, 2014, [Commun](http://www.editionsladecouverte.fr/catalogue/index-commun-9782707169389.html). * Ostrom, 1990 : [Governing the commons](http://www.wtf.tw/ref/ostrom_1990.pdf). # English abstract This article suggests decomposing digital services into a series of components on which to apply rules for sharing in order for them to operate as digital commons through the resulting governance. These components are: source code, usage rights, data produced by users, usage data, means of communication, brand, and modes of evolution. Missing to appropriately share any of these components opens up loopholes that enable the reenclosure of resources necessary to the operation of the service as a digital common in the medium or long term. For each of these component, this article defines basic constraints to be applied on the rules to guarantee their sustainability. Additional constraints are also suggested for services whose value depends on the active contribution of their community, since this contribution capacity is directly correlated to the time invested by its members and is therefore a rival resource. This framework highlights aspects of digital services that are often considered peripheral and facilitates the definition of a governance appropriate for a sustainable community operation. # Remerciements Ces personnes ont permis à cet ouvrage d'être ce qu'il est aujourd'hui : * David Bruant * Henri Verdier * Laurent Bossavit * Laurent Joubert * Mauko Quiroga * Philippe Honigman * Sandra Chakroun * Vincent B # Changelog Ce document évolue dans le temps. Le journal des modifications ci-dessous décrit ses évolutions et les regroupe sous des numéros de version suivant la spécification [SemVer](https://semver.org/lang/fr/), afin de permettre d'en référencer des versions spécifiques. ### v1.2.0 (19/08/2021) * Fusionne les parties « Gouvernance » et « Acteurs » en une seule section « Rôles », organisée autour des risques adressés par les rôles (pourquoi il faut les tenir) et des formes juridiques possibles (qui peut les tenir). * Éclate le constituant Données en Données et Statistiques au vu du faible nombre de cas réels où les statistiques sont ouvertes. * Renomme et précise le constituant Communauté en Communication. * Précise le constituant Stratégie. * Réécrit l'introduction de la partie Constituants et y intègre la grille de synthèse. * Renomme les recommandations « pour les acteurs publics » en « opérationnelles », car il n'y a que peu de cas où elles sont réellement spécifiques aux acteurs publics. * Réorganise les pages en groupes. * Ajout du terme « code of conduct ». * Ajout de l'ops dans le constituant Code source. * Ajout du changelog. #### v1.1.2 (09/02/2020) * Corrige la forme de l'analyse de Docker. #### v1.1.1 (15/12/2018) * Reformulation mineure. ### v1.1.0 (25/02/2018) * Modifie le calcul du SLA. ## v1.0.0 (08/01/2018) * Première publication. ## v0 (août 2017) * Première présentation interne à la DINUM. # Format et PDF Ce livre est mis à disposition par le biais d'un [GitBook](https://www.gitbook.com), un système d'édition basé sur le logiciel de gestion de version collaboratif Git. Cela signifie que vos contributions sont bienvenues et espérées ! Si vous trouvez des fautes, des formulations trop lourdes, ambiguës, ou encore si vous avez des retours d'expérience ou des recommandations alternatives, [corrigez le texte](https://github.com/MattiSG/construire-communs-numeriques) directement (si vous ne savez pas comment faire, passez par un commentaire via le bouton `+` qui apparaît quand vous survolez un paragraphe avec votre souris). ### Téléchargement Vous pouvez lire ce livre [en ligne](https://communs.mattischneider.fr) ou le télécharger au format [PDF](https://github.com/MattiSG/livre-blanc-communs-numeriques/blob/traduction/assets/construire_communs_numeriques_v1_2_0.pdf). # Licence Ce livre vous est offert sous une licence [CC-BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.fr). Cela signifie que vous pouvez le lire, le distribuer, le citer, le modifier et l'adapter comme bon vous semble, y compris de manière commerciale, tant que : * Vous accompagnez l’utilisation d’un lien vers `communs.mattischneider.fr`. * Le contenu que vous créez sur la base de celui-ci est sous une licence similaire, c’est-à-dire qu’il n’interdit à personne de réutiliser vos améliorations. Pour plus de détails, vous pouvez lire la [licence complète](https://creativecommons.org/licenses/by-sa/4.0/deed.fr).