Page suivante Page précédente Table des matières

4. Propriété et logiciels au source ouvert

Que signifie le terme « propriété » lorsque ce qui est possédé est duplicable à l'infini, hautement malléable, et que la culture environnante n'est ni capable de faire appliquer des lois, ni dans une situation économique où les ressources sont limitées ?

En fait, dans le cas des logiciels au source ouvert, c'est une question à laquelle il est facile de répondre. Le(s) propriétaire(s) d'un projet sont ceux qui ont le droit exclusif, et reconnu comme tel par l'ensemble de la communauté, d'en redistribuer des versions modifiées.

(Nous parlerons de « propriétaire » au singulier, comme si tous les projets appartenaient à une seule personne. Cependant, il doit être clair que les projets peuvent appartenir à des groupes. Nous examinerons les dynamiques internes de tels groupes plus tard dans cet article.)

Selon les licences de logiciels au source ouvert standard, tous sont égaux dans le jeu de l'évolution. En pratique, il y a toutefois une distinction, reconnue par tous, entre les patchs

NdT : Modification d'un programme dans le but de corriger des erreurs ou d'introduire de nouvelles fonctionnalités.
« officiels », approuvés et intégrés dans le logiciel par les mainteneurs publiquement reconnus, et les patchs « pirates », proposés par des tiers. Les patchs pirates sont peu fréquents et, en général, pas considérés comme sûrs [RP].

Il est facile d'établir que la redistribution publique est un enjeu fondamental. L'usage encourage les gens à patcher le logiciel pour un usage personnel lorsque c'est nécessaire, et de ne pas prêter attention aux gens qui redistribuent des versions modifiées au sein d'un groupe fermé d'utilisateurs ou de développeurs. C'est uniquement lorsque les modifications sont diffusées à la communauté en général, en concurrençant l'original, que la notion de propriété du projet entre en ligne de compte.

Il existe en général trois manières de devenir le responsable d'un projet de logiciel au source ouvert. La première, la plus évidente, est de le créer. Lorsqu'un projet ne compte qu'un mainteneur depuis son origine et que ce mainteneur est toujours actif, l'usage ne permet même pas de remettre en cause cette autorité.

La deuxième manière de devenir responsable d'un projet, c'est de se faire confier cette charge par le précédent propriétaire (on appelle parfois cela « passer le relais »). Il est évident pour la communauté que les responsables de projets ont le devoir de choisir un successeur compétent lorsqu'ils ne veulent ou ne peuvent plus investir le temps nécessaire dans le développement ou la maintenance du projet.

Il est révélateur que dans le cas de projets importants, de tels passations de pouvoirs sont généralement annoncées en fanfare. Bien que la communauté du logiciel au source ouvert n'ai jamais vraiment remis en cause le choix d'un successeur par le responsable d'un projet, il est important que dans la pratique le dauphin apparaisse légitime aux yeux de la communauté.

Pour les projets mineurs, il est généralement suffisant de modifier le nom du propriétaire du projet dans le fichier d'historique joint à la distribution. On présume que si le propriétaire précédent n'a pas, en réalité, passé le relais volontairement, il ou elle pourra reprendre le contrôle de son projet, soutenu par la communauté, en objectant publiquement dans un délai raisonnable.

La troisième façon de prendre les rênes d'un projet est d'avoir des idées de développement, alors que le responsable précédent a disparu ou perdu tout intérêt pour ce programme. Si sa succession vous intéresse, il vous faut le rechercher. S'il reste introuvable, alors vous devez annoncer dans un endroit approprié (comme les forums de Usenet dédiés à ce type de logiciels) que le projet semble orphelin et que, dorénavant, vous envisagez de prendre les choses en main.

L'usage veut que vous laissiez passer un peu de temps avant de vous déclarer le nouveau responsable du projet. Si pendant ce laps de temps, quelqu'un annonce qu'il travaillait déjà sur ce projet, son annonce l'emporte sur la vôtre. Il est de bon ton d'annoncer publiquement vos intentions plus d'une fois. Vous vous légitimerez d'autant plus si vos annonces sont faites dans de nombreux forums adéquats (forums connexes, listes de diffusions) et si vous faites preuve de patience en attendant d'éventuelles réponses. En général, plus visibles seront vos efforts pour retrouver l'ancien propriétaire ou d'autres prétendants, plus votre revendication, s'il n'y a pas de réponse, sera légitimée.

Si vous avez passé avec succès toutes ces étapes devant l'assemblée des utilisateurs du projet et qu'il n'y a pas d'objection, alors vous pouvez vous proclamer propriétaire de ce projet orphelin et marquer votre nom dans le fichier d'historique du projet. Cependant, cette méthode est moins sûre que celle du passage de relais, et vous ne pouvez pas vous attendre à être considéré comme pleinement légitimé, du moins pas avant d'avoir réalisé d'importantes améliorations sur le projet, aux yeux de tous.

J'ai observé ces coutumes en action depuis 20 ans, depuis l'avant FSF, l'antiquité des logiciels au source ouvert. Elles ont un certain nombre de caractéristiques très intéressantes. L'une des plus intéressantes est que la plupart des hackeurs les ont respectées sans en être pleinement conscient. En effet, ce qui est écrit ici semble être la première mise au point consciente et raisonnablement complète jamais faite.

Autre fait intéressant, ces coutumes inconscientes ont été appliquées avec une cohérence remarquable, voire surprenante. J'ai observé l'évolution de centaines de projets de logiciels au source ouvert, et je peux malgré tout compter le nombre de violations significatives à ces règles sur les doigts.

Un troisième fait intéressant est que ces coutumes ont toujours évolué dans la même direction. C'est-à-dire en responsabilisant davantage le public, en l'informant plus, et en prenant garde de préserver les mérites et l'historique des projets de façon à établir la légitimité des propriétaires du moment (entre autres choses).

Ces particularités suggèrent que ces coutumes ne sont pas fortuites, mais l'effet d'une organisation spontanée, implicite, ou d'une finalité (generative pattern) dans la culture des logiciels au source ouvert, essentielle à son fonctionnement.

L'une des premières remarques qu'on m'ait faite, portait sur l'enseignement qu'on pouvait tirer du contraste entre la culture des hackeurs sur Internet et la culture des crackeurs ou pirates (l'activité des « wAr3z d00dz » consiste à cracker des jeux et à pirater des BBS (Bulletin Board Systems)) : toutes deux ont leurs propres finalités. Nous reviendrons sur ce contraste plus tard.


Page suivante Page précédente Table des matières