Comparaison des licences Open Source [Guide]

Facture: Ce guide détaillé vous donne une comparaison efficace des licences Open Source. Avec les licences Open Source expliquées ici, cela devrait vous aider à choisir la bonne licence Open Source pour votre projet.

Donc, vous travaillez sur ce nouveau projet cool pendant un moment - et vous êtes prêt maintenant à faire le mouvement critique de source fermée à open source.

Il ne semble pas beaucoup plus de travail que de nettoyer les sources et l'historique des commit avant de pousser votre dépôt sur GitHub or bitbucket... ... jusqu'à ce que la question de la licence apparaisse. Il y a tellement de choix disponibles. Lequel choisir? Et est-ce que tu vraiment besoin d'une licence après tout?

La réponse courte à cette dernière question est facile: oui, vous vraiment besoin d'une licence. En ce qui concerne la licence dont vous avez besoin, je peux même faire une réponse plus courte: elle dépend.

Mais si vous êtes sérieux au sujet de votre projet, vous voulez probablement un peu plus de détails. Alors lisez en avant - et souvenez-vous: vous entrez maintenant dans le territoire de la guerre sainte!

Ai-je besoin d'une licence? Et qu'est-ce qu'une licence après tout?

Une licence est un officiel permission accordée par le propriétaire de certains travaux (le «concédant») à d'autres personnes (le «détenteur de licence») et régissant la façon dont le détenteur de la licence est autorisé à utiliser le travail du concédant.

Cela prend la forme d'un contrat, les deux parties doivent être d'accord avec. De nos jours, l'acceptation est plutôt implicite: juste par en utilisant un peu de travail, vous êtes réputé être d'accord avec sa licence d'utilisation.

Juste pour faire savoir clairement, lorsque vous libérez votre propre travail, le concédant est accompagner. Et le licencié, personne en utilisant votre code. De manière générale, cela comprend deux catégories principales: mobiles et les utilisateurs finaux.

Et pour résoudre quelques termes de vocabulaire supplémentaires, par modification votre travail, un titulaire de licence crée ce qu'on appelle un travail dérivé. Tous les permis ne sont pas d'accord si le utilisé de votre travail dans un travail plus important qualifiera ce dernier comme un travail dérivé ou non. Comme vous le verrez ci-dessous, certaines licences traitent spécifiquement de ces problèmes.

Quel est le but de la licence?

Fondamentalement, la Licence est un moyen pour le Concédant et le Licencié de convenir du droits et obligations of tous les deux d'eux. Ces droits et obligations associés à une licence peuvent être quelque chose - dans la mesure de ce qui est permis par la loi. Par exemple, un concédant de licence pourrait exiger que la titulaire cite son nom lorsqu'elle utilise son travail. Ou peut autoriser à copier son travail, mais ne pas le modifier de quelque façon que ce soit. Ou même exiger que le travail dérivé soit publié selon les mêmes conditions que l'œuvre originale.

D'un autre côté, la Licence est un moyen de protéger le Licencié aussi. En indiquant clairement comment il peut utiliser votre travail, il ne risque pas de vous voir demander de façon inattendue des redevances ou une autre forme de compensation pour avoir utilisé votre travail. Quelque chose qui est critique pour votre adoption de travail.

Ainsi, la licence protégera votre travail. Protègera le concédant. Mais vous protégera aussi. Je veux dire toi, personnellement. Par exemple en limitant la responsabilité du Concédant pour les dommages potentiels causés par son travail.

Et si je n'utilise aucune licence?

En l'absence d'une licence explicitement associée à une œuvre, le droit d'auteur "par défaut" pour la juridiction de l'auteur s'applique. En d'autres termes, n'allons jamais Considérez l'absence de licence comme une concession implicite pour nous de faire ce que nous voulons avec votre travail. C'est exactement le contraire: sans licence spécifique, vous, l'auteur, n'avez renoncé à AUCUN de vos droits tels qu'accordés par la loi.

