Reading Time: 11 minutes

Le choix d’une licence open-source pour le code de recherche est l’une des décisions les plus conséquentes qu’un chercheur prend – et celle que la plupart des étudiants diplômés et des chercheurs principaux rencontrent pour la première fois sans aucune formation formelle.

Votre choix de licence détermine qui peut utiliser votre code, comment il peut l’utiliser, si les revendications de brevet sont traitées et si les modifications en aval restent ouvertes. Cela affecte directement la reproductibilité, l’attribution et le respect des mandats des bailleurs de fonds. Pourtant, la communauté des chercheurs n’a pas de ressource éducative standard qui guide les chercheurs dans le processus de décision réel, compare les principales licences en langage simple ou explique l’intersection souvent confuse des licences de données et de licences de logiciel.

Ce guide aborde cet écart. Il guide les chercheurs à travers les étapes pratiques de la sélection d’une licence, compare les principales options, explique les exigences des bailleurs de fonds, clarifie la distinction data-vs-code et décrit les considérations institutionnelles avant de publier du code.

Pourquoi le choix de licence est important

L’idée fausse la plus importante dans la communauté des chercheurs est que la publication de code sans licence signifie qu’il est du domaine public ou librement utilisable. Ce n’est pas le cas. En vertu de la loi sur le droit d’auteur, le code sans fichier de licence explicite reste entièrement protégé par des droits d’auteur, ce qui signifie que personne d’autre ne peut légalement le copier, le modifier ou le distribuer, pas même dans des contextes académiques. C’est la réalité juridique fondamentale que chaque équipe de recherche doit comprendre avant de partager publiquement le code.

https://open-science-training-handbook.gitbook.io/book/02OpenScienceBasics/03OpenResearchSoftware et OpenSource Documente explicitement cette idée fausse et répertorie d’autres mythes courants sur l’open-source licence.

Au-delà de la conformité légale, votre choix de licence a des conséquences directes sur trois domaines :

reproductibilité

Une licence open-source donne aux autres chercheurs l’autorisation légale d’exécuter, de modifier et de reproduire votre travail. Sans cela, même les chercheurs qui souhaitent reproduire vos résultats sont confrontés à une incertitude juridique, un obstacle qui sape le mouvement de reproductibilité dans la science informatique.

Attribution

Différentes licences gèrent l’attribution différemment. Les licences permissives telles que MIT et BSD nécessitent une attribution dans les redistributions des sources, tandis que les licences Copyleft telles que GPL intègrent profondément les exigences d’attribution dans leurs conditions. La licence que vous choisissez détermine la façon dont votre contribution est créditée en aval.

Conformité des bailleurs

Les principaux bailleurs de fonds de la recherche ont désormais des attentes explicites en matière de licences. La politique de données logicielles de la NASA 41A (SPD-41A) nécessite explicitement une licence open-source permissive pour tous les logiciels développés par le projet et exclut généralement les licences propriétaires ou sources. Horizon Europe s’attend à des licences de permission équitables. Guide des meilleures pratiques du NIH sur les licences publiques open source. Ignorer ces exigences peut créer des violations de conformité après la publication.

Le processus de décision

Le choix d’une licence est une décision structurée et non une sélection aléatoire. Suivez ces étapes :

Étape 1 : clarifiez ce que vous voulez que les autres fassent

Demandez-vous : voulez-vous que les autres utilisent votre code librement dans des projets propriétaires, ou voulez-vous que toutes les modifications restent open-source ? Cette question entraîne le reste de la décision.

Si vous souhaitez une adoption maximale, y compris l’utilisation par l’industrie, les projets propriétaires et la distribution commerciale sans restriction, les licences permissives (MIT, BSD) sont appropriées. Si vous souhaitez que les travaux dérivés restent open-source, les licences Copyleft (GPL) sont le choix.

Step 2 — Consider patent implications

Si votre recherche implique de nouveaux algorithmes, des méthodes d’apprentissage automatique ou une intégration matérielle, le risque de brevet devient pertinent. Apache 2.0 est la seule licence permissive largement utilisée avec une délivrance de brevet explicite. Cela signifie que les contributeurs accordent aux utilisateurs en aval une licence pour toute réclamation de brevet détenue par des contributeurs pour le code dans le cadre du projet. MIT, BSD et GPL ne contiennent pas de délivrance de brevets explicites (GPLv3 comprend une clause de représailles au brevet mais aucune octroi de contribution).

