FAQ

HAL est une archive ouverte, c’est-à-dire une plate-forme qui permet à la fois l’archivage pérenne et la diffusion en libre accès de la production scientifique. Elle a été créée en 2001 par le CNRS et continue à être maintenue par le Centre pour la Communication Scientifique directe (CCSD).

Plate-forme nationale et pluridisciplinaire, HAL permet également la création d’instances institutionnelles ou thématiques. HAL est au cœur de la stratégie Science ouverte à l’échelle nationale (Plan national pour la Science ouverte, CNRS, ANR, etc.) comme à l’UL.

Le portail HAL Univ. Lorraine a officiellement ouvert en mai 2016. Il est devenu la bibliographie officielle de l’Université en 2018.

Au lancement du projet en 2014, 4 solutions ont été testées : Dspace, HAL, Islandora et Okina (basée sur Drupal). HAL, sorti vainqueur de cette phase de tests en répondant à plus de 80% des fonctionnalités attendues listées par nos laboratoires pilotes, a logiquement été choisi par le comité de pilotage. Identifiée comme archive nationale par le Ministère, HAL est utilisé par plus de 150 établissements de l’ESR et facilite ainsi la gestion des publications dans les UMR. Depuis cette date, de nombreuses fonctionnalités ont été ajoutées (en savoir plus).

L’article 30 de la loi Pour une république numérique vous autorise à déposer la version auteur acceptée pour publication de vos articles de revue dans HAL, quel que soit le contrat signé avec l’éditeur. Si l’éditeur le requiert, vous pouvez paramétrer un embargo lors du dépôt dans HAL. Ce dernier est de maximum 6 mois ou 12 mois, selon la discipline. Voir le guide d’application de l’article 30.

La version acceptée pour publication est la version finale de l’article, qui intègre les corrections des reviewers. Elle peut également être appelé final draft post-refereeing ou accepted article ou accepted author manuscript. Son contenu est identique à la version PDF éditeur mais sans la mise en page.

La stratégie de non-cession des droits a été élaborée par des financeurs internationaux membres de la Coalition S, dont l’ANR. Elle consiste à ne plus céder l’exclusivité de ses droits d’auteur à un éditeur pour permettre, grâce au dépôt dans HAL, le libre accès immédiat aux articles, sans frais supplémentaire, et quel que soit le modèle de diffusion de la revue dans laquelle ils sont publiés. Voir la fiche pratique.

En cas de doute, contacter : 

L’article 30 de la Loi pour une République numérique (LRN) vous autorise à déposer la dernière version auteur de vos articles (sans mise en page de l’éditeur), quel que soit le contrat signé avec l’éditeur, au plus tard 6 mois ou 12 mois après la publication.

Pour les types de documents autres que les articles, c’est le contrat signé avec l’éditeur qui s’applique. Cela est toutefois négociable.

Voir la fiche pratique https://zenodo.org/record/6506651/files/copo_fiche-ao-droits_2022.pdf

Infographie « A partir d’un dépôt HAL »

À partir d’un dépôt unique dans HAL :

• j’archive ma production de manière pérenne ;
• je suis très bien référencé par les moteurs de recherche ;
• je peux être lu par le plus grand nombre, notamment par les citoyens qui ont contribué à financer ma recherche ;
• j’alimente mon CV en ligne et mon compte ORCID ;
• j’alimente mon site web perso et/ou celui de mon unité de recherche de manière dynamique ;
• j’exporte la liste de mes publications ou de celles de mon unité en quelques clics grâce à ExtrHAL.

Le Réseau d’Appui à la Recherche est une équipe de bibliothécaires répartis sur tous les campus de l’université. Ses membres sont à votre service pour vous former, vous accompagner, effectuer le contrôle qualité des dépôts UL et répondre à toute question concernant HAL. N’hésitez pas à les contacter :

Ils peuvent intervenir dans vos équipes/unités selon les modalités qui vous semblent les plus adaptées : présentation, atelier, focus sur un point spécifique, permanence dans les unités, rendez-vous individuel, en présentiel ou à distance.

En outre, des ateliers d’1h en ligne sont proposés régulièrement (nombre de places limité à 5 personnes pour faciliter les échanges) :

• HAL essentiel : les bases pour savoir déposer un document dans HAL
• Mon identité dans HAL : pour faire le point sur votre compte HAL, vos multiples formes auteurs, créer votre idHAL / CV HAL et faire le lien avec votre profil ORCID.
• Projet ANR et HAL pour connaître les attentes de l’agence quant à l’ouverture des publications issues des projets qu’elle finance.
• Référencer mon code dans HAL et l’archiver avec Software Heritage

S’inscrire

Pour toute aide concernant le choix d’un outil de gestion de vos données, n’hésitez pas à contacter l’atelier de la donnée ADOC Lorraine :  