Mais rappelez-vous toujours qu'une licence régit les droits et obligations. Vous êtes-vous déjà demandé pourquoi tant de textes de Licence contenaient un avertissement écrit dans TOUTES LES LETTRES DE MAJUSCULES à propos des garanties fournies avec un produit - ou plus souvent l'absence de garantie? C'est à protéger le propriétaire du travail contre les garanties implicites ou les suppositions de l'utilisateur. La dernière chose que vous voulez est d'être poursuivi en conséquence de la libération de votre travail open-source!

Puis-je utiliser une licence personnalisée?

Oui, vous pouvez. Mais vous ne devriez probablement pas.

En tant que contrat, une licence ne peut pas (dans la plupart des juridictions? Tous) avoir préséance sur les lois territoriales. D'où la difficulté de faire respecter les droits de licence dans un monde globalisé. Il serait probablement plus facile (je veux dire, moins difficile) de défendre une licence "standard" devant un juge. En fait, de tels cas ont déjà été défendus dans plusieurs juridictions et peuvent être cités comme précédents. Évidemment, quelque chose qui ne peut pas être fait avec une licence personnalisée.

En plus, les licences personnalisées (parfois surnommées Vanity Licences) peut créer des incompatibilités avec d'autres licences, résultant en une mauvaise compatibilité de votre travail légalement parlant.

Puis-je utiliser plusieurs licences?

Oui. La multi-licence - notamment la double licence - n'est pas si rare. Cela est particulièrement vrai lorsque vous voulez construire une entreprise autour de votre travail gratuit. Dans ce cas, votre projet sera probablement publié sous licence FOSS et une licence commerciale.

Une autre utilisation de la multi-licence est d'augmenter la compatibilité, en permettant à votre travail d'être combiné avec des travaux publiés sous des termes différents ou pour satisfaire différents besoins ou exigences des utilisateurs. C'est une raison pour laquelle certains projets sont publiés sous plusieurs licences de logiciels libres.

Mais attention: toutes les licences ne sont pas compatibles entre elles! Encore une fois, je vous déconseillerais de réinventer la roue en restant avec des licences compatibles bien connues si vous voulez aller dans ce sens.

Puis-je changer la licence "plus tard"?

Oui. Le détenteur des droits d'auteur est responsable des conditions de licence. Il est plutôt facile de changer la licence tant que vous êtes le seul contributeur. Mais pour prendre un exemple extrême, si Linus Torvald voulait lancer le noyau Linux sous une licence différente, il aurait probablement besoin d'abord de l'accord des milliers de contributeurs à ce projet. Quelque chose d'impossible en pratique.

Pour un projet de taille plus raisonnable, cela peut être fait. Et en fait, c'était comme vous le verrez dans quelques exemples ci-dessous.

Quelle licence Open Source devrais-je utiliser?

Ok, maintenant, vous êtes convaincu que vous devriez utiliser une licence standard. Mais Lequel choisir? Le choix final dépend de vous. Et il y a des comparateurs très bien faits disponibles sur le web pour vous aider dans votre choix. Juste pour citer mes favoris:

Mais comme toujours avec les affaires juridiques, la réponse définitive sera de lire - et comprendre - le texte faisant autorité de la licence. Cela peut nécessiter l'aide d'un avocat professionnel. Quelque chose que je ne suis pas.

Mais ce que je peux faire est de vous fournir une introduction aux licences les plus courantes afin de guider vos premiers pas.

GNU General Public License (GPL)

La GPL est l'une des licences Open Source les plus populaires. Il existe plusieurs versions - mais pour un nouveau projet, vous devriez considérer le plus récent, qui est le GPL 3 au moment de cette écriture.

Soutenir un fort copyleft, la GPL est probablement la licence de logiciel libre la plus protectrice. Quelque chose qu'il peut être loué ou critiqué pour dépendre de votre point de vue. Le concept de base derrière la GPL étant tous Les travaux dérivés doivent également être libérés sous licence GPL.

