Au-delà du développement : licence, archivage, etc.
Cours
Frédéric Santos 
Dans cette section, nous explorons quelques problématiques qui vont au-delà du développement à proprement parler, mais qui sont importantes pour la “vie” future de votre package R s’il est voué à être publiquement diffusé.
Certaines problématiques plus “avancées”, comme l’utilisation d’un fichier Codemeta.json pour saisir les métadonnées de votre package, ou encore le dépôt de votre package dans HAL (Chuffart 2023), seront abordées lors de la dernière matinée de formation.
1 Choisir une licence
1.1 Quelques licences classiques
Choisir l’une des licences classiques vous permettra de préciser à vos utilisateurs dans quelles conditions votre code peut être utilisé, partagé et modifié.
En fonction de vos préférences, le site Choose A License pourra vous proposer les licences les plus adaptées, en sachant que la plupart des packages R sont publiés sont licence GPL (tout comme R lui-même !), ou sous licence MIT.
Toutefois, aucune de ces licences n’est pleinement compatible en droit français. C’est pourquoi le CNRS et l’Inria ont créé la licence CeCILL, qui est basiquement une légère modification de la licence GPL pour la rendre totalement compatible en droit français. Pour tous les agents travaillant dans des établissements publics de recherche scientifique, la licence CeCILL est conseillée pour protéger au mieux vos travaux, tout en leur offrant un bon degré d’ouverture.
1.2 En pratique
Concrètement, inclure un fichier LICENCE.txt1 à la racine de votre package (et indiquer la licence choisie dans le champ License du fichier DESCRIPTION de votre package R) est suffisant.
Comme nous l’avons vu précédemment, la fonction R usethis::use_gpl3_license() permet de réaliser automatiquement ces deux opérations pour la licence GPL3. En revanche, il n’existe pas (à ce jour) d’équivalent pour la licence CeCILL : ces deux opérations devront donc être réalisée manuellement.
2 Numéros de version
Au fur et à mesure de l’évolution de votre package, de nombreuses versions stables seront progressivement diffusées. Choisir une convention claire pour numéroter les versions peut être important pour vos utilisateurs.
Il existe de nombreuses conventions standard, par exemple :
- la numérotation
<version majeure>.<version mineure>.<patch>, donnant par exemple1.8.2, qui est la convention utilisée par R lui-même ; - la numérotation calendaire, dite “Calver”, et basée sur la date du jour de sortie : par exemple, la version
20240618pour une sortie le 18 juin 2024.
3 Archivage et disponibilité à long terme
Dans cette formation, vous avez développé un package R avec Git, et l’avez simultanément hébergé sur une forge logicielle. Il est probable que, dans la pratique, vous ferez également ce choix, et utiliserez Git pour versionner votre travail, et GitHub ou GitLab pour collaborer et le diffuser.
Toutefois, une forge logicielle n’est pas une archive logicielle : elle permet et facilite le travail collectif sur un package, mais elle n’a pas vocation à en garantir l’accès à long terme. Les forges logicielles les plus célèbres sont détenues par des entreprises privées, qui peuvent à tout moment en changer les conditions d’utilisation, voire les fermer (cela s’est déjà produit !). Si vous avez diffusé votre package (par exemple dans un article académique) en utilisant un lien vers une forge logicielle, celui-ci risque donc à terme de devenir un lien mort, compliquant la chaîne d’accès et de citation de votre package.
L’archive Software Heritage, projet soutenu par l’Inria et l’Unesco, vise à apporter une solution à ce problème, en archivant de manière pérenne et garantie l’ensemble du code source des logiciels (un peu comme Zenodo le fait pour les données). Les forges usuelles basées sur Git (GitHub, GitLab.com, et les forges institutionnelles qui en ont fait la demande) sont périodiquement moissonnées par Software Heritage, qui en archive directement le contenu. C’est également le cas pour les packages R officiels du CRAN.
Lorsque vous publiez votre package, mieux vaut donc partager un lien vers le dépôt archivé sur Software Heritage plutôt qu’un lien vers GitHub ou GitLab.com.
La documentation de Softare Heritage vous apprendra par exemple à :
Références
Notes de bas de page
Ce fichier peut aussi s’appeler indifféremment
LICENSE.txt,LICENSE(sans extension),LICENSE.md, etc. L’essentiel est de fournir à la racine du package un fichier au format texte brut indiquant clairement les conditions d’utilisation du package.↩︎