Explorez les licences Open source courantes

  • 8 minutes

Des centaines de licences open source existent, mais la plupart des logiciels open source utilisent un nombre relativement faible de licences populaires. Comprendre ces licences courantes, leurs termes et leurs implications aide les organisations à prendre des décisions éclairées sur les composants open source qu’ils peuvent incorporer en toute sécurité dans leur logiciel.

Spectre des licences

Les licences open source existent sur un spectre de très permissives à fortement copyleft :

Capture d’écran du spectre des licences.

Licences permissives avec attribution

Sur le côté gauche du spectre sont des licences permissives qui imposent des restrictions minimales :

  • Caractéristiques: Autorisez l’utilisation de code dans des logiciels propriétaires sans exiger que le logiciel propriétaire soit open source.
  • Exigence principale : Attribution : conservez les avis de droits d’auteur et le texte de licence.
  • Utilisation commerciale : Entièrement compatible avec la création et la vente de logiciels commerciaux propriétaires.
  • Liberté en aval : Les utilisateurs peuvent choisir s’il faut utiliser des dérivés open source.

Exemples: Licence MIT, Licence Apache 2.0, Licences BSD.

Licences Copyleft

Sur le côté droit du spectre se trouvent des licences copyleft avec de fortes exigences réciproques :

  • Caractéristiques: Exiger des travaux dérivés et des travaux combinés pour utiliser la même licence.
  • Nature virale : La licence « se propage » aux logiciels qui incorporent ou sont combinés avec le code sous licence.
  • Exigence du code source : La distribution des fichiers binaires nécessite de rendre le code source disponible.
  • Préservation de la liberté : Assurez-vous que le logiciel reste open source au fur et à mesure qu’il évolue et est incorporé dans d’autres projets.

Exemples: Licence publique générale GNU (GNU v2 et v3), LICENCE PUBLIQUE GÉNÉRALE GNU Affero (AGPL).

Licences copyleft faibles

Au milieu du spectre sont des licences de copie faible qui équilibrent l’ouverture avec la viabilité commerciale :

  • Caractéristiques: Exiger des modifications apportées au composant sous licence pour être open source, mais autoriser l’incorporation du composant dans des travaux propriétaires plus volumineux.
  • Compatible avec la bibliothèque : Conçu pour les bibliothèques qui peuvent être utilisées dans des applications propriétaires.
  • Copie au niveau du fichier ou au niveau du module : Les exigences s’appliquent au composant sous licence lui-même, et non à l’ensemble de l’application.
  • Équilibre pratique : Activez l’utilisation commerciale tout en garantissant que les améliorations apportées au composant restent open source.

Exemples: Licence publique générale GNU (LGPL), licence publique Mozilla (MPL), licence publique Eclipse (EPL).

Licences permissives courantes

Licence MIT

La licence MIT est l’une des licences open source les plus simples et les plus permissives :

Termes clés :

  • Autorisations: Utilisez, copiez, modifiez, fusionnez, publiez, distribuez, sous-licence et vendez le logiciel.
  • Conditions: Incluez l’avis de copyright et le texte de licence dans toutes les copies ou portions substantielles.
  • Limitations: Aucune garantie, aucune responsabilité pour les dommages-intérêts.

Pourquoi les projets choisissent MIT :

  • Adoption maximale : Les restrictions minimales encouragent l’utilisation généralisée.
  • Simple et clair : Texte de licence court facile à comprendre.
  • Commercial-friendly : Aucun obstacle à l’incorporation de code sous licence MIT dans des logiciels propriétaires.
  • Flexibilité: Les utilisateurs disposent d’une liberté totale dans la façon dont ils utilisent et distribuent le logiciel.

Projets sous licence MIT populaires : React, Angular, Node.js, jQuery, Rails, .NET Core.

Implications pour les organisations :

  • Sécurisé pour une utilisation commerciale : Peut incorporer des composants sous licence MIT dans des logiciels propriétaires sans restrictions.
  • Attribution requise : doit conserver les avis de copyright, généralement satisfaits en incluant du texte de licence dans la documentation de l’application ou à propos des boîtes de dialogue.
  • Aucune octroi de brevet : La licence MIT ne traite pas explicitement des brevets, ce qui crée une ambiguïté potentielle.

