Depuis lors, de nombreux États, gouvernements locaux et membres de la société civile ont travaillé sur les enjeux de cette ouverture et de sa mise en pratique pour une administration. En France, la Direction interministérielle du numérique et du système d’information et de communication de l’État (DINSIC) finalisera en février 2018 une politique de contribution aux logiciels libres. Elle a donc souhaité échanger avec les acteurs de l’État, mais également les communautés du libre, les associations, les sociétés privées et le secteur académique sur les modalités d’ouverture des codes source.
Pour cela, elle lance maintenant un appel à commentaires, ouvert jusqu’au 6 janvier 2018, sur une politique de contribution open source, qui a pour objectif de synthétiser les préconisations et les meilleures pratiques dans le domaine. Cette politique actuellement en version alpha vise en effet à répondre à un certain nombre de questions : comment ouvrir ses codes source ? Quelle licence choisir ? Comment un agent public peut-il contribuer à un logiciel libre existant ? Etc.
Les objectifs de cette politique interministérielle de contribution aux logiciels libres sont donc de :
- fixer les règles et principes à respecter pour l’ouverture des codes source ;
- accompagner les ministères et partager les meilleures pratiques ;
- définir la gouvernance des politiques de contribution de l’État.
La politique de contribution se compose de quatre parties :
- principes d’ouverture des codes source ;
- modalités et meilleures pratiques ;
- instanciation de politique de contribution ministérielle ;
- gouvernance associée.
Les principes d'ouverture de codes source actuellement définis sont entre autres :
- principe de subsidiarité : la politique peut être instanciée localement avec une priorité plus forte ;
- reconnaissance individuelle des développeurs : utilisation de leurs adresses email pour tracer leurs contributions ;
- distinction des contributions professionnelles/personnelles : possibilité de contribuer sur un même projet dans le cadre du milieu professionnel ou à titre personnel. Le mail professionnel doit être utilisé sur le temps professionnel ;
- pas d’engagements (ni support/ni revue des suggestions de modification) ;
- autorisation par défaut de contribuer aux projets sous licences FSF ou OSI ;
- recommandation d’utiliser les familles de licences permissives dans le cas général ;
- etc.
Pour les meilleures pratiques, on peut citer entre autres :
- utilisation nécessaire d’un système de suivi de version distribué (git, bitbucket, mercurial) ;
- aide au choix d’une plateforme de publication (GitHub, GitLab, etc.) ;
- gestion des comptes personnels et d’organisations : utilisation de dépôts au sein de comptes d’organisation. Les dépôts de comptes personnels sont à proscrire et ne doivent être utilisés que pour des développements personnels. Il est recommandé d’avoir deux propriétaires (owner) par dépôt ;
- inventaire des comptes d’organisation ;
- distinction des contributions professionnelles/personnelles ;
- aide au choix de la licence : les licences recommandées par défaut sont Apache 2.0 (permissive) et GNU GPL v3 (avec partage à l’identique). Il est possible de fournir un logiciel sous plusieurs licences simultanément, bien que cela puisse entrainer de la confusion ;
- gestion des versions : avoir une politique de gestion des versions est recommandé ;
- fichiers par défaut dans un dépôt (repository) : s'assurer d’avoir au minimum les fichiers README, CONTRIBUTING et LICENSE ;
- bonnes pratiques de développement ;
- etc.
Sont concernés, l’ensemble des codes source développés en interne par l’administration ou développés pour le compte de l’administration. Chaque administration de l’État aura la possibilité d’instancier sa propre politique de contribution pour la préciser et l’amender. Il faut aussi préciser que les fonctions publiques hospitalières et territoriales sont hors périmètre de cette politique de contribution, mais elles peuvent s’en inspirer librement.
La politique de contribution vise en premier les nouveaux développements, afin qu’ils respectent les meilleures pratiques déjà mises en œuvre au sein des communautés et des acteurs du libre. Pour l’ouverture de codes source existants, des actions complémentaires seront en effet 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, et feront l’objet d’une méthodologie à part.
Source : Blog Etalab, Politique de contribution aux logiciels libres
Et vous ?
Que pensez-vous de cette initiative ?
Êtes-vous pour ou contre la tendance à pousser les entreprises vers l'open source ? Pourquoi ?
Croyez-vous que le libre et l’open source ont de l’avenir dans l’administration française ? Pourquoi ?
Qu’en est-il dans votre entreprise ? Faites-vous de l’open source ? Partagez votre expérience.