Fort copyleft
L'œuvre convient à un usage commercial.
Les titulaires de licence peuvent modifier le travail.
Les détenteurs de licence doivent libérer la source en même temps que le travail dérivé.
Les travaux dérivés doivent être libérés selon les mêmes termes.

Projets populaires

La GPL est la licence naturelle pour les projets de la Free Software Foundation. Incluant le Outils GNU au cœur de tout système Linux. Grands projets - a fortiori commerciaux - ont tendance à utiliser la licence GPL conjointement avec une ou plusieurs autres licences.

Inkscape (Dessin vectoriel): GPLv2
Drupal (Système de gestion de contenu Web): GPLv2
MariaDB (Bases de données): GPL v2
MySQL (Bases de données): GPL et licence commerciale
Qt (framework d'application multiplate-forme): LGPL, GPL et Commercial - en fonction des modules et du niveau d'accord de service

Licence Publique Générale Limitée GNU (LGPL)

La GPL est très restrictive dans la mesure où elle oblige tout travail dérivé à être publié en open-source sous les mêmes termes. Ceci est particulièrement important pour les bibliothèques - qui sont des blocs de construction pour des logiciels plus importants: en libérant une bibliothèque sous la GPL, vous forcez toute application en utilisant cette bibliothèque à être publié en tant que GPL aussi. Quelque chose que la LGPL adresse.

Pour les bibliothèques, le FSF distingue trois cas:

Votre bibliothèque implémente une norme qui est en concurrence avec une norme non-libre. Dans ce cas, une large adoption de votre bibliothèque aidera la cause du logiciel libre. La FSF suggère la licence Apache assez permissive pour ce cas (décrit plus loin dans cet article).
Votre bibliothèque implémente une norme déjà implémentée par d'autres bibliothèques. Dans ce cas, il n'y a aucun avantage pour le Logiciel Libre à abandonner entièrement le copyleft. Donc, la FSF recommande la LGPL.
Enfin, si votre bibliothèque ne pas rivaliser avec d'autres bibliothèques ou d'autres normes, la FSF recommande la GPL.

Les arguments de la FSF sont pour la plupart éthiques et philosophiques. En pratique, les développeurs peuvent avoir d'autres préoccupations. Surtout si elles envisagent de développer une entreprise basée sur le travail sous licence. Encore une fois, la double licence peut être une option à considérer.

Faible copyleft (lié à la bibliothèque liée dynamiquement)
L'œuvre convient à un usage commercial.
Les titulaires de licence peuvent modifier le travail.
Les détenteurs de licence doivent libérer la source en même temps que le travail dérivé.
si tu modifier le travail, vous doivent libérer l'œuvre modifiée selon les mêmes termes.
si tu utilisé l'Œuvre, vous n'avez pas besoin de libérer l'Œuvre Dérivée sous les mêmes termes.

Projets populaires

OpenOffice.org 3 (suite bureautique): LGPLv3 - mais Apache OpenOffice 4 est passé à la licence Apache 2.0.
GTK +, la boîte à outils GIMP (Boîte à outils GUI): LGPLv2.1
CUPS (système d'impression multi-plateforme): GPL ou LGPLv2 avec une exception pour les systèmes d'exploitation Apple - en fonction des composants.
WineHQ (Windows couche de compatibilité): LGPLv2.1
GNU Aspell (Vérificateur d'orthographe): LGPLv2.1

Licence publique Eclipse (EPL 1.0)

Avec un copyleft plus faible que la LGPL, la licence Eclipse est plus favorable aux entreprises car elle permet la sous-licence et la construction de logiciels en EPL et en code non-EPL (même propriétaire), à condition que le code non-EPL soit un "Module (s) séparé (s) de logiciel".

En outre, l'EPL ajoute une protection supplémentaire aux contributeurs de code EPL dans le cas de poursuites / dommages causés par une offre commerciale incluant cette œuvre.

Faible copyleft (lié au "module" du logiciel)
L'œuvre convient à un usage commercial.
Les titulaires de licence peuvent modifier le travail.
Si vous modifier le travail, vous doivent libérer l'œuvre modifiée selon les mêmes termes.
Si vous utilisé l'Œuvre, vous n'avez pas besoin de libérer l'Œuvre Dérivée sous les mêmes termes.
Les distributeurs commerciaux du logiciel doivent défendre ou indemniser les contributeurs originaux d'EPL contre les poursuites / dommages causés par l'offre commerciale.

Projets populaires

Évidemment, l'EPL est la licence naturelle pour les projets de la Fondation Eclipse. Y compris l'IDE Eclipse populaire. Mais il a gagné une certaine popularité au-delà de cela - en particulier dans le monde de Java:

Clojure (Langage de programmation)
Graphviz (Paquet de visualisation graphique)
Jetty (Serveur d'application): double licence EPL1.0 / Licence Apache 2.0 depuis Jetty 7
JUnit (Framework de test d'unité Java)

Licence publique Mozilla (MPL)

La licence publique Mozilla est une licence utilisée pour un logiciel développé par la fondation Mozilla. Mais ce n'est certainement pas limité à cette zone. Le MPL vise à être une étape de compromis entre des licences strictes (comme la licence GPL) et des licences permissives (comme la licence MIT).

Dans la MPL, "l'unité de licence" est le fichier source. Les concédants ne sont pas autorisés à restreindre les droits de l'utilisateur et l'accès à tout fichier couvert par la MPL. Mais le même projet peut également contenir des fichiers sous licence propriétaires non-MPL. Le projet résultant peut être libéré sous n'importe quelle licence, à condition que l'accès aux fichiers sous licence MPL soit accordé.

Faible copyleft (lié à des fichiers individuels)
L'œuvre convient à un usage commercial.
Les titulaires de licence peuvent modifier le travail.
Les titulaires de permis doivent fournir une attribution appropriée pour le travail.
Les titulaires de licence peuvent redistribuer des travaux dérivés selon des termes différents
Les titulaires de licence ne peuvent pas attribuer de licence à une source sous licence MPL
Les détenteurs de licence doivent distribuer le code source sous licence MPL avec leur travail dérivé.

Projets populaires

Mozilla Firefox (navigateur Web), Mozilla Thunderbird (client de messagerie): MPL
LibreOffice (suite bureautique): MPL2.0
Moteur de base de données H2 (base de données): MPL2.0 et Eclipse License 1.0
Caire (Moteur graphique 2D): MPL 1.1 ou LGPLv2.1

Licence Apache 2.0 (ASL 2.0)

Avec l'ASL, nous entrons dans le royaume de permissif licences gratuites. Mais même la FSF suggère la licence Apache dans certains cas. La licence Apache est permissive car elle ne nécessite pas tous Les travaux dérivés doivent être distribués selon les mêmes termes. En d'autres termes, il s'agit d'une licence non-copyleft.

L'ASL est la seule licence utilisée pour les projets de la Fondation Apache Software. Étant considéré comme favorable aux entreprises, il a été largement adopté en dehors de cette organisation. Il n'est pas rare de voir des projets d'entreprise être publiés sous l'ASL.

Non-copyleft
L'œuvre convient à un usage commercial.
Les titulaires de licence peuvent modifier le travail.
Les titulaires de permis doivent fournir une attribution appropriée pour le travail.
Les titulaires de licence peuvent redistribuer des travaux dérivés sous des termes différents.
Les détenteurs de licence n'ont pas à distribuer le code source en même temps que leur travail dérivé.

Projets populaires

Android (système d'exploitation): ASL 2.0 avec quelques exceptions (notamment en ce qui concerne le noyau Linux)
Apache httpd (Serveur Web): ASL 2.0
Apache Spark (Cadre informatique de cluster): ASL 2.0
Cadre de printemps (Framework pour les applications d'entreprise basées sur Java): ASL 2.0

MIT License

Celui-ci est une licence très populaire. Même probablement le plus populaire. En mettant très peu de restrictions sur la réutilisation, la licence MIT peut facilement être associée à d'autres licences, de la licence GPL aux licences propriétaires.

Non-copyleft
L'œuvre convient à un usage commercial.
Les titulaires de licence peuvent modifier le travail.
Les titulaires de permis doivent fournir une attribution appropriée pour le travail.
Les titulaires de licence peuvent redistribuer des travaux dérivés selon des termes différents
Les détenteurs de licence n'ont pas à distribuer le code source en même temps que leur travail dérivé.

Projets populaires

node.js (Environnement d'exécution JavaScript): licence MIT
jQuery (bibliothèque JavaScript côté client): Licence MIT (jusqu'à 2012, MIT / GPL à double licence)
Atome (éditeur de texte): MIT License
AngularJS (Framework d'application JavaScript): MIT License
SQLAlchemy (Boîte à outils SQL et Object Relational Mapper pour Python): Licence MIT

Licences BSD

La licence BSD est disponible en trois versions. La licence originale à 4 clauses, la licence à 3 clauses «révisée» et la licence à 2 clauses «simplifiée». Tous dans l'esprit sont très proches de la licence MIT. Et en effet, il y a très peu de différences pratiques entre la licence BSD à 2 clauses et la licence MIT.

Les licences BSD pour les clauses 3 et 4 ajoutent d'autres exigences concernant la réutilisation des noms et la publicité. C'est quelque chose à considérer si vous voulez protéger votre produit ou votre nom de marque.

Non-copyleft
L'œuvre convient à un usage commercial.
Les titulaires de licence peuvent modifier le travail.
Les titulaires de permis doivent fournir une attribution appropriée pour le travail.
Les titulaires de licence peuvent redistribuer des travaux dérivés sous des termes différents.
Les détenteurs de licence n'ont pas à distribuer le code source en même temps que leur travail dérivé.
Les titulaires de licence ne peuvent pas utiliser le nom d'auteur ou la marque de commerce originale pour endosser le travail dérivé (3- et 4- clause BSD)
Les titulaires de licence doivent reconnaître l'auteur original dans tous les documents publicitaires mentionnant des fonctionnalités ou l'utilisation de l'œuvre (clause 4 BSD)

Projets populaires

Django (trame web): 3-clause BSD
Redis (magasin de données): 3-clause BSD
Ruby (langage de programmation): clause 2 BSD et licence personnalisée
Nginx (Serveur Web): 2-clause BSD
NetBSD (Système d'exploitation): 2-clause BSD - 4-clause BSD jusqu'à 2008

Le dernier mot sur les licences Open Source

Si vous venez aussi loin, félicitations! Vous le comprenez maintenant, licence est vraiment énorme et sujet complexe. Mais cela vaut la peine de prendre le temps de choisir la bonne licence pour votre projet - et de faire ce choix tôt. Cela pourrait vous épargner beaucoup de problèmes plus tard, de sorte que vous pouvez utiliser votre temps et votre énergie pour travailler sur votre projet plutôt que de faire face à des problèmes de copyright ou de compatibilité légale.

Même si j'ai fait de mon mieux pour rendre ce sujet accessible, il n'est pas toujours facile de résumer les subtilités des diverses licences. Et au-delà des quelques licences majeures présentées ici, il y a des dizaines d'autres plus ou moins couramment utilisés.

Alors, n'hésitez pas à utiliser la section des commentaires ci-dessous pour nous dire ce qui est YOUR licence préférée et pourquoi. Ou pour mentionner quelques caractéristiques importantes que j'ai pu oublier!

Source

Comparaison des licences Open Source [Guide]