Licence Apache 2.0

La licence Apache 2.0 est une licence permissive avec protection explicite des brevets :

Termes clés :

  • Autorisations: Utilisez, reproduire, préparer des travaux dérivés, afficher, exécuter, sous-licence et distribuer.
  • Conditions: Inclure l’avis de copyright, le texte de licence et l’avis des modifications ; préserver les avis de brevet ; fournir l’attribution.
  • Octroi de brevets : Octroi explicite des droits de brevet des contributeurs.
  • Représailles aux brevets : Les octrois de brevets se terminent si le titulaire lance un litige en matière de brevets contre les contributeurs.
  • Limitations: Aucune garantie, aucune responsabilité, aucun droit de marque.

Pourquoi les projets choisissent Apache 2.0 :

  • Clarté des brevets : Les octrois explicites de brevets fournissent une certitude juridique.
  • Transparence des modifications : L’obligation de documenter les modifications favorise la transparence.
  • Confiance de l’entreprise : Les termes clairs et les protections de brevets mettent les entreprises à l'aise pour contribuer.
  • Compatibilité: Compatible avecPG v3 (mais pasPG v2).

Projets Apache 2.0 populaires : Kubernetes, TensorFlow, Android, Spring Framework, Apache Hadoop, Apache Kafka.

Implications pour les organisations :

  • Protection des brevets : L’octroi explicite de brevets réduit le risque de litige en matière de brevets des contributeurs.
  • Avis de modification : Doit indiquer quand des fichiers ont été modifiés.
  • Exigences d’attribution : Légèrement plus complexe que le MIT, nécessitant la conservation des fichiers NOTICE.
  • Arrêt défensif : Les octrois de brevets se terminent si vous poursuivez les contributeurs pour violation des brevets, ce qui encourage la coexistence pacifique.

Licences BSD (2 clauses et 3 clauses)

Les licences BSD (Distribution de logiciels Berkeley) sont des licences permissives similaires à MIT :

BSD 2-Clause (BSD simplifié) :

  • Autorisations: Redistribution et utilisation dans des formulaires sources et binaires, avec ou sans modification.
  • Conditions: Conservez l’avis de copyright, la liste des conditions et la clause d’exclusion de responsabilité ; conservez l’attribution dans la documentation pour les distributions binaires.
  • Limitations: Aucune garantie, aucune responsabilité.

BSD 3-Clause (BSD modifié) :

  • Condition supplémentaire : Impossible d’utiliser les noms des titulaires de droits d’auteur pour approuver des produits dérivés sans autorisation.
  • Protection des marques : Empêche de suggérer une approbation implicite par les auteurs d’origine.

Projets sous licence BSD populaires : FreeBSD, OpenBSD, parties de macOS et iOS.

Implications pour les organisations :

  • Similaire au MIT : Restrictions minimales, conviviales pour le commerce.
  • Restriction d’utilisation des noms : 3-Clause BSD empêche l’utilisation de noms de projet pour le marketing sans autorisation.
  • Bien établi : Longue histoire dans les logiciels universitaires et commerciaux.

Licences copyleft courantes

Licence publique générale GNU (PG) v2 et v3

La licence publique générale GNU est la licence copyleft la plus connue :

Termes clés de la GPL v2 :

  • Autorisations: Utilisez, modifiez et distribuez le logiciel.
  • Conditions: Distribuer du code source avec des fichiers binaires ; les œuvres dérivées doivent utiliser LA licencePG v2 ; conservez les avis de droits d’auteur.
  • Étendue copyleft : s’applique aux œuvres dérivées et aux travaux combinés qui relient avec le code GPL.
  • Limitations: Aucune garantie, aucune responsabilité.

Améliorations apportées à LA VERSION 3 DEPG :

  • Protection des brevets : Octrois explicites de brevets similaires à Apache 2.0.
  • Prévention de la tivoisation : Empêche l’utilisation de restrictions matérielles pour empêcher les utilisateurs d’exécuter des logiciels modifiés.
  • Compatibilité internationale : Amélioration de la clarté juridique pour les juridictions internationales.
  • Compatibilité d’Apache 2.0 : Peut combiner du codePG v3 avec du code Apache 2.0.

