├── LICENSE.pdf ├── docs ├── pocos-dinsic-stable.pdf └── pocos-dinsic-18052018.pdf ├── comptes-organismes-publics-autres-forges ├── bibliotheques-organismes-publics ├── instanciation.en.md ├── MAINTAINERS ├── instanciation.md ├── README.en.md ├── comptes-organismes-avec-politique-de-publication-floss.csv ├── DCO-fr.txt ├── README.md ├── gouvernance.en.md ├── gouvernance.md ├── comptes-organismes-publics-esr ├── introduction.en.md ├── introduction.md ├── ouverture.en.md ├── faq.en.md ├── faq.md ├── ouverture.md ├── LICENSE ├── comptes-organismes-publics ├── pratique.en.md └── pratique.md /LICENSE.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DISIC/politique-de-contribution-open-source/HEAD/LICENSE.pdf -------------------------------------------------------------------------------- /docs/pocos-dinsic-stable.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DISIC/politique-de-contribution-open-source/HEAD/docs/pocos-dinsic-stable.pdf -------------------------------------------------------------------------------- /docs/pocos-dinsic-18052018.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DISIC/politique-de-contribution-open-source/HEAD/docs/pocos-dinsic-18052018.pdf -------------------------------------------------------------------------------- /comptes-organismes-publics-autres-forges: -------------------------------------------------------------------------------- 1 | https://forge.clermont-universite.fr 2 | https://adullact.net/projects/ines-libre/ 3 | https://gforge.inria.fr 4 | https://adullact.net/projects/place-orme-src/ 5 | https://sourcesup.renater.fr 6 | https://dev-eole.ac-dijon.fr 7 | 8 | -------------------------------------------------------------------------------- /bibliotheques-organismes-publics: -------------------------------------------------------------------------------- 1 | https://www.npmjs.com/search?q=%40dataesr 2 | https://www.npmjs.com/search?q=%40etalab 3 | https://www.npmjs.com/search?q=%40gouvfr 4 | https://www.npmjs.com/search?q=%40ircam 5 | https://www.npmjs.com/search?q=%40socialgouv 6 | https://www.npmjs.com/search?q=%40opendatateam 7 | https://pypi.org/user/etalab/ 8 | https://pypi.org/user/opendatateam/ 9 | -------------------------------------------------------------------------------- /instanciation.en.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Instantiate a local Contribution Policy 3 | menu: 4 | main: 5 | name: "Instantiate" 6 | weight: 40 7 | --- 8 | 9 | ## In summary 10 | 11 | * Ability to instantiate and amend this policy 12 | * Contact the "parent" policy to inform about the declination 13 | * Provide a mean of contact for the instantiated policy 14 | 15 | ## Inventories of instantiated departmental policies 16 | 17 | * No ministerial policy instantiated to date 18 | * Example: < Ministry XXX >: [http: //reference.url/ministerialpolicy](http: //reference.url/ministerialpolicy) 19 | 20 | ## Instantiation procedure 21 | 22 | 1. Fork this repository to initiate your departmental policy 23 | 2. Make a pull request on this file to list the child contribution policy and its URL 24 | 3. Contact the support of this policy and validate the main contact of the child policy 25 | 26 | Do not hesitate to contact us for any questions. 27 | -------------------------------------------------------------------------------- /MAINTAINERS: -------------------------------------------------------------------------------- 1 | [Interministériel] 2 | 3 | DINUM : 4 | 5 | * Bastien Guerry (bzg) 6 | 7 | ANSSI : 8 | 9 | * Arnaud Fontaine (af-anssi) 10 | 11 | [Ministériel] 12 | 13 | Ministères : 14 | 15 | * Affaires sociales et santé : Julien Bouquillon (revolunet) 16 | * Agriculture : Frédéric Bronnert (fredericbronnert) 17 | * Agriculture : Sylvain Perrinel (Pinpin31) 18 | * Armées : Philippe Debraize (DEBRAIZE) 19 | * Culture : Pierre Le Clainche (plecmc) 20 | * Education : Florent Barth (bartman21) 21 | * Education : Luc Bourdot (luceole) 22 | * Enseignement supérieur et recherche : Abdelkader Karik (Mechayem) 23 | * Intérieur : Alain Barbay (alain-barbay) 24 | * Intérieur : Jean-Charles Bastoul 25 | * Intérieur : Simon Cavey (SimonCavey) 26 | * MEF / DGFiP : Thierry Aimé (yrtvkuj) 27 | * MTES/MCT : Nicolas Chuche (nchuche) 28 | 29 | [Autre] 30 | 31 | * Cour des Comptes : Adrien Geffroy (ageffroy) 32 | 33 | Contributeurs : 34 | 35 | * Développeur web: Hugues Moreno (hmore) 36 | -------------------------------------------------------------------------------- /instanciation.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Instanciation des politiques de contribution ministérielles 3 | menu: 4 | main: 5 | name: "Instanciation" 6 | weight: 40 7 | --- 8 | 9 | ## En résumé 10 | 11 | * Possibilité d'instancier et de reprendre cette politique 12 | * Contacter la politique « mère » pour informer de la déclinaison 13 | * Fournir obligatoirement un moyen de contact pour la politique instanciée 14 | 15 | ## Inventaires des politiques ministérielles instanciées 16 | 17 | * Aucune politique ministérielle instanciée à ce jour 18 | * Exemple : : [http://reference.url/politique-ministerielle](http://reference.url/politique-ministerielle) 19 | 20 | ## Procédure d'instanciation 21 | 22 | 1. Fourcher ce dépôt pour initier votre politique ministérielle 23 | 2. Faire une pull request sur ce fichier pour lister la politique de contribution fille et son URL 24 | 3. Contacter le support de cette politique (`opensource@data.gouv.fr`) et valider le moyen de contact principal de la politique fille 25 | 26 | N'hésitez pas à prendre contact avec nous pour toute question. 27 | -------------------------------------------------------------------------------- /README.en.md: -------------------------------------------------------------------------------- 1 | # Open Source contribution policy 2 | 3 | Welcome to the DINUM Free Software Contribution Policy. 4 | 5 | > UPDATE November, 2021: This document is being obsoleted by the free software and digital commons action plan: see https://[communs.numerique.gouv.fr](https://communs.numerique.gouv.fr). 6 | 7 | > UPDATE March 13, 2018: The document has been validated at the February 15th, 2018 CSIC Tech. 8 | 9 | The purpose of this document is to describe HOW to open source codes according to best practices. 10 | 11 | To know which source codes should be open, please refer to the Law for a Digital Republic. 12 | 13 | [comptes-organismes-publics](comptes-organismes-publics) contains a list of URLs for source code of public organizations (work in progress). This list allows to build the [dataset of source code repositories from the public sector](https://www.data.gouv.fr/fr/datasets/inventaire-des-depots-de-code-source-des-organismes-publics), which you can browse on [code.etalab.gouv.fr](https://code.etalab.gouv.fr). 14 | 15 | The [data-codes-sources-fr](https://github.com/etalab/data-codes-sources-fr) collects metadata for all source code repositories from this list. 16 | 17 | This document is published under the [Open License 2.0](LICENSE.pdf). 18 | -------------------------------------------------------------------------------- /comptes-organismes-avec-politique-de-publication-floss.csv: -------------------------------------------------------------------------------- 1 | organisation,url-politique-floss 2 | https://github.com/betagouv,https://doc.incubateur.net/startups/developpement/licences 3 | https://github.com/medialab,https://medialab.sciencespo.fr/a-propos/#deontology 4 | https://gitlab.com/healthdatahub,https://www.health-data-hub.fr/open-source 5 | https://github.com/etalab,https://www.etalab.gouv.fr/accompagnement-logiciels-libres 6 | https://framagit.org/etalab,https://www.etalab.gouv.fr/accompagnement-logiciels-libres 7 | https://github.com/MTES-MCT,https://doc.incubateur.net/startups/developpement/licences 8 | https://github.com/SocialGouv,https://doc.incubateur.net/startups/developpement/licences 9 | https://github.com/StartupsPoleEmploi,https://doc.incubateur.net/startups/developpement/licences 10 | https://github.com/incubateur-territoires,https://doc.incubateur.net/startups/developpement/licences 11 | https://github.com/minagri-initial,https://doc.incubateur.net/startups/developpement/licences 12 | https://github.com/LAB-MI,https://doc.incubateur.net/startups/developpement/licences 13 | https://gitlab.com/fabnum-minarm,https://doc.incubateur.net/startups/developpement/licences 14 | https://github.com/fabnumdef,https://doc.incubateur.net/startups/developpement/licences 15 | https://github.com/abes-esr,https://github.com/abes-esr/abes-politique-developpement 16 | -------------------------------------------------------------------------------- /DCO-fr.txt: -------------------------------------------------------------------------------- 1 | Developer Certificate of Origin 2 | Version 1.1 3 | 4 | Certificat d'origine des contributions du développeur : 5 | 6 | En faisant une contribution à ce projet, j’atteste que : 7 | 8 | (a) Ma contribution a été créée en tout ou partie par moi, et que j’ai 9 | le droit de la soumettre sous la licence applicable au projet; ou 10 | que 11 | 12 | (b) Ma contribution s’appuie sur des travaux antérieurs qui, à ma 13 | connaissance, sont couverts par une licence open source et que 14 | j’ai le droit sous cette licence de soumettre cette contribution 15 | avec mes modifications, créées en tout ou partie par moi, sous la 16 | licence applicable au projet; ou que 17 | 18 | (c) La contribution m’a été offerte par un tiers qui a certifié que 19 | les points (a), (b) ou (c) ont été respectés et que je n’ai pas 20 | modifié cette contribution. 21 | 22 | (d) Je comprends et accepte que ce projet et ma contribution sont 23 | publics, et qu’un enregistrement de cette contribution (comprenant 24 | également l’ensemble des informations à caractère personnel me 25 | concernant et notamment ma signature) soit attaché indéfiniment à 26 | ce projet et qu’il peut librement être rediffusé à des tiers 27 | conformément à la licence applicable au projet ou aux autres 28 | licences impliquées. 29 | 30 | Certificat d'origine des contributions du développeur est une 31 | traduction et a été conçu pour être compatible avec sa version 32 | anglaise (même numéro de version) qui peut être utilisée 33 | indifféremment. 34 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | **Ce dépôt est en voie d'archivage**. 2 | 3 | Pour ajouter un compte d'organisation à référencer, voir [ce dépôt](https://git.sr.ht/~etalab/codegouvfr-sources) et envoyer un mail à [logiciels-libres@data.gouv.fr](mailto:logiciels-libres@data.gouv.fr). 4 | 5 | Une partie du contenu de la politique de contribution sera prochainement réintégré dans [les guides](https://communs.numerique.gouv.fr/guides/) publiés par le pôle logiciels libres d'Etalab. 6 | 7 | Pour vous tenir informés, [inscrivez-vous à la gazette BlueHats](https://infolettres.etalab.gouv.fr/subscribe/bluehats@mail.etalab.studio). 8 | 9 | # Modalités d'ouverture des codes sources 10 | 11 | Bienvenue sur la politique de contribution aux logiciels libres de la DINUM. 12 | 13 | > MISE A JOUR du 13 mars 2018: La politique de contribution aux logiciels libre a été validée au CSIC Tech du 15 février 2018. 14 | 15 | L'objectif de ce document est de décrire COMMENT ouvrir les codes sources en respectant les bonnes pratiques. 16 | 17 | Pour savoir quels sont les codes sources qui doivent être ouverts, veuillez vous référer à la loi pour une République numérique ou à ce [guide interactif pour l'ouverture des codes sources](https://guide-juridique-logiciel-libre.etalab.gouv.fr/). 18 | 19 | Vous trouverez dans le fichier [comptes-organismes-publics](comptes-organismes-publics) une liste de points d'accès à des codes sources d'organismes publics. Celle-ci permet de construire [l'inventaire des dépôts de code source des organismes publics](https://www.data.gouv.fr/fr/datasets/inventaire-des-depots-de-code-source-des-organismes-publics/), inventaire vous pouvez parcourir sur [code.etalab.gouv.fr](https://code.etalab.gouv.fr). La liste est en construction, n'hésitez pas à la compléter. 20 | 21 | Ce document est publié sous la [Licence Ouverte 2.0][LO link]. 22 | 23 | Il est aussi téléchargeable [au format PDF](docs/pocos-dinsic-stable.pdf). 24 | 25 | [LO link]: https://github.com/DISIC/politique-de-contribution-open-source/raw/master/LICENSE.pdf 26 | -------------------------------------------------------------------------------- /gouvernance.en.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Governance of the Interdepartmental Contribution Policy 3 | menu: 4 | main: 5 | name: "Governance" 6 | weight: 50 7 | --- 8 | 9 | The DINUM maintains this document and is responsible for it (it owns the repository and manages the permissions). The development of this policy aims to be collaborative and the entities to which it applies are all invited to participate in its development. 10 | 11 | Two types of organizations are distinguished: 12 | 13 | * Interdepartmental: DINUM and ANSSI 14 | * Ministry 15 | 16 | with only one role per organization (write permission on this policy). All contributors with write permissions are listed in the [MAINTAINERS](https://github.com/DISIC/politique-de-contribution-open-source/blob/master/MAINTAINERS) file. 17 | 18 | ## Management of contributions 19 | 20 | All contributions are welcome. They are made via a *pull request* on the branch `next` which is the branch of the next version of the policy. 21 | 22 | * pull request with **major** changes must be approved by at least three other ministerial organizations and the ANSSI. 23 | 24 | * pull requests with **minor** changes must be approved by at least one other departmental organization. 25 | 26 | All maintainers have the ability to merge *pull requests* on the `next` branch. If several maintainers belong to the same department, their validation only counts for one organization. 27 | 28 | ## Version Management 29 | 30 | Only the DINUM and the ANSSI can merge to the `master` branch which corresponds to the validated version: 31 | 32 | * At each merge on the `master` branch a tag is added according to the` v [MAJOR] v. [MINOR] `scheme according to the approved *pull requests* on the` next` branch. 33 | 34 | * The open source contribution policy can be modified for slight changes (typos, etc.) without updating the version (semver PATCH numbers are ignored) directly on the `master` branch. 35 | 36 | All modifications can be done at any given time. Discussions and comments are logged in the comments of the *pull request*. 37 | -------------------------------------------------------------------------------- /gouvernance.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Gouvernance de la politique de contribution interministérielle 3 | menu: 4 | main: 5 | name: "Gouvernance" 6 | weight: 50 7 | --- 8 | 9 | La DINUM maintient ce document et en est responsable (elle est propriétaire du dépôt et de la gestion des droits d'écriture). L'élaboration de cette politique a vocation à être collaborative et les entités auxquelles elle s'applique sont toutes invitées à participer à son évolution. 10 | 11 | Deux types d'organisations sont distinguées : 12 | 13 | * Interministériel : DINUM et ANSSI 14 | * Ministériel 15 | 16 | avec un seul rôle par organisation (droit d'écriture sur cette politique). L'ensemble des contributeurs avec les droits d'écriture sont listés dans le fichier [MAINTAINERS](https://github.com/DISIC/politique-de-contribution-open-source/blob/master/MAINTAINERS). 17 | 18 | ## Gestion des contributions 19 | 20 | Toutes les contributions sont les bienvenues. Elles sont faites via une *pull request* sur la branche `next` qui est la branche d'élaboration d'une nouvelle version de la politique. 21 | 22 | * les `pull request` apportant des modifications **majeures** doivent être approuvées par au moins trois autres organisations ministérielles et l'ANSSI. 23 | 24 | * les `pull request` apportant des modifications **mineures** doivent être approuvées par au moins une autre organisation ministérielle. 25 | 26 | Tous les mainteneurs ont la possibilité de fusionner les *pull requests* sur la branche `next`. Si plusieurs mainteneurs appartiennent à un même ministère, leur validation ne compte que pour une organisation. 27 | 28 | ## Gestion des versions 29 | 30 | Seules la DINUM et l'ANSSI peuvent fusionner sur la branche `master` qui correspond à la version validée : 31 | 32 | * À chaque fusion sur la branche `master` un tag est ajouté suivant le schéma `v[MAJEUR].[MINEUR]` en fonction des *pull requests* approuvées sur la branche `next`. 33 | 34 | * La politique de contribution open source peut être modifiée pour des changements légers (coquilles, etc.) sans mise à jour version (les numéros de PATCH de semver sont ignorés) directement sur la branche `master`. 35 | 36 | Toutes les modifications peuvent être faites au fil de l'eau. Les discussions et commentaires sont tracées dans les commentaires de la *pull request*. 37 | -------------------------------------------------------------------------------- /comptes-organismes-publics-esr: -------------------------------------------------------------------------------- 1 | https://forge.grandlyon.com 2 | https://forgemia.inra.fr 3 | https://framagit.org/parcoursup 4 | https://framagit.org/synalp 5 | https://git.cines.fr/dad 6 | https://git.unicaen.fr/open-source 7 | https://git.unicaen.fr/pdn-certic 8 | https://github.com/BRGM 9 | https://github.com/CCSDForge 10 | https://github.com/CNRS-DSI-Dev 11 | https://github.com/CatalaLang 12 | https://github.com/DIVERSIFY-project 13 | https://github.com/Deducteam 14 | https://github.com/EsupPortail 15 | https://github.com/GHFC 16 | https://github.com/Geographie-cites 17 | https://github.com/IGNF 18 | https://github.com/INRA 19 | https://github.com/INSIDE-information-systems 20 | https://github.com/Icy-imaging 21 | https://github.com/Ifsttar 22 | https://github.com/Inist-CNRS 23 | https://github.com/InriaMecsci 24 | https://github.com/Irstea 25 | https://github.com/LETG 26 | https://github.com/OPIDoR 27 | https://github.com/OpenEdition 28 | https://github.com/SimPLU3D 29 | https://github.com/Spirals-Team 30 | https://github.com/X-DataInitiative 31 | https://github.com/atlanmod 32 | https://github.com/cea-hpc 33 | https://github.com/cea-leti 34 | https://github.com/cea-list 35 | https://github.com/cea-sec 36 | https://github.com/ctools 37 | https://github.com/diverse-project 38 | https://github.com/elabftw 39 | https://github.com/ezpaarse-project 40 | https://github.com/gammalib 41 | https://github.com/genotoul-bioinfo 42 | https://github.com/inrae 43 | https://github.com/inria 44 | https://github.com/ivre 45 | https://github.com/linbox-team 46 | https://github.com/medialab 47 | https://github.com/metwork-framework 48 | https://github.com/neuroanatomy 49 | https://github.com/openfun 50 | https://github.com/powerapi-ng 51 | https://github.com/riatelab 52 | https://github.com/sympa-community 53 | https://github.com/unistra 54 | https://github.com/vle-forge 55 | https://gitlab.adullact.net/UPSud 56 | https://gitlab.ccsd.cnrs.fr 57 | https://gitlab.cerema.fr 58 | https://gitlab.com/cortext 59 | https://gitlab.huma-num.fr 60 | https://gitlab.in2p3.fr/Enssib 61 | https://gitlab.inria.fr/belenios 62 | https://gitlab.inria.fr/cedar/ 63 | https://gitlab.inria.fr/coquelicot 64 | https://gitlab.inria.fr/dsi_public 65 | https://gitlab.inria.fr/openvibe 66 | https://gitlab.inria.fr/stopcovid19 67 | https://gitlab.inria.fr/verifisc 68 | https://gitlab.inria.fr/vidjil 69 | https://gitlab.irstea.fr 70 | https://gitlab.orfeo-toolbox.org 71 | https://gitub.u-bordeaux.fr 72 | https://github.com/HolAutisme 73 | https://github.com/OpenFLUID 74 | https://github.com/abes-esr 75 | https://gitlab.math.unistra.fr 76 | https://github.com/iscpif 77 | https://github.com/istex 78 | https://github.com/gemoc 79 | https://github.com/openmole 80 | https://github.com/imagesdesmaths 81 | https://github.com/BibCnrs 82 | https://github.com/dsi-ehess 83 | https://gitlab.u-psud.fr 84 | https://github.com/MLanguage 85 | https://github.com/guix-mirror 86 | https://github.com/coq 87 | https://gitlab.inria.fr/why3 88 | https://github.com/ocaml 89 | https://github.com/Antique-team 90 | https://gricad-gitlab.univ-grenoble-alpes.fr 91 | https://github.com/gip-recia 92 | https://github.com/dataesr 93 | https://github.com/plantnet 94 | https://github.com/INHAParis 95 | https://gitlab.fresnel.fr 96 | https://gitlab.mbb.cnrs.fr 97 | https://github.com/ifremer-bioinformatics 98 | https://gitlab-research.centralesupelec.fr 99 | -------------------------------------------------------------------------------- /introduction.en.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Contribution Policy for Free Software of the State 3 | menu: 4 | main: 5 | name: "Introduction" 6 | weight: 10 7 | --- 8 | 9 | __History and versions__ 10 | 11 | | Version | Comment | Date | 12 | |---------|----------------------------------|------------| 13 | | 0.1 | Initialization | 01/11/2017 | 14 | | 0.2 | Opening of the call for comments | 06/12/2017 | 15 | | 0.3 | End of the call for comments | 28/01/2018 | 16 | | 1.0RC01 | Project submitted to validation | 02/10/2018 | 17 | | 1.0 | Validated | 16/02/2018 | 18 | | 1.1 | Validated | 09/09/2019 | 19 | 20 | ## Objectives 21 | 22 | Under the Law for a Digital Republic of [October 7, 2016][LoiRepNum link], source codes are administrative documents that are communicable and reusable. In the case where it is possible to choose an Open Source license, the decree [n ° 2017-638 of April 27, 2017][DecretLicences link] specifies the families of licenses that can be used. The detailed list of the licenses and their versions are available on the website [data.gouv.fr][Licenses link]. 23 | 24 | The objectives of this interdepartmental Open Source contribution policy are: 25 | 26 | * set the rules and principles for opening source codes 27 | * support the ministries and share good practices 28 | * define the governance. 29 | 30 | This document is intended for developers or their managers, whether they are public servants (officials 31 | or contractual) or service providers. 32 | 33 | ## Scope 34 | 35 | This contribution policy applies to the state's information and communication system in accordance with Article 1 of [Decree No. 2014-879 of 1 August 2014][DecretDINUM link]. Each state administration has the opportunity to instantiate its own contribution policy to clarify and amend it. 36 | 37 | Source codes covered by this policy are the ones: 38 | 39 | * developed internally by the administration 40 | * developed on behalf of the administration. 41 | 42 | This contribution policy aims at *new* developments. For the opening of existing source codes, additional actions will be needed, such as defining the scope, reviewing quality and security, and ensuring compliance specifically on intellectual property. 43 | 44 | Public hospital and local governments are outside the scope of this contribution policy. 45 | 46 | ## Document structure 47 | 48 | The contribution policy is composed of: 49 | 50 | * [Principles of opening of source codes](ouverture.en.md) 51 | * [Best practices](pratique.en.md) 52 | * [Local Contribution Policy Instantiation](instanciation.en.md) 53 | * [Associated governance](gouvernance.en.md) 54 | 55 | ## Responsibility of the document 56 | 57 | The DINUM produces and maintains this document; it ensures its implementation and the associated support. For any questions, or requests for changes, please refer to the *Governance* section. 58 | 59 | This document is published under the [Open License 2.0][LO link] 60 | 61 | ## External references 62 | 63 | This document was developed thanks to the many works below: 64 | 65 | * [Open Government Partnership collaboration](https://github.com/DISIC/foss-contrib-policy-template) 66 | * [USA 18F Open Source Policy](https://github.com/18F/open-source-policy/blob/master/CONTRIBUTING.md) 67 | * [Whitehouse Source Code Policy](https://sourcecode.cio.gov) 68 | * [UK GDS (Government Digital Service)](http://gds-operations.github.io/guidelines/) 69 | * [Canada British Columbia](https://github.com/bcgov/BC-Policy-Framework-For-GitHub) 70 | * [Australia Digital Transformation Agency](https://www.dta.gov.au/standard/8-make-source-code-open/) 71 | * [Linux Foundation Open Source Guides](https://www.linuxfoundation.org/resources/open-source-guides/) 72 | * [Core Infrastructure Initiative](https://bestpractices.coreinfrastructure.org) 73 | * [Open Source Guides](https://opensource.guide) 74 | * [FSFE software reuse](https://reuse.software) 75 | * [Google Open Source](http://opensource.google.com) 76 | 77 | Work is also underway by the Government of Canada: [https://github.com/canada-ca/Open_First_Whitepaper](https://github.com/canada-ca/Open_First_Whitepaper) 78 | 79 | 80 | 81 | [Logo LO]: https://www.etalab.gouv.fr/wp-content/uploads/2011/10/licence-ouverte-open-licence.gif 82 | [LO link]: https://github.com/DISIC/politique-de-contribution-open-source/raw/master/LICENSE.pdf 83 | [LoiRepNum link]: https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=6E9C9BD1F4AAF6E6FD525E8FE902A615.tplgfr26s_2?cidTexte=JORFTEXT000033202746&categorieLien=id 84 | [DecretDINUM link]: https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=6E9C9BD1F4AAF6E6FD525E8FE902A615.tplgfr26s_2?cidTexte=JORFTEXT000029337021&idArticle=&dateTexte=20171101 85 | [DecretLicences link]: https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000034502557&categorieLien=id 86 | [Licenses link]: https://www.data.gouv.fr/fr/licences 87 | -------------------------------------------------------------------------------- /introduction.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Politique de contribution aux logiciels libres de l’État 3 | menu: 4 | main: 5 | name: "Introduction" 6 | weight: 10 7 | --- 8 | 9 | __Historique et versions__ 10 | 11 | | Version | Commentaire | Date | 12 | | -------- | ------------------------------------------------- | ------------ | 13 | | 0.1 | Initialisation | 01/11/2017 | 14 | | 0.2 | Ouverture de l'appel à commentaires | 06/12/2017 | 15 | | 0.3 | Fin de l'appel à commentaires | 28/01/2018 | 16 | | 1.0RC01 | Projet soumi à validation | 10/02/2018 | 17 | | 1.0 | Validation en CSIC Tech | 16/02/2018 | 18 | | 1.1 | Validation par les contributeurs | 9/09/2019 | 19 | 20 | ## Objectifs 21 | 22 | Conformément à la Loi pour une République numérique du [7 octobre 2016][LoiRepNum link], les codes sources sont des documents administratifs communicables et réutilisables. Dans le cas où il est possible de choisir une licence libre, le décret [n° 2017-638 du 27 avril 2017][DecretLicences link] précise les familles de licences qui peuvent être utilisées. La liste détaillée des licences avec leurs versions est disponible sur le site [data.gouv.fr][Licenses link]. 23 | 24 | Les objectifs de cette politique interministérielle de contribution aux logiciels libres sont de : 25 | 26 | * fixer les règles et principes à respecter pour l'ouverture des codes sources 27 | * accompagner les ministères et partager les bonnes pratiques 28 | * définir la gouvernance des politiques de contribution de l'État. 29 | 30 | Ce document est à destination des développeurs ou de leurs responsables, qu'ils soient agents publics (titulaires ou contractuels) ou prestataires. 31 | 32 | ## Périmètre 33 | 34 | Cette politique de contribution s'applique au système d'information et de communication de l'État conformément à l'article 1er du [décret n° 2014-879 du 1er août 2014][DecretDINUM link]. Chaque administration de l'État a la possibilité d'instancier sa propre politique de contribution pour la préciser et l'amender. 35 | 36 | Sont concernés l'ensemble des codes sources : 37 | 38 | * développés en interne par l'administration 39 | * développés pour le compte de l'administration. 40 | 41 | Cette politique de contribution vise les *nouveaux* développements afin qu'ils respectent les bonnes pratiques. Pour l'ouverture de codes sources existants, des actions complémentaires seront nécessaires, telles que la définition du périmètre d'ouverture du code, sa revue qualité, sa revue sécurité, l'analyse de conformité et l'analyse de la propriété intellectuelle. 42 | 43 | Les fonctions publiques hospitalières et territoriales sont hors périmètre de cette politique de contribution mais elles peuvent s'en inspirer librement. 44 | 45 | ## Structure du document 46 | 47 | La politique de contribution est composée de : 48 | 49 | * [Principes d’ouverture des codes sources](ouverture.md) 50 | * [Modalités et bonnes pratiques](pratique.md) 51 | * [Instanciation de politique de contribution ministérielle](instanciation.md) 52 | * [Gouvernance associée](gouvernance.md) 53 | 54 | ## Responsabilité du document 55 | 56 | La DINUM produit et maintient ce document ; elle veille à sa mise en œuvre et assure le support associé. Pour toute question, ou demande d'évolutions, veuillez vous référer à la partie *Gouvernance*. 57 | 58 | Ce document est publié sous la [**Licence Ouverte 2.0**][LO link] 59 | 60 | ## Références externes 61 | 62 | Ce document a été élaboré grâce aux nombreux travaux ci-dessous : 63 | 64 | * [Open Government Partnership collaboration](https://github.com/DISIC/foss-contrib-policy-template) 65 | * [USA 18F Open Source Policy](https://github.com/18F/open-source-policy/blob/master/CONTRIBUTING.md) 66 | * [Whitehouse Source Code Policy](https://sourcecode.cio.gov) 67 | * [UK GDS (Government Digital Service)](http://gds-operations.github.io/guidelines/) 68 | * [Canada British Columbia](https://github.com/bcgov/BC-Policy-Framework-For-GitHub) 69 | * [Australia Digital Transformation Agency](https://www.dta.gov.au/standard/8-make-source-code-open/) 70 | * [Linux Foundation Open Source Guides](https://www.linuxfoundation.org/resources/open-source-guides/) 71 | * [Core Infrastructure Initiative](https://bestpractices.coreinfrastructure.org) 72 | * [Open Source Guides](https://opensource.guide) 73 | * [FSFE software reuse](https://reuse.software) 74 | * [Google Open Source](http://opensource.google.com) 75 | 76 | Un travail est également en cours par le gouvernement du Canada : [https://github.com/canada-ca/Open_First_Whitepaper](https://github.com/canada-ca/Open_First_Whitepaper) 77 | 78 | [Logo LO]: https://www.etalab.gouv.fr/wp-content/uploads/2011/10/licence-ouverte-open-licence.gif 79 | [LO link]: https://github.com/DISIC/politique-de-contribution-open-source/raw/master/LICENSE.pdf 80 | [LoiRepNum link]: https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=6E9C9BD1F4AAF6E6FD525E8FE902A615.tplgfr26s_2?cidTexte=JORFTEXT000033202746&categorieLien=id 81 | [DecretDINUM link]: https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=6E9C9BD1F4AAF6E6FD525E8FE902A615.tplgfr26s_2?cidTexte=JORFTEXT000029337021&idArticle=&dateTexte=20171101 82 | [DecretLicences link]: https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000034502557&categorieLien=id 83 | [Licenses link]: https://www.data.gouv.fr/fr/licences 84 | -------------------------------------------------------------------------------- /ouverture.en.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Opening Principles of source codes 3 | menu: 4 | main: 5 | name: "Principles" 6 | weight: 20 7 | --- 8 | 9 | ## Preamble 10 | 11 | ### Principle of subsidiarity 12 | 13 | Politics can be instantiated locally with a higher priority. 14 | 15 | See the [instantiation](Instanciation.md) section if you want to decline this policy within your organization. 16 | 17 | ### Contribution Policy Assistance 18 | 19 | Contact `opensource @ data.gouv.fr` for any questions about this policy. 20 | 21 | ## Principle of attribution of contributions 22 | 23 | ### Attribute contributions to individuals 24 | 25 | In order to recognize authorship, the developer's individual email address is used: 26 | 27 | * For agents: use of the professional email address. 28 | * For service providers, use the email address of their company (no contractor email address provided by the administration) 29 | 30 | If a developer does not wish to see his identity published, he can use a pseudonym. On the other hand, the use of generic or anonymous email addresses should be avoided. 31 | 32 | ### Differentiate professional and personal contributions 33 | 34 | It is possible for a developer to contribute on the same project professionally and privately. The State is recognizing developers' property on contributions made outside of working time. Contributions made to the professional time must be associated with a professional email address. 35 | 36 | ## Contribute to third-party projects 37 | 38 | ### Default permission to contribute to FSF or OSI licensed projects 39 | 40 | Contributions to existing projects with FSF or OSI licenses are allowed by default. Licenses validated by the Free Software Foundation and Open Source Initiative and listed on their respective pages: 41 | 42 | * FSF: [https://www.gnu.org/licenses/license-list.fr.html](https://www.gnu.org/licenses/license-list.fr.html) (excluding non-free licenses presented as such); 43 | * OSI: [https://opensource.org/licenses/alphabetical](https://opensource.org/licenses/alphabetical). 44 | 45 | 46 | Conversely, licenses not retained by these organizations (such as * Beerware *) do not fall under the default authorization. A consolidated table of licenses validated by one or the other organization is maintained on the site [https://spdx.org/licenses/](https://spdx.org/licenses) 47 | 48 | ### Signature of *Corporate Contributor License Agreement* 49 | 50 | The DINUM is responsible for signing the Corporate Contributor License Agreement (CCLA) with the communities or companies that require it, in order to allow the professional contributions of the civil servant. If this is requested by the other party, it will maintain a lists of individuals covered by the agreement. Another possibility is that the CCLA is a prerequisite for signing an individual Contributor License Agreement (iCLA). In this case, the signature of a CCLA by the DINUM will serve as a pre-authorization to sign iCLA. 51 | 52 | If you wish to contribute to a project requiring this type of formalism, whether it is to sign a CCLA, add you to the list of authorized contributors, or check the possibility of signing an iCLA, contact the assistance address indicated above. 53 | 54 | List of CCLAs signed: 55 | 56 | * At this stage, no CCLA has been signed by the DINUM. 57 | 58 | ## Contribute by publishing a new project 59 | 60 | ### The publication of the source code creates neither obligation nor guarantee 61 | 62 | * No obligation to support and take into account the requests of the users nor more generally obligation to animate the community. 63 | * No guarantees beyond what is provided by the license. 64 | 65 | ### Default permission to contribute a new project under the licenses listed by the decree 66 | 67 | The state is not intended to be a software editor. Apart from the three exceptions of the Law for a Digital Republic for which you can contact the support e-mail address in case of question, there is no prior authorization required from the DINUM. However, please refer to your supervisor before publishing a new project in your organization's account. 68 | 69 | As a reminder, the licenses to use are available by decree on the site: [http://www.data.gouv.fr/fr/licences](http://www.data.gouv.fr/fr/licences). 70 | 71 | ### Elements to consider when choosing a free/open-source software license 72 | 73 | Permissive licenses should be considered first. 74 | 75 | When, for the sake of public interest, the Administration has reason to ensure that third-party modifications to the software are accessible under the same conditions, it will consider a reciprocal license. In particular, if it is a software that is the basis of an online service for which it wishes to prevent any re-appropriation, it may consider the GNU Affero General Public License. 76 | 77 | The choice of the license of a project need also to take into account the third-party components included in its technical framework, according to the modalities of their technical relations. 78 | 79 | The ecosystem where the project is located may also guide the choice of the license, within the limits of the previous criteria. 80 | 81 | Note that software solutions are often modular and the issue of licensing can arise at many levels. For example, for a website solution, the modules of the web interface may be published under a different license than the server-side source code. 82 | 83 | ### Developer Certificate of Origin (DCO) 84 | 85 | Projects published by the State do not require specific rights of contributors apart from those granted by their respective licenses (no use of CLA). On the other hand, contributors are requested to sign a Certificate of Origin of Contributions (*Developer Certificate of Origin*). A French translation is available in this repository. 86 | -------------------------------------------------------------------------------- /faq.en.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Frequently Asked Questions 3 | menu: 4 | main: 5 | name: FAQ 6 | weight: 70 7 | layout: faq 8 | --- 9 | 10 | ## Scope 11 | 12 | ### "Am I affected by this open source contribution policy?" 13 | 14 | As stated in the introduction, if the Law for a Digital Republic applies to the entire administration, the scope of the DINUM focuses on the central administrations (with some exceptions according to Decree No. 2014-879 of August 1 2014). 15 | 16 | If you are part of a local authority, this policy does not apply to you, even though the Law for a Digital Republic applies. 17 | 18 | If you are part of an operator or a public institution under the tutelage of a ministry, you are concerned. 19 | 20 | #### And if I belong to a research institution? 21 | 22 | The Law for a Digital Republic applies in the same way. 23 | 24 | 25 | #### And if I am an employee of an outsourcing company? 26 | 27 | If you are involved in a public contract, you are concerned. However, the details of the contractual obligations will depend on the CCTP and the CCAP. 28 | 29 | #### And if I am self-employed / self-entrepreneur? 30 | 31 | If you work for an administration within the scope of the DINUM, you are also concerned. 32 | 33 | ### "Which codes are intended to be open?" 34 | 35 | The obligation to open the codes is related to the Digital Republic law which plans a gradual opening until October 7, 2018. At this date, all codes that have economic, social, sanitary or environmental value must be opened by default. 36 | 37 | Any code written as part of a public service mission is publishable and reusable for other purposes, except for the following: 38 | 39 | - The code must be completed (i.e. put into production) 40 | - This communication must not undermine: 41 | - A secret protected by law (commercial or industrial secret of a third party, etc.) 42 | - State security, and public security of people or government information systems 43 | - Research or prevention of offenses of any kind 44 | 45 | ### "I have a doubt about opening a source code, who can I contact?" 46 | 47 | Please email the contact address provided in this policy. 48 | 49 | ## Licenses 50 | 51 | ### "How to choose among the different licenses offered?" 52 | 53 | See [Opening / Default Authorization to Contribute to FSF or OSI Licensed Projects](ouverture.en.md#permission-by-fail-to-contribute-to-projects-sublicense-fsf- or-osi) and [Opening / Authorization to contribute a new project with decree licenses](ouverture.en.md#authorization-by-fail-to-contribute-a-new- project-with-the-licenses-of-the decree). 54 | 55 | Feel free to come back to us using the contact address for any questions or advice. 56 | 57 | ### "I need legal help on an open source license, who can I contact?" 58 | 59 | Please email the contact address provided in this policy. 60 | 61 | ## Electronic identity 62 | 63 | ### "Which e-mail address should I use to contribute to a project?" 64 | 65 | Everything is detailed in the page [Opening / Assigning Contributions to Individuals](ouverture.en.md#assign-contributions-to-individuals). 66 | 67 | #### And if I am an employee of an outsourcing company? 68 | 69 | Everything is detailed in the page [Opening / Assigning Contributions to Individuals](ouverture.en.md#assign-contributions-to-individuals). 70 | 71 | #### And if I am self-employed / self-entrepreneur? 72 | 73 | In this case, your identity is what really counts and it is the same to use a professional or personal email address. Choose what you want. 74 | 75 | ### "Should I use my professionnal email if I have been contributing to a project for a long time on my own?" 76 | 77 | If the contributions are made in the professional context, you are actually asked to use your professional email address. 78 | 79 | ## Miscellaneous 80 | 81 | ### "Do I need to get validation before I publish code?" 82 | 83 | Although a pre-authorization by default is proposed by the DINUM, it may be necessary to obtain the approval of your supervisor (the same way you have validated your training proposed by the training department). For the publication of a new code base and not a contribution to an existing code, you will need to obtain a repository on your organization's account. 84 | 85 | ### "My administration does not have an organization account on the online code hosting service I want to use. What should I do?" 86 | 87 | If your administration has an account on another platform, contact the manager of this account. 88 | 89 | If it is not the case, contact the support email address provided in this policy. 90 | 91 | ### "I do not dare to make my first commit in public, can I get help?" 92 | 93 | If you have a contribution available on a private repository, it is possible and encouraged to request a peer review. 94 | 95 | We advise you to identify someone who is closest to your organization and has already made a public contribution to help you. 96 | 97 | If you can not identify someone, you can contact the support email address provided in the policy, so that we can help you find peers. 98 | 99 | ### "Can I code in a language other than French?" 100 | 101 | The names of variables and functions, as well as code comments, can be written in the language of the intended developer community. However, the user documentation must be available in French. 102 | 103 | ### "Why not asking for CLAs for my project?" 104 | 105 | For most software projects in the public administration, CLAs (Contributor License Agreements) may discourage external contributions. It is sometimes argued that CLAs make it easier to change the project's license, but they are not mandatory for this operation. 106 | -------------------------------------------------------------------------------- /faq.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Foire aux questions 3 | menu: 4 | main: 5 | name: FAQ 6 | weight: 70 7 | layout: faq 8 | --- 9 | 10 | ## Périmètre 11 | 12 | ### « Suis-je concerné(e) par cette politique de contribution open source ? » 13 | 14 | Comme indiqué dans l'introduction, si la loi République Numérique s'applique à toute l'administration, le périmètre de la DINUM se concentre sur la fonction publique d'État (avec quelques exceptions selon le décret n° 2014-879 du 1er août 2014). 15 | 16 | Si vous faites partie d'une collectivité territoriale, cette politique ne vous concerne pas, bien que la loi République Numérique s'applique. 17 | 18 | Si vous faites partie d'un opérateur ou d'un établissement public sous la tutelle d'un ministère, vous êtes concerné. 19 | 20 | #### Et si j'appartiens à un établissement de recherche ? 21 | 22 | La loi République Numérique s'applique de la même manière. 23 | 24 | #### Et si je suis salarié d'une ESN / SSII ? 25 | 26 | Si vous intervenez dans le cadre d'un marché public, vous êtes concernés. Toutefois, le détail des obligations contractuelles dépendra du CCTP et du CCAP. 27 | 28 | #### Et si je suis indépendant / auto-entrepreneur ? 29 | 30 | Si vous travaillez pour une administration relevant du périmètre de la DINUM, vous êtes également concerné. 31 | 32 | ### « Quels sont les codes qui ont vocation à être ouverts ? » 33 | 34 | L'obligation d'ouverture des codes est liée à la loi République Numérique qui prévoit une ouverture progressive jusqu'au 7 octobre 2018. A cette date, une ouverture par défaut est prévue pour tous les codes qui revêtent un intérêt économique, social, sanitaire ou environnemental. 35 | 36 | Tout code écrit dans le cadre d'une mission de service publique est potentiellement communicable et réutilisable à d'autres fins, aux exceptions suivantes près : 37 | 38 | - Le code doit être achevé (i.e. mis en production) 39 | - Sa communication ne doit pas porter atteinte à : 40 | - Un secret protégé par la loi (secret commercial ou industriel d'un tiers, etc.) 41 | - La sûreté de l'État, la sécurité publique, des personnes ou des systèmes d'information des administrations 42 | - La recherche ou la prévention d'infractions de toute nature 43 | 44 | ### « J'ai un doute sur l'ouverture d'un code source, vers qui puis-je me renseigner ? » 45 | 46 | Vous pouvez contacter l'adresse électronique de contact proposée dans la politique de votre ministère ou `opensource@data.gouv.fr`. 47 | 48 | ## Licences 49 | 50 | ### « Comment choisir parmi les différentes licences proposées ? » 51 | 52 | Voir [Ouverture / Autorisation par défaut de contribuer à des projets sous licence FSF ou OSI](ouverture.md#autorisation-par-défaut-de-contribuer-à-des-projets-sous-licence-fsf-ou-osi) et [Ouverture / Autorisation par défaut de contribuer un nouveau projet avec les licences du décret](ouverture.md#autorisation-par-défaut-de-contribuer-un-nouveau-projet-avec-les-licences-du-décret). 53 | 54 | N'hésitez pas à revenir vers nous en utilisant l'adresse de contact pour toute question ou conseil. 55 | 56 | ### « J'ai besoin d'une aide juridique sur une licence Open Source, qui puis-je contacter ? » 57 | 58 | Vous pouvez contacter l'adresse électronique de contact proposée dans la politique de votre ministère ou `opensource@data.gouv.fr`. 59 | 60 | ## Identité électronique 61 | 62 | ### « Quelle adresse électronique utiliser pour contribuer à un projet ? » 63 | 64 | Tout est détaillé dans la page [Ouverture / Attribuer les contributions aux individus](ouverture.md#attribuer-les-contributions-aux-individus). 65 | 66 | #### Et si je suis salarié d'une ESN / SSII ? 67 | 68 | Tout est détaillé dans la page [Ouverture / Attribuer les contributions aux individus](ouverture.md#attribuer-les-contributions-aux-individus). 69 | 70 | #### Et si je suis indépendant / auto-entrepreneur ? 71 | 72 | Dans ce cas précis, l'identité prime et il revient au même d'utiliser une adresse électronique professionnelle ou personnelle. Choisissez ce que vous voulez. 73 | 74 | ### « Dois-je utiliser mon mail pro si je contribue depuis longtemps à un projet à titre personnel ? » 75 | 76 | Si les contributions se font dans le cadre professionnel, il vous est effectivement demandé d'utiliser votre adresse électronique professionnelle. 77 | 78 | ## Divers 79 | 80 | ### « Dois-je obtenir une validation avant de publier du code ? » 81 | 82 | Bien qu'une pré-autorisation par défaut soit proposée par la DINUM, il peut être nécessaire d'obtenir l'accord de votre supérieur hiérarchique (au même titre que vous faites valider vos formations proposées par le service formation). Pour la publication d'une nouvelle base de code et pas une contribution à un code existant, vous devrez obtenir un dépôt sur le compte de votre organisation. 83 | 84 | ### « Mon administration n'a pas de compte d'organisation sur le service en ligne d'hébergement de code que je souhaite utiliser. Que faire ? » 85 | 86 | Si votre administration dispose d'un compte sur une autre plate-forme, contactez le responsable de ce compte. 87 | Si ce n'est pas le cas, contactez l'adresse électronique de contact proposée dans la politique. 88 | 89 | ### « Je n'ose pas faire mon premier commit en public, puis-je obtenir de l'aide ? » 90 | 91 | Si vous avez une contribution disponible sur un dépôt privé, il est possible et encouragé de demander une revue par les pairs. 92 | 93 | Nous vous conseillons d'identifier quelqu'un au plus proche de votre structure qui a déjà contribué publiquement pour qu'il puisse vous aider. 94 | 95 | Si toutefois vous ne parvenez pas à identifier quelqu'un, vous pouvez contacter l'adresse électronique de contact proposée dans la politique 96 | pour que nous puissions vous aider à trouver des pairs (`opensource@data.gouv.fr`). 97 | 98 | ### « Puis-je coder dans une langue autre que le français ? » 99 | 100 | Le nom des variables et des fonctions, ainsi que les commentaires de code peuvent être rédigés dans la langue de la communauté de développeurs visée. Toutefois, la documentation utilisateur devra être disponible en français. 101 | 102 | ### « Pourquoi ne devrais-je pas demander un CLA sur mon projet ? » 103 | 104 | Pour la plupart des projets logiciels de l'administration, un CLA (Contributor License Agreements) risque de décourager les contributions extérieurs. Le besoin de CLA est parfois invoqué pour faciliter un changement de licence, mais il n'est pas indispensable pour cette opération. 105 | -------------------------------------------------------------------------------- /ouverture.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Principes d’ouverture des codes sources 3 | menu: 4 | main: 5 | name: "Ouverture" 6 | weight: 20 7 | --- 8 | 9 | ## Préambule 10 | 11 | ### Principe de subsidiarité 12 | 13 | La politique peut être instanciée localement avec une priorité plus forte. 14 | 15 | Voir la section [instanciation](Instanciation.md) si vous souhaitez décliner cette politique au sein de votre organisation. 16 | 17 | ### Assistance sur la politique de contribution 18 | 19 | Contacter `opensource@data.gouv.fr` pour toute question sur cette politique. 20 | 21 | ## Principe de reconnaissance des contributions 22 | 23 | ### Attribuer les contributions aux individus 24 | 25 | Afin de reconnaître la paternité des contributions, l'adresse électronique individuelle du développeur est utilisée: 26 | 27 | * Pour les agents : utilisation de l'adresse électronique professionnelle. 28 | * Pour les prestataires de services, utilisation de l'adresse électronique de leur société d'attachement (pas d'adresse prestataire fournie par l'administration) 29 | 30 | Toutefois, au cas où un développeur ne souhaiterait pas voir son identité publiée, il peut utiliser un pseudonyme. En revanche, l'utilisation d'adresses électroniques génériques ou anonymes est à proscrire. 31 | 32 | ### Distinguer les contributions professionnelles et personnelles 33 | 34 | Il est possible pour un développeur de contribuer sur un même projet dans le cadre du milieu professionnel et à titre personnel, l'État reconnaissant aux développeurs la propriété sur les contributions réalisées en dehors du temps de travail. Les contributions réalisées sur le temps professionnel doivent être associées à une adresse électronique professionnelle. 35 | 36 | ## Contribuer à des projets tiers 37 | 38 | ### Autorisation par défaut de contribuer à des projets sous licence FSF ou OSI 39 | 40 | Les licences validées par les organismes Free Software Foundation et Open Source Initiative et recensées sur leurs pages respectives : 41 | 42 | * FSF : [https://www.gnu.org/licenses/license-list.fr.html](https://www.gnu.org/licenses/license-list.fr.html) (en excluant les licences non libres présentées comme telles) ; 43 | * OSI : [https://opensource.org/licenses/alphabetical](https://opensource.org/licenses/alphabetical). 44 | 45 | À l'inverse les licences non retenues par ces organismes (comme la *Beerware*) ne rentrent pas dans le cadre de l'autorisation par défaut. Un tableau consolidé des licences validées par l'un ou l'autre organisme est maintenu sur le site [https://spdx.org/licenses/](https://spdx.org/licenses) 46 | 47 | ### Signature des *Corporate Contributor License Agreement* 48 | 49 | La DINUM prend en charge de signer les accords de contributions spécifiques (Corporate Contributor License Agreement ou CCLA) avec les communautés ou les entreprises qui l'exigent, afin de permettre les contributions des agents à titre professionnel aux projets concernés. Si cela est demandé par l'autre partie, elle maintiendra les listes d'individus couverts par l'accord. Une autre possibilité est que l'accord de CCLA soit un pré-requis à la signature d'un Contributor License Agreement individuel (iCLA). Dans ce cas, la signature d'un CCLA par la DINUM vaudra pré-autorisation pour la signature d'iCLA. 50 | 51 | Si vous souhaitez contribuer à un projet réclamant ce type de formalisme, que ce soit pour signer un CCLA, vous rajouter à la liste des contributeurs autorisés, ou vérifier la possibilité de signer un iCLA, contactez l'adresse d'assistance indiquée plus haut. 52 | 53 | Liste des CCLA signés : 54 | 55 | * A ce stade, aucun CCLA n'a encore été signé par la DINUM. 56 | 57 | ## Contribuer en publiant un nouveau projet 58 | 59 | ### La publication du code source ne crée ni obligation ni garantie 60 | 61 | * Aucune obligation de support et de prise en compte des demandes des utilisateurs ni plus généralement d'obligation d'animer la communauté. 62 | * Pas de garanties au-delà de ce qui est prévu par la licence. 63 | 64 | ### Autorisation par défaut de contribuer un nouveau projet avec les licences du décret 65 | 66 | L'État n'a pas vocation à être éditeur de logiciels. En dehors des trois exceptions prévues à la loi pour une République numérique pour lesquelles vous pouvez contacter l'adresse électronique de support en cas de question, il n'y a pas d'autorisation préalable à demander auprès de la DINUM. Pour autant, veuillez vous référer à votre supérieur hiérarchique avant la publication d'un nouveau projet dans le compte de votre organisation. 67 | 68 | Pour rappel, les licences à utiliser sont disponibles par décret sur le site : [http://www.data.gouv.fr/fr/licences](http://www.data.gouv.fr/fr/licences). 69 | 70 | ### Éléments à considérer dans le choix de la licence libre 71 | 72 | Les licences permissives doivent être considérées en priorité. 73 | 74 | Si la défense de l'intérêt général justifie de garantir que les modifications apportées par un tiers au logiciel libre qu'elle publie soient accessibles sous les mêmes conditions, elle envisagera une licence à réciprocité. En particulier, s'il s'agit d'un logiciel qui est à la base d'un service en ligne pour lequel elle souhaite se prémunir de toute réappropriation, elle pourra considérer la licence GNU Affero General Public License. 75 | 76 | Le choix de la licence d'un projet devra également prendre en compte celles des composants Open Source tiers constituant son cadre technique, selon les modalités de leurs relations techniques. 77 | 78 | L'écosystème où s'insère le projet pourra aussi aiguiller le choix de la licence, dans la limite de la latitude laissée par les critères précédents. 79 | 80 | À noter que les solutions logicielles sont souvent modulaires et que la question de la licence peut se poser à plusieurs niveaux. Par exemple, pour une solution de site web, les modules de l'interface web pourront être publiés sous une licence différente de celle qui couvre le code source côté serveur. 81 | 82 | ### Distribution des logiciels sous forme de paquets 83 | 84 | Le code source des logiciels est souvent empaqueté de façon à être utilisé dans d'autres projets. Chaque écosystème utilise son système de distributions de paquets: modules `npm` ou `pypi`, images `docker`, fichiers `deb`, etc. 85 | 86 | Il est recommandé de distribuer, en plus du code source des logiciels, les paquets qui facilitent leur réutilisation. 87 | 88 | Pour connaître les sites sur lesquels publier vos paquets, contactez le [mainteneur](MAINTAINERS) de cette politique correspondant à votre ministère. Si vous ne savez pas qui contacter, écrivez à `opensource@data.gouv.fr`. 89 | 90 | ### Certification de l'origine des contributions (DCO) 91 | 92 | Les projets publiés par l'État n'exigent pas de droits spécifiques des contributeurs en dehors de ceux accordés par leurs licences respectives (pas d'utilisation de CLA). En revanche, il est demandé aux contributeurs de signer un Certificat d'origine des contributions (*Developer Certificate of Origin*). Afin de s'insérer dans les standards en usage, il a été choisi d'utiliser une traduction française du texte utilisé pour le noyau Linux et repris par de nombreux autres projets. 93 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | LICENCE OUVERTE / OPEN LICENCE 2 | =================================================================== 3 | 4 | - Version 2.0 5 | - Avril 2017 6 | 7 | 8 | « RÉUTILISATION » DE L’« INFORMATION » SOUS CETTE LICENCE 9 | ------------------------------------------------------------------- 10 | 11 | Le « Concédant » concède au « Réutilisateur » un droit non exclusif et gratuit 12 | de libre « Réutilisation » de l’« Information » objet de la présente licence, 13 | à des fins commerciales ou non, dans le monde entier et pour une durée 14 | illimitée, dans les conditions exprimées ci-dessous. 15 | 16 | Le « Réutilisateur » est libre de réutiliser l’« Information » : 17 | 18 | - de la reproduire, la copier, 19 | - de l’adapter, la modifier, l’extraire et la transformer, pour créer des 20 | « Informations dérivées », des produits ou des services, 21 | - de la communiquer, la diffuser, la redistribuer, la publier et la transmettre, 22 | - de l’exploiter à titre commercial, par exemple en la combinant avec d’autres 23 | informations, ou en l’incluant dans son propre produit ou application. 24 | 25 | Sous réserve de : 26 | 27 | - mentionner la paternité de l’« Information » : sa source (au moins le nom du 28 | « Concédant ») et la date de dernière mise à jour de l’« Information » 29 | réutilisée. 30 | 31 | Le « Réutilisateur » peut notamment s’acquitter de cette condition en renvoyant, 32 | par un lien hypertexte, vers la source de « l’Information » et assurant une 33 | mention effective de sa paternité. 34 | 35 | Par exemple : 36 | 37 | « Ministère de xxx - Données originales téléchargées sur 38 | http://www.data.gouv.fr/fr/datasets/xxx/, mise à jour du 14 février 2017 ». 39 | 40 | Cette mention de paternité ne confère aucun caractère officiel à la 41 | « Réutilisation » de l’« Information », et ne doit pas suggérer une quelconque 42 | reconnaissance ou caution par le « Concédant », ou par toute autre entité 43 | publique, du « Réutilisateur » ou de sa « Réutilisation ». 44 | 45 | 46 | « DONNÉES À CARACTÈRE PERSONNEL » 47 | ------------------------------------------------------------------- 48 | 49 | L’« Information » mise à disposition peut contenir des « Données à caractère 50 | personnel » pouvant faire l’objet d’une « Réutilisation ». Si tel est le cas, 51 | le « Concédant » informe le « Réutilisateur » de leur présence. 52 | 53 | L’« Information » peut être librement réutilisée, dans le cadre des droits 54 | accordés par la présente licence, à condition de respecter le cadre légal 55 | relatif à la protection des données à caractère personnel. 56 | 57 | 58 | « DROITS DE PROPRIÉTÉ INTELLECTUELLE » 59 | ------------------------------------------------------------------- 60 | 61 | Il est garanti au « Réutilisateur » que les éventuels « Droits de propriété 62 | intellectuelle » détenus par des tiers ou par le « Concédant » sur 63 | l’« Information » ne font pas obstacle aux droits accordés par la présente 64 | licence. 65 | 66 | Lorsque le « Concédant » détient des « Droits de propriété intellectuelle » 67 | cessibles sur l’« Information », il les cède au « Réutilisateur » de façon non 68 | exclusive, à titre gracieux, pour le monde entier, pour toute la durée des 69 | « Droits de propriété intellectuelle », et le « Réutilisateur » peut faire tout 70 | usage de l’« Information » conformément aux libertés et aux conditions définies 71 | par la présente licence. 72 | 73 | 74 | RESPONSABILITÉ 75 | ------------------------------------------------------------------- 76 | 77 | L’« Information » est mise à disposition telle que produite ou reçue par le 78 | « Concédant », sans autre garantie expresse ou tacite que celles prévues par la 79 | présente licence. L’absence de défauts ou d’erreurs éventuellement contenues 80 | dans l’« Information », comme la fourniture continue de l’« Information » n’est 81 | pas garantie par le « Concédant ». Il ne peut être tenu pour responsable de 82 | toute perte, préjudice ou dommage de quelque sorte causé à des tiers du fait de 83 | la « Réutilisation ». 84 | 85 | Le « Réutilisateur » est seul responsable de la « Réutilisation » de 86 | l’« Information ». 87 | 88 | La « Réutilisation » ne doit pas induire en erreur des tiers quant au contenu 89 | de l’« Information », sa source et sa date de mise à jour. 90 | 91 | 92 | DROIT APPLICABLE 93 | ------------------------------------------------------------------- 94 | 95 | La présente licence est régie par le droit français. 96 | 97 | 98 | COMPATIBILITÉ DE LA PRÉSENTE LICENCE 99 | ------------------------------------------------------------------- 100 | 101 | La présente licence a été conçue pour être compatible avec toute licence libre 102 | qui exige au moins la mention de paternité et notamment avec la version 103 | antérieure de la présente licence ainsi qu’avec les licences : 104 | 105 | - « Open Government Licence » (OGL) du Royaume-Uni, 106 | - « Creative Commons Attribution » (CC-BY) de Creative Commons et 107 | - « Open Data Commons Attribution » (ODC-BY) de l’Open Knowledge Foundation. 108 | 109 | 110 | DÉFINITIONS 111 | ------------------------------------------------------------------- 112 | 113 | Sont considérés, au sens de la présente licence comme : 114 | 115 | Le « Concédant » : toute personne concédant un droit de « Réutilisation » sur 116 | l’« Information » dans les libertés et les conditions prévues par la présente 117 | licence 118 | 119 | L’« Information » : 120 | 121 | - toute information publique figurant dans des documents communiqués ou publiés 122 | par une administration mentionnée au premier alinéa de l’article L.300-2 du 123 | CRPA; 124 | - toute information mise à disposition par toute personne selon les termes et 125 | conditions de la présente licence. 126 | 127 | La « Réutilisation » : l’utilisation de l’« Information » à d’autres fins que 128 | celles pour lesquelles elle a été produite ou reçue. 129 | 130 | Le « Réutilisateur »: toute personne qui réutilise les « Informations » 131 | conformément aux conditions de la présente licence. 132 | 133 | Des « Données à caractère personnel » : toute information se rapportant à une 134 | personne physique identifiée ou identifiable, pouvant être identifiée 135 | directement ou indirectement. Leur « Réutilisation » est subordonnée au respect 136 | du cadre juridique en vigueur. 137 | 138 | Une « Information dérivée » : toute nouvelle donnée ou information créées 139 | directement à partir de l’« Information » ou à partir d’une combinaison de 140 | l’« Information » et d’autres données ou informations non soumises à cette 141 | licence. 142 | 143 | Les « Droits de propriété intellectuelle » : tous droits identifiés comme tels 144 | par le Code de la propriété intellectuelle (notamment le droit d’auteur, droits 145 | voisins au droit d’auteur, droit sui generis des producteurs de bases de 146 | données…). 147 | 148 | 149 | À PROPOS DE CETTE LICENCE 150 | ------------------------------------------------------------------- 151 | 152 | La présente licence a vocation à être utilisée par les administrations pour la 153 | réutilisation de leurs informations publiques. Elle peut également être 154 | utilisée par toute personne souhaitant mettre à disposition de 155 | l’« Information » dans les conditions définies par la présente licence. 156 | 157 | La France est dotée d’un cadre juridique global visant à une diffusion 158 | spontanée par les administrations de leurs informations publiques afin d’en 159 | permettre la plus large réutilisation. 160 | 161 | Le droit de la « Réutilisation » de l’« Information » des administrations est 162 | régi par le code des relations entre le public et l’administration (CRPA). 163 | 164 | Cette licence facilite la réutilisation libre et gratuite des informations 165 | publiques et figure parmi les licences qui peuvent être utilisées par 166 | l’administration en vertu du décret pris en application de l’article L.323-2 167 | du CRPA. 168 | 169 | Etalab est la mission chargée, sous l’autorité du Premier ministre, d’ouvrir le 170 | plus grand nombre de données publiques des administrations de l’Etat et de ses 171 | établissements publics. Elle a réalisé la Licence Ouverte pour faciliter la 172 | réutilisation libre et gratuite de ces informations publiques, telles que 173 | définies par l’article L321-1 du CRPA. 174 | 175 | Cette licence est la version 2.0 de la Licence Ouverte. 176 | 177 | Etalab se réserve la faculté de proposer de nouvelles versions de la Licence 178 | Ouverte. Cependant, les « Réutilisateurs » pourront continuer à réutiliser les 179 | informations qu’ils ont obtenues sous cette licence s’ils le souhaitent. 180 | -------------------------------------------------------------------------------- /comptes-organismes-publics: -------------------------------------------------------------------------------- 1 | https://dev.ch-poitiers.fr 2 | https://forge.grandlyon.com 3 | https://forge.univ-lyon1.fr 4 | https://forgemia.inra.fr 5 | https://framagit.org/datatourisme 6 | https://framagit.org/etalab 7 | https://framagit.org/openfisca 8 | https://framagit.org/parcoursup 9 | https://framagit.org/synalp 10 | https://git.ademe.fr 11 | https://git.beta.pole-emploi.fr 12 | https://git.cines.fr/dad 13 | https://git.unicaen.fr/open-source 14 | https://git.unicaen.fr/pdn-certic 15 | https://github.com/1024pix 16 | https://github.com/139bercy 17 | https://github.com/AgenceBio 18 | https://github.com/ansforge 19 | https://github.com/ANSSI-FR 20 | https://github.com/ARCEP-dev 21 | https://github.com/AccessiDys 22 | https://github.com/ApieFrance 23 | https://github.com/AssuranceMaladieSec 24 | https://github.com/Bibliome 25 | https://github.com/BRGM 26 | https://github.com/BaseAdresseNationale 27 | https://github.com/BibCnrs 28 | https://github.com/CCSDForge 29 | https://github.com/CEREMA 30 | https://github.com/CNRS-DSI-Dev 31 | https://github.com/CatalaLang 32 | https://github.com/Cour-de-cassation 33 | https://github.com/DGA-MI-SSI 34 | https://github.com/DGFiP 35 | https://github.com/DGTresor 36 | https://github.com/DIVERSIFY-project 37 | https://github.com/DREAL-NA 38 | https://github.com/Deducteam 39 | https://github.com/Delegation-numerique-en-sante 40 | https://github.com/EDS-APHP 41 | https://github.com/EsupPortail 42 | https://github.com/GHFC 43 | https://github.com/GendarmerieNationale 44 | https://github.com/Geographie-cites 45 | https://github.com/HolAutisme 46 | https://github.com/IGNF 47 | https://github.com/INRA 48 | https://github.com/INSIDE-information-systems 49 | https://github.com/IRSN 50 | https://github.com/Icy-imaging 51 | https://github.com/Ifsttar 52 | https://github.com/Inist-CNRS 53 | https://github.com/InriaMecsci 54 | https://github.com/InseeFr 55 | https://github.com/InseeFrLab 56 | https://github.com/Irstea 57 | https://github.com/LAB-MI 58 | https://github.com/LETG 59 | https://github.com/LINCnil 60 | https://github.com/LemonLDAPNG 61 | https://github.com/MINAGRI-INITIAL 62 | https://github.com/MTES-MCT 63 | https://github.com/MinistereSupRecherche 64 | https://github.com/OCSInventory-NG 65 | https://github.com/OPIDoR 66 | https://github.com/OpenEdition 67 | https://github.com/OpenFLUID 68 | https://github.com/PnCevennes 69 | https://github.com/PnEcrins 70 | https://github.com/PnX-SI 71 | https://github.com/PrefectureDePolice 72 | https://github.com/ProgrammeVitam 73 | https://github.com/SimPLU3D 74 | https://github.com/SocialGouv 75 | https://github.com/SocieteNumerique 76 | https://github.com/Spirals-Team 77 | https://github.com/StartupsPoleEmploi 78 | https://github.com/X-DataInitiative 79 | https://github.com/abes-esr 80 | https://github.com/addok 81 | https://github.com/administration-solrep 82 | https://github.com/afimb 83 | https://github.com/ambanum 84 | https://github.com/assurance-maladie-digital 85 | https://github.com/atlanmod 86 | https://github.com/banquedefrance 87 | https://github.com/betagouv 88 | https://github.com/cea-hpc 89 | https://github.com/cea-leti 90 | https://github.com/cea-list 91 | https://github.com/cea-sec 92 | https://github.com/cget-carto 93 | https://github.com/clipos 94 | https://github.com/clipos-archive 95 | https://github.com/communaute-cimi 96 | https://github.com/consultation-gouv 97 | https://github.com/cour-des-comptes 98 | https://github.com/cstb 99 | https://github.com/ctools 100 | https://github.com/culturecommunication 101 | https://github.com/cw-leia 102 | https://github.com/datalab-mi 103 | https://github.com/datalocale 104 | https://github.com/dgac 105 | https://github.com/dinsic-pim 106 | https://github.com/diplomatiegouvfr 107 | https://github.com/disic 108 | https://github.com/diverse-project 109 | https://github.com/elabftw 110 | https://github.com/entrepreneur-interet-general 111 | https://github.com/eole 112 | https://github.com/erasme 113 | https://github.com/etalab 114 | https://github.com/etalab-ia 115 | https://github.com/ezpaarse-project 116 | https://github.com/fabnumdef 117 | https://github.com/gammalib 118 | https://github.com/geobretagne 119 | https://github.com/georchestra 120 | https://github.com/gemoc 121 | https://github.com/genotoul-bioinfo 122 | https://github.com/geodatagouv 123 | https://github.com/histovec 124 | https://github.com/ia-flash 125 | https://github.com/imagesdesmaths 126 | https://github.com/ina-foss 127 | https://github.com/incubateur-territoires 128 | https://github.com/indsante 129 | https://github.com/inrae 130 | https://github.com/inria 131 | https://github.com/iscpif 132 | https://github.com/istex 133 | https://github.com/ivre 134 | https://github.com/leximpact 135 | https://github.com/linbox-team 136 | https://github.com/lutece-secteur-public 137 | https://github.com/matchid-project 138 | https://github.com/medialab 139 | https://github.com/messagerie-melanie2 140 | https://github.com/meteofrance 141 | https://github.com/metwork-framework 142 | https://github.com/micmacIGN 143 | https://github.com/nanterre 144 | https://github.com/nantesmetropole 145 | https://github.com/neuroanatomy 146 | https://github.com/numerique-gouv 147 | https://github.com/observatoire-territoires 148 | https://github.com/opencti-platform 149 | https://github.com/opendatateam 150 | https://github.com/openfisca 151 | https://github.com/openfun 152 | https://github.com/openmole 153 | https://github.com/polewebmaedi 154 | https://github.com/powerapi-ng 155 | https://github.com/region-bretagne 156 | https://github.com/riatelab 157 | https://github.com/sgmap-agd 158 | https://github.com/signaux-faibles 159 | https://github.com/sigrennesmetropole 160 | https://github.com/sipf 161 | https://github.com/snosan-tools 162 | https://github.com/spyrales 163 | https://github.com/strasbourg 164 | https://github.com/sympa-community 165 | https://github.com/unistra 166 | https://github.com/vle-forge 167 | https://github.com/wookey-project 168 | https://gitlab.adullact.net/UPSud 169 | https://gitlab.adullact.net/aife 170 | https://gitlab.adullact.net/departements-notaires 171 | https://gitlab.adullact.net/e-carre 172 | https://gitlab.adullact.net/gip-recia-snc 173 | https://gitlab.adullact.net/larochelle 174 | https://gitlab.adullact.net/prodigeadmin 175 | https://gitlab.adullact.net/socio-connect 176 | https://gitlab.adullact.net/marche-sll 177 | https://gitlab.ccsd.cnrs.fr 178 | https://gitlab.cerema.fr 179 | https://gitlab.com/CSTB 180 | https://gitlab.com/DREES_code 181 | https://gitlab.com/api-meubles 182 | https://gitlab.com/arsante 183 | https://gitlab.com/cortext 184 | https://gitlab.com/dreal-datalab 185 | https://gitlab.com/fabnum-minarm 186 | https://gitlab.com/france-mobilites 187 | https://gitlab.com/hatvp-open 188 | https://gitlab.com/healthdatahub 189 | https://gitlab.com/musee-saint-raymond 190 | https://gitlab.com/pidila 191 | https://gitlab.huma-num.fr 192 | https://gitlab.in2p3.fr/Enssib 193 | https://gitlab.inria.fr/ 194 | https://gitlab.inria.fr/why3 195 | https://gitlab.inria.fr/belenios 196 | https://gitlab.inria.fr/coquelicot 197 | https://gitlab.inria.fr/dsi_public 198 | https://gitlab.inria.fr/openvibe 199 | https://gitlab.inria.fr/stopcovid19 200 | https://gitlab.inria.fr/verifisc 201 | https://gitlab.inria.fr/vidjil 202 | https://gitlab.inria.fr/guix-hpc 203 | https://gitlab.irstea.fr 204 | https://gitlab.math.unistra.fr 205 | https://gitlab.orfeo-toolbox.org 206 | https://gitlab.ow2.org/lemonldap-ng 207 | https://gitlabjf.ccomptes.fr 208 | https://gitub.u-bordeaux.fr 209 | https://github.com/AFB-dataviz 210 | https://github.com/cre-dev 211 | https://gitlab.com/op18-enki 212 | https://gitlab.adullact.net/dgfip 213 | https://github.com/dsi-ehess 214 | https://github.com/pass-culture 215 | https://gitlab.com/rdes_dreal 216 | https://gitlab.com/peren 217 | https://gitlab.u-psud.fr 218 | https://github.com/MLanguage 219 | https://github.com/Envinorma 220 | https://github.com/dfir-orc 221 | https://github.com/stemjail 222 | https://github.com/caml-pkcs11 223 | https://github.com/rusticata 224 | https://github.com/landlock-lsm 225 | https://github.com/caradoc-org 226 | https://github.com/picty 227 | https://github.com/guix-mirror 228 | https://github.com/coq 229 | https://github.com/ocaml 230 | https://github.com/Antique-team 231 | https://gricad-gitlab.univ-grenoble-alpes.fr 232 | https://github.com/gip-recia 233 | https://github.com/datagir 234 | https://github.com/dataesr 235 | https://github.com/plantnet 236 | https://edu-git.ac-versailles.fr 237 | https://github.com/aphp 238 | https://plmlab.math.cnrs.fr 239 | https://github.com/orleans-metropole 240 | https://github.com/gouvernementfr 241 | https://gitlab.factory.social.gouv.fr 242 | https://github.com/INHAParis 243 | https://github.com/dinum-HubEE 244 | https://gitlab.fresnel.fr 245 | https://gitlab.mbb.cnrs.fr 246 | https://gitlab.mobilites-m.fr/m 247 | https://github.com/ifremer-bioinformatics 248 | https://github.com/dnum-mi/ 249 | https://gitlab-research.centralesupelec.fr 250 | https://github.com/AC-Rennes-OpenSource 251 | https://github.com/dsi-github 252 | https://github.com/ac-nantes-dec 253 | https://github.com/academiePoitiers 254 | https://github.com/InterieurGouvFr 255 | https://gitlab.mim-libre.fr 256 | https://gitlab.com/affelnet-lycee-group 257 | https://github.com/Gendarmerie-Nationale 258 | -------------------------------------------------------------------------------- /pratique.en.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Best practices 3 | menu: 4 | main: 5 | name: "Best practices" 6 | weight: 30 7 | --- 8 | 9 | ## Source code version tracking system 10 | 11 | Using a distributed version tracking system such as git is recommended. Svn or cvs systems are deprecated. 12 | 13 | ## Help in choosing a web platform 14 | 15 | In addition to the source code version tracking system, a web platform offers a range of associated collaborative tools and aims to mobilize a community of developers. These platforms may be hosted by a third party or by the administration. 16 | 17 | Examples of web platforms hosted by a third party: 18 | 19 | * GitHub: [https://github.com](https://github.com) 20 | * GitLab: [http://gitlab.com](http://gitlab.com) (enterprise version) 21 | * Bitbucket : https://bitbucket.org 22 | * Adullact: [http://gitlab.adullact.net](http://gitlab.adullact.net) - using [GitLab](https://about.gitlab.com/installation/) 23 | * FSFE: [https://git.fsfe.org](https://git.fsfe.org) - using [Gitea](https://gitea.io/) 24 | * FSF: [https://git.savannah.gnu.org/cgit/](https://git.savannah.gnu.org/cgit/) - using [cgit](https://git.zx2c4.com/cgit/) 25 | 26 | The source code of github.com is not free just like some modules of gitlab.com; some platforms publish anonymous data in open data; their geographic scope may vary, as well as the number of developers who use it. The list is incomplete. 27 | 28 | The choice to create an organizational account within an existing Web platform is the responsibility of the administration, which can also host its own public forge. 29 | 30 | Choosing a forge for a project must be done according to the level of collaboration expected and the interfaces with the private repositories and the rest of the development platform. 31 | 32 | To know on which forge you should publish your source code, contact the [maintaineur](MAINTAINERS) of this policy from your ministry. If you don't know who you should get in touch with, send an email to `opensource@data.gouv.fr`. 33 | 34 | ## Management of personal and organizations accounts 35 | 36 | All projects initiated by an administration must be published in repositories under an organization accounts. Personal account repositories should only be used for temporary technical forks or personal developments. 37 | 38 | Here are the recommendations for managing organization accounts or groups: 39 | 40 | - make the users and owners publicly visible; 41 | - publish at least one email address as the contact email; 42 | - indicate what website is associated with the organization account; 43 | - if the platform allows it, verified the website associated with the account; 44 | - add a description and a picture. 45 | 46 | To handle repositories, it is recommended to have at least two organization owners and to publish the email address of at least one owner. 47 | 48 | ## Inventory of organization accounts 49 | 50 | A list of known forges and organization accounts from the public sector is readable in the [comptes-organismes-publics](comptes-organismes-publics) file : if you happen to know a forge or an organization account that should appear in this list, please submit a _pull request_. 51 | 52 | This list is used for [code.etalab.gouv.fr](https://code.etalab.gouv.fr) which allows anyone to look for repositories within all forges and organization accounts. 53 | 54 | You can also reference an organization account as a government account in GitHub: 55 | 56 | 1. Register if you have not done so already in the community [https://github.com/government/welcome](https://github.com/government/welcome) 57 | 58 | 2. Reference your organization account by adding it on the page: [https://github.com/github/government.github.com/blob/gh-pages/_data/governments.yml](https:// github.com/github/government.github.com/blob/gh-pages/_data/governments.yml) as per [https://government.github.com/community/](https://government.github .com / community /) 59 | 60 | ## Distinction of personal / professional contributions 61 | 62 | The distinction between personal and professional contributions is based on the associated email address. The contributor must change its email accordingly. 63 | 64 | In the case of using `git`, this can be done easily: 65 | 66 | * For a professional contribution: 67 | 68 | `git config user.email "firstname.lastname@ministere.gouv.fr"` 69 | 70 | * For a personal contribution: 71 | 72 | `git config user.email "email@perso.fr"` 73 | 74 | To find the email address currently used: 75 | 76 | `git config --get user.email` 77 | 78 | In cases where the contributor does not wish to see his personal identity attached to his contribution, an email address (or alias) need to be made available by the department to allow the use of a pseudonym. Beware some open source projects may refuse contributions under pseudonym. 79 | 80 | ## Help in choosing the license 81 | 82 | The choice of a license is also the choice of a community of developers and an ecosystem of associated tools. Once the license family is chosen, it is primarily the targeted developer's community that determines the choice. 83 | 84 | The recommended licenses by default are: 85 | 86 | * Permissive: Apache 2.0 87 | * Reciprocal: GNU GPL v3 (standard, lesser or affero in function) 88 | 89 | > Multilicensing: It is possible to provide software under several licenses simultaneously, although this can lead to confusion. 90 | 91 | ## Version Management 92 | 93 | Having a versioning policy is recommended. The semantic versioning guide (https://semver.org/lang/en/) is a good example to follow. 94 | 95 | ## Files in the repository 96 | 97 | Make sure you have at least the README, CONTRIBUTING, and LICENSE files. 98 | 99 | * CODE\_OF\_CONDUCT : a code of conduct to regulate the community of contributors. Examples can be found: [https://www.djangoproject.com/conduct/](https://www.djangoproject.com/conduct/) and [https://github.com/18F/code-of- conduct](https://github.com/18F/code-of-conduct). 100 | 101 | * CONTRIBUTING: contribution guide, how to get involved and identification of the contribution process and associated licenses. Example: [https://github.com/moby/moby/blob/master/CONTRIBUTING.md](https://github.com/moby/moby/blob/master/CONTRIBUTING.md) 102 | 103 | * GOVERNANCE: describes project governance, roles and voting rights. An example is available in this repository [gouvernance.md](gouvernance.md). 104 | 105 | * INSTALL: install instructions. 106 | 107 | * LICENSE: software license. 108 | 109 | * MAINTAINERS: list of project maintainers (usually with voting or commit rights). Example: [https://github.com/moby/moby/blob/master/MAINTAINERS](https://github.com/moby/moby/blob/master/MAINTAINERS) 110 | 111 | * NFR: choice of technical architecture of the project that do not correspond to functional requirements. 112 | 113 | * README: description of the project. Can describe the purpose and the administration behind the publication. 114 | 115 | * ROADMAP: public road map. 116 | 117 | These files must be in plain text or with minimum marking (ie Markdown). It is not recommended to use binary formats (ie PDF). 118 | 119 | ## Heads source files 120 | 121 | According to the detailed recommendations in [https://reuse.software](https://reuse.software) each source code file must have its author, SPDX license ID, and a copy of the license in the local repository. 122 | 123 | * Examples of file header (headers): 124 | 125 | ``` 126 | / * 127 | * Copyright (c) 2017 Alice Commit 128 | * 129 | * SPDX-License-Identifier: BSD-2-Clause 130 | * License-Filename: LICENSES / BSD-2-Clause_Alice.txt 131 | * / 132 | ``` 133 | 134 | or in the case of a project that automatically tracks its contributors: 135 | 136 | ``` 137 | / * 138 | * This file is part of the project X. It's copyrighted by the contributors 139 | * recorded in the version of the history of the file, available from 140 | * its original location http://git.example.com/X/filename.c 141 | * 142 | * SPDX-License-Identifier: BSD-2-Clause 143 | * License-Filename: LICENSES / BSD-2-Clause_Charlie.txt 144 | * / 145 | ``` 146 | 147 | To ensure software compliance, these identifiers enable to generate automatically inventories of licenses in the form of "Bill of Material". 148 | 149 | The complete list of SPDX identifiers is available at this address: [https://spdx.org/licenses/](https://spdx.org/licenses/) 150 | 151 | ## Traceability of development (DCO) 152 | 153 | It is recommended to propose to contributors to sign a _Developer's Certificate of Origin_. It allows her to attest that her contribution is genuine, respectful of previous works and that she accepts futur use for it under the project's license. A French translation is made available [DCO-Fr.txt](https://github.com/DISIC/politique-de-contribution-open-source/blob/master/DCO-fr.txt) and the english version is readble [here](https://developercertificate.org/). 154 | 155 | In order to accept the DCO, the contributor only needs to sign off her commits with the command: 156 | 157 | > `git commit --signoff` (or `git commit -s`) 158 | 159 | A DCO procedure should preferrably be set at the beginning of the project and it should be clearly stated in the `CONTRIBUTING` file of the repository. 160 | 161 | ## Development practices 162 | 163 | Best development practices also apply in the context of open development, and in particular those related to the normative documents enforced within the administration: 164 | 165 | * [General reference of interoperability](http://references.modernisation.gouv.fr/interoperabilite) 166 | * [General accessibility reference framework for administrations](http://references.modernisation.gouv.fr/rgaa-accessibilite/) 167 | * [General Security Reference](https://www.ssi.gouv.fr/administration/reglementation/numerique-confidence/the-referentiel-general-de-securite-rgs/) 168 | 169 | Opening the code also amplifies the importance of some of these best practices: 170 | 171 | * **Legal compliance** in the use of third-party libraries. The vast majority of current developments are based on third-party open source libraries, hence it is necessary to ensure the compatibility with their respective licenses and comply with their obligations. 172 | * **Modularization of developments** to maximize code reuse but also to isolate any sources of error 173 | * **Respect of a unique coding guideline** per project. 174 | * **Documentation**, inside the code (comments and messages of * commit *) and outside the code (see below). 175 | 176 | ## Documentation good practices 177 | 178 | The recommendations below are not mandatory rules but define a goal. The quality of an open source project is closely related to the quality of its documentation, paying attention to this list is heavily recommended. 179 | 180 | - The documentation is published under [**Licence Ouverte 2.0**][LO link]. 181 | - It is in sync with the software. 182 | - It proposes a user manuel and a developer manual. 183 | - It is available online (as a website) and offline (as a PFD document). 184 | - It is written in proper french and/or proper english. 185 | - It meets several expectations (FAQ, tutorials, reference manual, etc.) 186 | - It contains zero or very few cultural or contextual references which may become obscure to future users. 187 | 188 | ## Security 189 | 190 | ### Identified interlocutor 191 | 192 | It is recommended to identify a person in charge of the security of the project that will ensure compliance with best practices implemented during development, and to treat potential security incidents. It is also better to use a dedicated e-mail address to deal with security incidents or intellectual property issues which would be discovered by a third party. 193 | 194 | ### Secure development 195 | 196 | * Write code that follows recognized security practices and that does not make use of dangerous constructions in the language used 197 | * [SEI CERT Coding Standards](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards) 198 | * PHP The Right Way (http://eilgin.github.io/php-the-right-way/) 199 | * [Secure Coding Guidelines for Java SE](http://www.oracle.com/technetwork/java/seccodeguide-139067.html) 200 | * [Importance of languages ​​for security](https://www.ssi.gouv.fr/agence/publication/mind-your-languages-new-article-on-the-importance-of-languages-for-security/ ) 201 | * [Security and Java language](https://www.ssi.gouv.fr/javasec/) 202 | * [Security and functional languages](https://www.ssi.gouv.fr/lafosec/) 203 | 204 | * Eliminate all *debug* messages (by compilation conditional or through a run-time variable) and any unnecessary information for the user in error messages (e.g. Java / PHP / Python call trace) when going into production 205 | 206 | * Eliminate all dead code (*i.e.* code not called / no achievable) as it could be confusing and / or think that it is still functional and tested; this code, no maintained, could be wrongly reinstated by a developer 207 | 208 | * All external inputs (e.g. user) must be checked before use or storage, according to good safety practices and in function of their destination. 209 | 210 | ### Do not rely on security by obscurity 211 | 212 | Obscurity is generally recognized as an insufficient practice, but in the case of a project with open code, this strategy is deprecated. It must therefore be replaced by other more robust strategies such as defense in depth. 213 | 214 | ### Secret / sensitive data, cryptography 215 | 216 | * No secret items (such as a password or key cryptographic) should only be stored in the code or in the comments; use configuration files that are not versioned (*cf* `.gitignore`) 217 | 218 | * No secret element should be written by the program in clear in a file (including including a log file) or in a database, always prefer a hashed version with a state of the art hash function (*i.e* salt for each entry) 219 | * [General Security Reference System - Annex B3](https://www.ssi.gouv.fr/uploads/2014/11/RGS_v-2-0_B3.pdf) 220 | * No secret element must transit in clear on the network 221 | * Do not implement a cryptographic mechanism yourself but use recognized libraries using parameters and robust cryptographic suites 222 | * [Security Recommendations for TLS](https://www.ssi.gouv.fr/nt-tls/) 223 | * [General Security Reference System - Annex B3](https://www.ssi.gouv.fr/uploads/2014/11/RGS_v-2-0_B3.pdf) 224 | 225 | 226 | ### Development tools and dependencies 227 | 228 | * Use software and libraries where appropriate third parties maintained and up-to-date security patches; prefer libraries (re) known, and the simplest possible 229 | 230 | * Use the code analysis services offered by the platform and systematically process problems brought up before integration 231 | 232 | * Only push *commits* of code that compile, are tested, and functional, accompanied by corresponding unit tests; some platforms offer the opportunity to replay automatically the unit tests of a project to ensure the non-regression (e.g. [Travis](https://docs.travis-ci.com/), [Homu](https://github.com/servo/homu)) 233 | 234 | * Create a *tag* (e.g. v2.0.1) for each version (e.g. 2.0.1), and 235 | sign it cryptographically (see [GPG signature 236 | verification](https://github.com/blog/2144-gpg-signature-verification)) 237 | 238 | * Respect the recommendations and good safety practices issued by the ANSSI applicable to the project 239 | * [Good practices of ANSSI](https://www.ssi.gouv.fr/administration/bonnes-pratiques/) 240 | * [ANSSI / DINUM agile methodology security guide](https://www.ssi.gouv.fr/uploads/2017/07/guide-securite-agile_v0.42_anssi_dinsic.pdf) 241 | 242 | ## Tools 243 | 244 | The contribution policy is not intended to offer specific tools. However specifically for managing open code, you can find the referenced tools on [https://www.linuxfoundation.org/tools-managing-open-source-programs/](https://www.linuxfoundation.org/tools-managing-open-source-programs/#1) useful. 245 | -------------------------------------------------------------------------------- /pratique.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Bonnes pratiques 3 | menu: 4 | main: 5 | name: "Bonnes pratiques" 6 | weight: 40 7 | --- 8 | 9 | ## Système de suivi de version de code source 10 | 11 | L’utilisation d'un système de suivi de version distribué tel que Git est recommandée. Les systèmes SVN ou CVS sont déconseillés. 12 | 13 | ## Aide au choix d’une plateforme Web 14 | 15 | En plus du système de suivi de version du code source, une plateforme Web propose une panoplie d’outils collaboratifs associés et vise à mobiliser une communauté de développeurs. Ces plateformes peuvent être hébergées par un tiers ou par l’administration. 16 | 17 | Exemples de plateformes Web hébergées par un tiers : 18 | 19 | * GitHub : https://github.com 20 | * GitLab : http://gitlab.com (version entreprise) 21 | * Bitbucket : https://bitbucket.org 22 | * Adullact : http://gitlab.adullact.net - utilisant [GitLab](https://about.gitlab.com/installation/) 23 | * FSFE : https://git.fsfe.org - utilisant [Gitea](https://gitea.io/) 24 | * FSF : https://git.savannah.gnu.org/cgit/ - utilisant [cgit](https://git.zx2c4.com/cgit/) 25 | 26 | Les codes source de github.com et bitbucket.org ne sont pas libres, tout comme certains modules de gitlab.com ; certaines plateformes publient des données anonymisées en open data ; leurs portées géographiques peuvent varier, de même que le nombre de développeurs qui l’utilisent. La liste est incomplète. 27 | 28 | Le choix de créer un compte d’organisation au sein d’une plateforme Web existante relève de l’administration, qui peut également héberger sa propre forge publique. 29 | 30 | Le positionnement d’un projet sur une forge doit se faire en fonction du niveau de collaboration attendu et des interfaces avec les dépôts privés et le reste de la plateforme de développement. 31 | 32 | Pour connaître la forge sur laquelle publier votre code source, contactez le [mainteneur](MAINTAINERS) de cette politique correspondant à votre ministère. Si vous ne savez pas qui contacter, écrivez à `opensource@data.gouv.fr`. 33 | 34 | ## Gestion des comptes personnels et d’organisation 35 | 36 | Tous les projets initiés par une administration doivent être publiés dans des dépôts au sein de comptes d’organisation. Les dépôts de comptes personnels ne doivent être utilisés que pour des fourches (*forks*) techniques temporaires ou des développements personnels. 37 | 38 | Voici les recommandations pour la gestion des comptes d'organisation ou des groupes : 39 | 40 | - faire apparaître les noms d’utilisateurs des propriétaires ; 41 | - faire apparaître au moins une adresse e-mail de contact ; 42 | - faire apparaître le nom de domaine associé au compte d’organisation ; 43 | - si la plateforme le permet, faire vérifier le nom de domaine associé au compte ; 44 | - renseigner une description de l’organisation et une image l’identifiant. 45 | 46 | Pour la gestion des dépôts, il est recommandé d’avoir deux propriétaires et de faire apparaître le nom d’utilisateur d’au moins un propriétaire. 47 | 48 | ## Inventaire des comptes d’organisation 49 | 50 | Une liste des forges publiques et des comptes d’organisation connus à ce jour est lisible dans le fichier [comptes-organismes-publics](comptes-organismes-publics) : si vous avez connaissance d’une forge ou d’un compte d’organisation d’un organisme public qui n’y figure pas, vous pouvez soumettre une proposition via une _pull request_. 51 | 52 | Cette liste alimente le site [code.etalab.gouv.fr](https://code.etalab.gouv.fr) qui permet de chercher des dépôts dans l’ensemble de ces forges et comptes d’organisation. 53 | 54 | Vous pouvez aussi référencer un compte d’organisation comme un compte gouvernemental dans GitHub : 55 | 56 | 1. Inscrivez-vous si ce n’est pas déjà fait dans la communauté [https://github.com/government/welcome](https://github.com/government/welcome) ; 57 | 58 | 2. Référencez votre compte d’organisation en l’ajoutant sur la page : [https://github.com/github/government.github.com/blob/gh-pages/_data/governments.yml](https://github.com/github/government.github.com/blob/gh-pages/_data/governments.yml) conformément à la page [https://government.github.com/community/](https://government.github.com/community/). 59 | 60 | ## Distinction des contributions personnelles / professionnelles 61 | 62 | La distinction entre contributions personnelles et professionnelles se base sur l’adresse électronique associée. Le contributeur doit donc changer celle-ci en fonction de la situation où il se trouve. Dans le cas de l’utilisation de `git`, cela peut se faire simplement : 63 | 64 | * Pour une contribution professionnelle : 65 |
`git config user.email "prenom.nom@ministere.gouv.fr"` 66 | 67 | * Pour une contribution personnelle : 68 |
`git config user.email "email@perso.fr"` 69 | 70 | Pour connaître l’adresse électronique actuellement utilisée : 71 |
`git config --get user.email` 72 | 73 | Dans les cas où le contributeur ne souhaite pas voir son identité personnelle attachée à sa contribution, une adresse électronique (ou alias) devra être mise à disposition par le ministère pour permettre l’utilisation d’un pseudonyme. Attention certains projets open source peuvent refuser les contributions sous pseudonyme. 74 | 75 | ## Aide au choix de la licence 76 | 77 | Le choix d’une licence est aussi le choix d’une communauté de développeurs et d’un écosystème d’outils associés. Une fois la famille de licence trouvée, c’est avant tout la communauté visée qui détermine le choix. 78 | 79 | Les licences recommandées par défaut sont : 80 | 81 | * Permissive : Apache 2.0 82 | * Avec obligation de réciprocité : GNU GPL v3 (standard, lesser ou affero en fonction) 83 | 84 | > Multilicensing : il est possible de fournir un logiciel sous plusieurs licences simultanément, bien que cela puisse entraîner de la confusion. 85 | 86 | ## Gestion des versions 87 | 88 | Avoir une politique de gestion des versions est recommandé. Le guide de versioning sémantique (https://semver.org/lang/fr/) est un bon exemple à suivre. 89 | 90 | ## Fichiers présents dans le dépôt 91 | 92 | Assurez-vous d’avoir au minimum les fichiers README, CONTRIBUTING et LICENSE. 93 | 94 | * CODE\_OF\_CONDUCT : un code de conduite pour réguler la communauté de contributeurs. Voici quelques exemples : [https://www.djangoproject.com/conduct/](https://www.djangoproject.com/conduct/), [https://github.com/18F/code-of-conduct](https://github.com/18F/code-of-conduct), [Contributor Covenant](https://www.contributor-covenant.org/), [Charte de GNU pour une communication bienveillante](https://www.gnu.org/philosophy/kind-communication.fr.html), etc. 95 | 96 | * CONTRIBUTING : guide de contribution, comment s’impliquer et identification du processus de contribution et des licences associées. Exemple: [https://github.com/moby/moby/blob/master/CONTRIBUTING.md](https://github.com/moby/moby/blob/master/CONTRIBUTING.md) 97 | 98 | * GOVERNANCE : décrit la gouvernance du projet, les rôles et les droits de votes. Un exemple est disponible dans ce dépôt [gouvernance.md](gouvernance.md). 99 | 100 | * INSTALL : description de la procédure d’installation d’un logiciel. 101 | 102 | * LICENSE : licence de publication du logiciel. 103 | 104 | * MAINTAINERS : liste des mainteneurs du projet (avec des droits de vote ou de commit généralement). Exemple: [https://github.com/moby/moby/blob/master/MAINTAINERS](https://github.com/moby/moby/blob/master/MAINTAINERS) 105 | 106 | * NFR : choix d’architecture technique du projet qui ne correspondent pas à des exigences fonctionnelles. 107 | 108 | * README : description du projet. Peut décrire l’objectif et l’administration à l'origine de la publication. 109 | 110 | * ROADMAP : feuille de route publique. 111 | 112 | Ces fichiers doivent être en texte simple ou avec du marquage minimum (ie Markdown). Il n’est pas recommandé d’utiliser des formats binaires (ie PDF). 113 | 114 | ## Entête des fichiers sources 115 | 116 | Conformément aux recommandations détaillées dans [https://reuse.software](https://reuse.software) chaque fichier de code source doit disposer de son auteur, de son identifiant de licence SPDX, ainsi que d’une copie de la licence dans le dépôt local. 117 | 118 | * Exemples d’entête de fichier (headers) : 119 | 120 | ``` 121 | /* 122 | * Copyright (c) 2017 Alice Commit 123 | * 124 | * SPDX-License-Identifier: BSD-2-Clause 125 | * License-Filename: LICENSES/BSD-2-Clause_Alice.txt 126 | */ 127 | ``` 128 | 129 | ou dans le cas d’un projet faisant un suivi automatique de ses contributeurs : 130 | 131 | ``` 132 | /* 133 | * This file is part of project X. It's copyrighted by the contributors 134 | * recorded in the version control history of the file, available from 135 | * its original location http://git.example.com/X/filename.c 136 | * 137 | * SPDX-License-Identifier: BSD-2-Clause 138 | * License-Filename: LICENSES/BSD-2-Clause_Charlie.txt 139 | */ 140 | ``` 141 | 142 | Ces identifiants permettent de générer automatiquement des inventaires des licences sous la forme de « Bill of Material », afin de garantir la conformité du logiciel. 143 | 144 | L’ensemble des identifiants SPDX est disponible à cette adresse : [https://spdx.org/licenses/](https://spdx.org/licenses/) 145 | 146 | ## Traçabilité des développements (DCO) 147 | 148 | Il est recommandé de proposer aux contributeurs de signer un _Developer's Certificate of Origin_. Il permet au contributeur d’attester de l’originalité de sa contribution en plus du respect des licences des connaissances antérieures utilisées et qu’il accepte l’usage qui en sera fait. Une traduction du DCO est disponible [ici](https://github.com/DISIC/politique-de-contribution-open-source/blob/master/DCO-fr.txt) et l’original est accessible [là](https://developercertificate.org/) (en anglais). 149 | 150 | Pour accepter le DCO, il suffit que le contributeur signe chaque commit avec la commande: 151 | 152 | > `git commit --signoff` (ou `git commit -s`) 153 | 154 | Une procédure de DCO est de préférence instaurée au début du projet et elle est clairement indiquée dans un fichier `CONTRIBUTING` du dépôt. 155 | 156 | ## Bonnes pratiques de développement 157 | 158 | Les bonnes pratiques de développement courantes s’appliquent également en contexte de développement ouvert, et notamment celles liées au respect des référentiels en vigueur dans l’administration : 159 | 160 | * [Référentiel général d’interopérabilité (RGI)](http://references.modernisation.gouv.fr/interoperabilite ) 161 | * [Référentiel général d’accessibilité pour les administrations (RGAA)](http://references.modernisation.gouv.fr/rgaa-accessibilite/) 162 | * [Référentiel général de sécurité (RGS)](https://www.ssi.gouv.fr/administration/reglementation/confiance-numerique/le-referentiel-general-de-securite-rgs/) 163 | 164 | L’ouverture du code vient par ailleurs amplifier l’importance de certaines de ces bonnes pratiques : 165 | 166 | * **Conformité juridique** dans l’utilisation de bibliothèques tierces. La très grande majorité des développements actuels reposant sur des bibliothèques Open Source tierces, il est nécessaire de s’assurer de la compatibilité de leurs licences respectives et du respect des obligations de celles-ci. 167 | * **Modularisation des développements** afin de maximiser la réutilisation de code mais aussi d’isoler les éventuelles sources d’erreur 168 | * **Respect d’une unique convention de développement** par projet. 169 | * **Documentation**, à l’intérieur du code (commentaires et messages de *commit*) et hors du code (voir ci-après). 170 | 171 | ## Bonnes pratiques de documentation 172 | 173 | Les recommandations ci-dessous fixent un idéal, pas un ensemble d’obligations. Néanmoins, la qualité d’un projet Open Source étant étroitement corrélée à la qualité de sa documentation, on y prêtera une attention particulière. 174 | 175 | - La documentation est publiée sous [**Licence Ouverte 2.0**][LO link]. 176 | - Elle est à jour avec la version du logiciel qu’elle documente. 177 | - Elle propose un manuel utilisateur et un guide du contributeur. 178 | - Elle est lisible en ligne (site web) et hors-ligne (document PDF). 179 | - Elle est rédigée dans un français et/ou un anglais corrects. 180 | - Elle cible plusieurs attentes (FAQ, tutoriels, manuel approfondi, etc.) 181 | - Elle contient le moins possible de références culturelles ou contextuels risquant de devenir incompréhensibles. 182 | 183 | ## Sécurité 184 | 185 | ### Interlocuteur identifié 186 | 187 | Il est recommandé d’identifier un responsable de la sécurité du projet qui sera garant de vérifier le respect des bonnes pratiques mises en œuvre durant le développement, et de traiter les éventuels incidents de sécurité. Il est également préférable d’avoir recours à une adresse électronique dédiée, à destination du responsable identifié au moins, pour traiter des incidents de sécurité ou des problèmes liés à la propriété intellectuelle qui seraient découverts par un tiers. 188 | 189 | ### Développement sécurisé 190 | 191 | * Écrire du code qui respecte des pratiques de sécurité reconnues et qui ne fait pas usage de constructions dangereuses dans le langage utilisé 192 | * [SEI CERT Coding Standards](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards) 193 | * [PHP The Right Way](http://eilgin.github.io/php-the-right-way/) 194 | * [Secure Coding Guidelines for Java SE](http://www.oracle.com/technetwork/java/seccodeguide-139067.html) 195 | * [Importance des langages pour la sécurité](https://www.ssi.gouv.fr/agence/publication/mind-your-languages-nouvel-article-sur-limportance-des-langages-pour-la-securite/) 196 | * [Sécurité et langage Java](https://www.ssi.gouv.fr/javasec/) 197 | * [Sécurité et langages fonctionnels](https://www.ssi.gouv.fr/lafosec/) 198 | 199 | * Éliminer tous les messages de *debug* (par compilation conditionnelle ou par un contrôle via une variable à l’exécution) et toute information inutile pour l’utilisateur dans les messages d’erreur (e.g. trace d’appel Java/PHP/Python) lors de la mise en production 200 | 201 | * Éliminer tout le code mort (*i.e.* code non appelé/non atteignable) car il pourrait prêter à confusion et/ou laisser penser qu’il est toujours fonctionnel et testé ; ce code, non maintenu, pourrait être réintégré à tort par un développeur 202 | 203 | * Toutes les entrées externes (e.g. de l’utilisateur) doivent être contrôlées avant leur utilisation ou leur stockage, selon les bonnes pratiques de sécurité en fonction de leur destination. 204 | 205 | ### Ne pas compter sur la sécurité par l’obscurité 206 | 207 | La sécurité par l’obscurité est globalement reconnue comme une pratique insuffisante, mais dans le cas d’un projet dont le code est ouvert, cette stratégie est caduque. Elle doit donc être remplacée par d’autres stratégies plus robustes comme par exemple la défense en profondeur. 208 | 209 | ### Données secrètes/sensibles, cryptographie 210 | 211 | * Aucun élément secret (tel qu’un mot de passe ou une clé cryptographique) ne doit être stocké dans le code ou dans les commentaires ; avoir recours à des fichiers de configuration qui ne sont pas versionnés (*cf* `.gitignore`) 212 | * Aucun élément secret ne doit être écrit par le programme en clair dans un fichier (y compris un fichier de journalisation) ou dans une base de données, toujours préférer une version hachée par une fonction de hachage reconnue à l’état de l’art et correctement utilisée (*i.e* salée pour chaque entrée) 213 | * [Référentiel général de sécurité - Annexe B3](https://www.ssi.gouv.fr/uploads/2014/11/RGS_v-2-0_B3.pdf) 214 | * Aucun élément secret ne doit transiter en clair sur le réseau 215 | * Ne pas implémenter soi-même de mécanisme cryptographique mais utiliser des bibliothèques reconnues en utilisant des paramètres et des suites cryptographiques robustes 216 | * [Recommandations de sécurité relatives à TLS](https://www.ssi.gouv.fr/nt-tls/) 217 | * [Référentiel général de sécurité - Annexe B3](https://www.ssi.gouv.fr/uploads/2014/11/RGS_v-2-0_B3.pdf) 218 | 219 | ### Outils de développement et dépendances 220 | 221 | * Utiliser, le cas échéant, des logiciels et des bibliothèques tierces maintenus et à jour des correctifs sécurité; préférer des bibliothèques (re)connues, et les plus simples possibles. 222 | * Utiliser les services d’analyse de code offerts par la plateforme d’hébergement et traiter systématiquement avant intégration les problèmes remontés. 223 | * Ne pousser que des *commits* de code qui compilent, testés et fonctionnels, accompagnés des tests unitaires correspondants ; certaines plateformes offrent la possibilité de rejouer automatiquement les tests unitaires d’un projet afin d’assurer la non-régression (e.g [Travis](https://docs.travis-ci.com/), [Homu](https://github.com/servo/homu)). 224 | * Créer un *tag* (e.g. v2.0.1) pour chaque version (e.g. 2.0.1), et le signer cryptographiquement (voir [GPG signature verification](https://github.com/blog/2144-gpg-signature-verification)). 225 | * Respecter les recommandations et bonnes pratiques de sécurité émises par l’ANSSI applicables au projet 226 | * [Bonnes pratiques de l’ANSSI](https://www.ssi.gouv.fr/administration/bonnes-pratiques/) 227 | * [Guide de sécurité méthodologie agile ANSSI / DINUM](https://www.ssi.gouv.fr/uploads/2017/07/guide-securite-agile_v0.42_anssi_dinsic.pdf) 228 | 229 | ## Outillage 230 | 231 | La politique de contribution n’a pas vocation à proposer un outillage particulier. Toutefois spécifiquement pour la gestion de code ouvert, vous pourrez trouver les outils référencés sur [https://www.linuxfoundation.org/tools-managing-open-source-programs/](https://www.linuxfoundation.org/tools-managing-open-source-programs/#1) utiles. 232 | --------------------------------------------------------------------------------