Mozilla Public License 2.0

Autorisations, conditions et limitations en un coup d'œil

Classement autorisations/conditions/limitations : données de choosealicense.com (GitHub, licence MIT).

De quelle licence s'agit-il ?

La MPL 2.0 a été publiée par la fondation Mozilla en janvier 2012. Utilisée par les produits Mozilla comme Firefox et Thunderbird, elle se distingue par un copyleft dont la portée est le fichier. Les fichiers sous MPL (et les modifications de ces fichiers) doivent être publiés en source sous MPL, mais les fichiers séparés nouvellement écrits peuvent être sous une autre licence, et la « Larger Work » (article 3.3) combinant du code MPL peut être distribuée dans son ensemble aux conditions de votre choix. Elle comporte aussi une licence de brevets explicite et une clause de résiliation en cas de litige sur les brevets.

Ce qu'il faut respecter lors de la distribution

• En cas de distribution sous forme exécutable, indiquer comment obtenir le source des fichiers sous MPL (article 3.2).
• Ne pas supprimer ni modifier les mentions de licence des fichiers MPL.
• Si vous modifiez un fichier MPL, continuer à le distribuer sous MPL-2.0.

Secondary License et compatibilité GPL

L'article 1.12 de la MPL-2.0 définit la GPL-2.0, la LGPL-2.1, l'AGPL-3.0 et leurs versions ultérieures comme « Secondary License ». Selon l'article 3.3, une Larger Work combinant du code MPL et du code sous licence GNU peut être distribuée sous licence GNU. Toutefois, si l'auteur d'origine a ajouté l'avis Exhibit B (« Incompatible With Secondary Licenses ») au fichier, cette compatibilité ne s'applique pas. La MPL-1.1 ne disposait pas de ce mécanisme et était incompatible avec la GPL ; la 2.0 a corrigé ce point.

Idées reçues fréquentes

• « Utiliser une bibliothèque MPL rend mon application MPL » — Non. Les fichiers que vous avez créés n'ont pas à être sous MPL.
• « La MPL ne peut pas être mélangée avec la GPL » — Depuis la 2.0, c'est possible tant qu'il n'y a pas d'Exhibit B.
• « Si je copie un fichier MPL dans mon fichier, mon fichier reste libre » — La partie de code MPL recopiée reste sous MPL. La frontière du fichier étant celle des obligations, il est plus sûr de séparer le code en fichiers plutôt que de le mélanger.

Comment l'appliquer

Placez le texte dans LICENSE, et il est recommandé d'ajouter en tête de chaque fichier source l'avis de l'Exhibit A (« This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0… »). S'il est difficile de l'insérer dans le fichier, vous pouvez le placer à un endroit où le destinataire le cherchera, comme un fichier LICENSE du répertoire concerné. L'identifiant SPDX est MPL-2.0 (MPL-2.0-no-copyleft-exception en présence de l'Exhibit B).

Dans quels cas l'utiliser ?

C'est un bon compromis lorsque l'on veut récupérer les améliorations de la bibliothèque ou du moteur lui-même sans contraindre la licence des produits qui l'utilisent. Ses conditions sont plus simples que celles de la LGPL et la liaison statique ne pose pas de problème. Lorsque HashiCorp a fait passer Terraform de la MPL-2.0 à la BUSL en 2023, la communauté a forké la version MPL-2.0 sous le nom d'OpenTofu.

Peut-on intégrer du code MPL-2.0 dans un autre projet ?

Verdict général lorsque du code publié sous cette licence est intégré et distribué dans un projet sous l'une des licences ci-dessous. Voir d'autres combinaisons dans le vérificateur de compatibilité →

Le contenu de ce site est fourni à titre d'information générale et ne constitue pas un conseil juridique. Pour toute décision de distribution, de contrat ou de litige, consultez un avocat ou un autre professionnel.