note Note générale

Libérer le code source d'un logiciel: petit guide

📌 Contexte
Cette note se veut un petit guide pour les personnes/organismes qui songeraient à libérer le code source d'un logiciel. Des guides plus complets sont liés à la toute fin dans la section Références. Elle s'inscrit dans la série de notes Rêver En commun 2030 - un logiciel libre dans un écosystème ouvert, réalisée par FACiL.

1. Pourquoi libérer ?

Les motivations pour libérer un logiciel sont nombreuses et de divers ordres. Une personne étudiant l'informatique peut choisir de le faire dans un contexte d'apprentissage. Une autre personne qui a plus d'expérience peut vouloir démontrer et mettre en valeur ses compétences de programmation pour le bien de sa carrière. Des organismes publics peuvent souhaiter mutualiser des ressources, éviter les dédoublement­s. Des entreprises privées du secteur technologique peuvent souhaiter se démarquer, se donner un avantage concurrentiel. Toutes ces motivations peuvent intervenir en pratique, mais il arrive parfois aussi (heureusement) que des raisons supérieures interviennent. Par exemple, des raisons qui découlent de la lecture des principaux documents qui exposent la philosophie du logiciel libre.

💡 Logiciel libre [free software] désigne des logiciels qui respectent la liberté des utilisateurs. En gros, cela veut dire que les utilisateurs ont la liberté d'exécuter, copier, distribuer, étudier, modifier et améliorer ces logiciels.

En résumé, si on prend le temps de remonter aux sources, on comprend que le domaine de liberté défini par les licences de logiciel libre est nécessaire à la protection des libertés au fondement de la démocratie[1]. Le code source des logiciels ne peut pas être traité comme la simple «propriété intellectuelle» d'une personne ou d'une entreprise : il est plutôt comme le texte de nos lois et participe de la régulation sociale dans la société numérique[2]. Le développeur d'un logiciel non libre est dans une position de pouvoir vis-à-vis des utilisateurs. Le développeur d'un logiciel libre renonce à cette position et redonne aux utilisateurs les moyens d'exercer un contrôle sur leur informatique.

Les logiciels ne sont pas que des éléments incontournables de la régulation sociale dans le 21e siècle numérique : ils sont aussi des ressources. De ce point de vue, ils peuvent être développés et maintenus tels des biens communs lorsque publiés sous une licence adéquate. Ce n'est pas automatique : il faut non seulement le socle des licences libres, mais aussi une forme d'organisation adaptée et la volonté de marcher en terrain inconnu. Parler d'« innovation sociale » n'est sans doute pas exagéré. Heureusement, plus de quarante ans d'expérimentation et d'inventivité dans le milieu du logiciel libre ont permis de révéler des voies possibles pour démocratiser des pans entiers de l'économie numérique... si nous faisons les bons choix individuels et collectifs !

2. Comment libérer ?

Le principal critère qui distingue les logiciels libres de ceux qui ne le sont pas est d'ordre juridique. Sous quelle licence un logiciel est-il publié ? S'il est publié sous une licence reconnue comme «libre» par la Free Software Foundation (FSF) et/ou l'Open Source Initiative (OSI), pas trop de doute : il est libre. Il existe un certain nombre de licences suffisamment reconnues, adoptées et éprouvées devant les tribunaux pour être en quelque sorte devenues des standards de fait en la matière. C'est le cas par exemple des licences GPL, BSD, MIT, Apache et Mozilla.

Parmi les licences généralement reconnues comme «libres», on distingue deux grandes catégories : celles qui exigent la «réciprocité» et celles qui ne l'exigent pas.

Qu'est-ce que cette «réciprocité» au fait ? C'est le principe au coeur du copyleft des licences GPL et des autres licences qui s'en inspirent[3]. Sur le plan historique, les licences à réciprocité sont apparues pour palier aux faiblesses du domaine public et des premières licences libres «universitaires» comme BSD et MIT. La principale de ces faiblesses est que rien n'empêche un auteur de piger du code dans le domaine public (ou sous licence BSD ou MIT) pour l'intégrer à une oeuvre dérivée qui sera entièrement sa propriété exclusive. On peut donc légalement prendre dans le pot commun sans remettre dans le pot commun. La réciprocité est précisément l'inverse.

Les licences à réciprocité ne sont pas toutes identiques. Continuons avec l'exemple des licences GPL:

  • La GNU General Public Licence (GPL) est une licence à réciprocité «forte»; comme son nom l'indique, elle se veut «générale» et est donc conçue pour tout type de logiciel qui n'est pas trivial[4]. Certains des logiciels les plus connus au monde sont publiés aux conditions de cette licence : les principaux logiciels GNU, le noyau Linux, WordPress, Drupal, Git, MySQL/MariaDB, VLC, OBS Studio, etc.
  • La GNU Lesser General Public Licence (LGPL) est une licence à réciprocité «faible» conçue pour un cas bien particulier : les bibliothèques logicielles qu'on voudrait rendre utilisables même par les développeurs d'applications non libres. Par exemple, si je développe la meilleure bibliothèque au monde pour encoder et décoder la vidéo, peut-être est-ce une bonne idée qu'elle puisse être intégrée dans le maximum d'applications pour s'imposer comme standard de fait, même dans milieu du développement non libre. Quelques exemples de logiciels disponibles sous cette licence : les bibliothèques développées par VideoLAN (qui fait VLC), FFmpeg, GTK, Qt, etc.
  • La GNU Affero General Public Licence (AGPL) est une licence à réciprocité «forte» qui offre tout ce qu'offre la GPL, mais avec en plus une clause pensée spécialement pour l'utilisation des logiciels sur un réseau, par exemple les applications Web. Si un logiciel exécuté sur un serveur est publié aux conditions de la AGPL, le serveur (ou plutôt la personne ou l'organisme qui l'opère) est dans l'obligation de fournir le code source aux utilisateurs car l'utilisation via le réseau est comprise comme une forme de «distribution» du logiciel. Quelques exemples de logiciels : Mastodon, F-Droid, Nextcloud, PeerTube, etc. Peut-être la licence la plus appropriée pour les plateformes En commun développées par Projet collectif ?