Pourquoi les projets choisissentPG :

  • Garantir la liberté : PG garantit que les modifications restent open source, empêchant les duplications propriétaires.
  • Bâtiment communautaire : Encourage le partage des améliorations apportées à la communauté.
  • Alignement philosophique : S’aligne sur la philosophie du logiciel libre que le logiciel doit rester libre.

Projets sous licence GÉNÉRAL populaires : Noyau Linux (PG v2), Git (PG v2), WordPress (GCC v2), GCC (GCC v3), Bash (PG v3).

Implications pour les organisations :

  • Exigences relatives aux œuvres dérivées : Si vous modifiez le code GPL ou que vous créez des œuvres dérivées, vous devez les publier sous GPL lorsqu’ils sont distribués.
  • Problèmes de liaison : La liaison de code propriétaire avec les bibliothèques sous GPL peut déclencher des exigences de copyleft (l’interprétation varie).
  • Distribution commerciale : Peut vendre des logiciels sous GPL, mais doit fournir du code source aux clients.
  • Considérations SaaS : Le GPL v2 et v3 n'exigent pas la divulgation du code source pour le SaaS, à moins que l'AGPL ne soit utilisé.

Gnu Affero General Public License (AGPL)

L’AGPL étend la version 3 de GPL avec une condition d'utilisation du réseau :

Exigence AGPL supplémentaire :

  • Copie réseau : Si vous modifiez le logiciel AGPL et que les utilisateurs interagissent avec lui via un réseau (SaaS), vous devez fournir du code source à ces utilisateurs.
  • Fermeture de l’échappatoire ASP : Empêche les entreprises de modifier le logiciel et de l’offrir en tant que service sans partager de modifications.

Pourquoi les projets choisissent AGPL :

  • Protection SaaS : Garantit que les services cloud ne peuvent pas utiliser de logiciels open source sans contribuer.
  • Copyleft renforcé : Protection maximale contre l’utilisation propriétaire.

Projets sous licence AGPL populaires : MongoDB (modifié par AGPL), RocketChat, Grafana.

Implications pour les organisations :

  • À éviter pour le SaaS : La plupart des organisations évitent les logiciels sous licence AGPL pour les offres de service, car ils nécessitent la publication des modifications en open source.
  • Utilisation interne : Peut être utilisé en interne sans déclencher des exigences s’il n’est pas exposé aux utilisateurs sur un réseau.
  • Évaluation du risque: Évaluez soigneusement si les logiciels sont qualifiés d'« interaction sur un réseau ».

Licences copyleft faibles courantes

Licence publique générale limitée GNU (LGPL)

Le LGPL permet de lier les bibliothèques sans déclencher les exigences complètes de la GPL :

Termes clés :

  • Utilisation de la bibliothèque : Peut lier des bibliothèques LGPL à partir de logiciels propriétaires sans ouvrir l’application propriétaire.
  • Modifications apportées à la bibliothèque : Les modifications apportées à la bibliothèque LGPL’d elle-même doivent être open source.
  • Liaison dynamique : LGPL autorise explicitement la liaison dynamique avec du code propriétaire.
  • Travaux dérivés : Les applications complètes ne fonctionnent pas uniquement parce qu’elles utilisent des bibliothèques LGPL.

Pourquoi les projets choisissent LGPL :

  • Adoption de la bibliothèque : encourage l’utilisation dans les logiciels propriétaires tout en protégeant la bibliothèque elle-même.
  • Position de compromis : Équilibre l’ouverture avec la viabilité commerciale.
  • Adéquation des bibliothèques standard : Approprié pour les bibliothèques destinées aux composants standard.

Projets sous licence LGPL populaires : Qt (double licence avec option commerciale), GTK, GStreamer, de nombreuses bibliothèques C.

