#use wml::debian::template title="Comparaison des Licences de logiciel"

#use wml::debian::translation-check translation="a2d057aa44562ddcc643379de20b7fc2c0c7f9e4" translation_maintainer="Christian Couder"


<P><STRONG>******Ce document est en cours de développement*******</STRONG>

<P>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).

<P>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
<A HREF="#mistakes">erreurs courantes</A> qui rendent le logiciel
difficile à distribuer.

<P>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.

<UL>
<LI>La <A HREF="https://www.gnu.org/">GNU General Public License (GPL)</A>
(Licence publique générale GNU).
	<BR>
	<B>Résumé :</B> le code source doit être rendu disponible ; le logiciel
	peut être vendu ; les travaux dérivés doivent utiliser la même licence.
	<BR>
	<B>Bon :</B> 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.
	<BR>
	<B>Bon/mauvais :</B> 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. 

<LI>La Licence artistique
	<A HREF="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</A>.
	<BR>
	<B>Résumé :</B> 
	<BR>
	<B>Bon :</B> 
	<BR>
	<B>Mauvais :</B> 

<LI><A HREF="https://opensource.org/licenses/BSD-3-Clause">Les licences de type BSD</A>.
	<BR>
	<B>Résumé :</B> les binaires et le code source doivent contenir la 
		licence ; la publicité doit reconnaître le travail des 
		développeurs inscrits sur la licence.
	<BR>
	<B>Bon/mauvais :</B> 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.
	<BR>
	<B>Bon/mauvais :</B> 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.
</UL>

<HR>

<P><A NAME="mistakes">Quelques erreurs fréquentes dans les licences écrites 
soi-même</A> :
<UL>
<LI>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.
	<BR>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.
<LI>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
	<A HREF="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/">FSSTND</A>.
	Mais en faisant cela, nous n'avons alors pas le droit de le distribuer.
<LI>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.
	<BR>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.
<LI>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.
</UL>