C'est tout ce qu'il y a à savoir sur les licences ? Bien sûr que non ! On trouve heureusement plusieurs guides pour approfondir le sujet (voir la section «Références» ci-bas).

Choisir une licence c'est aussi choisir un modèle économique. Sur ce sujet on ne peut plus important mais qui déborde le cadre de cette note on trouve aussi plusieurs ressources sur Internet et nous en indiquons quelques-unes dans la section «Références».

Le code est libéré : quoi faire ensuite ?

Que reste-t-il à faire une fois que le code est libéré ? Presque tout en réalité ! S'il fallait résumer, on pourrait dire qu'il faut surtout être prêt à animer une «communauté», ce qui implique notamment de faire beaucoup de communication pour faciliter la collaboration.

Rendre disponible le code source via une forge logicielle publique est sans doute la première action à poser si on entend bien développer le logiciel «à l'air libre». Ce n'est pas une obligation découlant des licences libres elle-mêmes, mais c'est attendu des développeurs car il y a de très nombreux précédents.

Dans le dépôt de code d'une forge accessible publiquement, un certain nombre de documents doivent être présents si on veut suivre les bonnes pratiques et adhérer aux conventions les plus suivies :

  • README - Ce document est la porte d'entrée pour toute personne qui découvre le projet de code. Il doit répondre aux questions qu'auront différents publics : les personnes qui veulent simplement utiliser le logiciel ou obtenir de l'aide; les personnes qui veulent déployer le logiciel dans leur propre environnement; les personnes qui veulent potentiellement contribuer au projet
  • README.fr - Oui, les développeurs se débrouillent généralement en anglais, mais les autres ? Pensez à maintenir une version française de la porte d'entrée de votre projet au minimum !
  • LICENCE/COPYING - Il s'agit d'une copie de la licence choisie pour le code
  • CONTRIBUTING - C'est souvent via ce fichier que sont donnés des détails sur la bonne manière de faire des contributions au projet. On pense bien sûr aux contributions de code, mais aussi il ne faut pas oublier les importants rapports de bogue, la documentation, la traduction, etc.
  • CODE OF CONDUCT - Les interactions en ligne entre humains sont ce qu'elles sont... Non seulement vous n'êtes pas obligés d'endurer les comportements abusifs, mais c'est de votre devoir (en tant qu'initiateurs d'un projet) de voir à protéger les membres de votre communauté contre toutes sortes de comportements qui n'ont pas leur place dans le Libre (ni ailleurs)
  • AUTHORS - Une liste de toutes les personnes/organisations qui ont fait des contributions au projet. Ce fichier se nomme parfois CREDITS
  • CHANGELOG - Ce document contient une liste des changements réalisés d'une version à l'autre du logiciel au fil de son développement. Les principaux changements sont souvent mis en évidence dans un langage moins technique via un fichier RELEASE-NOTES
  • SECURITY - La politique de sécurité du projet est souvent rendue explicite dans ce document. On s'attend habituellement à ce qu'une personne/organisation qui croit avoir identifié une faille de sécurité contacte d'abord les responsables du projet en privé avant de la rendre publique.
  • Autres - Non seulement il y a parfois d'autres documents (exemples : INSTALL, MAINTAINERS, etc.), mais il y a pas mal de variations car les conventions évoluent et sont souvent établies au niveau des langages, outils et environnement de développement

Il arrive parfois qu'on rende public un dépôt qui a déjà un historique d'activités de plusieurs mois voire plusieurs années. Il devient très important dans un tel cas de vérifier qu'il n'y ait pas de trace de données personnelles ou sensibles (exemples : mot de passe, adresses de courriel) dans tout l'historique du projet.

Notes

  1. Voir la «Philosophie du projet GNU» sur gnu.org ou le recueil des essais de Richard Stallman Free Software, Free Society (3e éd., 2015).
  2. Lawrence Lessig, Code and Other Laws of Cyberspace (1999).
  3. C'est aussi du principe de réciprocité dont il est question dans la condition SA (Share-Alike) des licences Creative Commons.
  4. Un logiciel trivial serait par exemple un programme simple qui fait quelque chose de banal en moins de 300 lignes de code.

Références

Cette section contient des liens vers des documents parfois en anglais. Le fait de lier ne constitue pas un appui. Notamment, plusieurs documents parlent d'open source (même en français), alors que nous privilégions l'expression logiciel libre.

shareCopier le lien

note Note(s) liée(s)

diversity_3Organisation(s) reliée(s)

bookmark Terme(s) relié(s)

padding Carnet(s) relié(s)

file_copy 27 notes
Analyse de soutenabilité des plateformes En commun
file_copy 27 notes
person
Intégré par Joël Nadeau, le 16 septembre 2024 11:33

Auteur·trice(s) de note

Mathieu Gauthier-pilote

forumContacter l’auteur·trice

forumDiscuter de la note

Publication

16 septembre 2024

Modification

25 septembre 2024 22:05

Historique des modifications

Visibilité

lock_open public

Pour citer cette note

Mathieu Gauthier-pilote. (2024). Libérer le code source d'un logiciel: petit guide. Praxis (consulté le 12 octobre 2024), https://praxis.encommun.io/n/M-283fxCckG9KjoQVGh7Nykv64U/.

shareCopier