Implications pour les organisations :

  • Peut être utilisé dans les applications propriétaires : Sécurité pour utiliser des bibliothèques LGPL dans des applications commerciales.
  • Doit fournir la source de la bibliothèque : Si vous modifiez la bibliothèque LGPL, fournissez le code source pour les modifications.
  • Complexité de liaison statique : La liaison statique peut déclencher des exigences plus strictes ; la liaison dynamique est plus sûre.

Licence publique Mozilla (MPL) 2.0

La MPL 2.0 offre un copyleft au niveau du fichier :

Termes clés :

  • Copie au niveau du fichier : Les exigences s’appliquent uniquement aux fichiers initialement sous MPL.
  • Exemption de travail plus grande : Peut combiner des fichiers MPL’d avec des fichiers propriétaires dans la même application.
  • Divulgation de code source : Doit fournir du code source pour les fichiers MPL’d.
  • Octroi de brevets : Inclut l’octroi explicite de brevets et l’arrêt défensif.
  • Compatibilité GPL : MPL 2.0 est compatible avec GPL.

Pourquoi les projets choisissent MPL 2.0 :

  • Balance : Plus forte que les licences permissives, plus souple que GPL.
  • Utilisation commerciale : Active l’utilisation commerciale tout en protégeant le composant open source.
  • Suivi des fichiers : La copie au niveau du fichier facilite le suivi de la conformité.

Projets sous licence MPL populaires : Firefox, Thunderbird, LibreOffice.

Implications pour les organisations :

  • Peut combiner avec du code propriétaire : Intégration plus facile avec des logiciels propriétaires que LAPG.
  • Suivi au niveau du fichier : Doit conserver des limites claires entre les fichiers MPL’d et les fichiers propriétaires.
  • Modifications partagées : Les modifications apportées aux fichiers MPL’d doivent être partagées, mais les ajouts dans des fichiers distincts ne le sont pas.

Compatibilité des licences

Différentes licences ont des règles de compatibilité différentes :

Combinaisons compatibles

  • MIT + Apache 2.0 : Compatible : peut combiner dans le même projet.
  • MIT +PG v3 : Compatible : peut incorporer du code sous licence MIT dans des projetsPG v3.
  • Apache 2.0 +PG v3 : Compatible :PG v3 peut incorporer du code Apache 2.0.
  • LGPL + GPL : Compatible : peut mettre à niveau LGPL vers GPL.

Combinaisons incompatibles

  • PG v2 + Apache 2.0 : Incompatible : impossible de combiner dans le même travail.
  • GPL + Propriétaire : Incompatible : la GPL exige que les œuvres dérivées soient sous licence GPL.
  • Différentes licences copyleft : Généralement incompatibles—on ne peut généralement pas combiner le code GPL, AGPL et LGPL avec différentes licences copyleft de manière à satisfaire les conditions de l'ensemble.

Considérations relatives à la compatibilité

Lors de la sélection des dépendances :

  • Inventaire des licences : Connaître les licences pour toutes les dépendances.
  • Vérification de compatibilité : Vérifiez que les licences de différents composants sont compatibles.
  • Révision légale : Les cas complexes nécessitent une expertise juridique pour évaluer la compatibilité.

Stratégies de double licence

Certains projets offrent plusieurs options de licence :

Open source + Commercial

  • Stratégie: Proposer sous Licence publique générale (GPL, copyleft) ou licence commerciale.
  • Raisonnement: Les entreprises souhaitant incorporer des logiciels propriétaires achètent une licence commerciale ; La communauté open source utilise la version GPL.
  • Exemples: Qt, MySQL, MongoDB (approche modifiée).

Plusieurs licences open source

  • Stratégie: Autoriser les utilisateurs à choisir parmi plusieurs licences compatibles.
  • Justification: Optimisez la compatibilité avec différents projets.
  • Exemples: Certaines bibliothèques offrent des options de licence Apache 2.0 ou MIT.

Comprendre les licences open source courantes, leurs termes et leur compatibilité aide les organisations à prendre des décisions éclairées sur les composants open source à utiliser et sur la façon de structurer leurs logiciels pour maintenir la conformité des licences. L’unité suivante explore les implications et les évaluations des licences qui aident à évaluer les risques et à prendre des décisions.