Eclipse 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 ?

L'EPL 2.0 a été publiée par la fondation Eclipse en août 2017. L'IDE Eclipse, Jakarta EE et de nombreux projets de la fondation Eclipse l'utilisent. La distribution d'un programme sous EPL et de ses modifications (« Contribution ») impose de publier le source, mais le code séparé dans des modules distincts et non dérivé du code EPL peut être distribué sous une autre licence (y compris commerciale). Elle comporte une licence de brevets explicite et une clause qui met fin à la licence de brevets de quiconque engage une action en affirmant que le programme viole un brevet.

Ce qui a changé par rapport à l'EPL-1.0

• La clause désignant le droit de l'État de New York comme loi applicable a été supprimée.
• La définition d'« œuvre dérivée » a été alignée sur la notion du droit d'auteur.
• Le mécanisme de Secondary License (Exhibit A) a été introduit : si l'auteur d'origine le désigne, le résultat combiné avec la GPL-2.0, etc., peut être distribué sous cette licence.

Ce qu'il faut respecter lors de la distribution

• En cas de distribution sous forme de source, distribuer selon les conditions de l'EPL-2.0 et inclure une copie de la licence.
• En cas de distribution sous forme de code objet (binaire), indiquer comment obtenir le source par un moyen raisonnable et veiller à ce que vos propres conditions de licence ne restreignent pas les droits des destinataires de l'EPL.
• Conserver les mentions de droit d'auteur.
• Les distributeurs commerciaux ont une obligation de défense et d'indemnisation afin que la responsabilité ne retombe pas sur les autres contributeurs (article 4).

Idées reçues fréquentes

• « L'EPL est compatible avec la GPL » — Pas par défaut. Cela ne vaut que pour le code dont l'auteur d'origine a désigné une Secondary License via l'Exhibit A.
• « Tous les plugins EPL doivent être sous EPL » — S'ils fonctionnent comme modules séparés et ne dérivent pas du code EPL, ils peuvent être sous une autre licence. Le caractère dérivé s'apprécie selon le droit d'auteur.
• « Même sans modification, le simple usage impose de publier le source » — L'obligation de publication porte sur le code EPL (et ses modifications). Sans modification, il suffit d'indiquer comment obtenir le source du code d'origine.

Comment l'appliquer

Placez le texte dans LICENSE et, si nécessaire, ajoutez dans chaque fichier un avis de Secondary License au format de l'Exhibit A. L'EPL n'ayant pas de texte d'en-tête imposé comme GNU ou Apache, un en-tête avec l'identifiant SPDX EPL-2.0 est recommandé (si la GPL-2.0 est désignée comme Secondary License, l'expression SPDX s'écrit parfois EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0).

Dans quels cas l'utiliser ?

Elle convient aux écosystèmes pilotés par des entreprises qui veulent garder ouvert le cœur d'une plateforme ou d'un framework tout en permettant la vente commerciale des modules d'extension. Une alternative plus simple, par fichier, est la MPL-2.0.

Peut-on intégrer du code EPL-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.