- TODO : ajouter éléments sur publicode.yml (et codemeta.json)
- Une collectivité territoriale développe un outil de correction grammaticale pour LibreOffice. Ce logiciel est un module d’un logiciel libre existant et il répond à un besoin générique : il est pertinent d’en faire un logiciel libre « contributif » (niveau A).
- Une administration développe un outil pour organiser la collecte de données sur le web (scraping). C’est un outil web « monolithique » mais qui répond à un besoin rencontré hors de l’administration : il peut être publié comme logiciel libre « ouvert » (niveau B).
- Une administration centrale développe un thème pour les sites qu’elle publie à l’aide de Jekyll. Ce thème est un module d’un logiciel libre existant mais il répond à un besoin spécifique de l’organisme public : son code source peut être publié, mais sans recherche active de contributeurs ni maintenance particulière à l’égard des contributions extérieures (niveau C).
Chaque organisme peut tenter de prioriser les logiciels à ouvrir en fonction de ces critères.
La licence GFDL (GNU Free Documentation License), rédigée par la FSF, est une forme de copyleft destinée à être utilisée sur un manuel, un guide ou tout autre document afin d’assurer à chacun la liberté effective de le copier et de le redistribuer, avec ou sans modifications, que ce soit à des fins commerciales ou non commerciales.
La licence Etalab 2.0 est aussi une bonne licence pour publier le contenu d’une documentation.
Les licences Creative commons ont été conçues pour permettre la diffusion des oeuvres encadrées par le droit d’auteur, mais distinctes du logiciel.
Voici les deux licences les plus utiles dans le contexte des travaux des administrations.
Creative commons « paternité - partage à l’identique », (CC-BY-SA)
Cette licence s’apparente à une licence de logiciel libre de type copyleft. Toute oeuvre dérivée pourra être redistribuée à condition de conserver la licence initiale. Un éventuel usage commercial est possible, sans l’autorisation de l’auteur.
Une telle licence permettra la publication de documents dont la nature évolutive est claire. C’est particulièrement vrai pour la documentation logicielle, documents d’analyse fonctionnelle, d’architecture, de conception technique, d’installation, d’exploitation, ainsi que les guides et tutoriels utilisateurs. Un contributeur pourra ainsi redistribuer, s’il le souhaite, une nouvelle version du logiciel, avec une documentation mise à jour.
Creative commons « paternité - pas de modification », (CC-BY-ND)
Cette licence interdit de redistribuer toute version modifiée de l’oeuvre. Comme il n’est pas possible de créer une oeuvre dérivée, il n’y a pas de pertinence à exiger le partage à l’identique. Cette licence est incompatible avec l’esprit d’une licence libre. Un usage commercial est possible, sans l’autorisation de l’auteur. Ce type de licence convient à la publication :
- de textes officiels : textes juridiques, rapports publics, lettres de mission, cadres techniques
- de documents factuels ou contractuels : compte-rendus de réunion, points de décisions, CCTP, CCAP
- de documents de communication : communiqués politiques , interviews institutionnelles ou nominatives, témoignages, discours
Il est possible d’interdire les usages commerciaux en ajoutant une clause « Pas d’utilisation commerciale ». Une telle déclinaison existe pour chacune des licences précédemment citées. Mais en interdisant un usage commercial sur les oeuvres, qu’interdit-t’on en vérité ?
Il est interdit au licencié de tirer un profit commercial ou une compensation financière quelconque de la présentation, de la représentation, de la communication de l’oeuvre pour quelques supports, médias, procédés techniques et formats utilisés. Par exemple une personne ayant compilé un CD contenant des documents sous Creative commons de type « pas d’utilisation commerciale » ne pourra vendre même à prix coûtant le CD, sans en avoir demandé l’autorisation. De même, une édition papier d’un document, ne peut être diffusée sauf gratuitement.
Notes sur les langues employées dans un dépôt de code sources :
- les messages de commits doivent être rédigés en anglais ;
- le code source doit lui-même privilégier l’anglais, sauf pour tout ce qui relève d’un domaine métier propre à l’administration ;
- la documentation utilisateur doit être rédigée en français ;
- les documentations pour les développeurs et les instructions pour les contributeurs doivent être rédigée en anglais.
L’architecture de fichiers d’un dépôt de code source type pour l’administration devrait ressembler à ça :
=== . ├── CODE_OF_CONDUCT.fr.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.fr.md ├── CONTRIBUTING.md ├── LICENSE.md ├── publiccode.yml ├── README.fr.md └── README.md ===
Potentiellement, si plusieurs licences sont appliquées au code source
(plusieurs dépendances avec des licences différentes, la documentation
sous une licence à part, etc.) le fichier LICENSE.md peut référencer
la licence spécifique pour chaque élément du dépôt, et mettre les
différentes licences dans un dossier LICENSES :
=== . ├── CODE_OF_CONDUCT.fr.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.fr.md ├── CONTRIBUTING.md ├── LICENSE.md ├── LICENSES │ ├── CC-BY-SA-4.0 │ └── MIT ├── publiccode.yml ├── README.fr.md └── README.md ===
Les messages de commits devraient ressembler aux exemples suivants. Ici, ils sont sont rédigés en français pour en faciliter la lecture par les agents publics développeurs en position de publier des codes sources, mais devraient être rédigés en anglais.
===
- Ajout d’un fichier README
- Ajout d’une licence et des informations sur l’auteur
- Ajout d’une présentation générale du dépôt
- Ajout d’instructions d’installation
- Ajout de lien vers la documentation
- Ajout de conventions de programmation
- Ajout d’instructions pour les contributeurs
- Ajout d’un fichier publiccode.yml
===
Vous pouvez consulter cette présentation BlueHats qui propose des pistes.
Chercher une forge proche en consultant https://code.gouv.fr/sources/#/repos Un compte d’organisation car ce sont les seuls prix en compte sur code. gouv. Penser à demander de référencer la forge de l’orga à contact@code.gouv.fr Si l’organisation à plusieurs forges ou comptes d’orga : pas de problème. Si nouveaux codes : forge/compte d’organisation Si projet existant : fork sur la forge d’organisation. Les forks sont listés sur code.gouv.fr
Est-il souhaitable d’utiliser ma solution de gestion de code Source (GitLab, Bitbucket) en ouvrant des projets en mode public?
lire le rapport sur les forges REX déploiement et maintenance. plutôt chercher une forge publique proche. (proche = ministère ? réseau des laboratoires ?) ce qui assurera la visibilité, c’est d’être référencé, pas le fait d’être sur une “grande” forge. seules défférences fonctionnelles : pas les fonctionnalités GIT mais les fonctionnalités de la CI/CD.
Est-il préférable de conbribuer en tant qu’individu (prenom.nom de l’agent) ou plutôt en tant qu’organisation aux logiciels libres ? (compte individuel ou compte entreprise ?)
en tant qu’individu.
les équipes métiers peuvent évaluer architecture des projets : modularité et généricité donnent un bonus de réemployabilité ( réutilisable par d’autres administrations). des demandes d’autres administrations prioriser : le plus générique, le meilleure. VS le spéicifique ou le mal écrit n’est pas un bon candidat pour une publication open-source. Expliciter pourquoi nous publions un dépôt. Quels logiciels ouverts à quel degrès https://code.gouv.fr/documentation/#/publier?id=quels-logiciels-ouvrir-à-quel-degré-
Quels précautions et quels points à vérifier avant d’ouvrir du code source interne à notre organisation ?
sécurité - pas de secret dans l’historique GIT sécurité - ne pas augmenter la surface d’attaque ( mais ne pas sécuriser en cachant) legalité - choisir la licence logicielle ( en tenant compte des licences intégrées des modules et bibliothèques employées ) https://www.data.gouv.fr/fr/pages/legal/licences/ https://code.gouv.fr/guides/juridique/
simplement informer le manager. autonomie https://www.numerique.gouv.fr/publications/politique-logiciel-libre/
En tant qu’agent de l’État, puis-je contribuer à un logiciel libre existant et utilisé dans mon administration/service sur mon temps de travail? Si oui dans quelles conditions ?
Si le logiciel est réalisé par un ou plusieurs salariés dans le cadre d’une relation de subordination à leur employeur : les droits moraux restent acquis aux auteurs mais les droits d’exploitation sont transmis de plein droit à l’employeur. Cette disposition est valable pour l’agent dans ses missions de services publics (Art. L. 131-3-1 du Code de la propriété intellectuelle).
Si le logiciel est réalisé sur le temps libre de l’auteur, de sa propre initiative, avec ses propres moyens techniques et sans rapport avec sa fonction : il est alors auteur de plein droit et dispose à sa guise de l’ensemble des prérogatives liées à l’expression en particulier des droits d’exploitation.
Donc en tant qu’agent de l’État, il est possible de contribuer si vous avez l’accord de votre hiérarchie.
Le document qui acte de cette possibilité de contribuer à des logiciels libres existants est la politique de contribution open source de 2018.
Cependant, ça peut être plus compliqué que de simplement obtenir l’accord de la hiérarchie, notamment s’il faut signer un CLA pour contribuer au projet. Dans ce cas-là, les services juridiques devront s’en mêlent. S’il n’y a qu’un DCO, vous pouvez l’accepter sans mobiliser vos services juridiques.
AGPL Licence section 13:
Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
- Il n’est pas question d’utilisation d’un logiciel pour tomber sous les obligations de redistributions. Il faut que le logiciel soit modifié pour devoir fournir le code source du logiciel qui tourne sur un serveur.
- La question : Est-ce qu’un appel d’API constitue une modification du code source ?
- Soit un logiciel A sous AGPL exécuté sur une machine 1 et qui expose des API en web service sur cette machine 1
- Soit un logiciel B sur une machine 2 qui interroge les API exposées via la machine 1
- Le logiciel B ne contient aucune ligne de code du logiciel A
- Le logiciel B sollicite des points d’accès (“endpoints”) de la machine A
Est-ce que le logiciel B peut être considéré comme dérivant du code source du logiciel A?
Le code source du logiciel B doit-il être redistribué aux utilisateurs du logiciel B?
Cette section viendra documenter des exemples utiles à l’illustration des différents sujets.
- https://publiccode-editor.etalab.studio : site web facilitant la
création de fichiers
publiccode.yml. - https://publiccodenet.github.io/assessment-eligibility/ : site web pour tester votre éligibilité au standard pour un code public.
- https://github.com/finos/open-source-readiness
- https://www.ow2.org/view/MRL/
- Framasoft : Ce site propose une base référençant plus de 1200 applications sous licence libre et disponible sous Windows. Figurer dans cette base est une bonne garantie du caractère libre d’un logiciel.
- Adullact : Sur ce site une vérification précise du caractère libre de l’application est opérée avant toute mise à disposition, c’est une condition de l’hébergement.
- Apache : La gouvernance autour des projets de la fondation Apache est très forte. De part ses statuts elle héberge exclusivement des projets sous licence Apache Licence. Le caractère libre des composants est garanti.
- Debian : le fait pour une application d’être packagée par la communauté Debian dans les sections « main » et « contrib » des dépôts de la distribution, est une forte garantie de son caractère libre. Ce sont d’ailleurs les principes du logiciel libre selon Debian qui ont donnés naissance aux 10 critères permettant de qualifier une licence open source selon l’Open Source Initative. Depuis la page http://www.debian.org/distrib/packages il est possible de rechercher un logiciel afin de vérifier qu’il appartient bien au section « Main » ou « contrib ».
- FSF/UNESCO Free Software Directory : La Free Software Foundation et l’UNESCO ont recensé plus de 16 900 logiciels pour lesquels le caractère libre de la licence a été vérifié.
Vous pouvez lire notre entrée de blog de mars 2022 sur les feuilles de routes.
Voici une liste des politiques ministérielles déjà publiées concernant le logiciel libre :
- Ministère de la Cohésion des Territoires et des Relations avec les Collectivités Territoriales
- Ministère des Solidarités et de la Santé
- Ministère de la Transition Écologique
- Ministère de l’Agriculture et de l’Alimentation
- Ministère de l’Intérieur
- Ministère de la Justice
- Ministère de l’Économie, des Finances et de la Relance
- Ministère de l’Enseignement Supérieur, de la Recherche et del’Innovation
- Ministère de la Transformation et de la Fonction publiques
- Services du Premier ministre
- Ministère de la Culture
- Ministère de la Transition Écologique
- Ministère du Travail, de l’Emploi et de l’Insertion
- Ministère de l’Éducation nationale, de la Jeunesse et des Sports
- Ministère de l’Enseignement supérieur, de la Recherche et de l’Innovation
Les success stories dans le privé sont désormais compliquées à dénombrer. En vrac, on peut citer : Orekit, RedHat (du moins pendant de nombreuses années), Mozilla, Axelior, Eclipse, etc.
Pour le public, on peut citer : Lutece de la ville de Paris, le fait qu’un État fédéral allemand fait passer 30 000 PC sous Linux et LibreOffice, lefait que le système de design de l’État (DSFR) permet entre 3,1 et 4,9 M€ d’économies par an (note de bas page 86). Vous pouvez voir une liste plus complète de logiciel libre à fort potentiel de réutilisation sur code.gouv.efr/awesome.
- Généralités:
- Exmplaire sur les messages de commit en anglais
- Exemplaire sur la doc utilisateur en français
- Exemplaire sur la doc dev en anglais
- Exemplaire sur les noms de variable dans la langue du référentiel (FR, EN)
- Exemplaire sur les commentaires dans le code qui sont en anglais
- Utiliser la licence AGPL
- Recommandations de sécurité relatives à un système GNU/Linux, ANSSI, 2022
- Le poste de travail Linux
- Web Components
- Concentration des logs
- Pare-feu applicatif
- Alternative à Log4j
- Messagerie asynchrone interapplicative
- Messagerie : Passerelles de filtrage
- Environnement de développement informatique
- Orchestration de conteneurs
- Gestion de l’identité
- Etude centOS
- Logiciels de GMAO
- Espace de travail collaboratif
- Tableau de collecte de données
- L’OpenJDK 17
- Autorité de certification
- Solution de VPN
- Alternative à MECM
- Les logiciels de la recherche et leurs licences : trois visions sur un objet
- https://espacechercheurs.enpc.fr/sites/default/files/logigramme_a_plat.pdf