Étape 3 – Aligner sur les conventions communautaires

Étudiez les licences utilisées par des projets similaires dans votre sous-champ. Une bibliothèque de méthodes numériques dans la science des matériaux informatiques doit tenir compte des licences que les cadres établis utilisent. L’alignement de la communauté réduit les frictions pour les contributeurs et les utilisateurs.

Pour un contexte plus approfondi sur les flux de travail de développement open source dans les contextes de recherche, consultez notre guide sur les Contribution à Fipy, qui explique comment le code fonctionnant dans la communauté fonctionne dans la pratique.

Étape 4 – Vérifier les exigences institutionnelles

De nombreuses universités exigent l’approbation du Tech Transfer Office avant de publier un logiciel sous licence open-source. Les contrats de travail peuvent restreindre les décisions de licence. Vérifiez toujours la politique institutionnelle avant d’appliquer une licence.

Étape 5 — Appliquez la licence choisie

Placez un fichier de licence à la racine du référentiel, nommé exactement comme le texte de la licence (par exemple, LICENSE.mit, LICENSE.apache ou LICENSE.gpl). Ajoutez éventuellement des en-têtes de droits d’auteur aux fichiers source, bien que cela ne soit pas requis par la plupart des licences.

Utilisez choosealicense.com comme outil interactif pour faire correspondre votre cas d’utilisation à une recommandation de licence.

Comparaison de licence

Les quatre licences les plus couramment utilisées dans les logiciels de recherche sont MIT, BSD, Apache 2.0 et GPL. Ils se répartissent en deux familles :

  • Permissive (MIT, BSD, Apache 2.0) : autoriser une utilisation propriétaire, exiger une attribution, courte et simple
  • Copyleft (GPL) : exige que les travaux dérivés restent open-source et une protection communautaire renforcée

Licence MIT

La plus simple de toutes les licences largement utilisées. Un seul paragraphe de texte nécessitant une attribution dans les redistributions des sources. Pas de délivrance de brevet, pas de copyleft, pas d’exigence de compatibilité pour les bibliothèques en aval.

Meilleure pour : adoption maximale. Lorsque vous voulez que votre code soit utilisé partout – dans les articles académiques, les produits propriétaires et les dérivés modifiés – sans restrictions.

Adoption de recherche : Le MIT est la licence la plus courante parmi les projets open source sous licence (65 %), selon une étude de 2026 de Jahanshahi. Il domine en raison de sa simplicité et de sa large compatibilité avec les autres types de licences.

Licence BSD

Très similaire au MIT. La licence BSD à deux clauses est fonctionnellement équivalente à MIT. La variante à trois clauses ajoute une clause de non-approbation explicite, empêchant les autres d’utiliser votre nom pour promouvoir des produits dérivés.

Meilleur pour : lorsque vous souhaitez une adoption maximale, plus une protection contre l’utilisation abusive d’approbation. Le BSD en trois clauses est courant dans les communautés de recherche financées par le gouvernement et de calcul haute performance.

Apache 2.0

La seule licence permissive largement utilisée avec une délivrance de brevet explicite. Plus long que MIT ou BSD (~200 lignes), il comprend des termes supplémentaires concernant l’utilisation des marques, les avis de droits d’auteur et les représailles des brevets aux contributeurs.

Meilleure pour : Recherche avec une exposition importante aux brevets : algorithmes, méthodes d’IA, intégration matérielle ou projets communautaires où les contributeurs pourraient détenir des brevets pertinents pour le code.

Adoption de recherche : Environ 12 % des projets open source sous licence utilisent Apache 2.0, ce qui en fait le deuxième choix le plus courant.

GPL (licence publique générale)

La licence Copyleft la plus importante. GPLv2 et GPLv3 sont les deux versions principales. GPLv3 comprend des dispositions anti-tivoization (empêchant les restrictions matérielles d’exécuter des logiciels modifiés) et une clause de rétorsion des brevets ; GPLv2 n’a pas ces protections. Pour les logiciels de recherche modernes, GPLv3 est le choix actuel.

