#use wml::debian::template title="Comparison des Licences de Logiciel"

<!--translation 1.6-->

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

<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 necomprennent 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 a beaucoup de gens qui
comprennent les nuances des licences et n'ont pas d'opinions fortes
sur le sujet).

<P>Au cours des années un certain nombre de licenses have 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 license 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="http://www.gnu.org/">GNU General Public License (GPL)</A>.
	<BR>
	<B>RESUME:</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
	garantie 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 commercial.
	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 commercial 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 license
	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'ammé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 License Artistique
	<A HREF="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</A>.
	<BR>
	<B>RESUME:</B> 
	<BR>
	<B>BON:</B> 
	<BR>
	<B>MAUVAIS:</B> 

<LI><A HREF="../misc/bsd.license">Les licences de type BSD</A>.
	<BR>
	<B>RESUME:</B> Les binaires et le code source doivent contenir la licence;
		la publicité doit reconnaître le travail des développeurs inscrits sur
		la license.
	<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 license. 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 driveurs pour XFree86 peut donner une
		indication, c'est que les meilleurs driveurs 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 buggés. Elles peuvent aussi gagner
		des 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.

<LI><A HREF="../misc/modified.bsd.license">La Licence BSD Modifiée</A>.
	<BR>
	<B>RESUME:</B> Exactement comme la licence BSD ci dessus sauf que la
		clause sur la publicité a été enlevée.
	<BR>
	<B>BON:</B> Avec le dévelopement des distributions Linux de grosses
		collections de logiciels sont distribuées. Selon la clause sur la
		publicité de la licence BSD tous les développeurs doivent être
		inscrit sur toutes les publicités.
		Cela devient ridicule avec l'augmentation du nombre de
		développeurs qui tend vers le millier. De ce fait beaucoup de gens
		insistent sur l'utilisation d'une version modifiée de la licence
		de type BSD sans cette clause.
</UL>

<HR>
<A name="mistakes">
Quelques erreurs fréquentes dans les licences écrites soi même:
<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 mentioné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 suffisament 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 compétiteurs n'entre sur le marché et
	le vendent à un prix plus bas.
	<BR>Note: la Licence Artistique utilise le terme `Cachet raisonnable pour
	la copie', mais elle définie 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 entrainer
	des problèmes. Combien de personnes savent où elle 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évelopement sur le code original ne
	s'interomp 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>