Guide du développeur sur les licences open source

Toutes les licences open source ne sont pas identiques. Certains d'entre eux obligent le fournisseur de logiciels à accorder des licences de brevet aux utilisateurs et aux développeurs du logiciel. D'autres licences obligent le développeur qui utilise le produit ou la bibliothèque sous licence à proposer le code source de ce produit ou de cette bibliothèque aux mêmes conditions. D'autres donnent simplement le code, sans aucune garantie d'aucune sorte ni aucune préoccupation. Dans cet article, je vais essayer de mettre en évidence les principales différences entre les licences open source les plus utilisées du point de vue d'un utilisateur de logiciel et d'un développeur de logiciel.

Lorsqu'en 1984, Richard Stallman lance le projet GNU de création d'un système d'exploitation libre, il retrouve l'idée que les logiciels doivent être partagés entre développeurs, ingénieurs et utilisateurs ; et ils devraient pouvoir l'améliorer de manière collaborative de la même manière que la science est généralement pratiquée.

Cette option contrastait avec le concept habituel de logiciel sous licence choisi par la plupart des sociétés de logiciels et des développeurs pour distribuer et vendre leurs programmes. Aujourd'hui, plus de trente ans plus tard, les logiciels open source continuent lentement de conquérir de vastes secteurs de notre industrie : Linux, Android, Apache et Git sont des exemples de produits open source leaders dans leurs catégories.

Logiciel libre ou open source ?

Dans cet article, j'utiliserai les termes « open-source » et « gratuit » comme synonymes en faisant référence à des logiciels ou à des licences. À mon avis, les deux termes expriment la même idée. "Open-source" l'exprime de manière pratique et technique, et utiliser "Free" met l'accent sur une signification philosophique et politique du concept.

Malheureusement le mot « gratuit » en anglais, en plus d'être l'adjectif associé à « liberté », signifie aussi « sans frais ». C'est la raison pour laquelle je préfère généralement dire "open-source".

Propriétés communes des logiciels open source

Je suppose que vous avez déjà une idée approximative de ce qu'est un logiciel open source. Mais comme nous allons parler des détails des différentes licences, nous devons d'abord parler des propriétés spécifiques qui définissent les logiciels open source.

Tout d'abord : je ne suis pas avocat, et ce n'est pas un avis juridique. En cas de doute, veuillez vous référer au texte même des licences dont je parle, et à votre conseiller juridique.

Tous les logiciels open source, selon l'Open Source Initiative, sont distribués sous une licence qui donne à ses utilisateurs et développeurs (les titulaires de licence) certains droits. La liste complète peut être consultée dans la définition Open Source, mais voici un résumé de base :

1. Redistribution gratuite du logiciel : le logiciel peut être vendu ou offert en tant que produit ou inclus dans un progiciel. Cela peut se faire sans payer de royalties.
2. Le code source du logiciel sous licence est soit inclus dans la distribution, soit au moins il existe des moyens bien connus d'obtenir le code source. Ce code source est utilisable pour développer des versions modifiées du logiciel.
3. La création d'œuvres dérivées est autorisée et la licence leur permet d'être distribuées sous les mêmes conditions et sous la même licence que le logiciel original. Selon la licence du logiciel d'origine, dans certains cas, ces œuvres dérivées doivent être différenciées du logiciel d'origine en modifiant leur nom ou leur numéro de version, ou ne peuvent être distribuées que sous la forme de correctifs de code source.
4. Le logiciel peut être utilisé par n'importe quelle personne ou groupe de personnes, et dans n'importe quel domaine d'activité, sans limitation.

Mais vous devez garder à l'esprit que les licences de logiciels ne parlent que de l'utilisation ou de la distribution des autorisations accordées par les détenteurs des droits d'auteur. Les licences open source peuvent vous permettre de redistribuer librement le logiciel ou les œuvres dérivées, mais cette autorisation peut également être restreinte dans certains pays où l'exportation de logiciels cryptographiques est interdite. De la même manière, les licences open source vous permettent d'utiliser le logiciel à n'importe quelle fin, mais cela ne signifie pas qu'elles vous permettent de pirater une banque à l'aide d'un logiciel sous licence open source. Les brevets logiciels en sont un autre exemple : certaines licences open source autorisent l'utilisation libre des brevets, mais pas toutes.