Meilleur pour : lorsque vous avez besoin de code en aval pour rester open-source. GPL s’assure que toutes les modifications ou travaux dérivés distribués publiquement doivent également être publiés sous GPL.

Adoption de recherche : Environ 5 % des projets sous licence utilisent GPL. Il est moins courant dans la recherche car de nombreux chercheurs préfèrent des termes permissifs pour une réutilisation scientifique maximale.

Tableau de comparaison

Le tableau suivant résume les principales fonctionnalités des quatre licences :

Fonctionnalité mit BSD Apache 2.0 GPL
copyleft ? Non Non Non Oui
délivrance de brevet ? Non Non Oui (explicite) Rétorsion GPLv3 uniquement
En-têtes de droits d’auteur requis ? Oui Oui Oui Oui
Le mieux pour ? Adoption maximale Adoption + protection sans approbation Exposition de brevets, projets communautaires Garantir l’ouverture en aval
Durée de la licence ? ~ 1 paragraphe ~ 1 paragraphe ~ 200 lignes ~ 80 lignes (GPLv3)
Compatible avec une utilisation propriétaire ? Oui Oui Oui Non (les travaux dérivés doivent rester GPL)

Le tableau de comparaison ci-dessus synthétise les conseils de https://safeguard.sh/resources/blog/open-source-license-comparison-mit-apache-gpl-bsd et https://ospo.library.jhu.edu/learn-grow/licensing-overview/choose-a-license/ (Johns Hopkins Ospo).

Recommandation

Pour la plupart des codes de recherche – solveurs numériques, outils de simulation, scripts d’analyse de données – Nous recommandons MIT. C’est le plus simple, le plus largement compatible et permet à n’importe qui d’être utilisé par n’importe qui sans obstacles juridiques. L’adoption large de MIT signifie que les contributeurs ne sont pas confrontés à des problèmes de compatibilité de licence lors de la combinaison de votre code avec d’autres bibliothèques populaires.

Choisissez Apache 2.0 lorsque :

  • Votre recherche implique de nouveaux algorithmes avec une exposition aux brevets
  • Vous souhaitez une subvention de brevet explicite pour protéger les utilisateurs en aval
  • Vous construisez un projet communautaire où les contributeurs peuvent détenir des brevets pertinents

Choisissez GPL lorsque :

  • Vous devez garantir que les modifications restent open source
  • Votre code est un cadre ou une bibliothèque où la gestion des dépendances en aval est importante
  • Vous accordez la priorité à l’application de l’ouverture à l’adoption maximale

Mandats de bailleurs de fonds

Les bailleurs de fonds de recherche attendent de plus en plus des pratiques d’octroi de licences spécifiques. Ignorer ces exigences crée un risque de conformité après la publication.

NASA — SPD-41A

La politique de données logicielles de la NASA 41a (SPD-41A) nécessite une licence open-source permissive pour tous les logiciels développés par un projet. Les licences propriétaires ou disponibles à la source sont généralement interdites pour le code créé sous le financement de la NASA. Cela fait du choix de la licence une exigence de conformité, et non simplement une préférence stratégique, pour les équipes de recherche financées par la NASA.

NIH — Politique Open Source

Le guide des meilleures pratiques des National Institutes of Health (NIH) sur les licences publiques open source. Bien que le NIH n’exige pas une licence spécifique, sa politique open source et ses directives sur les logiciels en tant que SHA encouragent fortement les termes open source permissifs pour les logiciels développés avec le financement des NIH.

Horizon Europe

