{"id":1216,"date":"2026-08-21T14:28:46","date_gmt":"2026-08-21T14:28:46","guid":{"rendered":"https:\/\/matforge.org\/?p=1216","raw":"https:\/\/matforge.org\/?p=1216"},"modified":"2026-08-21T14:28:46","modified_gmt":"2026-08-21T14:28:46","slug":"open-source-licensing-research-software-choosing-a-license","status":"publish","type":"post","link":"https:\/\/matforge.org\/fr\/open-source-licensing-research-software-choosing-a-license\/","title":{"rendered":"Licence open source pour les logiciels de recherche : choix d’une licence","raw":"Licence open source pour les logiciels de recherche : choix d'une licence"},"content":{"rendered":"Reading Time: <\/span> 11<\/span> minutes<\/span><\/span>

Le choix d’une licence open-source pour le code de recherche est l’une des d\u00e9cisions les plus cons\u00e9quentes qu’un chercheur prend – et celle que la plupart des \u00e9tudiants dipl\u00f4m\u00e9s et des chercheurs principaux rencontrent pour la premi\u00e8re fois sans aucune formation formelle.<\/h2>\n

Votre choix de licence d\u00e9termine qui peut utiliser votre code, comment il peut l’utiliser, si les revendications de brevet sont trait\u00e9es et si les modifications en aval restent ouvertes. Cela affecte directement la reproductibilit\u00e9, l’attribution et le respect des mandats des bailleurs de fonds. Pourtant, la communaut\u00e9 des chercheurs n’a pas de ressource \u00e9ducative standard qui guide les chercheurs dans le processus de d\u00e9cision r\u00e9el, compare les principales licences en langage simple ou explique l’intersection souvent confuse des licences de donn\u00e9es et de licences de logiciel.<\/p>\n

Ce guide aborde cet \u00e9cart. Il guide les chercheurs \u00e0 travers les \u00e9tapes pratiques de la s\u00e9lection d’une licence, compare les principales options, explique les exigences des bailleurs de fonds, clarifie la distinction data-vs-code et d\u00e9crit les consid\u00e9rations institutionnelles avant de publier du code.<\/p>\n

Pourquoi le choix de licence est important<\/h2>\n

L’id\u00e9e fausse la plus importante dans la communaut\u00e9 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\u00e8rement prot\u00e9g\u00e9 par des droits d’auteur, ce qui signifie que personne d’autre ne peut l\u00e9galement le copier, le modifier ou le distribuer, pas m\u00eame dans des contextes acad\u00e9miques. C’est la r\u00e9alit\u00e9 juridique fondamentale que chaque \u00e9quipe de recherche doit comprendre avant de partager publiquement le code.<\/p>\n

https:\/\/open-science-training-handbook.gitbook.io\/book\/02OpenScienceBasics\/03OpenResearchSoftware et OpenSource<\/a> Documente explicitement cette id\u00e9e fausse et r\u00e9pertorie d’autres mythes courants sur l’open-source licence.<\/p>\n

Au-del\u00e0 de la conformit\u00e9 l\u00e9gale, votre choix de licence a des cons\u00e9quences directes sur trois domaines :<\/p>\n

reproductibilit\u00e9<\/h3>\n

Une licence open-source donne aux autres chercheurs l’autorisation l\u00e9gale d’ex\u00e9cuter, de modifier et de reproduire votre travail. Sans cela, m\u00eame les chercheurs qui souhaitent reproduire vos r\u00e9sultats sont confront\u00e9s \u00e0 une incertitude juridique, un obstacle qui sape le mouvement de reproductibilit\u00e9 dans la science informatique.<\/p>\n

Attribution<\/h3>\n

Diff\u00e9rentes licences g\u00e8rent l’attribution diff\u00e9remment. Les licences permissives telles que MIT et BSD n\u00e9cessitent une attribution dans les redistributions des sources, tandis que les licences Copyleft telles que GPL int\u00e8grent profond\u00e9ment les exigences d’attribution dans leurs conditions. La licence que vous choisissez d\u00e9termine la fa\u00e7on dont votre contribution est cr\u00e9dit\u00e9e en aval.<\/p>\n

Conformit\u00e9 des bailleurs<\/h3>\n

Les principaux bailleurs de fonds de la recherche ont d\u00e9sormais des attentes explicites en mati\u00e8re de licences. La politique de donn\u00e9es logicielles de la NASA 41A (SPD-41A) n\u00e9cessite explicitement une licence open-source permissive pour tous les logiciels d\u00e9velopp\u00e9s par le projet et exclut g\u00e9n\u00e9ralement les licences propri\u00e9taires ou sources. Horizon Europe s’attend \u00e0 des licences de permission \u00e9quitables. Guide des meilleures pratiques du NIH sur les licences publiques open source. Ignorer ces exigences peut cr\u00e9er des violations de conformit\u00e9 apr\u00e8s la publication.<\/p>\n

Le processus de d\u00e9cision<\/h2>\n

Le choix d’une licence est une d\u00e9cision structur\u00e9e et non une s\u00e9lection al\u00e9atoire. Suivez ces \u00e9tapes :<\/p>\n

\u00c9tape 1 : clarifiez ce que vous voulez que les autres fassent<\/h3>\n

Demandez-vous : voulez-vous que les autres utilisent votre code librement dans des projets propri\u00e9taires, ou voulez-vous que toutes les modifications restent open-source ? Cette question entra\u00eene le reste de la d\u00e9cision.<\/p>\n

Si vous souhaitez une adoption maximale, y compris l’utilisation par l’industrie, les projets propri\u00e9taires et la distribution commerciale sans restriction, les licences permissives (MIT, BSD) sont appropri\u00e9es. Si vous souhaitez que les travaux d\u00e9riv\u00e9s restent open-source, les licences Copyleft (GPL) sont le choix.<\/p>\n

Step 2 \u2014 Consider patent implications<\/h3>\n

Si votre recherche implique de nouveaux algorithmes, des m\u00e9thodes d’apprentissage automatique ou une int\u00e9gration mat\u00e9rielle, le risque de brevet devient pertinent. Apache 2.0 est la seule licence permissive largement utilis\u00e9e avec une d\u00e9livrance de brevet explicite. Cela signifie que les contributeurs accordent aux utilisateurs en aval une licence pour toute r\u00e9clamation de brevet d\u00e9tenue par des contributeurs pour le code dans le cadre du projet. MIT, BSD et GPL ne contiennent pas de d\u00e9livrance de brevets explicites (GPLv3 comprend une clause de repr\u00e9sailles au brevet mais aucune octroi de contribution).<\/p>\n

\u00c9tape 3 \u2013 Aligner sur les conventions communautaires<\/h3>\n

\u00c9tudiez les licences utilis\u00e9es par des projets similaires dans votre sous-champ. Une biblioth\u00e8que de m\u00e9thodes num\u00e9riques dans la science des mat\u00e9riaux informatiques doit tenir compte des licences que les cadres \u00e9tablis utilisent. L’alignement de la communaut\u00e9 r\u00e9duit les frictions pour les contributeurs et les utilisateurs.<\/p>\n

Pour un contexte plus approfondi sur les flux de travail de d\u00e9veloppement open source dans les contextes de recherche, consultez notre guide sur les Contribution \u00e0 Fipy, qui explique comment le code fonctionnant dans la communaut\u00e9 fonctionne dans la pratique.<\/a\u00a00><\/p>\n

\u00c9tape 4 \u2013 V\u00e9rifier les exigences institutionnelles<\/h3>\n

De nombreuses universit\u00e9s exigent l’approbation du Tech Transfer Office avant de publier un logiciel sous licence open-source. Les contrats de travail peuvent restreindre les d\u00e9cisions de licence. V\u00e9rifiez toujours la politique institutionnelle avant d’appliquer une licence.<\/p>\n

\u00c9tape 5 \u2014 Appliquez la licence choisie<\/h3>\n

Placez un fichier de licence \u00e0 la racine du r\u00e9f\u00e9rentiel, nomm\u00e9 exactement comme le texte de la licence (par exemple, LICENSE.mit<\/code>, LICENSE.apache<\/code> ou LICENSE.gpl<\/code>). Ajoutez \u00e9ventuellement des en-t\u00eates de droits d’auteur aux fichiers source, bien que cela ne soit pas requis par la plupart des licences.<\/p>\n

Utilisez choosealicense.com<\/a> comme outil interactif pour faire correspondre votre cas d’utilisation \u00e0 une recommandation de licence.<\/p>\n

Comparaison de licence<\/h2>\n

Les quatre licences les plus couramment utilis\u00e9es dans les logiciels de recherche sont MIT, BSD, Apache 2.0 et GPL. Ils se r\u00e9partissent en deux familles :<\/p>\n