fsfe-france
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fsfe-france] Emacs21 & GFDL (was: Free Software Magazine)


From: Loic Dachary
Subject: [Fsfe-france] Emacs21 & GFDL (was: Free Software Magazine)
Date: Sun, 13 Jan 2002 12:59:32 +0100

Denis Barbier writes:

 > Bon, alonzo.
 > Of course IANAL and je ne connais rien au monde de l'édition, donc il ne
 > faut pas prendre ce que je raconte pour argent comptant.
 > 
 > Tout d'abord, mettons les choses au clair, quelle est donc la licence de la
 > doc d'Emacs ? Pour celà, c'est très simple, je tape « info emacs » pour
 > en avoir le coeur net et ... merde, pas d'emacs.

        Sur la Debian GNU/Linux unstable c'est dans le package emacs21
(/usr/share/info/emacs-21/). Quelle distribution utilises-tu ? 

 > Il existe donc des sections invariantes qui sont désignées comme telles
 > dans la notice indiquant que cette documentation est sous cette licence.
 > À partir de là, je me demande donc quelles sont ces sections

        Les notices de licence sont incluses dans la version
transparente (source) mais pas dans la version opaque (binaire). Je
suis d'accord avec toi qu'il serait plus pratique d'inclure une
information dans la documentation à ce propos, même si ce n'est pas
une obligation légale. Un patch ?

 > invariantes. Après 3 tours de la doc, je dois me rendre à l'évidence,
 > nada, rien. Je reviens sur la FDL, et c'est bizarre parce que dans
 > l'addendum ils expliquent comment rédiger une notice de copyright,
 > mais ce manuel en est dépourvu. Déjà premier malaise.

        La notice de licence et de copyright doit se trouver dans les
versions transparentes (source), pas dans les versions opaques (binaire).
Comme pour les logiciels, en fait.

 > L'idée logique est alors d'aller regarder dans les sources. Et là, il
 > faut le vouloir pour trouver des infos sur ces sections invariantes.

        Je pense que c'est un problème d'habitude ou de mauvaise compréhension
du mécanisme d'application des licences. Si quelqu'un sait que dans un
logiciel ou une documentation tu as 1) la licence, 2) la notice de copyright,
3) la notice de licence et que dans la plupart des cas 1) est un fichier à
part, 2) et 3) se trouvent en tête de chaque fichier source, tu localise
la notice de licence rapidement et tu trouves les sections invariantes.

        Je pense qu'inclure une information à ce propos dans la documentation
elle même évite de se poser ces questions.

 > 1) Section VERBATIM COPYING :
 >    You may copy and distribute the Document in any medium, either
 >    commercially or noncommercially, provided that this License, the
 >    copyright notices, and the license notice saying this License applies
 >    to the Document are reproduced in all copies [...]
 > 
 > Il faut distribuer etc/gfdl.1 ou man/doclicense.texi ?

        Peu importe.

 > Si les sources du manuel incluaient un fichier COPYING, ça serait plus
 > simple.
 
        Vrai.

 > condition « free of added material » me fait tiquer, est-ce que les 84Mo
 > (non compressés) de fichiers des sources qui ne composent pas le manuel
 > n'enfreignent pas cette condition ? 

        Non, dans la mesure ou le package contient aussi la version
transparente (source). La distribution opaque (binaire) est accompagnée de
la version transparente. Tu disposes des deux, donc cela remplit la condition

        ... you must either include a
            machine-readable Transparent copy along with each Opaque copy ...

        et n'oblige pas à mettre à disposition une version "free of added
material". On parle ici du tarbal disponible sur ftp.gnu.org.

 > Moui, ça n'a pas l'air pratique tout ça. Comment ils font les
 > distributeurs de paquets ? J'ai jeté un oeil dans le paquet Debian,
 > et j'ai l'impression qu'ils ne distribuent que le format info.

        Exact.

 > Ça veut donc dire qu'ils fournissent un lien vers les sources du manuel
 > (en considérant que les 84Mo de fichiers non nécessaires ne contredisent
 > pas le « free of added material »). Et ils s'assurent que ce lien
 > restera valide pendant un an. J'aimerai bien savoir comment ils font.

        Effectivement, Debian viole dans ce cas la clause "free of
added material". Par ailleurs, ils ne garantissent pas la pérénité de
1 an.  Peut-être souhaites-tu discuter avec le packageur de Debian
pour qu'il remédie à cela ? Il faut sans doute aussi faire en sorte
que tous les packages contenant des docs FDL soient soigneux de ce
point de vue.

        L'utilité pratique de tout cela n'est pas grande, mais l'aspect
didactique est très important. Cela montre le bon exemple. En effet, si
un éditeur de livres procède de la même façon et fait disparaitre les 
URL contenant la version transparente au bout d'un mois, il aura alors
beau jeu de dire que personne ne se conforme à cette clause, y compris
Debian qui est censé être rigoureux et clair.

 > Donc il ne faut pas toucher aux sections invariantes, d'où leur nom.
 > C'est ce qui a engendré une discussion interminable sur debian-legal,
 > est-il acceptable d'avoir des morceaux qu'on ne peut pas modifier ?
 > Je trouve pour ma part que ce n'est pas acceptable, et espère voir
 > la doc d'Emacs rejetée dans la section non-free de Debian pour cette
 > raison.

        Une section invariante ne peut être que "secondaire", i.e. ne
traitant pas du sujet du document lui même. Je le précise parceque
c'est un point souvent oublié. Je retourne la question : est-il
possible de concevoir une licence de documentation en se passant de
cet aspect ?  Je ne crois pas. Evidement, les sections invariantes,
même secondaires, peuvent être un emmerdement constant si elles
contiennent des textes qui sont inacceptables pour une raison une
autre. De ce point de vue on est dans une zone de flou ou il n'existe
pas aujourd'hui de solution absolument satisfaisante.

        C'est un peu comme le problème avec la licence Zend, qui est
libre mais chiante. On ne sait pas tracer une frontière qui dirait que
la licence de Zend n'est pas libre pour de bonnes raisons. De la même
façon, une documentation contenant des invariants, certes secondaires,
mais chiants pourraient rendre une documentation difficilement
re-exploitable dans les faits. 

 > Voici quelques-uns des problèmes que cela engendre :
 >   - la page http://www.gnu.org/philosophy/bsd.html explique
 >     pourquoi la clause de publicité de la licence BSD originale
 >     entraine des problèmes pratiques, chacun y allant de sa
 >     publicité ; c'est exactement la même chose ici, chacun peut
 >     rajouter une section qui ne peut pas être enlevée ;

        Oui. A la petite différence que tu n'es pas obligé d'ajouter une
section invariante. Mais je comprends le point.

 >   - les traductions doivent conserver les sections invariantes
 >     inchangées ;

        Oui.

 >   - pour du logiciel libre, avoir une partie du texte qui ne peut être
 >     ni modifiée ni enlevée, ça gêne aux entournures.

        Les Logiciels Libres contiennent déjà des sections invariantes ...
la licence et les notices de copyright ;-) Mais bon, c'est de l'ergotage.
Ton troll me fait réfléchir sur les sections invariantes et leurs dérives
possibles. Tu as un pointeur sur le thread de debian-legal qui parle de tout
ça ?

        A++,

-- 
Loic   Dachary         http://www.dachary.org/  address@hidden
12 bd  Magenta         http://www.senga.org/      address@hidden
75010    Paris         T: 33 1 42 45 07 97          address@hidden
        GPG Public Key: http://www.dachary.org/loic/gpg.txt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]