Les attentes de financement du Conseil européen de la recherche et d’Horizon Europe attendent explicitement des licences d’autorisation pour les logiciels de recherche. Katz et ses collègues documentent la façon dont cette politique a évolué lors des récents cycles de financement et comment les équipes de recherche européennes doivent aligner leurs décisions de licence sur des principes équitables (https://open-research-europe.ec.europa.eu/articles/5-199).

Guides institutionnels du RDM

De nombreuses universités ont des politiques formelles de gestion des données de recherche (RDM) qui traitent des licences de logiciels. Le guide Max Planck RDM fournit des conseils pratiques sur la sélection des licences pour les logiciels de recherche (https://rdm.mpdl.mpg.de/2023/05/02/how-to-select-a-license-for-research-software/), tandis que KU Leuven propose une liste de contrôle explicite pour l’alignement équitable Licence (https://www.kuleuven.be/rdm/en/guidance/fair-research-software).

Guide pratique : Si vous n’êtes pas sûr des attentes de votre bailleur de fonds, consultez les conditions générales de votre subvention ou demandez à votre bureau de recherche. La plupart des politiques de bailleurs de fonds sont publiées publiquement et peuvent être vérifiées avant la publication.

Données et licences de code

L’une des sources de confusion les plus courantes dans les logiciels de recherche est la relation entre la licence de données et la licence logicielle. Les chercheurs appliquent fréquemment la même licence aux deux, créant des incompatibilités légales.

Creative Commons ne fonctionne pas pour le code

Les licences Creative Commons (CC) ont été conçues pour les données, les publications et le contenu éducatif. Ils manquent de termes critiques dont la licence logicielle nécessite :

  • Termes de distribution du code source
  • Termes de distribution binaires exécutables
  • Termes de liaison de bibliothèque
  • Clauses de représailles aux brevets

Creative Commons recommande explicitement d’utiliser les licences CC pour les logiciels. L’application de CC-BY ou CC-BY-SA au code crée une ambiguïté juridique plutôt que de la clarté.

Vous pourriez avoir besoin de deux licences

Pour les projets de recherche qui incluent à la fois des données et du code, l’approche correcte consiste souvent en deux licences distinctes :

  • Licence CC pour les données : CC-BY 4.0 pour les jeux de données et les publications
  • Licence OSS pour le code : MIT, Apache 2.0 ou GPL pour les logiciels

https://www.rug.nl/digital-competence-centre/research-data/archive-and-publi sh/how-to-work-with-dataversenl/chosing-a-licence-for-your-dataset?lang=fr Fournit des conseils explicites sur cette distinction pour les équipes de recherche qui gèrent à la fois des ensembles de données et des logiciels.

Exemple pratique

Un projet qui publie un solveur numérique (code) ainsi que la sortie de simulation (données) devrait :

  1. Inclure LICENSE.mit pour le code du solveur (licence MIT)
  2. Inclure LICENSE.cc-by-4.0 ou similaire pour les fichiers de données
  3. Documenter les deux licences dans le fichier ReadMe de référentiel

Considérations sur la propriété intellectuelle institutionnelle

Avant de publier du code sous une licence open source, vous devez vérifier la politique de propriété intellectuelle (IP) institutionnel. Il s’agit du piège administratif le plus courant pour les chercheurs universitaires.

Bureaux de transfert de technologie universitaire

La plupart des universités considèrent le code de recherche comme une propriété intellectuelle institutionnelle. Un bureau de transfert technique (TTO) ou un bureau équivalent détient généralement le droit d’auteur sur le code rédigé par les employés dans le cadre de leurs fonctions. La publication d’un tel code sous une licence open source sans approbation de la TTO peut constituer une violation de la propriété intellectuelle.

contrats de travail

De nombreux contrats de travail universitaires contiennent des clauses de propriété intellectuelle précisant à qui appartiennent les résultats de la recherche. Les membres du corps professoral peuvent avoir plus de flexibilité que les chercheurs postdoctoraux ou le personnel de recherche. Vérifiez vos conditions de contrat spécifiques.

Restrictions des organismes de financement

Certaines agences de financement imposent des restrictions de licence qui vont au-delà des propres attentes de l’agence. Par exemple, certains programmes DARPA ou DOE peuvent spécifier des familles de licences particulières ou exiger des conditions de brevet.

Étapes pratiques

  1. Contactez votre Tech Transfer Office avant de publier un code sous une licence open-source
  2. Consultez votre contrat de travail pour les clauses de propriété de la propriété intellectuelle
  3. Vérifier les conditions de subvention pour les restrictions de licence
  4. Document Approbation institutionnelle dans votre référentiel ou votre documentation

Prochaines étapes pratiques

Si vous avez du code à publier ou du code déjà publié sans licence, voici un plan d’action pratique :

avant de publier

  1. clarifiez votre intention de licence — utilisez le cadre de décision ci-dessus (section 2)
  2. Vérifier la conformité institutionnelle — Contactez votre bureau de transfert de technologie
  3. Vérifier les exigences des bailleurs de fonds — Examiner les conditions de subvention pour les attentes en matière de licences
  4. Sélectionnez la licence — utilisez choosealicense.com

Après avoir sélectionné une licence

  1. Téléchargez le texte de la licence de la source officielle (p.
  2. Créer un fichier de licence dans la racine du référentiel avec le texte exact de la licence
  3. Nommez le fichier de manière cohérente — utilisez LICENSE.mit, LICENSE.apache ou LICENSE.gpl pour plus de clarté
  4. Ajouter un avis de copyright — Le texte de la licence comprend généralement un espace réservé pour l’année de droit d’auteur et le nom de l’auteur. Remplissez ceci.
  5. Document dans Readme — Indiquez la licence utilisée, faites un lien vers le fichier de licence et expliquez comment les autres peuvent utiliser le code

Si vous avez déjà publié du code

  1. Ajouter immédiatement un fichier de licence — même si le code n’était pas sous licence auparavant, l’ajout d’une licence est une simple correction
  2. Mise à jour de la documentation du référentiel — Clarifier les conditions de licence pour les utilisateurs existants
  3. Avertir les utilisateurs existants — Si le code a des utilisateurs, communiquez les nouvelles conditions de licence

Résumé

Le choix d’une licence open-source pour les logiciels de recherche n’est pas un détail administratif mineur – c’est une décision stratégique qui affecte qui peut utiliser votre travail, comment il peut l’utiliser et si votre code est conforme aux mandats des bailleurs de fonds. Le paysage est stable et bien documenté : les licences permissives (MIT, BSD, Apache 2.0) permettent une adoption maximale, tandis que les licences Copyleft (GPL) garantissent une ouverture en aval.

Pour la plupart des codes de recherche, le MIT est le choix recommandé en raison de sa simplicité, de sa large compatibilité et de son adoption dominante (65 % des projets sous licence). Choisissez Apache 2.0 lorsque l’exposition par brevet est pertinente, et GPL lorsque vous devez garantir que le code aval reste open source.

Vérifiez toujours la politique de propriété intellectuelle institutionnelle avant d’appliquer une licence, faites une distinction claire entre la licence de données (CC) et la licence logicielle (MIT, Apache, GPL) et assurez-vous de respecter les exigences des bailleurs de fonds. La plus grande idée fausse – ce code sans licence est librement réutilisable – est la raison pour laquelle chaque équipe de recherche doit explicitement choisir et publier une licence.

Guides connexes

Si vous souhaitez étendre vos pratiques logicielles de recherche au-delà de la licence, ces guides connexes offrent une couverture complémentaire :

Liste de contrôle : votre sélection de licences en 5 minutes

  1. Que voulez-vous que les autres fassent ?Permissive (MIT/BSD) pour une adoption maximale ; Apache 2.0 pour la protection des brevets ; GPL pour une ouverture renforcée
  2. Votre institution a-t-elle besoin d’une approbation ? Contactez le bureau de transfert technique avant de publier
  3. Votre bailleur de fonds a-t-il des exigences ? Vérifiez la NASA SPD-41A, Horizon Europe Fair Alignement, NIH
  4. Publiez-vous également des données ? Utilisez CC pour les données ; Utiliser OSS pour le code
  5. Le fichier de licence est-il dans la racine du référentiel ? Ajoutez-le immédiatement s’il manque

Suivez cette liste de contrôle avant de publier un code de recherche. Il couvre la conformité et les considérations stratégiques essentielles qui vous protègent ainsi que vos utilisateurs.

Si vous créez des logiciels de recherche pour une adoption plus large, consultez notre guide sur bâtiment Communautés de logiciels de recherche durable, qui couvrent l’intégration des contributeurs, les modèles de gouvernance et les pratiques communautaires qui complètent les bonnes décisions de licence.

Cet article fournit des conseils pédagogiques sur les licences open source pour les logiciels de recherche. Il ne constitue pas un avis juridique. Consultez toujours le bureau de transfert de technologie de votre établissement et le conseiller juridique pour la conformité aux exigences spécifiques de licence et aux politiques en matière de propriété intellectuelle.