Avant hier, j'ai assisté à un exposé sur la propriété intellectuelle
dans le développement logiciel: historique du droit d'auteur, rattachement
des logiciels au droit d'auteur, licences, etc.
Ce n'est pas le premier exposé sur ce sujet auquel j'assiste et,
comme chaque fois avec un public de développeurs, les questions
fusent, comme si chacun esssayait d'éprouver la cohérence des règles
au travers de situations réelles ou imaginées. Une saine habitude.
J'ai pu apprécier au passage la patience des deux intervenantes.
L'une des questions posées concernait la situation suivante: Un logiciel
est développé par un auteur jusqu'à une version v1. Ensuite, un autre
auteur prend la main et fait des modifications successives (donc des
commits successifs). Au bout d'un certain temps, il ne reste plus
aucune ligne du code original. La question est donc: Le premier auteur
est-il encore considéré comme auteur du logiciel après toutes
les modifications du second auteur ?
On peut y voir une variante de la question à propos du bâteau de Thésée:
Le fait de reprendre le code de l'auteur original du logiciel pour
en remplacer successivement des parties, les réécrire, etc., revient
en quelque sorte à changer les pièces abîmées du bâteau de Thésée:
on ne peut pas les changer n'importe comment, puisqu'elles doivent
continuer de s'inscrire dans les parties inchangées. De même pour
le logiciel: Pour qu'il continue de fonctionner, les modifications
de certaines parties doivent rester compatibles avec le reste
du logiciel.
La forme originale du logiciel continue donc de peser et d'influencer
les nouveaux développements.
Pour rappel, je considère que le potentiel
d'évolution d'un logiciel est orienté dans une direction, vers une
idéalité. Disons que la vision de l'auteur original
a donné une forme au logiciel, lui permettant d'évoluer facilement
dans certaines directions, bien plus difficilement dans d'autres.
On comprend donc bien que le nouveau logiciel, obtenu après modifications
sucessives de la version originale, contient encore une part du premier auteur,
de son geste créatif, de son "effort personnalisé".
Il est souvent plus facile de changer la forme d'un logiciel en recommençant
depuis rien, plutôt que de changer un logiciel existant. Faire un peu "changer de cap"
un logiciel est une opération parfois plus délicate qu'un grand changement.
Encore faut-il percevoir les directions d'évolutions possibles du logiciel en question,
au travers de sa forme, donc accéder en quelque sorte à la vision de l'auteur original
quant au futur qu'il avait imaginé pour son logiciel. C'est loin d'être facile.
C'est pourtant souvent ce qu'il est préconisé de faire, avec une
dimension
économique. On pense (trop) souvent qu'il sera moins coûteux de reprendre un logiciel
pour le faire évoluer à la marge afin d'ajouter une fonctionnalité plutôt
que d'en réécrire une grosse partie, voire tout refaire de zéro.
Le développeur se retrouve donc régulièrement devant un dilemme: continuer
le développement d'un logiciel dans la même direction, c'est-à-dire
sous la contrainte de sa forme, ou bien s'affranchir de la forme pour en
créer une nouvelle, afin d'orienter le logiciel dans une autre direction.
Nul n'est besoin de changer la forme d'un logiciel si elle lui permet d'évoluer
dans la direction voulue. Dans le cas contraire, il ne faut pas hésiter à
changer la forme du logiciel pour changer son orientation.
La perception des possibilités d'évolution d'un logiciel n'est
accessible qu'après un certain temps passé à étudier le logiciel. Ce temps
passé, cet investissement, pèse alors dans la décision de conserver la
forme ou d'en changer.
S'il est aussi difficile de repartir de zéro, ou tout du moins de se lancer
dans de grands changements d'un logiciel, c'est également parce que
cela semble impliquer de tout jeter, de perdre tout le savoir qui était
dans ce logiciel, parfois appelé "capital". En fait, réécrire tout ou
partie d'un logiciel n'implique pas cette perte: L'ancien code est
toujours disponible et on peut aller voir comment était traité un
problème, permettant ainsi de ne pas refaire les mêmes erreurs,
d'éventuels jeux tests peuvent encore s'appliquer, ... Bref,
il s'agit en quelque sorte de s'affranchir de la forme sans oublier le passé,
sans descendre des épaules de géants.