Guide pratique pour appliquer une licence

1. Le fichier LICENSE à la racine du dépôt

La première chose à faire est de placer le texte de la licence dans un fichier LICENSE (ou LICENSE.txt, LICENSE.md) à la racine du dépôt. GitHub, GitLab et les gestionnaires de paquets recherchent ce fichier pour reconnaître la licence. Dans le générateur, choisissez une licence, saisissez l'année et le titulaire, et téléchargez-le immédiatement.

• Ne pas modifier le texte : remplissez seulement les champs comme [year] et [fullname] de la MIT, de la BSD ou de l'ISC, et laissez le reste tel quel. Modifier les phrases empêche la reconnaissance comme licence standard et peut poser des problèmes d'interprétation.
• Les licences GNU en texte intégral : les textes de la GPL, de la LGPL et de l'AGPL n'ont aucun champ à remplir. Le titulaire et la clause de version s'indiquent dans l'avis des fichiers.

2. Indiquer l'année et le titulaire

• Année : on indique généralement l'année de première publication. On utilise parfois une plage comme 2019-2026. Aucune obligation légale de mise à jour annuelle.
• Titulaire : pour du code écrit par une personne, son propre nom ; pour du code écrit dans le cadre d'un emploi, l'employeur est généralement titulaire (selon le pays et le contrat). Les projets à nombreux contributeurs écrivent parfois The Example Project Authors et tiennent la liste dans un fichier AUTHORS.
• La mention de droit d'auteur ne crée pas le droit, elle le signale. Le droit d'auteur existe même sans mention.

3. Fichiers annexes selon la licence

Le NOTICE de l'Apache-2.0 n'est pas obligatoire, mais quiconque redistribue du code qui en contient un doit en conserver le contenu. L'ASF recommande de n'inscrire dans le NOTICE que les mentions d'attribution exigées par la loi, sans remerciements ni texte intégral de licence.

4. En-têtes des fichiers source

Un court en-tête dans chaque fichier permet aux informations de licence de suivre le fichier même s'il est copié isolément.

# SPDX-FileCopyrightText: 2026 Example Inc.
# SPDX-License-Identifier: Apache-2.0

GNU, Apache et MPL recommandent aussi un avis officiel, mais de plus en plus de projets le remplacent par les seules deux lignes SPDX. Pour plus de détails, voir le guide SPDX.

5. Métadonnées des paquets et README

• Indiquez l'identifiant SPDX dans le champ license de package.json, Cargo.toml, pyproject.toml, etc.
• Ajoutez à la fin du README une section « Licence » résumant en une ou deux lignes (p. ex. « This project is licensed under the MIT License — see LICENSE »).

6. Mentions pour le code tiers

Si vous distribuez du code d'autrui, vous devez aussi respecter les obligations de sa licence.

• Pour le code copié, conservez dans le fichier concerné la mention de droit d'auteur et la licence d'origine.
• Pour une distribution en binaire ou en application, rassemblez la liste des composants open source utilisés et le texte intégral de leurs licences dans un fichier THIRD_PARTY_NOTICES ou dans l'écran « Licences open source » de l'application.
• Si les dépendances sont nombreuses, générez la liste automatiquement avec un outil SBOM ou la fonction de rapport de licences du gestionnaire de paquets.

7. Accepter des contributions : DCO ou CLA

Les contributions externes répartissent le droit d'auteur entre plusieurs personnes. Deux méthodes permettent de le gérer.

• DCO : le contributeur ajoute Signed-off-by: à ses commits pour confirmer qu'il a « le droit de soumettre ce code sous la licence du projet ». Léger, il est utilisé par le noyau Linux.
• CLA : contrat par lequel le contributeur accorde au projet des droits étendus, y compris celui de changer la licence. Nécessaire pour une double licence commerciale ou pour se réserver la possibilité de changer de licence plus tard.

Consignez les règles de contribution dans CONTRIBUTING.md.

8. Changer de licence

• Le titulaire peut appliquer une autre licence aux versions futures. Les autorisations accordées pour les versions déjà distribuées ne sont généralement pas révocables.
• Si le code contient des contributions d'autres personnes, leur accord est nécessaire (sauf si une CLA vous a donné le droit de relicencier).
• Passer d'une licence permissive à un copyleft est relativement facile (le code permissif peut entrer dans un projet copyleft), mais passer d'un copyleft à une licence permissive est pratiquement impossible sans l'accord de tous les titulaires.
• Indiquez clairement la date, la raison et les versions concernées par le changement dans le CHANGELOG et le README.

Liste de contrôle

1. Texte de LICENSE (seuls les champs à remplir complétés)
2. Fichiers annexes (NOTICE, COPYING.LESSER, etc.)
3. En-têtes de fichiers (deux lignes SPDX)
4. Métadonnées des paquets et README
5. Mentions pour le code tiers
6. Règles de contribution (DCO ou CLA)

Cet article est fourni à titre d'information générale et ne constitue pas un conseil juridique. Pour toute décision importante, consultez un professionnel.

Sources

• GitHub Docs, Adding a license to a repository — https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository
• Apache, Applying the Apache License · Assembling LICENSE and NOTICE — https://www.apache.org/legal/apply-license.html
• GNU, How to Use GNU Licenses for Your Own Software — https://www.gnu.org/licenses/gpl-howto.html
• REUSE Specification — https://reuse.software/spec/
• Developer Certificate of Origin — https://developercertificate.org/