Alors, peut-on utiliser un logiciel open-source dans le développement d'un produit ou d'un projet ? Fondamentalement, cela dépend de la licence du logiciel utilisé et de la licence prévue pour le produit final. Les différentes licences sont également importantes lorsque vous souhaitez publier votre propre code en open source et que vous décidez quelle licence vous devez utiliser.

Copyleft

Un concept assez intéressant à propos des licences open-source est ce qu'on appelle généralement le copyleft, l'opposé du droit d'auteur. Lorsque le droit d'auteur est utilisé pour protéger la propriété intellectuelle (y compris les logiciels) contre la copie ou la distribution, le copyleft est utilisé pour garantir que la propriété intellectuelle et les logiciels open source peuvent être copiés ou distribués en tant que source ouverte.

Selon sa force, il existe deux types de copyleft :

• Copyleft fort : lorsque les œuvres dérivées d'autres œuvres sous licence à copyleft fort, ou liées à ces œuvres, doivent continuer à avoir des licences à copyleft fort, voire exactement la même licence. Autrement dit, ces œuvres open source ne peuvent pas être fermées à l'avenir.
• Copyleft faible : lorsque des œuvres utilisant des œuvres sous licence avec un copyleft faible, ou liées à celui-ci, peuvent être concédées sous d'autres licences, même des licences à source fermée. Dans ce cas, le copyleft n'affecte que l'œuvre originale sous licence à copyleft faible.

Il existe également des licences open source sans copyleft : elles ne se soucient tout simplement pas de l'ouverture future des logiciels dérivés.

Permissivité

Selon leur permissivité, les licences peuvent également être classées en :

• Licences strictes : lorsque vous ne pouvez pas mélanger des logiciels sous licence puissants avec des logiciels à source fermée, ou même avec des logiciels sous licence plus permissive.
• Licences permissives : lorsque les produits peuvent généralement être mélangés avec des logiciels à source fermée ou des logiciels avec une licence totalement open-source.

Habituellement, les licences à copyleft fort sont également strictes, et les licences à copyleft faible sont plus permissives, mais il n'est pas nécessaire qu'il en soit ainsi.

Différences entre les licences open source

