Comparaison des Licences de logiciel

******Ce document est en cours de développement*******

Les gens qui évoluent autour du Logiciel ouvert ont tendance à développer une opinion très forte au sujet des licences. Les débutants ne s'en soucient guère tant qu'ils sont plus concernés par la fin du travail en cours et ne comprennent pas les implications à long terme du choix pour un logiciel d'une licence plutôt qu'une autre (il est douteux de penser qu'il y ait beaucoup de gens qui comprennent les nuances des licences et n'aient pas d'opinions fortes sur le sujet).

Au cours des années un certain nombre de licences ont gagné de l'importance en donnant aux auteurs de logiciels le type de contrôle sur leurs créations que la plupart d'entre eux désiraient. Il est encore courant de trouver du logiciel qui n'a pas de copyright visible ou qui contient une unique licence développée par son auteur. Ce dernier cas peut être assez ennuyeux pour les distributeurs de logiciel (à la fois en ligne et ceux créant des CD) car beaucoup de ces licences contiennent des erreurs courantes qui rendent le logiciel difficile à distribuer.

Ce qui suit est une liste des licences les plus courantes de Logiciel libre (ouvert) et pour chacune quelques-uns de leurs bons et mauvais côtés. Seuls les points de la licence intéressants pour la discussion sont donnés. De plus, beaucoup de points sont placés sous le simple titre « BON/MAUVAIS ». Ce sont des points qui peuvent être bons ou mauvais, selon le point de vue duquel on se trouve.

La GNU General Public License (GPL) (Licence publique générale GNU).
Résumé : le code source doit être rendu disponible ; le logiciel peut être vendu ; les travaux dérivés doivent utiliser la même licence.
Bon : il y a de bonnes raisons pour lesquelles c'est la licence la plus utilisée pour le Logiciel libre (ouvert). Elle permet une bonne protection des droits des développeurs de logiciel et la disponibilité du code source garantit que les utilisateurs n'auront pas à se soucier de perdre le support dans le futur.
Bon/mauvais : le logiciel distribué en utilisant la GPL ne peut être incorporé dans du logiciel propriétaire. La question de savoir si c'est en fait une bonne chose dépend de votre point de vue. Les gens qui développent du logiciel propriétaire se sentent souvent frustrés quand il y a une solution disponible qui ne peut être utilisée à cause de conflits de licences. Bien sûr, rien ne les empêche de contacter l'auteur et de voir s'ils peuvent acheter une version utilisant une licence différente. La plupart des gens qui distribuent du logiciel avec la GPL ne considèrent pas ces restrictions comme mauvaises, parce que cela permet aux autres d'utiliser et d'améliorer le logiciel alors que cela empêche (en pratique) les autres de se faire de l'argent à partir de leur dur travail sans leur permission.
La Licence artistique http://language.perl.com/misc/Artistic.html.
Résumé :
Bon :
Mauvais :
Les licences de type BSD.
Résumé : les binaires et le code source doivent contenir la licence ; la publicité doit reconnaître le travail des développeurs inscrits sur la licence.
Bon/mauvais : les entreprises qui veulent qu'un exécutable soit largement disponible (éventuellement gratuitement) sans publier le code source utilisent souvent cette licence. Un bon exemple est une entreprise qui veut distribuer un pilote de carte graphique. Les avocats du logiciel « Open Source » préféreraient de toute façon que l'entreprise distribue les spécifications matérielles. Si le développement des pilotes pour XFree86 peut donner une indication, c'est que les meilleurs pilotes sont ceux écrit avec le code source disponible. Les entreprises n'arrivent qu'à faire apparaître comme mauvais leurs produits en distribuant des pilotes propriétaires qui sont lents et bogués. Elles peuvent aussi gagner sur les coûts de développement en laissant les autres développer les pilotes pour eux.
Bon/mauvais : n'importe qui peut récupérer le source, le modifier, et distribuer le résultat sans rendre public les changements. Trouver cela bon ou mauvais est une question de préférence personnelle.

Quelques erreurs fréquentes dans les licences écrites soi-même :

Soit ne pas permettre, ou restreindre les ventes du logiciel à but lucratif. Cela rend difficile la distribution du logiciel sur CD. Les gens font souvent l'erreur d'utiliser des termes qui ne sont pas bien définis, comme un « coût raisonnable ». Il vaut mieux simplement utiliser une des licences mentionnées ci-dessus car elles reviennent au même sans avoir recours à de telles phrases. Par exemple, en permettant à n'importe qui de distribuer le logiciel, la GPL maintient les prix suffisamment bas grâce aux forces naturelles du marché. Si quelqu'un vend un CD avec une grosse marge il ne faudra pas attendre longtemps avant que des concurrents n'entrent sur le marché et le vendent à un prix plus bas.
Remarque : la Licence Artistique utilise le terme « Cachet raisonnable pour la copie », mais elle définit ce terme pour essayer de le rendre moins vague.
Ne pas permettre la distribution de versions modifiées du logiciel. Cela empêche la distribution du logiciel par certains groupes. Par exemple, depuis que Debian distribue des logiciels compilés, il est souvent nécessaire de modifier le code source pour le compiler ou pour le rendre compatible avec la FSSTND. Mais en faisant cela, nous n'avons alors pas le droit de le distribuer.
Obliger à ce que tous les changements soient rapportés à l'auteur. Bien que ce soit une bonne idée de rapporter à l'auteur les modifications/améliorations afin qu'elles puissent être plus largement distribuées, l'obliger peut entraîner des problèmes. Combien de personnes savent où elles seront dans 5 ans ? Modifiez cela en « Les modifications au logiciel devraient être rapportées à l'auteur ». La plupart des gens le feront.
Cette clause est habituellement inclue pour empêcher que des projets sous-branche se développent. L'histoire a montré que, tant que le développement sur le code original ne s'interrompt pas, les sous-branches n'auront du succès que si une autre force motive la séparation.
Déclarer que le logiciel est dans le domaine public, mais ensuite ajouter des contraintes (comme le fait de ne pas autoriser la vente à but lucratif). Soit une chose est dans le domaine public soit elle ne l'est pas — il n'y a pas de milieu. De telles licences n'ont aucun sens et il est probable que les conditions supplémentaires ne tiendront pas devant un tribunal.