Je veux poser une licence sur mon code : comment faire ?

Prérequis sur les licences logicielles

En bref

En détail

Ajouter le fichier AUTHORS.md à la racine de votre code source

  • Identifier toutes les personnes créditées dans le code source... mais pas que !

  • Les personnes qui sont notées dans le fichier AUTHORS.md ont les droits de créateurs sur le code source / le logiciel

    • Les auteurs d'un logiciel sont les personnes qui ont créé le logiciel initialement ou qui l'ont fortement fait évoluer.
      • Ils sont responsables de :
        • la gestion du projet (le porteur qui gère les finances, les achats de matériel et les ressources humaines, et/ou l'encadrant principal qui gère la planification et la coordination des différentes tâches),
        • la conception (les chercheurs qui apportent leur contribution scientifique),
        • le développement (les doctorants et les stagiaires),
        • et la création du logiciel dans son ensemble (équipe technique en support au déploiement et à la maintenance).
      • Ils peuvent être considérés comme les propriétaires intellectuels du logiciel ;
    • Les contributeurs d'un logiciel sont des personnes qui apportent des modifications, des améliorations ou des ajouts au logiciel après sa création initiale.
      • Ils peuvent :
        • proposer des fonctionnalités supplémentaires,
        • corriger des bugs,
        • optimiser les performances,
        • ou apporter toute autre contribution au projet.

Que doit-on y inscrire ?

  • Prénom NOM (email institutionnel), fonction (Service/Composante/Unité, Employeur) [Taux global de participation au projet en %age]
  • Autant de lignes que de personnes identifiées comme auteurs

Exemple pratique : AUTHORS.md

Quels sont les droits d'auteurs du logiciel ?

  • Droits moraux réduits à la paternité : détenus par les auteurs (créateurs)
    • Pas de droit de divulgation : on ne peut pas choisir quand et comment livrer le logiciel
    • Pas de droit de repentir : on ne peut pas retirer un logiciel livré
    • Pas de droit au respect de l'oeuvre : on ne peut pas s'opposer aux modifications futures
  • Droits patrimoniaux concernent l'exploitation : détenus par les employeurs (propriétaires)
    • Attention : les propriétaires (et non les créateurs) choisissent la licence à appliquer
  • Certains droits peuvent varier selon le statut de l'auteur et la date de création du logiciel : voir la section Aspect juridique des licences

La somme des taux de participation au projet ne doit pas dépasser 100% !

  • Ces taux de participation permettent de répartir les droits d'exploitation lorsqu'il y a plusieurs employeurs
  • Ils sont généralement définis collectivement entre tous les auteurs
  • Les autres contributeurs peuvent être signalés séparément dans une liste "contributors" dans ce même fichier ou dans un fichier séparé nommé CONTRIBUTORS.md

Exemple pratique : CONTRIBUTORS.md

Ajouter le fichier LICENSE.md à la racine de votre code source

  • Réfléchir à la licence que vous souhaitez apposer sur votre code !

  • Si vous avez plus d'une licence, créer un dossier LICENSES/ avec les licences de toutes les dépendances de votre code

  • Bien que la licence devrait être choisie par les tutelles, en pratique :
    • Le déposant choisit la licence
    • Le déposant est responsable de la compatibilité entre licences (entre le code déposé et ses dépendances)
    • Par conséquent : ne pas la choisir seul, se faire accompagner par une personne en appui aux dépôts de logiciels (au sein de son laboratoire ou de sa tutelle)

Que doit-on y inscrire ?

  • Le texte intégral du fichier de la licence choisie (choisir de préférence des licences approuvées par la FSF et l'OSI)
  • L'identifiant des différentes licences est accessible sur le site spdx.org

Exemple pratique LICENSE.md

  • Texte intégral de la licence choisie recopié depuis cette page GitHub

Quelle licence libre / open source choisir ?

  • Pour un logiciel
    • EUPL-1.2 : European Union Public License 1.2 (approuvée par la FSF et l'OSI, conforme avec le droit d'auteur dans les 27 états membres de l'UE, traduite en 23 langues par des juristes et compatible avec la licence GPL-3.0-or-later)
    • GPL-3.0-or-later pour plus de visibilité (mieux reconnue internationalement)
  • Pour une bibliothèque
    • EUPL-1.2 : Oblige le logiciel qui inclut cette bibliothèque à être distribué en copyleft fort lui aussi => sinon on ne peut pas installer automatiquement la dépendance avec le logiciel
    • LGPL-3.0-or-later : GNU Lesser General Public License v3.0 or later (approuvée par la FSF et l'OSI, ne peut pas devenir propriétaire) => permet au logiciel qui inclut cette bibliothèque d'être distribué sous n'importe quelle licence (même propriétaire)
  • Pour une documentation
    • etalab-2.0 : Etalab Open Licence 2.0 est régie par le droit français et compatible avec la licence CC-BY-4.0 (une seule obligation : mentionner la paternité)
    • CC-BY-4.0 : Les licences Creatives Commons ont plus de visibilité (mieux reconnues internationalement). Il faut absolument utiliser a minima la version estampillée BY afin d'être compatible avec le droit français (conservation de la paternité)

Peut-on changer de licence / ajouter une licence ?

  • A tout moment, la licence d'un logiciel peut être changée à condition que TOUS les auteurs cités soient contactés et acceptent ce changement
  • Un logiciel peut également être multi-licencié (plusieurs licences avec/sans restriction d'usage) afin d'aider les futurs utilisateurs
    • à intégrer de nouvelles dépendances dans ce logiciel (par exemple, pour ajouter facilement de nouvelles fonctionnalités)
    • à intégrer ce logiciel comme dépendance d'un autre logiciel (par exemple, pour construire un logiciel plus évolué intégrant d'autres outils)

Et si je ne pose pas de licence ?

  • Tout ce qui n'est pas explicitement autorisé par la licence est interdit
  • Donc un code source diffusé sans information de licence est un code uniquement accessible en lecture / consultation (interdiction de l'interpréter ou de le compiler)

Est-ce que le fichier LICENSE.md est suffisant ?

  • Pour faire simple : Oui !
  • Pour être complet : Non !
    • Il faudrait ajouter a minima en entête dans chaque fichier source, sous forme de commentaire dans le code, :
    • Il faudrait également mettre une ou plusieurs autres licences :
      • sur toute votre documentation
      • sur les images de votre logiciel
      • et sur vos jeux de données fournis à titre d'exemples dans vos tutoriels
  • Il existe un outil pour faire cela automatiquement, voici son tutoriel : https://reuse.software/tutorial/

Ajouter le fichier README.md à la racine de votre code source

  • Beaucoup de choses peuvent figurer dans le fichier README.md qui accompagne votre logiciel mais celui-ci doit rester clair et concis

Que peut-on y inscrire ?

  • Nom et description du logiciel

  • Exigences du système

  • Instructions d'installation

  • Guide de démarrage rapide

  • Fonctionnalités principales

  • Exemples d'utilisation

  • Licence du logiciel

  • Auteurs et crédits

  • État de développement

  • Informations de contact / support

  • FAQ (Foire Aux Questions)

Doit-on tout inscrire ?

  • Bien sûr que non, vous ferez évoluer le nombre et le contenu des sections au fur et à mesure de la maturité du logiciel (en gras ci-dessus apparaissent les rubriques indispensables pour une première diffusion)
  • N'oubliez pas d'adapter ces sections en fonction des spécificités de votre logiciel et des besoins de vos utilisateurs. L'objectif est de fournir les informations nécessaires pour faciliter l'adoption et l'utilisation de votre logiciel, ainsi que pour résoudre les problèmes éventuels rencontrés par les utilisateurs
  • Si vous souhaitez plus de détails sur le contenu des sections énumérées ci-dessus, voir la section contenu détaillé d'un fichier README

Exemple pratique README.md

  • Nom et description du logiciel

    • Akhenatongle est un logiciel développé sous windows pour Chanel permettant d'analyser automatiquement la tenue de vernis à ongles dans leur centre d'expertise à partir d'une série de photographies importées au format NEF (RAW de chez Nikon). Il produit des résultats exportables au format CSV

  • Instructions d'installation

    • Exécutable auto-installable sous Windows 7 64bits ou ultérieur
    • Ne pas refuser la demande d'installation éventuelle des redistribuables Visual C++
    • Ne pas refuser la demande de désinstallation automatique d'une précédente version d'Akhenatongle

  • Fonctionnalités principales

    • Chargement d'une campagne d'acquisition composée de photographies au format NEF (chaque photographie doit contenir 4 doigts ou 1 pouce) rangées dans des dossiers (1 dossier par paneliste)
    • Extraction automatique des contours vernis et affichage sous forme d'un masque venant couvrir par transparence l'ongle verni sur chaque photographie
    • Sauvegarde des statistiques moyennes (par paneliste et par verni) sur la couverture et l'uniformité chromatique sous forme d'un fichier CSV

  • Licence du logiciel

    • Licence propriétaire : voir le fichier LICENSE.md
    • Le logiciel Akhenatongle utilise les bibliothèques dynamiques suivantes
      • Qt 5.7.0 64bits sous licence LGPL-3.0-only : voir le fichier LICENSE_qt.txt
      • OpenCV 3.1.0 64bits sous licence BSD-3-Clause : voir le fichier LICENSE_opencv.txt
      • dcraw 9.27 en open source sans restriction (suppression des fonctions restreintes qui étaient sous licence GPLv2 dans le code source) : voir le fichier LICENSE_dcraw.txt
      • easyexif sous licence BSD-2-Clause : voir le fichier LICENSE_easyexif.txt

  • Auteurs et crédits

    • Auteurs principaux : Noël Richard et Bruno Mercier
    • Liste exhaustive des auteurs : voir le fichier AUTHORS.md
    • Liste exhaustive des contributeurs : voir le fichier CONTRIBUTORS.md

  • État de développement

    • Dernière version stable (5.0.1) compilée avec MSVC2015 sous Windows 7 64bits
    • Pas de nouvelle version prévue

  • Informations de contact / support

    • Pour toute demande (support, signalement de bug), veuillez contacter : Bruno Mercier

  • FAQ (Foire Aux Questions)

    • Q°01 : L'installeur me demande d'installer les redistribuables Visual C++ mais je les avais déjà installés au préalable. Dois-je les réinstaller ?
    • R°01 : L'installeur vérifie systématiquement quelle version des redistribuables Visual C++ est installée sur votre système. S'il vous demande de les installer, c'est que la version que vous possédez est trop ancienne. Merci d'accepter son installation pour le bon fonctionnement d'Akhenatongle.

Le fichier doit rester clair et concis !

  • Afin d'être complet dans ses explications tout en restant concis sur chaque section du fichier README.md
    • Renvoyez vers des pages dédiées lorsque vous avez beaucoup de choses à écrire (plus de 20 lignes dans une section)
    • Renvoyez vers les fichiers existants qui ont été décrits dans les précédentes sections (AUTHORS.md, CONTRIBUTORS.md et LICENSES.md par exemple ; ça vous évite de maintenir à jour des informations identiques dans plusieurs fichiers)
    • Renvoyez vers une documentation lorsqu'elle existe dans un autre format (site web dédié, etc)

Ajouter un entête sous forme de commentaire dans chaque fichier de votre code source

  • Vérifier que l'entête de chaque fichier de votre code source contienne les informations essentielles sur sa paternité.

Que doit-on y inscrire ?

  • Nom du fichier
  • Auteurs du fichier + Emails institutionnels
  • Date de dernière modification du fichier
  • Copyright ©
    • Année de création du fichier et
    • Droits patrimoniaux (liste exhaustive des tutelles du laboratoire ou du service)
  • Licence : nom du logiciel + nom de la licence logicielle au format SPDX

Doit-on tout inscrire ?

  • Oui bien sûr, c'est ce qui permet de garder une trace de qui a codé quoi au fil du temps.
  • Vous pouvez également ajouter un numéro de révision à votre fichier (rien à voir avec le numéro de version du logiciel)
  • Si vous n'avez pas effectué ce travail dans tous vos fichiers, pas de panique : aidez vous de l'outil reuse afin de poser automatiquement un copyright et une licence dans chaque fichier de votre code source.

Exemple pratique entête sous forme de commentaire C++ en Doxygen

/**
 * \file       RawOpen.h
 * \author     Alexandre BONY (alexandre.bony@univ-poitiers.fr)
 * \author     Bruno MERCIER (bruno.mercier@univ-poitiers.fr)
 * \version    1.1
 * \date       2016-06-27
 * \copyright  ©2014 Laboratoire XLIM, Université de Poitiers, CNRS, Université de Limoges
 *             Logiciel "Akhenatongle" sous licence propriétaire
 * \brief      Définition d'une Class CRawOpen.
 * \details    Cette classe permet de gérer l'ouverture des fichiers images au format NEF 
 *             (RAW 12 et 14 bits de Nikon).
 *             Les méthodes sont implémentées dans le fichier "RawOpen.cpp".
 */

Ajouter le fichier codemeta.json à la racine de votre code source

  • Pour partager son code source sur Software Heritage, il faut, a minima, avoir déposé l'ensemble des fichiers décrits ci-dessus ainsi qu'un fichier décrivant les métadonnées de votre logiciel : codemeta.json

  • Software Heritage est une plateforme web d'archivage de code source ouvert qui a pour ambition de collecter, préserver et partager tous les logiciels disponibles publiquement sous forme de code source

  • Même si votre code n'est pas ouvert, c'est une bonne pratique de générer systématiquement les métadonnées de votre logiciel

Que doit-on y inscrire ?

  • Les métadonnées de votre logiciel au format json

Comment ?

Guide pour établir des liens entre HAL et Software Heritage

Cette documentation a été rédigée après avoir suivi de nombreuses formations données par Teresa Gomez-Diaz (IGR au LIGM) et par Thibaud Guillebon (juriste à l'URFIST de Bordeaux).

Auteur : Bruno Mercier - Licence CC-BY-NC-SA-4.0