This file is indexed.

/usr/share/doc/HOWTO/fr-html/Software-Release-Practice-HOWTO.html is in doc-linux-fr-html 2013.01-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.69">
<title>HOWTO sur la publication de logiciels</title>
</head>
<body>
<h1>HOWTO sur la publication de logiciels</h1>
<h2>Eric S. Raymond &lt;esr@thyrsus.com&gt; Traduction par Thierry
B&eacute;zecourt &lt;thbzcrt@worldnet.fr&gt;</h2>
2.4, 12 juillet 2000
<hr>
<em>Ce HOWTO d&eacute;crit des m&eacute;thodes de publication de
logiciel convenant &agrave; des projets de logiciel libre pour
Linux. En adoptant ces r&egrave;gles, vous permettrez &agrave; vos
utilisateurs de compiler votre code et de l'utiliser plus
facilement, et &agrave; d'autres d&eacute;veloppeurs de mieux le
comprendre et de vous aider &agrave; l'am&eacute;liorer. Ce
document est &agrave; lire absolument par les d&eacute;veloppeurs
d&eacute;butants. Ceux qui ont plus d'exp&eacute;rience devraient
le parcourir &agrave; nouveau au moment de publier un nouveau
projet. Il sera mis &agrave; jour p&eacute;riodiquement afin de
refl&eacute;ter l'&eacute;volution des r&egrave;gles de bonne
pratique.</em>
<hr>
<h2><a name="s1">1. Introduction</a></h2>
<h2><a name="ss1.1">1.1 Raison d'&ecirc;tre de ce document</a></h2>
<p>Un vaste ensemble de traditions relatives au
d&eacute;veloppement de logiciels libres permet &agrave; d'autres
personnes de porter le code plus facilement, de l'utiliser et de
participer &agrave; son d&eacute;veloppement. Certaines de ces
conventions sont des traditions du monde Unix ant&eacute;rieures
&agrave; Linux ; d'autres ont &eacute;t&eacute; suscit&eacute;es
r&eacute;cemment par l'apparition de nouveaux outils et de
nouvelles technologies comme le World Wide Web.</p>
<p>Ce document vous aidera &agrave; acqu&eacute;rir ces
r&egrave;gles d'usage. Il se compose de plusieurs sections
th&eacute;matiques, chacune contenant une liste de points &agrave;
v&eacute;rifier. Consid&eacute;rez que ces sections sont pour votre
distribution comme la liste de contr&ocirc;le qu'un pilote d'avion
v&eacute;rifie avant le d&eacute;collage.</p>
<h2><a name="ss1.2">1.2 Nouvelles versions de ce document</a></h2>
<p>Ce document sera envoy&eacute; chaque mois dans le forum de
discussion <code>comp.os.linux.answers</code> . Ce document est
archiv&eacute; sur plusieurs sites FTP Linux, dont
<code>metalab.unc.edu</code> dans le r&eacute;pertoire
<code>pub/Linux/docs/HOWTO</code>.</p>
<p>Vous pouvez aussi voir la derni&egrave;re version, en anglais,
de ce HOWTO sur le World Wide Web &agrave; l'URL <a href=
"http://www.linuxdoc.org/HOWTO/Software-Release-Practice.html">http://www.linuxdoc.org/HOWTO/Software-Release-Practice.html</a>.
La version fran&ccedil;aise est disponible &agrave; l'adresse
<a href=
"http://metalab.unc.edu/pub/Linux/docs/HOWTO/translations/fr">http://metalab.unc.edu/pub/Linux/docs/HOWTO/translations/fr</a>.</p>
<p>Vous pouvez envoyer vos questions et vos commentaires sur ce
HOWTO &agrave; Eric S. Raymond, <a href=
"mailto:esr@snark.thyrsus.com">esr@snark.thyrsus.com</a>.</p>
<h2><a name="ss1.3">1.3 Note du traducteur sur l'usage de l'anglais
dans le document</a></h2>
<p>On a choisi de ne pas traduire les noms de fichiers que l'auteur
recommande d'inclure dans un logiciel. En effet, le monde des
logiciels libres est fortement internationalis&eacute;, et il
utilise l'anglais comme langue commune. On supposera donc que le
lecteur qui souhaiterait mettre en application les conseils de ce
HOWTO conna&icirc;t suffisamment d'anglais pour &eacute;crire des
documents tels que le fichier README ou le fichier INSTALL. Cela
n'interdit pas, bien entendu, d'inclure dans les projets une
version fran&ccedil;aise de ces documents, qui sera tr&egrave;s
appr&eacute;ci&eacute;e des utilisateurs francophones, qu'ils
parlent ou non l'anglais.</p>
<h2><a name="s2">2. R&egrave;gles d'usage pour l'appellation de
votre projet et de votre archive</a></h2>
<p>Au fur et &agrave; mesure que s'accro&icirc;t la charge de
travail des gestionnaires d'archives comme Metalab, le site PSA ou
le CPAN, les soumissions sont de plus en plus souvent
trait&eacute;es, en tout ou en partie, par des programmes (et non
en totalit&eacute; par des humains).</p>
<p>Il est donc tr&egrave;s important que le nom de votre projet et
celui de votre fichier d'archive suivent des r&egrave;gles
pr&eacute;cises, afin que des programmes informatiques puissent les
analyser et les comprendre.</p>
<h2><a name="ss2.1">2.1 Utilisez le style d'appellation GNU, avec
un pr&eacute;fixe suivi d'un num&eacute;ro du type
majeur.mineur.patch.</a></h2>
<p>Vous faciliterez la vie &agrave; tout le monde en donnant
&agrave; vos archives des noms dans le style GNU : un
pr&eacute;fixe-racine alphanum&eacute;rique tout en minuscules,
suivi par un tiret, puis un num&eacute;ro de version, une extension
et d'autres suffixes.</p>
<p>Supposons que vous ayez un projet nomm&eacute; "toto", qui en
est &agrave; la version 1, mise &agrave; jour 2, niveau 3. S'il est
compos&eacute; d'une seule archive (sans doute le code source),
voici &agrave; quoi devrait ressembler son nom :</p>
<dl>
<dt><b>toto-1.2.3.tar.gz</b></dt>
<dd>
<p>L'archive des sources</p>
</dd>
<dt><b>toto.lsm</b></dt>
<dd>
<p>Le fichier LSM (si vous l'envoyez &agrave; Metalab).</p>
</dd>
</dl>
<p>N'utilisez <em>pas</em> les noms suivants :</p>
<dl>
<dt><b>toto123.tar.gz</b></dt>
<dd>
<p>Beaucoup de programmes croiront qu'il s'agit du fichier
d'archive d'un projet nomm&eacute; `toto123', sans num&eacute;ro de
version.</p>
</dd>
<dt><b>toto1.2.3.tar.gz</b></dt>
<dd>
<p>Beaucoup de programmes croiront qu'il s'agit de l'archive d'un
projet nomm&eacute; `toto1' &agrave; la version 2.3.</p>
</dd>
<dt><b>toto-v1.2.3.tar.gz</b></dt>
<dd>
<p>Beaucoup de programmes prendront cela pour un projet
nomm&eacute; `toto-v1'.</p>
</dd>
<dt><b>to_to-1.2.3.tar.gz</b></dt>
<dd>
<p>Le caract&egrave;re soulign&eacute; est difficile &agrave;
prononcer, &agrave; taper, et &agrave; retenir.</p>
</dd>
<dt><b>ToTo-1.2.3.tar.gz</b></dt>
<dd>
<p>A moins que vous vouliez <em>vraiment</em> ressembler &agrave;
un accroc du marketing. L&agrave; encore, c'est difficile &agrave;
prononcer, &agrave; taper et &agrave; retenir.</p>
</dd>
</dl>
<p>Si vous voulez faire s&eacute;par&eacute;ment une archive de
sources et une archive de binaires, ou diff&eacute;rentes archives
de binaires, ou encore indiquer un certain type d'option de
fabrication dans le nom de l'archive, rajoutez pour cela une
extension <em>apr&egrave;s</em> le num&eacute;ro de version. Voici
quelques exemples :</p>
<dl>
<dt><b>toto-1.2.3.src.tar.gz</b></dt>
<dd>
<p>sources</p>
</dd>
<dt><b>toto-1.2.3.bin.tar.gz</b></dt>
<dd>
<p>binaires, type non sp&eacute;cifi&eacute;</p>
</dd>
<dt><b>toto-1.2.3.bin.ELF.tar.gz</b></dt>
<dd>
<p>binaires ELF</p>
</dd>
<dt><b>toto-1.2.3.bin.ELF.static.tar.gz</b></dt>
<dd>
<p>binaires ELF li&eacute;s statiquement</p>
</dd>
<dt><b>toto-1.2.3.bin.SPARC.tar.gz</b></dt>
<dd>
<p>binaires pour SPARC</p>
</dd>
</dl>
<p>N'utilisez <em>pas</em> des noms comme `toto-ELF.1.2.3.tar.gz',
car les programmes ont beaucoup de mal &agrave; s&eacute;parer un
infixe (tel que `ELF') de la racine du mot.</p>
<p>Un bon sch&eacute;ma d'appellation g&eacute;n&eacute;rique
contient, dans l'ordre, les parties suivantes :</p>
<ol>
<li>pr&eacute;fixe du projet</li>
<li>tiret</li>
<li>num&eacute;ro de version</li>
<li>point</li>
<li>"src" ou "bin" (optionnel)</li>
<li>point ou tiret (un point de pr&eacute;f&eacute;rence)</li>
<li>type de binaire et options (optionnel)</li>
<li>extensions relatives au mode d'archivage et de compression</li>
</ol>
<h2><a name="ss2.2">2.2 Mais respectez le cas &eacute;ch&eacute;ant
les conventions locales</a></h2>
<p>Certains projets ou communaut&eacute;s ont des conventions bien
&eacute;tablies pour les noms et les num&eacute;ros de version, et
ces conventions ne sont pas toujours compatibles avec les conseils
qui pr&eacute;c&egrave;dent. Par exemple, les modules Apache ont en
g&eacute;n&eacute;ral des noms du genre mod_foo, et ils ont
&agrave; la fois un num&eacute;ro de version propre et le
num&eacute;ro de la version d'Apache avec laquelle ils
fonctionnent. De m&ecirc;me, les num&eacute;ros de version des
modules Perl peuvent &ecirc;tre trait&eacute;s comme des nombres
d&eacute;cimaux (par exemple, vous pouvez voir 1.303 &agrave; la
place de 1.3.3), et les distributions s'appellent en
g&eacute;n&eacute;ral Foo-Bar-1.303.tar.gz pour la version 1.303 du
module Foo::Bar.</p>
<p>Apprenez et respectez les conventions des communaut&eacute;s et
d&eacute;veloppeurs sp&eacute;cialis&eacute;s ; suivez les
r&egrave;gles d&eacute;crites ci-dessus dans le cas
g&eacute;n&eacute;ral.</p>
<h2><a name="ss2.3">2.3 Choisissez avec le plus grand soin un
pr&eacute;fixe unique et facile &agrave; taper</a></h2>
<p>Le pr&eacute;fixe-racine devrait &ecirc;tre le m&ecirc;me pour
tous les fichiers d'un projet, et il devrait &ecirc;tre facile
&agrave; lire, &agrave; taper et &agrave; retenir. N'utilisez pas
le caract&egrave;re "soulign&eacute;". Et ne mettez pas de
majuscules ou de MajusculesInt&eacute;rieures sans une tr&egrave;s
bonne raison -- cela d&eacute;range le trajet naturel de l'oeil
humain, et vous aurez l'air de faire du marketing.</p>
<p>C'est difficile de s'y retrouver lorsque deux projets ont le
m&ecirc;me nom. Assurez-vous donc, dans la mesure du possible,
qu'il n'y a pas de conflit de noms avant de publier votre
premi&egrave;re version. Deux bons endroits pour v&eacute;rifier
ceci sont <a href="http://metalab.unc.edu/pub/Linux">l'index de
Metalab</a> et l'index des applications (appindex) &agrave;
<a href="http://www.freshmeat.net">Freshmeat</a>. Un autre endroit
recommand&eacute; est <a href=
"http://www.sourceforge.net">SourceForge</a>, en effectuant une
recherche par nom.</p>
<h2><a name="s3">3. R&egrave;gles d'usage pour la licence et le
copyright : la th&eacute;orie</a></h2>
<p>La licence que vous choisissez d&eacute;finit le contrat social
que vous souhaitez mettre en place avec vos co-d&eacute;veloppeurs
et vos utilisateurs. Le copyright que vous mettez sur le logiciel
sert principalement de d&eacute;claration l&eacute;gale de votre
droit &agrave; fixer les termes de la licence sur le logiciel et
sur les oeuvres qui en sont d&eacute;riv&eacute;es.</p>
<h2><a name="ss3.1">3.1 Les logiciels &agrave; code ouvert et le
copyright</a></h2>
<p>(Note du traducteur : dans cette section comme dans celles qui
suivent, l'expression "(logiciel &agrave;) code ouvert" est
utilis&eacute;e pour traduire l'anglais "open source", tandis que
l'expression habituelle "logiciel libre" sert &agrave; transcrire
"free software")</p>
<p>Tout ce qui n'appartient pas au domaine public poss&egrave;de un
copyright, voire plusieurs. Selon la Convention de Berne (qui a
force de loi aux Etats-Unis depuis 1978), le copyright n'a pas
besoin d'&ecirc;tre explicite. C'est-&agrave;-dire que les auteurs
d'une oeuvre sont d&eacute;tenteurs du copyright m&ecirc;me s'il
n'y a pas de note de copyright.</p>
<p>Il peut &ecirc;tre tr&egrave;s difficile de d&eacute;terminer
qui peut &ecirc;tre compt&eacute; comme un auteur, surtout lorsque
de nombreuses auteurs ont travaill&eacute; sur le logiciel. C'est
ce qui fait l'importance des licences. En pr&eacute;cisant les
conditions dans lesquelles l'oeuvre peut &ecirc;tre
utilis&eacute;e, elles donnent aux utilisateurs des droits qui les
prot&egrave;gent des actions arbitraires que pourraient
entreprendre les d&eacute;tenteurs du copyright.</p>
<p>Dans le logiciel propri&eacute;taire, les termes de la licence
sont formul&eacute;s de mani&egrave;re &agrave; prot&eacute;ger le
copyright. Ils permettent de donner quelques droits aux
utilisateurs tout en assurant au propri&eacute;taire (le
d&eacute;tenteur du copyright) la plus grande possibilit&eacute;
d'action possible sur le plan l&eacute;gal. Le d&eacute;tenteur du
copyright a une grande importance, et la licence est tellement
restrictive dans l'esprit que les d&eacute;tails techniques de ses
termes sont g&eacute;n&eacute;ralement sans importance.</p>
<p>Dans le logiciel &agrave; code ouvert, la situation est souvent
exactement inverse ; le copyright existe pour prot&eacute;ger la
licence. Les seuls droits qui sont toujours conserv&eacute;s au
d&eacute;tenteur du copyright sont ceux qui permettent de renforcer
la licence. Parmi les autres droits, un petit nombre seulement sont
r&eacute;serv&eacute;s, et c'est l'utilisateur qui a la plus grande
libert&eacute;. En particulier, le d&eacute;tenteur du copyright ne
peut pas modifier la licence sur une copie que vous poss&eacute;dez
d&eacute;j&agrave;. Par cons&eacute;quent, le d&eacute;tenteur du
copyright dans les logiciels &agrave; code ouvert n'a presque
aucune importance -- contrairement aux termes de la licence.</p>
<p>Normalement, le d&eacute;tenteur du copyright sur un projet est
le responsable actuel du projet ou une organisation
m&eacute;c&egrave;ne. Le changement de responsable &agrave; la
t&ecirc;te d'un projet se manifeste souvent par la modification du
copyright. Toutefois ce n'est pas une r&egrave;gle absolue ; dans
de nombreux projets &agrave; code source ouvert, le copyright
revient &agrave; de multiples personnes, et il n'y a pas de cas
connu o&ugrave; cela ait entra&icirc;n&eacute; des complications
sur le plan l&eacute;gal.</p>
<p>Certains projets choisissent de donner le copyright &agrave; la
Free Software Foundation, avec l'id&eacute;e que cette fondation a
un int&eacute;r&ecirc;t dans la d&eacute;fense du logiciel &agrave;
code ouvert, et poss&egrave;de les avocats pour s'en occuper.</p>
<h2><a name="ss3.2">3.2 D&eacute;terminer ce qui peut &ecirc;tre
qualifi&eacute; comme logiciel &agrave; code ouvert</a></h2>
<p>En ce qui concerne la licence, on peut distinguer plusieurs
sortes de droits transf&eacute;rables via une licence. Les droits
de <em>copie et de redistribution</em>, les droits
d'<em>utilisation</em>, les droits de <em>modification &agrave;
usage personnel</em> et les droits de <em>redistribution de copies
modifi&eacute;es</em>. Une licence peut restreindre chacun de ces
droits ou les accompagner de conditions.</p>
<p>L' <a href="http://www.opensource.org">Open Source
Initiative</a> est le r&eacute;sultat d'un important effort de
r&eacute;flexion sur ce qui fait un ``logiciel &agrave; code
ouvert'' ou (dans une terminologie plus ancienne) un ``logiciel
libre''. L'association place les contraintes suivantes sur les
licences :</p>
<ol>
<li>Un droit de copie illimit&eacute; doit &ecirc;tre
accord&eacute;.</li>
<li>Un droit d'utilisation illimit&eacute; doit &ecirc;tre
accord&eacute;.</li>
<li>Un droit de modication illimit&eacute; pour utilisation
personnelle doit &ecirc;tre accord&eacute;.</li>
</ol>
<p>Ces r&egrave;gles proscrivent les restrictions sur la
redistribution de binaires modifi&eacute;s ; cela correspond aux
besoins des distributeurs de logiciels, &agrave; qui il faut
pouvoir livrer sans entraves du code en &eacute;tat de marche. Cela
permet aux auteurs de demander que le code source modifi&eacute;
soit redistribu&eacute; sous la forme du code source original plus
des patchs, ce qui fait appara&icirc;tre les intentions de l'auteur
et, dans un``suivi d'audit'', toutes les modifications faites par
d'autres personnes.</p>
<p>L'OSD est la d&eacute;finition l&eacute;gale de la marque de
certification `OSI Certified Open Source', et vaut toutes les
d&eacute;finitions qu'on a pu faire du ``logiciel libre'' (note du
traducteur : OSI est ici l'Open Source Initiative et n'a rien
&agrave; voir avec l'Organisme de Standardisation Internationale ou
ISO). Toutes les licences courantes (MIT, BSD, Artistic et
GPL/LGPL) la v&eacute;rifient (encore que certaines, comme la GPL,
ajoutent d'autres restrictions que vous devriez comprendre avant de
les adopter).</p>
<p>Notez que les licences n'autorisant qu'un usage non commercial
ne peuvent <em>pas</em> &ecirc;tre qualifi&eacute;es de licences
&agrave; code ouvert, m&ecirc;me si elles affichent la licence
``GPL'' ou quelque autre licence courante. Elles font de la
discrimination envers des emplois, des personnes et des groupes
particuliers. Elles rendent la vie trop compliqu&eacute;e aux
distributeurs de CD-ROM et aux autres personnes qui essaient de
diffuser commercialement les logiciels &agrave; code ouvert.</p>
<h2><a name="s4">4. R&egrave;gles d'usage pour la licence et le
copyright : la pratique</a></h2>
<p>Voici comment appliquer dans la pratique la th&eacute;orie qui
pr&eacute;c&egrave;de :</p>
<h2><a name="ss4.1">4.1 Donnez le copyright &agrave;
vous-m&ecirc;me ou &agrave; la FSF</a></h2>
<p>Dans certains cas, si vous avez derri&egrave;re vous une
organisation m&eacute;c&egrave;ne qui poss&egrave;de des avocats,
vous pouvez choisir de donner le copyright &agrave; cette
organisation.</p>
<h2><a name="ss4.2">4.2 Choisissez une licence conforme &agrave;
l'Open Source Definition</a></h2>
<p>L'Open Source Definition (D&eacute;finition du Code Ouvert) est
la r&egrave;gle d'or pour les licences. L'OSD n'est pas une licence
en soi ; elle d&eacute;finit plut&ocirc;t un ensemble minimal de
droits qu'une licence doit garantir afin d'&ecirc;tre
consid&eacute;r&eacute;e comme une licence &agrave; code ouvert. On
peut trouver L'OSD, avec des documents compl&eacute;mentaires, sur
le site Web de l' <a href="http://www.opensource.org">Open Source
Initiative</a>.</p>
<h2><a name="ss4.3">4.3 N'&eacute;crivez pas votre propre licence
si vous pouvez l'&eacute;viter.</a></h2>
<p>Les licences compatibles &agrave; l'OSD et connues de tous ont
des traditions d'interpr&eacute;tation bien &eacute;tablies. Les
d&eacute;veloppeurs (et, dans la mesure o&ugrave; ils s'y
int&eacute;ressent, les utilisateurs) savent ce qui en
d&eacute;coule, et mesurent les risques et les inconv&eacute;nients
qu'elles comportent. Par cons&eacute;quent, utilisez si possible
l'une des licences standards sur le site de l'Open Source
Initiative.</p>
<p>Si vous devez &eacute;crire votre propre licence, prenez soin de
la faire certifier par l'Open Source Initiative. Cela vous
&eacute;pargnera de nombreuses discussions et des co&ucirc;ts
importants. Si vous n'&ecirc;tes jamais pass&eacute; par l&agrave;,
vous ne pouvez pas imaginer pas &agrave; quel point un d&eacute;bat
sur les licences peut tourner au vinaigre ; les gens s'enflamment,
parce que les licences sont consid&eacute;r&eacute;es comme des
pactes presque sacr&eacute;s qui touchent aux valeurs essentielles
de la communaut&eacute; des logiciels ouverts.</p>
<p>De plus, l'existence d'une tradition d'interpr&eacute;tation
bien &eacute;tablie pourrait se r&eacute;v&eacute;ler importante si
un jour votre licence faisait l'objet d'un proc&egrave;s. A la date
o&ugrave; ces lignes sont &eacute;crites (septembre 1999), il n'y a
pas d'exemple de d&eacute;cision judiciaire qui ait confirm&eacute;
ou invalid&eacute; une licence de logiciel &agrave; code ouvert.
Toutefois, c'est un principe de droit (au moins aux Etats-Unis, et
sans doute dans d'autres pays de droit coutumier comme l'Angleterre
et le reste du Commonwealth) que les cours de justice doivent
interpr&eacute;ter les licences et les contrats en fonction des
attentes et des pratiques de la communaut&eacute; qui les a
produits.</p>
<h2><a name="s5">5. R&egrave;gles d'usage du
d&eacute;veloppement</a></h2>
<p>La plupart de ces r&egrave;gles visent &agrave; assurer la
portabilit&eacute;, non seulement entre les diff&eacute;rentes
distributions de Linux, mais aussi avec d'autres
vari&eacute;t&eacute;s d'Unix. La portabilit&eacute; vers Unix
n'est pas seulement une question de professionnalisme ou de
savoir-vivre entre programmeurs, c'est aussi une assurance non
n&eacute;gligeable contre les &eacute;volutions futures de Linux
lui-m&ecirc;me.</p>
<p>D'autres personnes <em>finiront</em> par essayer de compiler
votre code dans d'autres environnements que Linux ; avec la
portabilit&eacute;, vous recevrez moins de messages ennuyeux de la
part d'utilisateurs perplexes.</p>
<h2><a name="ss5.1">5.1 Ecrivez soit en C ANSI pur, soit dans un
langage de script portable</a></h2>
<p>Pour des raisons de portabilit&eacute; et de stabilit&eacute;,
il est fortement recommand&eacute; d'&eacute;crire soit en C ANSI
pur, soit dans un langage de script dont la portabilit&eacute; soit
garantie par une impl&eacute;mentation multi-plateforme unique.</p>
<p>Parmi les langages de script, Python, Perl, Tcl, Emacs Lisp et
PHP respectent ce crit&egrave;re. Le bon vieux shell <em>ne
convient pas</em> ; il existe trop d'impl&eacute;mentations
diff&eacute;rentes, chacune ayant des particularit&eacute;s
subtiles, et l'environnement du shell est souvent transform&eacute;
de mani&egrave;re impr&eacute;visible par des configurations
propres &agrave; chaque utilisateur, comme les alias.</p>
<p>Java promet beaucoup sur le plan de la portabilit&eacute;, mais
les impl&eacute;mentations disponibles sur Linux sont encore
sommaires et mal int&eacute;gr&eacute;es dans le syst&egrave;me
d'exploitation. Java est encore un choix exotique, bien qu'il ait
de fortes chances de gagner en popularit&eacute; lorsqu'il aura
plus de maturit&eacute;.</p>
<h2><a name="ss5.2">5.2 Respectez les r&egrave;gles de
portabilit&eacute; du C</a></h2>
<p>Si vous &eacute;crivez en C, n'h&eacute;sitez pas &agrave;
utiliser &agrave; fond les fonctionnalit&eacute;s d&eacute;crites
dans la norme ANSI -- y compris les prototypes de fonction, qui
vous aideront &agrave; rep&eacute;rer les incoh&eacute;rences entre
modules. Les compilateurs du type K&amp;R rel&egrave;vent du
pass&eacute;.</p>
<p>En revanche, ne supposez <em>pas</em> que certaines
caract&eacute;ristiques sp&eacute;cifiques &agrave; GCC comme
l'option `-pipe' ou les fonctions imbriqu&eacute;es sont
disponibles. Cela vous poursuivra et vous vous en repentirez le
jour o&ugrave; quelqu'un portera votre logiciel vers un
syst&egrave;me autre que Linux, ou d&eacute;pourvu de GCC.</p>
<h2><a name="ss5.3">5.3 Utilisez
autoconf/automaker/autoheader</a></h2>
<p>Si vous &eacute;crivez en C, utilisez
autoconf/automaker/autoheader pour assurer la portabilit&eacute;,
v&eacute;rifier la configuration du syst&egrave;me et affiner vos
makefiles. De nos jours, les gens qui compilent &agrave; partir des
sources s'attendent &agrave; devoir juste taper "configure; make"
et que tout se compile proprement - sans la moindre erreur.</p>
<h2><a name="ss5.4">5.4 Soignez la rigueur de votre code avant
chaque nouvelle version</a></h2>
<p>Si vous &eacute;crivez en C, faites une compilation de test avec
l'option -Wall et corrigez les erreurs r&eacute;sultantes, au moins
une fois avant chaque nouvelle version. On trouve comme cela un
nombre surprenant d'erreurs. Pour &ecirc;tre vraiment complet,
compilez aussi avec l'option -pedantic.</p>
<p>Si vous &eacute;crivez en Perl, v&eacute;rifiez votre code avec
perl -c (voire -T dans les cas ad&eacute;quats). Utilisez perl -w
et 'use strict' religieusement (consultez la documentation de Perl
pour plus d'informations).</p>
<h2><a name="ss5.5">5.5 Soignez votre documentation et vos README
avant la livraison</a></h2>
<p>Passez-les au correcteur d'orthographe. Si vous donnez
l'impression de ne pas conna&icirc;tre l'orthographe et de vous en
moquer, les gents penseront que vous avez aussi b&acirc;cl&eacute;
votre code.</p>
<h2><a name="s6">6. R&egrave;gles d'usage pour la mise au point de
la distribution</a></h2>
<p>Les indications qui suivent montrent &agrave; quoi votre
distribution devrait ressembler lorsqu'on la r&eacute;cup&egrave;re
et qu'on la d&eacute;compacte.</p>
<h2><a name="ss6.1">6.1 Assurez-vous que vos archives se
d&eacute;compactent toujours dans un r&eacute;pertoire nouveau et
unique.</a></h2>
<p>L'erreur la plus aga&ccedil;ante que font les
d&eacute;veloppeurs novices est de fabriquer des archives qui
d&eacute;compactent les fichiers et r&eacute;pertoires de la
distribution dans le r&eacute;pertoire courant, avec le risque
d'&eacute;craser des fichiers d&eacute;j&agrave; pr&eacute;sents.
<em>Ne faites jamais cela !</em></p>
<p>A la place, faites en sorte que les fichiers de vos archives
partagent le m&ecirc;me r&eacute;pertoire, avec un nom
d&eacute;rivant de celui du projet. Ainsi, ils se placeront dans un
seul r&eacute;pertoire, juste <em>en-dessous</em> du
r&eacute;pertoire courant.</p>
<p>Voici un moyen de r&eacute;aliser cela dans un makefile, en
supposant que le r&eacute;pertoire de votre distribution est `toto'
et que SRC est une variable contenant la liste des fichiers de
votre distribution. Vous devez avoir GNU tar 1.13.</p>
<pre>
VERS=1.0
toto-$(VERS).tar.gz:
        tar --name-prefix='toto-$(VERS)/' -czf toto-$(VERS).tar.gz $(SRC)
</pre>
<p>Si votre version de tar est plus ancienne, faites quelque chose
dans ce genre :</p>
<pre>
toto-$(VERS).tar.gz:
        @ls $(SRC) | sed s:^:toto-$(VERS)/: &gt;MANIFEST
        @(cd ..; ln -s toto toto-$(VERS))
        (cd ..; tar -czvf toto/toto-$(VERS).tar.gz `cat toto/MANIFEST`)
        @(cd ..; rm toto-$(VERS))
</pre>
<h2><a name="ss6.2">6.2 Ecrivez un README</a></h2>
<p>Fournissez un fichier nomm&eacute; README ou READ.ME, qui donne
une vision d'ensemble de votre distribution. C'est une vieille
convention, et c'est le premier fichier que l'intr&eacute;pide
explorateur lira apr&egrave;s avoir extrait les sources.</p>
<p>Voici quelques &eacute;l&eacute;ments qu'il est bon d'avoir dans
un README :</p>
<ul>
<li>Une br&egrave;ve description du projet.</li>
<li>Un lien vers le site Web du projet, le cas
&eacute;ch&eacute;ant.</li>
<li>Des indications sur l'environnement de compilation du
d&eacute;veloppeur et sur les possibles probl&egrave;mes de
portabilit&eacute;.</li>
<li>Un plan d'ensemble des fichiers et sous-r&eacute;pertoires
importants.</li>
<li>Les instructions de compilation et d'installation, ou bien un
lien vers le fichier les contenant (habituellement INSTALL).</li>
<li>Le nom des responsables et des contributeurs, ou un lien vers
le fichier contenant ces noms (habituellement CREDITS).</li>
<li>Les derni&egrave;res nouvelles relatives au projet, ou un lien
vers un fichier les contenant (habituellement NEWS).</li>
</ul>
<h2><a name="ss6.3">6.3 Adoptez les conventions courantes
d'appellation des fichiers</a></h2>
<p>Avant m&ecirc;me d'avoir regard&eacute; le README, votre
intr&eacute;pide explorateur aura parcouru la liste des fichiers
dans le r&eacute;pertoire principal de votre distribution. Ces
noms, par eux-m&ecirc;mes, contiennent de l'information. En suivant
certaines r&egrave;gles d'appellation, vous donnerez &agrave;
l'explorateur de bons indices pour orienter son parcours.</p>
<p>Voici quelques noms recommand&eacute;s pour les fichiers du
r&eacute;pertoire principal, avec leur signification. Tous ne sont
pas indispensables dans chaque projet.</p>
<dl>
<dt><b>README ou READ.ME</b></dt>
<dd>
<p>le plan d'ensemble, &agrave; lire en premier</p>
</dd>
<dt><b>INSTALL</b></dt>
<dd>
<p>instructions de configuration, de compilation et
d'installation</p>
</dd>
<dt><b>CREDITS</b></dt>
<dd>
<p>liste des contributeurs du projet</p>
</dd>
<dt><b>NEWS</b></dt>
<dd>
<p>derni&egrave;res nouvelles</p>
</dd>
<dt><b>HISTORY</b></dt>
<dd>
<p>histoire du projet</p>
</dd>
<dt><b>COPYING</b></dt>
<dd>
<p>termes de la licence (convention GNU)</p>
</dd>
<dt><b>LICENSE</b></dt>
<dd>
<p>termes de la licence</p>
</dd>
<dt><b>MANIFEST</b></dt>
<dd>
<p>liste des fichiers</p>
</dd>
<dt><b>FAQ</b></dt>
<dd>
<p>"Foire Aux Questions" pour le projet, au format texte.</p>
</dd>
<dt><b>TAGS</b></dt>
<dd>
<p>fichier de tags g&eacute;n&eacute;r&eacute; automatiquement,
pour &ecirc;tre utilis&eacute; par Emacs ou vi</p>
</dd>
</dl>
<p>Remarquez que la convention g&eacute;n&eacute;rale est que les
fichiers dont le nom ne comporte que des majuscules sont des
fichiers d'information sur le projet lui-m&ecirc;me, et ne sont pas
des &eacute;l&eacute;ments du syst&egrave;me &agrave; compiler.</p>
<p>La pr&eacute;sence d'une FAQ vous soulagera beaucoup. Quand une
question relative au projet revient fr&eacute;quemment, rajoutez-la
dans la FAQ. Puis demandez aux utilisateurs de lire la FAQ avant de
poser des questions ou d'envoyer des rapports de bogues. Une FAQ
bien entretenue peut r&eacute;duire d'au moins un ordre de grandeur
la charge du support pour les mainteneurs du projet.</p>
<p>Il est bon d'avoir un fichier HISTORY ou NEWS avec un historique
du projet mis &agrave; jour &agrave; chaque nouvelle version. Entre
autres choses, il pourrait vous aider &agrave; prouver votre
ant&eacute;riorit&eacute; si vous &eacute;tiez pris dans un
proc&egrave;s pour contrefa&ccedil;on (ce n'est jamais encore
arriv&eacute; &agrave; personne, mais autant y &ecirc;tre
pr&eacute;par&eacute;).</p>
<h2><a name="ss6.4">6.4 Pr&eacute;voyez les mises &agrave;
jour</a></h2>
<p>Votre logiciel &eacute;voluera dans le temps au rythme des
versions successives. Certains des changements ne seront pas
compatibles avec l'existant. Par cons&eacute;quent,
r&eacute;fl&eacute;chissez bien &agrave; l'organisation du logiciel
afin que plusieurs versions puissent &ecirc;tre install&eacute;es
et coexister sur le m&ecirc;me syst&egrave;me. C'est
particuli&egrave;rement important pour les biblioth&egrave;ques de
fonctions : vous ne pouvez pas compter que tous les programmes
clients soient mis &agrave; jour d'un seul coup pour s'adapter aux
modifications de vos interfaces.</p>
<p>Les projets Emacs, Python et Qt ont adopt&eacute; une bonne
convention pour traiter ce probl&egrave;me, celle des
r&eacute;pertoires num&eacute;rot&eacute;s par version. Voici
&agrave; quoi ressemble une hi&eacute;rarchie de
biblioth&egrave;ques Qt (${ver} est le num&eacute;ro de version)
:</p>
<pre>
/usr/lib/qt
/usr/lib/qt-${ver}
/usr/lib/qt-${ver}/bin          # Emplacement de moc
/usr/lib/qt-${ver}/lib          # Emplacement des .so
/usr/lib/qt-${ver}/include      # Emplacement des fichiers d'en-t&ecirc;te
+
</pre>
<p>Une telle organisation vous permet de faire coexister plusieurs
versions. Les programmes clients doivent sp&eacute;cifier quelle
version de la biblioth&egrave;que ils d&eacute;sirent, mais c'est
un faible prix &agrave; payer en comparaison des
incompatibilit&eacute;s d'interface qu'ils &eacute;vitent.</p>
<h2><a name="ss6.5">6.5 Fournissez des RPM</a></h2>
<p>Le format standard de facto pour les distributions de binaires
&agrave; installer est celui qu'utilise le Red Hat Package Manager,
RPM. Il est pr&eacute;sent dans les distributions Linux les plus
populaires, et il est support&eacute; en pratique par toutes les
autres (sauf Debian et Slackware ; et Debian peut faire des
installations &agrave; partir de RPM).</p>
<p>Par cons&eacute;quent, c'est une bonne id&eacute;e de fournir
sur le site de votre projet des RPM installables en m&ecirc;me
temps qu'une archive des sources.</p>
<p>C'est aussi une bonne id&eacute;e d'inclure dans votre archive
de sources le fichier de sp&eacute;cification du RPM, avec dans le
Makefile une entr&eacute;e qui fabrique les RPM &agrave; partir de
lui. Le fichier de sp&eacute;cification devrait avoir l'extension
`.spec' ; c'est comme cela que l'option -t de rpm le trouve
&agrave; l'int&eacute;rieur de l'archive.</p>
<p>Encore un point de style : g&eacute;n&eacute;rez votre fichier
de sp&eacute;cification avec un script shell qui ins&egrave;re
automatiquement le num&eacute;ro de version en analysant le
Makefile ou un fichier version.h.</p>
<p>Note : si vous fournissez des RPM sources, utilisez BuildRoot
pour fabriquer le programme dans /tmp ou /var/tmp. Si vous ne le
faites pas, l'installation, r&eacute;alis&eacute;e au cours de la
partie install de votre fabrication, se d&eacute;roulera dans les
r&eacute;pertoires finaux. Ceci se produira m&ecirc;me en cas
d'homonymie de fichiers ou si vous ne d&eacute;sirez pas
r&eacute;ellement installer le produit. Une fois la fabrication
termin&eacute;e, les fichiers seront install&eacute;s &agrave; leur
emplacement d&eacute;finitif, et la base de donn&eacute;es RPM du
syst&egrave;me ne sera pas mise &agrave; jour. Des SRPM ayant ce
mauvais comportement sont des champs de mines et doivent &ecirc;tre
&eacute;vit&eacute;s.</p>
<h2><a name="s7">7. Comment bien communiquer</a></h2>
<p>Votre logiciel n'apportera pas grand-chose &agrave; l'univers si
vous &ecirc;tes le seul &agrave; conna&icirc;tre son existence. De
plus, en &eacute;tablissant une pr&eacute;sence visible sur
Internet pour votre projet, vous pourrez recruter plus facilement
des utilisateurs et des co-d&eacute;veloppeurs. On le fait
habituellement comme ceci :</p>
<h2><a name="ss7.1">7.1 Faites une annonce dans c.o.l.a et sur
Freshmeat</a></h2>
<p>Annoncez vos nouvelles versions dans <a href=
"news:comp.os.linux.announce">comp.os.linux.announce</a>. Non
seulement ce forum est lu par un grand nombre de personnes, mais
c'est aussi un fournisseur important pour des sites Web
d'information comme <a href=
"http://www.freshmeat.net">Freshmeat</a>.</p>
<h2><a name="ss7.2">7.2 Faites une annonce dans un forum de
discussion ad&eacute;quat</a></h2>
<p>Trouvez un forum USENET dont le th&egrave;me de discussion est
directement concern&eacute; par votre application, et faites-y
aussi votre annonce. N'envoyez votre message qu'aux endroits
o&ugrave; la <em>fonction</em> remplie par votre logiciel est
pertinente, et restez mesur&eacute;.</p>
<p>Si (par exemple) vous publiez un programme en Perl qui interroge
des serveurs IMAP, vous devriez probablement envoyer un message
dans comp.mail.imap. Mais s&ucirc;rement pas dans comp.lang.perl,
&agrave; moins que le programme utilise de mani&egrave;re
instructive des techniques Perl avanc&eacute;es.</p>
<p>Votre annonce devrait aussi contenir l'URL du site Web de votre
projet.</p>
<h2><a name="ss7.3">7.3 Ayez un site Web</a></h2>
<p>Si vous comptez &eacute;tablir une communaut&eacute;
substantielle d'utilisateurs ou de d&eacute;veloppeurs autour de
votre projet, celui-ci devrait avoir son site Web. Voici des
&eacute;l&eacute;ments que l'on trouve habituellement sur un site
Web :</p>
<ul>
<li>La charte du projet (pourquoi il existe, quelle est son
audience, etc).</li>
<li>Des liens pour le t&eacute;l&eacute;chargement des
sources.</li>
<li>Des instructions relatives &agrave; l'inscription &agrave; la
ou les liste(s) de diffusion.</li>
<li>Une FAQ (Foire Aux Questions).</li>
<li>Une version en HTML de la documentation.</li>
<li>Des liens vers des projets proches et/ou concurrents.</li>
</ul>
<p>Certains projets ont m&ecirc;me une URL pour un acc&egrave;s
anonyme &agrave; l'arborescence principale du code source.</p>
<h2><a name="ss7.4">7.4 H&eacute;bergez des listes de diffusion
pour votre projet</a></h2>
<p>Il est d'usage d'avoir une liste de d&eacute;veloppement
priv&eacute;e qui permet aux collaborateurs du projet de
communiquer et d'&eacute;changer des patchs. Vous voudrez
peut-&ecirc;tre cr&eacute;er en plus une liste d'annonces pour les
gens qui veulent &ecirc;tre inform&eacute;s de la progression du
projet.</p>
<h2><a name="ss7.5">7.5 Publiez dans les archives les plus
importantes</a></h2>
<p>Depuis plusieurs ann&eacute;es, le <a href=
"http://www.metalab/unc.edu/pub/Linux/">site Metalab</a> est le
plus important des endroits d'&eacute;change de logiciels pour
Linux.</p>
<p>Voici quelques autres sites notables :</p>
<ul>
<li>le site <a href="http://www.python.org">Python Software
Activity</a> (pour les logiciels &eacute;crits en Python).</li>
<li>le <a href="http://language.perl.com/CPAN">CPAN</a> ou
R&eacute;seau d'Archives Perl Global (pour les logiciels
&eacute;crits en Perl).</li>
</ul>
<h2><a name="s8">8. La bonne gestion d'un projet</a></h2>
<p>Bien g&eacute;rer un projet lorsque tous les participants sont
b&eacute;n&eacute;voles pr&eacute;sente des d&eacute;fis
particuliers. Le sujet est trop large pour &ecirc;tre trait&eacute;
dans le cadre d'un HOWTO. Heureusement, il existe des documents de
r&eacute;flexion qui vous aideront &agrave; comprendre les
principaux points.</p>
<p>Pour un essai sur l'organisation de base du d&eacute;veloppement
et du principe `distribuez t&ocirc;t, mettez &agrave; jour souvent'
propre au `mode bazar', lisez <a href=
"http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">The
Cathedral and the Bazaar</a>.</p>
<p>Pour une r&eacute;flexion sur les motivations psychologiques,
des coutumes de la communaut&eacute; et de la r&eacute;solution des
conflits, lisez <a href=
"http://www.tuxedo.org/~esr/writings/homesteading/">Homesteading
the Noosphere</a>.</p>
<p>Pour un expos&eacute; des principes &eacute;conomiques et des
mod&egrave;les commerciaux &agrave; adopter, lisez <a href=
"http://www.tuxedo.org/~esr/writings/magic-cauldron/">The Magic
Cauldron</a>.</p>
<p>Si vous &ecirc;tes allergique &agrave; la langue de Shakespeare,
vous pourrez trouver des traductions de ces documents sur le site
<a href="http://www.linux-france.org/article/these/">Linux
France</a>.</p>
<p>Ces papiers ne pr&eacute;tendent pas se poser comme les
r&eacute;f&eacute;rences ultimes &agrave; propos des
d&eacute;veloppements &agrave; code source ouvert. Mais ils
constituent les premi&egrave;res analyses s&eacute;rieuses
&eacute;crites sur le sujet, et n'ont pas encore &eacute;t&eacute;
d&eacute;pass&eacute;s (l'auteur esp&egrave;re toutefois qu'ils le
seront un jour).</p>
</body>
</html>