Aller au contenu
Antoine Le LouëtDéveloppeur senior indépendant (Accueil)
← Revenir au Journal

Conseils5 min de lecture

Licence Apache 2.0 : notices, modifications et brevets

Utiliser du code Apache 2.0 dans un produit : licence à joindre, fichiers modifiés, NOTICE et portée de la clause de brevets, avec un exemple de livraison.

Une livraison fictive de code Apache 2.0 modifié conserve la licence, signale les fichiers changés et reprend les attributions applicables d’un NOTICE fourni en amont.
Exemple fictif avec un NOTICE amont : la redistribution transporte le code et les informations requises par la section 4. Les modifications peuvent rester privées.

Une bibliothèque modifiée avant la livraison

Vous corrigez une bibliothèque Apache 2.0 et l’intégrez dans un logiciel livré à un client. Vous pouvez garder vos modifications privées et vendre ce logiciel. Avant l’envoi, il reste à joindre la licence, signaler les fichiers changés et reprendre les attributions applicables.

Apache 2.0 est une licence permissive, comme MIT. Elle permet l’usage commercial sans imposer la publication des sources de votre application. Elle précise davantage les conditions de redistribution et accorde aussi certains droits de brevets. L’identifiant SPDX correspondant est Apache-2.0 ; le nom désigne une licence réutilisable, y compris pour des projets extérieurs à la fondation Apache.

Ce que la section 4 demande de transmettre

Les conditions de redistribution s’appliquent aux copies du logiciel et aux œuvres dérivées, distribuées sous forme source ou compilée. Pour préparer la livraison d’une version modifiée, je relirais les quatre exigences de la section 4 :

  1. Donner aux destinataires une copie de la licence Apache 2.0. Une ligne dans un inventaire ne remplace pas le texte complet.
  2. Faire porter aux fichiers modifiés des mentions visibles indiquant qu’ils ont changé. Un historique Git absent de la livraison ne suffit pas à signaler ces modifications dans les fichiers.
  3. Conserver, dans les sources des œuvres dérivées distribuées, les avis de copyright, brevets, marques et attribution applicables au code repris.
  4. Si la distribution d’origine contient un fichier NOTICE, reproduire les avis d’attribution pertinents dans l’œuvre dérivée distribuée, selon les emplacements permis par la licence.

Ces obligations permettent une distribution binaire sans publication du code source. Vous pouvez appliquer d’autres conditions à vos modifications ou au produit dans son ensemble, tant que la redistribution du composant d’origine respecte Apache 2.0.

NOTICE : conserver les attributions pertinentes

LICENSE contient le texte de licence. NOTICE rassemble des informations d’attribution que la section 4 demande de reprendre lorsqu’un tel fichier existe en amont. Son contenu ne modifie pas la licence. L’absence de NOTICE amont ne crée pas une obligation générale d’en inventer un pour tout composant Apache 2.0.

La reprise des attributions peut se faire dans un NOTICE joint, dans les sources ou la documentation fournies, ou dans un affichage du logiciel là où figurent habituellement les avis tiers. Les mentions qui ne concernent aucune partie conservée peuvent être écartées. Je garderais la trace de ce choix pour pouvoir le relire à la prochaine mise à jour.

Dans notre exemple fictif, la livraison comprend le programme compilé et un dossier de licences tierces contenant le texte Apache 2.0 et les attributions pertinentes du NOTICE amont. Les fichiers sources modifiés portent également une mention de changement. Un commentaire tel que celui-ci peut préciser l’intervention, sans remplacer les avis d’origine :

Java · mention illustrative dans un fichier modifié
// Modifié par Équipe Exemple : adaptation du délai de connexion.
// Conserver également les avis d’origine applicables à ce fichier.

Vérifiez cette organisation dans l’archive réellement livrée. Le texte anglais de la licence doit rester inclus ; une traduction française aide à la lecture, mais la fondation précise que seul le texte anglais fait autorité.

Une licence de brevets au périmètre défini

Le droit d’auteur autorise la reprise du code. Un brevet peut porter sur une invention mise en œuvre par ce code : c’est une question distincte. La section 3 d’Apache 2.0 prévoit une concession explicite de certains droits de brevets par chaque contributeur.

Elle couvre les revendications que ce contributeur peut licencier et qui seraient nécessairement enfreintes par sa contribution seule, ou combinée au logiciel auquel elle a été soumise. Elle ne couvre donc pas tous ses brevets et ne garantit pas l’absence de brevets détenus par des tiers.

Parmi les revendications de brevets qu’un contributeur peut licencier, Apache 2.0 couvre celles nécessairement mises en œuvre par sa contribution seule ou avec le logiciel concerné. Les brevets des tiers restent hors de cette concession.
Schéma de principe de la section 3 : la concession est limitée aux revendications concernées de chaque contributeur. Elle ne constitue pas une garantie générale contre les brevets.

La section prévoit aussi une extinction : si vous engagez une action en contrefaçon de brevet affirmant que le logiciel ou une contribution incorporée enfreint un brevet, les licences de brevets accordées pour ce logiciel prennent fin à la date du dépôt de l’action. Le texte inclut certaines demandes reconventionnelles. Cette clause vise ces droits de brevets ; elle ne dit pas que tout droit d’auteur disparaît dès qu’un litige quelconque survient.

Les distinctions utiles avec MIT et la GPL

MIT impose principalement de conserver ses mentions et ne formule pas la même concession explicite de brevets. Apache 2.0 formalise en plus le signalement des fichiers modifiés et le traitement du NOTICE lorsqu’il existe. Les deux permettent un produit propriétaire : aucune n’oblige, à elle seule, à publier vos modifications.

La FAQ Apache indique une compatibilité avec la GPL version 3, mais pas avec la GPL version 2 seule. Une combinaison soumise à la GPL peut donc imposer des obligations supplémentaires au résultat distribué. Pour un composant annoncé GPL-2.0-or-later, la possibilité de choisir une version ultérieure mérite une vérification distincte ; ne réduisez pas l’analyse au mot « GPL ».

Apache 2.0 ne concède pas un droit général d’utiliser les marques du projet d’origine. Décrire la provenance du composant et reprendre ses attributions ne permet pas de présenter votre produit comme approuvé par ses auteurs. Elle prévoit aussi une fourniture sans garantie, sous les réserves du droit applicable ou d’un accord écrit.

Choisir Apache 2.0 pour son propre code

Si vous détenez les droits nécessaires, placez le texte officiel dans LICENSE et adaptez les en-têtes à vos titulaires de droits. La FAQ propose aussi des en-têtes courts utilisant SPDX-License-Identifier: Apache-2.0. L’identifiant sert à reconnaître la licence ; gardez son texte complet dans le projet et les distributions.

Je vérifierais ensuite un livrable précis : les composants réellement embarqués, leurs versions, les fichiers changés et les attributions à transmettre. Ces repères concernent la licence standard. Un accord de contribution séparé ou une combinaison de licences peut demander une analyse supplémentaire avant diffusion.

Sources et liens utiles

Partager sur LinkedIn (nouvel onglet)

Poursuivre la lecture
Tous les articles de la catégorie →