Il existe de nombreuses licences open-source. L'Open Source Initiative en a déjà approuvé plus de 80. Certaines sont redondantes et pourraient être considérées comme équivalentes à d'autres. D'autres sont spécifiques aux intérêts de l'éditeur du logiciel (comme la licence NASA), ou à un environnement ou à un objectif donné (comme la licence Educational Community, ou l'Open Font License).

Cette prolifération de licences repose sur des termes spécifiques dans la licence qui, ajoutés aux propriétés open source de base, autorisent ou interdisent d'autres utilisations. Des exemples de ces conditions supplémentaires peuvent inclure :

• Type de copyleft : faible ou fort ou inexistant.
• Type de permissivité : permissive ou stricte.
• L'obligation d'ajouter une mention de copyright dans le code source, ou dans l'interface utilisateur.
• Octroi automatique des brevets aux licenciés.
• Considérant comme licenciés non seulement les parties à qui le logiciel est distribué, mais également les utilisateurs du logiciel (afin que les personnes utilisant un service dans le cloud utilisant ce type de logiciel open-source aient le choix de télécharger le code source de les logiciels)

Problème de mélange de code avec différentes licences

Selon ce que nous avons déjà dit auparavant, certaines licences sont permissives, permettant aux utilisateurs de combiner le code avec un code source sous licence différente (peut-être avec des conditions supplémentaires). Ce cas permettrait de mélanger ce type de logiciels sous licence open-source avec des logiciels à source fermée. Un exemple de ce type de licence est la licence MIT.

D'autres sont plus restrictifs, de sorte que le code source ne peut être combiné qu'avec du code sous licence similaire, et le résultat final doit être sous licence avec la même licence d'origine. Un exemple de ce type de licence est la licence publique générale (GPL).

Vous souhaitez peut-être combiner du code sous licence avec deux licences open source restrictives différentes. En utilisant la liberté open-source d'utiliser le logiciel comme vous le souhaitez, vous pouvez le faire. Mais le programme final ne peut pas être redistribué, car il devrait être distribué sous deux licences qui ne sont pas compatibles entre elles.

Un exemple de cette situation était ZFS. ZFS est un système de fichiers très avancé et innovant qui a été inclus dans OpenSolaris en 2005. Il s'agit d'un logiciel open source sous licence selon les termes de la licence commune de développement et de distribution (CDDL). Bien qu'il s'agisse de code open source, il ne peut pas être intégré au noyau Linux car le code source de Linux est distribué sous les termes de la licence publique générale, une autre licence open source restrictive. Les binaires du noyau Linux compilés avec le support ZFS ne peuvent pas être distribués en raison du conflit de licence.

Ces types de conflits ne peuvent être résolus que si tous les propriétaires de l'un des programmes open source s'accordent pour modifier la licence ou ajouter des conditions d'exception dans la licence du logiciel. Par exemple : de nombreux programmes sous licence GPL sont liés à la bibliothèque OpenSSL. La distribution de la bibliothèque OpenSSL est sous licence, ce qui nécessite qu'une phrase apparaisse dans le matériel publicitaire et toute redistribution. Ces conditions supplémentaires ne sont pas compatibles avec la GPL, et à cause de cela, les développeurs de produits GPL qui utilisent OpenSSL ont inclus une exception dans leur licence permettant spécifiquement la liaison avec OpenSSL.

Caractéristiques différentielles des licences Open Source

Maintenant, je vais essayer d'analyser les licences open source les plus populaires, en remarquant leurs caractéristiques différentielles, avec un petit guide sur quand les utiliser ou non. Je les ai triés du plus au moins utilisé, selon la base de connaissances Black Duck.

Licence publique générale GNU (GPL)

La GPL est la licence open source la plus populaire. Il a été créé par la FSF comme licence du projet GNU, et c'est aussi la licence du noyau Linux.

Ses caractéristiques différentielles :

• Copyleft fort.
• Licence très stricte.
• On l'appelle généralement une licence « virale » : si vous liez votre code à un autre morceau de code sous licence GPL et que vous souhaitez distribuer les résultats, l'ensemble du produit doit être sous licence GPL.
• C'est aussi une licence « englobante » : si vous développez un logiciel et que vous souhaitez le mettre sous licence GPL, vous pouvez le lier ou inclure d'autres logiciels open source tant que ce logiciel dispose d'une licence compatible avec la GPL. Il ne nécessite aucune obligation non requise par la GPL.

Habituellement, le texte de la licence utilisée inclut le texte indiquant que le logiciel est distribué selon les termes de la GPL version N (ou toute version ultérieure).

Actuellement, il existe deux versions de licence GPL en cours d'utilisation : v2 et v3. La version 3 est sortie en 2007 pour résoudre certains problèmes apparus depuis la sortie de la version 2 en 1991.

La GPL v3 comprend des clauses et des termes supplémentaires, traitant des réglementations de compatibilité avec d'autres licences open source, obligeant à octroyer des licences de brevets, définissant les conditions d'utilisation des logiciels sous licence GPL en tant que micrologiciel dans les appareils et prenant en compte des concepts tels que la gestion des droits numériques.

Licence MIT

La licence open-source généralement connue sous le nom de licence MIT, alias licence X11, est une licence non copyleft très permissive qui permet à chacun d'utiliser le code sous licence pour ce que vous voulez tant que vous conservez le message de copyright et sachez que le logiciel est livré sans garantie d'aucune sorte.

Cette licence est très populaire, et est utilisée par plusieurs projets comme le X Window System, Ruby on Rails, jQuery ou Node.js.

Il est compatible avec la GPL, vous pouvez donc mélanger du code sous licence MIT dans un logiciel GPL.

Licence Apache 2.0

La licence Apache a été créée par Apache Software Foundation (ASF) en tant que licence pour son serveur HTTP Apache.

Tout comme la licence MIT, il s'agit d'une licence non copyleft très permissive qui permet d'utiliser le logiciel à n'importe quelle fin, de le distribuer, de le modifier et d'en distribuer des œuvres dérivées sans se soucier des redevances. Sa principale différence par rapport à la licence MIT sont :

• En utilisant la licence Apache, les auteurs du logiciel accordent des licences de brevet à tout utilisateur ou distributeur du code. Ces licences de brevet s'appliquent à tout brevet qui, étant licenciable par l'un des auteurs du logiciel, serait enfreint par le morceau de code qu'il a créé.
• La licence Apache exigeait que les parties non modifiées des œuvres dérivées conservent la licence.
• Dans chaque fichier sous licence, tout avis original de droit d'auteur, de brevet, de marque ou d'attribution doit être conservé.
• Dans chaque modification de fichier sous licence, il doit y avoir une notification indiquant que des modifications ont été apportées au fichier.
• Si le logiciel sous licence Apache inclut un fichier NOTICE, ce fichier et son contenu doivent être conservés dans toutes les œuvres dérivées.
• Si quelqu'un envoie intentionnellement une contribution pour un logiciel sous licence Apache à ses auteurs, cette contribution peut automatiquement être utilisée sous la licence Apache.

Cette licence est intéressante en raison de la licence de brevet automatique et de la clause de soumission de contribution.

Il est compatible avec la GPL, vous pouvez donc mélanger le code sous licence Apache dans le logiciel GPL.

Licence BSD

Il existe 3 licences BSD différentes. Ce sont toutes des licences très permissives sans copyleft.

La licence BSD à 2 clauses (ou licence BSD simplifiée) est totalement équivalente à la licence MIT expliquée précédemment.

La licence BSD à 3 clauses (ou nouvelle licence BSD) ajoute une clause, spécifiant que ni le nom du détenteur des droits d'auteur ni les noms de ses contributeurs ne peuvent être utilisés pour approuver ou promouvoir des produits dérivés du logiciel sans autorisation écrite préalable spécifique. Cette version est compatible avec la GPL, ce qui vous permet de mélanger du code sous licence BSD à 3 clauses dans un logiciel GPL.

La licence BSD à 4 clauses (ou licence BSD originale) ajoute une autre clause, spécifiant que tous les supports publicitaires mentionnant les fonctionnalités ou l'utilisation du logiciel doivent afficher une reconnaissance indiquant que le produit comprend un logiciel développé par le détenteur des droits d'auteur. Cette licence BSD à 4 clauses n'est pas compatible avec la GPL. Le code avec cette licence ne peut pas être renouvelé selon les termes de la GPL, car la quatrième clause ajoute une exigence qui n'est pas requise dans la GPL.

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

La LGPL a été créée par la FSF en tant que modification de la GPL avec un copyleft plus faible, permettant la liaison de logiciels sous licence LGPL avec n'importe quel autre logiciel. À l'origine, LGPL signifiait "Library General Public License", mais par la suite, il a pris son nom actuel "Lesser General Public License" représentant l'opinion de la FSF selon laquelle tous les logiciels devraient être libres, et à cause de cela, la LGPL ne devrait pas être généralement utilisé.

Vous pouvez lier un code source fermé à une bibliothèque ou à un logiciel LGPL et distribuer les résultats finaux tant que :

• Vous fournissez le code source de la partie sous LGPL, avec toutes les modifications que vous y avez apportées.
• Tout utilisateur ayant suffisamment de connaissances est en mesure de remplacer la partie LGPL du programme par une version modifiée. Cela peut être fait en distribuant la partie LGPL du programme sous forme de bibliothèque dynamique (DLL sous Windows, .so sous Linux/Unix), ou en fournissant le code objet de la partie non LGPL du programme.

La LGPL v3 est compatible avec la GPLv3, vous pouvez donc saisir le code LGPLv3 dans le logiciel GPL.

Licence Artistique

La licence artistique, dans sa version actuelle 2.0, est une licence open source permissive sans copyleft similaire à la licence MIT.

La principale différence entre la licence MIT et la licence artistique est que cette dernière exige que toute modification apportée au code soit clairement indiquée.

Cette licence est presque exclusivement utilisée dans la communauté Perl.

La licence artistique 2.0 actuelle est compatible avec GPL : vous pouvez mélanger du code sous licence artistique dans un logiciel GPL.

Licence publique Microsoft (MS-PL)

La licence publique Microsoft a été créée en 2008 par cette société comme l'une des licences open source créées par leur Shared Source Initiative.

C'est une licence de copyleft stricte et faible : elle permet la création et la distribution de programmes à code source fermé avec du code MS-PL, mais elle oblige à utiliser le MS-PL comme licence des œuvres dérivées si celles-ci sont distribuées en code source.

Je pense personnellement que cette licence est un peu perverse et contraire à l'esprit de l'open-source, permettant la fermeture de code pour que d'une certaine manière le détenteur des droits se fiche de ce que vous pouvez faire avec le logiciel, mais vous ne pouvez pas partager le code pour qu'il soit mélangé avec d'autres codes sources copyleft. Donc, d'une autre manière, le détenteur des droits d'auteur se soucie vraiment de ce que vous pouvez faire, et il ne veut pas que vous utilisiez le code pour des raisons telles que l'amélioration de Linux.

Le MS-PL est incompatible avec la GPL.

Licence publique Eclipse (EPL)

La licence publique Eclipse est la licence créée par la Fondation Eclipse pour son environnement de développement intégré. Il s'agit d'une licence restrictive et à faible copyleft, similaire à bien des égards à la LGPL. Il comprend également des clauses pour l'octroi automatique de licences de brevets.

L'EPL est incompatible avec la GPL.

Licence publique Mozilla (MPL)

La version 2.0 de la licence publique Mozilla est une licence permissive à faible copyleft créée par la fondation Mozilla pour ses produits.

Nous pourrions considérer cette licence comme similaire à LGPL, mais avec la principale différence que MPL permet également la liaison statique des morceaux de code MPL dans un logiciel à source fermée.

La MPL, dans sa version actuelle 2.0 est compatible avec la GPL. Ce n'est pas vrai pour les versions précédentes de la MPL.

Licence commune de développement et de distribution (CDDL)

Le CDDL est une licence permissive à faible copyleft créée par Sun (maintenant Oracle) basée sur la version 1.1 de MPL. Fondamentalement, il a les mêmes propriétés que le MPL. Ses termes ont été clarifiés, mais pas substantiellement modifiés.

Le CDDL est la licence open-source choisie par Sun (maintenant Oracle) pour plusieurs de ses produits, comme OpenSolaris ou NetBeans, entre autres.

Comme cette licence était basée sur la MPLv1.1, cette licence n'est pas compatible avec la GPL, vous ne pouvez donc pas mélanger une source sous licence CDDL dans un logiciel sous licence GPL. Beaucoup de gens disent que c'était intentionnel, donc le code source d'OpenSolaris ne peut pas être introduit dans le noyau Linux.

Licence publique générale GNU Afero (AGPL)

L'AGPL est une version de la GPL avec un copyleft encore plus fort et plus restrictif. Elle oblige à fournir le code source de l'application non seulement aux personnes recevant une copie du logiciel, mais également aux personnes qui utilisent ce logiciel à travers un réseau informatique.

Cette licence a été créée par la FSF pour donner aux développeurs les moyens d'éviter la fermeture pratique des logiciels open source lorsqu'ils sont exécutés sur des serveurs de réseau ou dans le cloud, la GPL ne pouvant obliger les fournisseurs de services à donner le code source aux utilisateurs. . Dans ce cas, le logiciel n'est pas distribué.

L'AGPLv3 est compatible avec la GPL3. Vous pouvez mettre du code AGPLv3 dans du code GPLv3, tant que le résultat final est sous licence AGPLv3.

Licence ISC

La licence ISC est une licence de logiciel libre permissive écrite par l'Internet Software Consortium (ISC). Il est fonctionnellement équivalent aux licences BSD et MIT à 2 clauses, après avoir supprimé certains langages jugés inutiles.

Initialement utilisé pour les propres versions logicielles d'ISC, il est depuis devenu la licence préférée d'OpenBSD (à partir de juin 2003), entre autres projets.

Il est compatible avec la GPL : vous pouvez mélanger du code sous licence ISC dans un logiciel GPL.

Licence réciproque Microsoft (MS-RL)

La licence Microsoft Reciprocal a été créée en 2008 par cette société comme l'une des licences open source créées par leur Shared Source Initiative.

C'est similaire au MS-PL expliqué précédemment, mais il a un copyleft un peu plus fort, ressemblant aux conditions du LGPL, CDDL et EPL. Cela nécessite que si vous mélangez votre code avec du code source sous licence MS-RL et que vous souhaitez distribuer les résultats finaux, au moins la partie originale sous licence MS-RL doit continuer à être sous licence avec cette licence.

Il n'est pas compatible avec la GPL.

Domaine public (CC0)

Selon Wikipédia, « les œuvres du domaine public sont celles dont les droits de propriété intellectuelle ont expiré, ont été confisqués ou sont inapplicables ». En consacrant une œuvre au domaine public, l'auteur renonce à tous ses droits sur celle-ci en vertu de la loi sur le droit d'auteur.

Il existe plusieurs projets logiciels sous domaine public, par exemple SQLite, la bibliothèque qui implémente un moteur de base de données SQL simple et intégrable qui est inclus dans plusieurs autres projets, tels que les projets Mozilla, Android, etc.

Il existe de nombreuses façons de dédier un logiciel au domaine public. Creative Commons a créé le CC0 Public Domain Dedication, un moyen universel de donner une œuvre dans le domaine public. La FSF recommande d'utiliser ce texte pour dédier des logiciels au domaine public.

Les œuvres sous domaine public sont compatibles avec toutes les licences open source ou fermées et peuvent être mélangées à tout autre logiciel.

Licences multiples

Il existe des logiciels open source à double ou triple licence. Cela signifie qu'une personne qui reçoit ce logiciel à licences multiples peut choisir sous quelle licence elle souhaite le distribuer. Comme chaque licence accorde des autorisations différentes et impose des obligations différentes, une sélection doit être faite pour choisir la licence qui répond le mieux aux besoins.

C'est un cas courant pour certaines bibliothèques. Par exemple, NSS est une bibliothèque créée par Mozilla qui implémente la prise en charge SSL/TLS, entre autres fonctionnalités liées à la sécurité. Il est sous licence triple sous licences MPL, GPL et LGPL.

Veuillez choisir une licence

Beaucoup de gens publient du code sur des plateformes comme GitHub sans aucune licence écrite. Personne ne devrait utiliser ce code. Nous n'avons aucune idée des autorisations dont nous disposons pour l'utiliser. Si vous l'utilisez, vous pourriez être poursuivi pour cela. C'est comme si ces gens nous taquinaient en disant « Hé, regarde ce que j'ai fait ! Cool, n'est-ce pas ? Mais tu ne peux pas t'en servir, je voulais juste te montrer ! ».

S'il vous plaît ne soyez pas l'un d'entre eux. Si vous téléchargez votre code sur GitHub ou sur des sites publics similaires, autorisez les autres à l'utiliser et à l'améliorer. Si vous ne voulez pas trop réfléchir, voici mes recommandations :

• Si vous voulez rester simple et permissif, permettant à chacun de faire ce qu'il veut avec votre code tant qu'il vous fournit une attribution et ne vous tient pas responsable, utilisez la licence MIT.
• Si vous voulez le garder permissif, permettant à chacun de faire ce qu'il veut avec votre code mais en énumérant judicieusement les droits en vertu de la loi sur le droit d'auteur et en accordant ces droits, ainsi qu'en fournissant une concession explicite des droits de brevet des contributeurs aux utilisateurs, utilisez la licence Apache 2.0 .

• Si vous vous souciez du partage des modifications et que vous ne voulez pas que votre code soit utilisé dans des développements fermés (ni dans des produits logiciels fermés ni dans des appliances matérielles fermées), utilisez la GPL v3.

  • Si vous ne vous souciez pas de la possibilité que votre logiciel soit utilisé dans une appliance fermée, utilisez la GPL v2. Mais s'il vous plaît, utilisez la phrase "ou toute version ultérieure", afin que votre code puisse également être utilisé dans des projets GPLv3.
  • Si vous ne vous souciez pas de la possibilité que votre logiciel soit utilisé dans un logiciel fermé, tant que votre logiciel ou la partie qui l'utilise continue d'être open-source selon les mêmes conditions, utilisez la LGPL v3.
  • Si vous voulez que toute personne utilisant votre logiciel via un réseau ait le droit d'obtenir son code source, utilisez AGPL v3.

Après tout cela, vous êtes peut-être épuisé de tous ces charabia quasi-juridiques presque absurdes. Mais tu sais quoi? C'est nécessaire. Parce que sans licence, vous n'avez pas le droit d'utiliser ou de distribuer de code.