Rédiger un plan de gestion de données pour un projet ou une structure

L’ensemble des tutelles du site universitaire lorrain conseille l’utilisation de DMP OPIDoR.

Produire des données

L’ensemble des tutelles conseille LimeSurvey (LimeSurvey UL, LimeSurvey Inria, LimeSurvey AgroParisTech, LimeSurvey INRAE) pour la mise en œuvre de questionnaires et le centre EXPLOR pour le calcul intensif.

Toutes les tutelles proposent en outre des plateformes scientifiques dont vous pouvez retrouver les présentations ici :

• Université de Lorraine
• Inria
• AgroParisTech
• INRAE

Gérer ses données

L’ensemble des tutelles conseille FileSender pour l’envoi de données volumineuses et la forge logicielle Gitlab pour la gestion des codes sources (Gitlab UL, Gitlab Inria, Gitlab INRAE).

D’autres services spécifiques sont proposés :

• Université de Lorraine : cahier de laboratoire électronique avec eLabFTW / gestion des échantillons avec GRR / gestion des accès pour des membres extérieurs à l’Université de Lorraine avec Invités Numériques
• INRAE : hébergement de bases de données postgresql ou mysql (https://cat.opidor.fr/index.php/BD_PostgreSQL) opéré par la DSI INRAE / hébergement de bases de données Postgresql opéré par l’unité SILVA. De nombreux autres services sont disponibles sur demande (ils nécessitent un compte INRAE), leur description étant fournie sur le portail Ariane INRAE ; notamment dans la catégorie ‘Infrastructures Informatiques Collectives’. INRAE soutient également un outil développé en interne pour la gestion d’échantillons lui aussi décrit et mobilisable depuis le portail Ariane.

Stocker ses données

• Université de Lorraine : B’UL pour le travail collaboratif et les données de moins de 20 Go (OTELo cloud pour le pôle OTELo) / PETA pour les données de forte volumétrie.
• Inria : MyBox pour le travail collaboratif et les données de moins de 10 Go (volume pouvant être étendu sur demande).
• AgroParisTech : SeaFile pour le travail collaboratif et les données de moins de 100 Go.
• CNRS : sDrive pour le travail collaboratif et les données de moins de 100 Go / ShareDocs (IR* Huma-Num ; pour le stockage et partage, travail quotidien des données ; volume jusqu’à environ 1 téraoctet de données) / Huma-Num Box (IR* Huma-Num ; pour volume important de données froides ou tièdes).
• INRAE : des solutions de stockage de fichiers performant, de stockage capacitif, Sharepoint, Nextcloud et des Nas locaux sont proposés par la DSI INRAE.  Pour solliciter ces services ou accéder à un descriptif, il suffit d’accéder au portail Ariane, catégories ‘Espaces de données’ ou ‘Services collaboratifs’.

Publier ses données

L’ensemble des tutelles recommande le dépôt des données finalisées dans un entrepôt disciplinaire de confiance (demander conseil à l’atelier de la donnée ADOC Lorraine pour trouver l’entrepôt adapté) ; à défaut, il est recommandé de déposer dans Recherche Data Gouv (espaces institutionnels Université de Lorraine, Inria, INRAE, CNRS).

Valoriser ses données

INRAE : divers services (applicatifs web, R Server …) s’appuyant sur le service de fournitures de machines virtuelles de la DSI INRAE. Par exemple l’application de modèle de bilan hydrique forestier BILJOU.

Université de Lorraine : plateforme numérique CENHTOR à destination des projets de recherche en SHS. Périmètre : projets  interdisciplinaires, données de recherche, exploitation (plateforme  outillée) et valorisation des corpus et bases de données, services  d’accompagnement au dépôt et à l’éditorialisation des données, curation  des données / bases thématiques pour les autres disciplines avec le logiciel libre OMEKA S / hébergement de serveurs virtuels.

CNRS : l’entrepôt de données NAKALA embarque un système de publication NAKALA-PRESS permettant d’éditorialiser un site web personnalisable à partir d’une collection de données déposées dans l’entrepôt.

Les données de la recherche représentent l’ensemble des données (brutes ou élaborées) qui constituent le matériel primaire des activités ou d’un projet de recherche scientifique. Le caractère multiforme (sons, vidéos, lignes de code, relevés thermiques…) du matériel justifie la complexité à en donner une définition unique.

Néanmoins, on s’accorde généralement sur la définition la plus communément admise, celle de l’OCDE, qui décrit les données de recherche comme « des enregistrements factuels (chiffres, textes, images et sons), qui sont utilisés comme sources principales pour la recherche scientifique et sont généralement reconnus par la communauté scientifique comme nécessaires pour valider des résultats de recherche ».

Consultez notre vidéo et notre fiche dédiées à la définition des données.

Les données sont les fondations de la recherche scientifique et la base à l’élaboration de nouvelles hypothèses.
Ainsi, une bonne gestion permet :

• de réduire le risque de perte et sécuriser les données avec des recommandations, des choix d’outils et d’hébergement adaptés,
• de garantir la provenance et la traçabilité de la donnée manipulée en documentant ces étapes,
• d’optimiser l’organisation de la masse des données produites par des bonnes pratiques.

L’objectif final est d’apporter au chercheur une approche raisonnée de ses données pour en tirer un maximum de bénéfices durant le projet mais également dans les années à venir.
Publier plus largement ses données permet :

• une ré-utilisation des jeux à caractère unique de part les coûts liés à leur production,
• une reproductibilité des recherches présentées dans les publications associées,
• une ré-exploitation par les étudiants comme matériel didactique,
• une émergence de nouvelles pistes de recherche pour booster l’innovation,
• et un enrichissement du patrimoine scientifique mondial.

Ouvrir ses données apporte de nombreux avantages :

• Obtenir plus de citations sur les publications liées aux données (source The citation advantage of linking publications to research data)
• Associer votre nom aux données que vous avez produites
• Répondre aux exigences de nombreuses revues et des financeurs
• Élargir votre réseau professionnel
• Bien conserver vos données et les sécuriser
• Gagner du temps et de l’argent en réutilisant les données d’autres chercheurs ; faire gagner du temps à d’autres chercheurs
• Contribuer à la reproductibilité des résultats de recherche
• Œuvrer pour la transparence de la démarche scientifique
• Anticiper les évolutions de l’évaluation, qui portera aussi sur les données de la recherche (voir l’appel de Paris sur l’évaluation de la recherche 2022)

En savoir plus : consultez notre fiche pratique Pourquoi ouvrir ses données ?

De nombreuses revues demandent l’accès aux données de recherche pendant le processus de peer-reviewing. DOREL permet de donner accès à des données déposées mais non encore publiées, via la fonction d’URL privée (voir la page dédiée dans le guide complet du déposant). De cette manière, les reviewers peuvent voir les données sans qu’elles ne soient accessibles à tout le monde, et les fichiers peuvent être modifiés autant que nécessaire avant publication (et donc attribution définitive de DOI). Besoin d’aide ? Écrivez à

DOREL permet de faire un lien depuis les données vers les publications associées. HAL permet également de faire le lien depuis les publications vers les données. Pour aller plus loin, consultez notre fiche pratique sur le chemin de la publication article / données de la recherche.

Les données de la recherche sont souvent accompagnées de scripts (écrits en Stata, R, MATLAB, Python…). Afin d’assurer la bonne lisibilité des données, il est recommandé de déposer ses scripts avec ses données dans un entrepôt. Les conseils du guide de Dataverse (ici, en anglais) peuvent être suivies pour DOREL.

A noter que les logiciels à part entière peuvent être déposés dans HAL et dans Software Heritage pour garantir leur pérennité. Voir ici le mode d’emploi.

Les données de la recherche générées dans le domaine de la santé sont régies par des réglementations spécifiques qui peuvent sembler foisonnantes. Pour vous y retrouvez, consultez notre fiche pratique sur les données de santé.

Un logiciel (ou programme d’ordinateur) est la description, dans un ou plusieurs langages informatiques, d’un processus de traitement d’instructions spécifiques que l’on souhaite faire réaliser par un ordinateur. Les programmes sont sous forme de code binaire (ou exécutable) et de code source (instructions lisibles par l’humain). Cette définition intègre tout algorithme exprimé dans un langage informatique exécutable. Le logiciel peut également comprendre une documentation et des exemples d’utilisation.

En savoir plus : livret « Codes sources et logiciels » du Comité national pour la Science Ouverte » (CoSO)

Dans le cadre de sa politique Science ouverte, l’Université de Lorraine incite à rendre accessible tous les codes, scripts et logiciels conçus dans le cadre d’un travail de recherche, dès lors que cette démarche est compatible avec le projet (en particulier du fait d’éventuelles clauses liées aux financeurs ou si une voie de valorisation économique par des logiciels propriétaires a déjà été choisie).

• Pour favoriser la transparence

L’objectif premier est de favoriser la transparence des méthodes menant aux résultats publiés, ainsi que leur reproductibilité par l’accessibilité du code source et des données associées sur une forge logicielle et un entrepôt de données.

Dès lors que ce sont des produits issus d’un travail de recherche, il importe de privilégier leur accessibilité en accès ouvert afin de contribuer à la qualité, à l’intégrité et à la diffusion de la recherche. Comme pour l’open source, le but de l’open science est de diffuser de manière transparente un outil informatique utile dans un domaine spécifique ou pour une communauté particulière.

• Pour valoriser votre travail et en revendiquer la paternité

La mise à disposition du code permet à la fois de le valoriser et d’en revendiquer la paternité. Les auteurs de la solution peuvent alors bénéficier d’apports sous forme de contributions, de citations ou bien de partenariats. La valorisation et la reconnaissance du temps de développement de ces outils à base de code, dans la carrière d’un chercheur/chercheuse, constitue par ailleurs un enjeu croissant.

Pour les codes sources et logiciels, il est important de considérer, pour les auteurs, leur portée et leur réutilisation potentielle et d’envisager un mode diffusion adapté.

La publication des codes sources et logiciels doit donc s’accompagner d’une étape préalable de réflexion quant à la valorisation possible du projet, suivant le public auquel ils sont destinés. Il conviendra notamment de s’interroger sur un mode de valorisation économique ou non, sur le choix d’une licence logicielle, sur les informations à mettre en ligne (documentation ou site dédié). Les services d’appui à la recherche de l’UL peuvent vous accompagner : .

Suivant le financement et le(s) partenariat(s) établi(s) dans la production de ce type d’objet informatique, l’ouverture du code source doit être réalisée avec une licence adaptée ou conduire à opter pour une stratégie spécifique permettant de conserver les droits d’utilisation et de modification du code initial. Lorsque les travaux associent des partenaires industriels ou économiques, la stratégie et le choix de licence(s) adéquate(s) pour votre code informatique s’avèrent d’autant plus importants si vous souhaitez en maîtriser le devenir.

• Pour les chercheurs et chercheuses

En mettant à disposition le code qui a servi, vous permettez aux autres chercheurs de vérifier, reproduire ou répliquer, réutiliser votre démarche de recherche.

• Pour les développeurs et développeuses

L’autre point important est également de permettre à tout personne qualifiée de reprendre et d’améliorer un outil passé ou présent pour de futures applications dans un contexte scientifique qui évolue rapidement (normes, exigences, formats, procédés, etc.). Le cycle de développement d’un logiciel ou autre objet informatique n’est pas figé dans le temps. Il peut être repris, évoluer et même survivre à son ou ses auteurs (notamment grâce aux fonctionnalités des forges qui permettent des copies du dépôt de code d’origine).

• Pour les générations futures

Le fait de mettre à disposition son code ou logiciel, permet aux générations futures de chercheurs de bénéficier d’efforts antérieurs de développement, de bénéficier d’une expertise et d’une transmission de savoir et de procédés dans un domaine applicatif spécifique.

C’est pourquoi la documentation liée à l’utilisation et la reproduction des résultats utilisant un code informatique est capitale. En plus de la documentation, l’environnement d’exécution et les dépendances liés au code sont également très importantes. Il faut a minima citer les sources et les ressources nécessaires à l’utilisation d’un code informatique et idéalement proposer un environnement d’exécution virtualisé contenant les éléments nécessaires requis (on parle de conteneurisation, ou de virtualisation suivant le cas).

Il est recommandé que le code source (une fois mature) soit accessible sur une forge logicielle, comme celle que propose l’UL. La forge de l’UL est automatiquement moissonnée par l’archive universelle des codes sources Software Heritage pour les dépôts de code en « mode public ». On peut indépendamment de l’archivage, référencer son code source, sur la plateforme HAL pour améliorer sa visibilité et faciliter sa citation.

HAL-UL est depuis 2018 la bibliographie officielle de l’Université de Lorraine. Les codes font partie des produits de la recherche qui peuvent y être référencés. Le dépôt des codes sources dans HAL favorise leur diffusion et leur citabilité grâce à des métadonnées (domaine, champs de recherche, mot-clefs, identifiants). Il facilite les liens entre données, codes et publications. Le bon référencement dans HAL permet en outre d’augmenter leur visibilité et leur partage sur le Web. HAL gère également le versionning de publication pour mettre à jour un code source qui a été repris ou actualisé lors d’une version de développement en cours.

Dans le cadre de sa politique SO, l’UL encourage le dépôt des codes sources dans HAL et leur archivage dans Software Heritage. Pour en savoir plus :

• Déposer le code source d’un logiciel
• Fiche synthétique HAL > déposer un logiciel dans HAL

Si vous avez un compte ORCID renseigné dans votre profil HAL, les codes référencés dans HAL pourront, comme vos autres publications, y être transférés.

Pour en savoir plus : Fiche synthétique HAL > lier son ORCID à HAL

Software Heritage assure l’archivage des codes sources accessibles publiquement. HAL facilite la citation des codes sources ainsi que leur affichage sur des sites webs (personnels, unités de recherche) et favorise le lien entre publications, données et codes.

Software Heritage est une infrastructure à but non lucratif créée en 2016 par INRIA. Elle est supportée par un panel d’institutions et de partenaires industriels à travers le monde en collaboration avec l’UNESCO. La partie visible sur internet, softwareheritage.org, est une plateforme avec une interface spécifique comprenant un site, de la documentation et une API dédiée ainsi qu’un système d’attribution d’identifiants uniques (SWHID) pour le code déposé.

« Collecter, préserver, partager » : l’ambition de Software Heritage est de permettre la constitution d’une archive universelle pour l’ensemble du code produit dans le monde en récupérant ce qui est possible et en le stockant de manière pérenne. La plateforme n’archive pas les données binaires mais les codes sources lisibles déposés dans des forges logicielles comme par exemple Gitlab ou Github ou manuellement déclenché par un utilisateur en lien avec des dépôts spécifiques (Debian, NPM, Pypi, etc). Software Heritage explore par défaut des plateformes de codes référencées, mais on peut également soumettre à l’archive des points de moissonnage spécifiques sur demande.

À partir d’un archivage réalisé, un identifiant unique est généré : le SWHID. Il permet d’effectuer une référence de manière précise et transparente au code pour sa diffusion à travers le web. Par ailleurs, le SWHID facilite le référencement de vos codes sources dans HAL (ou peut aussi être généré par un dépôt HAL de votre code sous forme d’archive zippée).

On parle d’ouverture de code source lorsqu’un code développé dans le cadre d’un travail de recherche est publié sur une forge logicielle ou un site internet et qu’il est en accès libre. Avant la mise en ligne d’un code sur le Web, plusieurs facteurs et conditions doivent être réunis :

• le code doit être suffisamment stable et fonctionnel ;
• la documentation associée doit permettre de comprendre l’utilité du code et fournir des exemples pour permettre sa réutilisation ainsi que des indications sur les contributions autorisées ;
• une réflexion doit avoir été menée sur la valorisation économique potentielle / souhaitée pour le choix d’une licence adaptée.

Il faut également considérer d’autres facteurs comme par exemple l’évolution possible du code développé : intégration dans d’autres programmes ou librairies ou bien encore sa reprise dans un projet plus vaste, etc. La capacité du code à être utilisée par d’autres disciplines ne doit pas être écartée. La documentation doit permettre de montrer l’intérêt qui peut en être fait pour faciliter les non-spécialistes à l’intégrer à leurs propres travaux dans leur discipline.

Si le code n’est pas destiné à évoluer par la suite (fin de projet de recherche sur cette thématique), son ouverture peut permettre aux personnes souhaitant l’adapter ou l’améliorer pour leurs propres besoins d’y contribuer. Pour cela, il est nécessaire de préciser les contributions qui peuvent être faites dans ce cadre, en ajoutant un fichier spécifique : par exemple, un fichier CONTRIBUTORS ou CONTRIBUTING dans le dépôt de code en spécifiant les règles à respecter pour les futurs contributeurs.

Par ailleurs la licence joue un rôle essentiel dans l’évolution possible du code d’origine et son partage par des contributions à la communauté. Par exemple, pour un code ouvert, certaines licences imposent que les modifications apportés par les contributeurs au projet soient rediffusées dans les mêmes conditions de licence, de manière à ce que tout le monde puissent bénéficier des améliorations apportées sur de nouvelles versions.

Il peut être très intéressant de l’associer à une publication scientifique relative au domaine ou aux données directement utilisées ou produites par le code ou logiciel. Les données scientifiques permettent également de maximiser la visibilité des travaux réalisés et associés avec le code source produit. Pour cela, on peut citer les identifiants pérennes relatifs à la publication, aux données et au code associé chaque fois que c’est possible, ainsi que les auteurs associés éventuels et contributeurs successifs. Les sites officiels qui recensent les publications scientifiques pourront plus facilement faire le lien entre ces trois types de production et les mettre en valeur lorsqu’une personne effectue des recherches sur une thématique en particulier.

Lors du dépôt de la publication sur l’archive ouverte HAL, vous déposez une notice liée à un code source en complément d’un article scientifique qui y ferait référence, ou spontanément pour faire état de l’existence d’un outil informatique développé dans le cadre de la recherche. Cela peut être un script de calcul, un module logiciel ou une librairie ou bien un programme complet.

À cette heure, la plateforme HAL ne permet que le référencement des codes accessibles librement. Si votre code ne l’est pas, il ne sera pas possible de le faire apparaître dans HAL. Néanmoins, vous pouvez créer manuellement une référence sur votre compte ORCID dans la section “Travaux”, type “Logiciel”.

Un nombre croissant de développeurs emploie désormais des outils d’IA générative en guise d’assistance à la production de code informatique. Aussi, il convient en premier lieu de garder à l’esprit les recommandations nationales comme internationales relatives à l’utilisation de l’IA générative en recherche, qui identifient principalement trois enjeux déclinables au cas particulier des codes, logiciels et à leur ouverture :

• Fiabilité : le code généré est-il réellement fonctionnel ? Dépend-t-il d’un environnement spécifique pour fonctionner ? Suis-je en mesure d’en expliquer et d’en justifier le fonctionnement ? Le code est-il optimisé ?
• Données personnelles : le travail réalisé à l’aide de l’IA générative me conduit-il à partager des données confidentielles et/ou non-anonymisées avec un service tiers susceptibles de réemployer voire de commercialiser ces données ? La mobilisation de l’IA générative pour développer en mobilisant des données est-elle conforme au Règlement Général de Protection des Données (RGPD) et, plus spécifiquement, au Plan de Gestion des Données (PGD) du projet ?
• Transparence : ai-je bien pris soin de préciser que j’avais utilisé une IA générative pour m’assister dans la production d’un code, et laquelle ? Ai-je documenté le code ? À qui appartient-il ? (si ce n’est pas du code générique ? Mais du code en Recherche (les sources doivent être citables à minima)

En outre, la question de l’impact environnemental constituant un motif de préoccupation croissante et compte-tenu des ressources nécessaires au fonctionnement des IA génératives, le recours à des modèles frugaux est à privilégier.

Un deuxième aspect réside dans la production de modèles et outils ouverts d’IA générative. Les chercheurs s’inscrivant dans une telle démarche sont ainsi appelés à publier et à ouvrir à la fois :

• le code,
• les poids et pondérations utilisés (paramètres et version du modèle utilisée, ainsi que le prompt en toute transparence),
• les données fournies à l’IA.

Un troisième aspect important est la vérification des différentes licences des briques logiciels qui seront utilisées et éventuellement intégrées par l’aide de l’IA générative. Ces différentes licences influenceront la licence finale du logiciel (notions de Copyleft et de distribution).

En droit français, un code source non accompagné d’une licence est protégé par le droit d’auteur, ce qui interdit toute utilisation, modification ou distribution sans l’autorisation expresse de l’auteur.

Tout code source considéré comme suffisamment original (c’est-à-dire considérée comme une œuvre de l’esprit par opposition au code générique) est protégé par le droit d’auteur. Par conséquent, sans indication spécifique de l’auteur, personne n’est autorisé à en faire quoi que ce soit (sauf la citation et l’usage privé). Il est donc préférable de choisir et de spécifier explicitement l’utilisation d’une licence dans son code source. Il faut également penser dès le départ à l’utilisation possible qui peut être faite du logiciel et à son évolution. Si vous n’avez pas d’idée particulière sur la question, il peut être intéressant de partir du principe qu’en cas de franc succès de votre solution, vous disposerez d’une licence adaptée pour prémunir le code contre toutes dérives ou menaces quant à son utilisation.

Il est également très important, en cours de développement logiciel, de vérifier les utilisations de codes sources extérieurs ayant contribué au projet et la compatibilité des autres licences avec celui-ci.

Dans certains cas (licence à copyleft fort sur un code réutilisé), vous n’aurez pas d’autre choix que de publier sous licence équivalente ou identique. Il peut être pertinent de prévoir un temps de développement interne supplémentaire au cours de son projet afin d’éviter l’incorporation de code extérieur possédant une licence incompatible ou trop « contaminante ».

Diffuser son logiciel ou son code source de manière libre, c’est-à-dire sous licence open source, permet de collaborer avec des chercheurs et chercheuses de tout horizon et de créer des projets d’importance dans l’ESR.

Le partage de son code source sous une licence libre et adaptée permet :

• une transparence sur les procédés permettant l’obtention des résultats,
• de garantir la reproduction des résultats présentés,
• une réutilisation à partir d’un socle de référence fiable,
• d’effectuer des comparaisons à partir de différentes approches scientifiques.

Du point de vue d’un chercheur ou d’une chercheuse, le fait d’utiliser un logiciel libre permet :

• de signaler tout dysfonctionnement (bugs) aux créateurs/mainteneurs,
• d’étudier et de modifier le code source pour proposer des correctifs, des évolutions,
• d’adapter le logiciel ou code source à son besoin,
• de faire partie d’une communauté d’échange autour d’une thématique ou problématique scientifique spécifique.

Ces types d’interactions sont donc très utiles si vous développez un logiciel, une bibliothèque et que vous souhaitez partager et recevoir des contributions d’autres personnes.

Enfin, il est important de rappeler que dans le cadre de son travail, l’Université de Lorraine possède ce que l’on appelle les droits patrimoniaux (publier, diffuser, distribuer), tandis que les créateurs du code ou du logiciel conservent les droits d’auteur(s). Donc si vous souhaitez diffuser votre logiciel sous licence open source ou le mettre à disposition dans le domaine public, assurez-vous d’avoir l’accord de votre structure pour éviter tout désaccord ultérieur quant à la mise à disposition de celui-ci.

En l’absence de licence, les modifications, distributions et exécutions du code ne sont juridiquement pas autorisées. Par ailleurs, si aucune licence n’est explicitement indiquée, une personne consultant le code (sur une forge, Software Heritage, HAL, une page web, etc.) pourrait ne pas savoir si cette omission est volontaire ou involontaire. De plus, les conditions d’utilisation du service hébergeant le code (comme une forge) peuvent prévoir une licence d’exploitation qui s’applique par défaut au code déposé, ce qui ajoute une source de confusion supplémentaire.

Le choix d’une licence open source (par opposition à la mise à disposition dans le domaine public qui est un renoncement à la paternité et aux droits d’auteur) permet à tout le monde de pouvoir ré-utiliser le code sous certaines conditions, tout en conservant les droits d’auteur(s).

Le choix d’une licence pour un code ou un logiciel dépend de la réflexion initiale de ses auteurs sur le modèle de diffusion économique et académique qu’ils souhaitent adopter avant son ouverture. Ce choix doit également tenir compte des utilisateurs cibles du logiciel.

Cela suppose une analyse préalable des modes de valorisation possibles pour le logiciel, en fonction de son domaine d’application, des futurs utilisateurs visés, ainsi que des solutions concurrentes déjà existantes. Cette démarche permet d’aligner la licence sur les objectifs stratégiques du projet, qu’ils soient commerciaux, collaboratifs ou académiques.

Trois grands types de licences, d’approches peuvent être envisagées :

• Licence libre ou open source : favorise la collaboration, la transparence et la réutilisation du code ;
• Licence propriétaire : restreint l’accès et l’utilisation du code, souvent pour des raisons commerciales ou de protection intellectuelle ;
• Modèle hybride : combine les deux approches, par exemple en ouvrant le cœur applicatif tout en gardant certains modules sous licence propriétaire.

Pour choisir une licence, il est essentiel de définir explicitement les droits accordés aux utilisateurs, souvent désignés par les degrés de liberté (DDL). Ces droits concernent principalement :

• L’utilisation : droits liés à la compilation et à l’exécution du code source (par exemple, pour un usage personnel, professionnel ou intégré dans un autre logiciel) ;
• L’étude : accès au fonctionnement interne du logiciel, notamment pour des analyses, des audits ou des besoins pédagogiques ;
• La distribution : conditions de redistribution (gratuite ou payante) et de commercialisation, y compris les modalités de partage du code source ou binaire ;
• La modification : autorisation ou restrictions concernant les améliorations (corrections, optimisations) ou les modifications majeures (refonte, adaptation à de nouveaux usages).

Le copyleft est un mécanisme juridique intégré à certaines licences (comme la GPL ou l’AGPL) qui vise à garantir la liberté d’un logiciel ou d’un code source, y compris dans ses versions modifiées ou dérivées. Contrairement au copyright, qui restreint les droits d’utilisation, le copyleft impose que toute œuvre dérivée conserve les mêmes libertés que l’original.

Pour qu’un logiciel ou un code source reste libre sous copyleft, sa licence doit explicitement autoriser les utilisateurs à étudier, modifier et redistribuer le code (degrés de liberté, ou DDL). Et exiger que toute version modifiée ou dérivée soit également distribuée sous les mêmes conditions de liberté (c’est l’effet « viral » ou « contaminant » du copyleft).

Le copyleft protège les logiciels libres contre l’appropriation privée (par exemple, l’intégration dans un logiciel propriétaire sans partage des modifications). Il assure ainsi que les améliorations profitent à toute la communauté, en maintenant un écosystème ouvert et collaboratif.

Il existe un grand nombre de licences OS, avec un copyleft plus ou moins fort. On distingue trois grandes catégories :

• Les licences avec copyleft « fort » (e.g. GNU GPL) : obligation de republier sous licence identique ou compatible. On parle alors de licence « contaminante », c’est-à-dire que la licence s’impose sur tous les aspects. La licence en question sera imposée à tout nouveau logiciel qui l’intègre en dérivation (adaptation, modification d’un code) ou qui l’associe en composition (combinaison-module-externe) ;
• Les licences avec copyleft plus « faible » (e.g. Lesser GPL) : la licence d’origine est appliquée mais des ajouts sont possibles avec d’autres types de licences, le but étant d’étendre ou de préciser certains aspects dus à l’évolution et/ou à l’incorporation de nouveau(x) code(s). La licence en question sera imposée à tout nouveau logiciel qui l’intègre en dérivation mais elle sera permissive en composition ;
• Sans copyleft (BSD, MIT). On parle de licence « permissives » ou « très permissives » car il y a très peu d’obligations pour les utilisateurs. Des ajouts et modifications sont possibles et il faut donc accepter que dans ce cas de figure, une utilisation propriétaire peut en être faite et sans contreparties spécifiques pour la communauté open source, qui ne bénéficiera peut être pas des modifications apportées. Cette licence de logiciel est permissive en dérivation et en composition.

Schéma des effets en combinaison et en dérivation en fonction du niveau de copyleft du logiciel libre.

Il existe une liste officielle qui répertorie l’ensemble des licences recommandées dans le secteur public français.

Vous pouvez retrouver l’ensemble des licences existantes et leurs identifiants à cette adresse : https://spdx.org/licenses/

Remarque : certaines licences sont plus adaptées à l’interprétation du droit français (exemple : CeCILL-C, http://www.cecill.info/licences/Licence_CeCILL-C_V1-fr.html)

Dès lors que vous publiez votre code source ou logiciel et qu’il est accessible en ligne par tous, vous devez avoir au préalable inclus un fichier spécifique de licence dans votre dépôt ou votre archive logiciel.

Ce fichier est généralement placé à la racine du projet et peut prendre des noms variés (généralement en anglais) :

• LICENSE (avec ou sans extention .txt, .md)
• COPYING (avec ou sans extention .txt, .md)
• « ID_DE_LA_LICENSE » par exemple : GPL-3.0-or-later.txt

Il n’y a pas de règles, simplement des conventions de nommage adoptées par une large communauté d’utilisateurs (développeurs) en ligne.

La présence de la licence est essentielle pour le dépôt et le référencement d’un code sur des plateformes comme HAL ou Software Heritage. Il est également important d’indiquer cette information quand vous utilisez une forge logicielle. Cela permet aux utilisateurs de savoir ce qu’ils peuvent faire avec celui-ci.

Une pratique courante est d’inclure en en-tête (headers) dans chaque fichier de son code source, une citation précisant les droits d’auteurs, la date, la licence employée (le cas échéant avec un lien vers le texte de la licence) et éventuellement une adresse de contact. Cela permettra en cas de doute ou de litige avéré de pouvoir s’appuyer sur une référence valable pour statuer sur une problématique en matière de droits.

Pour plus de clarté concernant les licences, il est également intéressant de préciser l’identifiant d’une licence dans son projet logiciel. Généralement, on précise cette information dans le fichier ‘codemeta.json’ présent dans le dépôt (ou dans le fichier de citation CFF). Vous pouvez retrouver les identifiants de licence à cette adresse de référence : https://spdx.org/licenses/.

Tout code source ou logiciel est considéré comme une œuvre de l’esprit et c’est donc le droit d’auteur qui protège le contenu du logiciel. Dans des cas spécifiques, un logiciel peut être brevetable sous certaines conditions en France, dès lors qu’il remplit les critères exigés par une caractérisation dite industrielle.

Le logiciel reste un objet à la croisée entre œuvre de l’esprit et invention technique. C’est plutôt le droit d’auteur qui protège le contenu du logiciel.

Dans des cas spécifiques, le logiciel peut être brevetable à condition qu’il fasse partie d’une invention technologique nouvelle impliquant une utilisation industrielle. Dans ce cas, il fait alors partie d’une invention plus globale qui, elle, peut être brevetée. Mais ce n’est pas le logiciel en lui-même qui est breveté.

Au-delà de la traduction en instructions informatiques (partie logiciel), l’invention inclut les idées, procédures, des concepts spécifiques et des méthodes de fonctionnement propres dans un domaine scientifique appliqué à l’industrie.

Le droit d’auteur protège le logiciel et le brevet protège l’invention. Le traitement de la brevetabilité des logiciels en Europe reste pour l’instant différent d’autres pays comme les États-Unis ou le Japon.

Le droit d’auteur pour un logiciel s’obtient sans formalités particulières, sous réserve que l’œuvre soit considérée comme suffisamment originale (par opposition à générique ou déjà existante). Il peut être utile dans certains cas d’effectuer une déclaration d’invention auprès de son employeur pour déterminer la stratégie et le niveau de valorisation qui peut être ensuite envisagé.

Il faut aussi comprendre que les brevets constituent, vis à vis des logiciels, un écosystème de documents difficilement interprétables sans l’aide d’un juriste. Il est assez compliqué de trouver explicitement ce que l’on recherche en matière de logiciels dans les registres des brevets.

Le recours aux brevets logiciels n’est pas recommandé pour un projet open source. En effet, si un logiciel était couvert par un brevet, il faudrait vérifier systématiquement que sa publication et sa distribution ne violent aucun droit de propriété intellectuelle existant. Une telle contrainte compliquerait considérablement le partage du logiciel, alors que l’open source vise précisément à le diffuser le plus largement et librement possible.

Le Comité Logiciels et Codes (CoLoC) peut vous accompagner sur ce volet comme à toutes les étapes de votre projet. Pour contacter le CoLoC :