Notes de réunion de Patrice Pillot, merci pour l’autorisation de publication
Hier et aujourd’hui se sont tenues à Toulouse deux journées de travail
organisées par le projet Plume du CNRS sur le thème « Pourquoi et
comment diffuser un développement logiciel de laboratoire ou
d’université en libre ? ».
En deux mots, le projet Plume est un projet interne au CNRS qui « vise à
Promouvoir les Logiciels Utiles, Maîtrisés et Economiques dans la
communauté de l’Enseignement Supérieur et de la Recherche [NDE : donc
pas seulement au CNRS], en majorité des logiciels libres ». Ses
objectifs, plus concrètement, sont de mutualiser les compétences et de
la valoriser, de valoriser les développements internes, de créer une
communauté et enfin de promouvoir l’utilisation et les contributions aux
logiciels libres. Pour ce faire, il propose sur son site web un jeu de
fiches qui sont consacrées soit à des logiciels, soit à des ressources
pour les créateurs ou les utilisateurs de logiciels libres. Pour être
validée, une fiche descriptive de logiciel libre (généralement assez
détaillée) doit être en usage dans au moins 3 laboratoires différents.
Les fiches qui n’ont pas été mises à jour depuis plus d’une année sont
archivées (mais restent disponibles).
Un sous-projet, RELIER, recense de la même façon les logiciels
développés en interne par les laboratoires (pour l’instant issus de
trois laboratoires pilotes sauf erreur de ma part). Une fiche est
consacrée à la question du référencement des développements internes sur
le site de Plume.
Les présentations relevaient grosso-modo de trois catégories :
- les aspects juridiques des logiciels libres
- présentation de références
- retours d’expérience
Les présentations sont disponibles sur le site je ne rentrerai donc
pas dans le détail, je vais juste faire une synthèse rapide, d’autant
que de nombreux propos se retrouvaient chez plusieurs intervenants.
Tous d’abord, de nombreux intervenants ont eu l’occasion de détailler
les raisons pour lesquelles on pouvait (devait, pour certains !)
développer des logiciels libres lorsque l’on travaillait dans un
laboratoire financé sur fonds publics (je ne cite que les raisons
propres au monde de l’enseignement supérieur et de la recherche (ESR),
pas les raisons générales bien connues des abonnés de la liste) :
- les LL sont les seuls à permettre la reproductibilité des travaux
publiés : si une publication scientifique ne met pas à disposition les
sources des logiciels utilisés, alors il n’y a aucun moyen de
vérifier la validité des résultats ; Sébastien Paumier dira que
pour un chercheur, « publier en code propriétaire c’est un viol
de la transparence scientifique » - corollairement, l’évaluation croisée d’un LL est rendue possible
par son utilisation dans des projets variés - indépendance par rapport aux plates-formes matérielles et donc
aux éditeurs, particulièrement cruciale dans un domaine ou
quelquefois certains logiciels vont avoir un cycle de vie très
long qui ne peut être interrompu simplement parce que « ça ne
marche plus sur la nouvelle version de **** » - capacité à forker si le projet adopte des choix techniques qui
ne satisfont plus les besoins des travaux menés dans le labo - évidemment possibilité de patcher pour correction ou ajout de
fonctionnalités - partant du principe que la résistance au changement est très
grande chez les utilisateurs, un intervenant (Sébastien Paumier)
a fait remarquer que le logiciel libre, parce qu’il permettait
à un chercheur de n’apporter qu’une fonctionnalité isolée à un
logiciel libre préexistant pouvait valoriser cette contribution
alors qu’il ne lui aurait souvent pas été possible (dans le
monde du logiciel privateur) de réécrire et encore moins
d’imposer l’usage d’un logiciel destiné finalement qu’à
n’implémenter cette fonctionnalité - possibilité de maintenir en vie du code écrit par des doctorants
ou des stagiaires (pour autant bien sûr que ceux-ci aient donné
leur accord pour que le logiciel soit libre) - avec les LL on remplace la concurrence par l’héritage et on est
donc davantage cité ce qui est bon pour l’évaluation bibliométrique - vitesse de l’innovation : plus besoin de réinventer la roue, on
se contente de travailler sur de vraies nouvelles avancées - évidemment le partage du savoir (l’une des missions de base de
la recherche publique) - la recherche publique étant financée en amont par des fonds publics,
il n’y a pas de raisons de faire /payer/ au contribuable une
deuxième fois en publiant sous licence privatrice - les LL encouragent la constitution de nouvelles collaborations
scientifiques - des retombées économiques deviennent envisageables dans la mesure
où d’une part diffuser des logiciels libres c’est d’abord diffuser
et c’est donc un moyen de contacter des entreprises et d’autre part
parce qu’il devient possible de mettre en place des services
« légers » autour d’un LL, voire de favoriser la création d’une
SSLL pour assurer ces services (donc création d’emploi). - la liberté du code facilité grandement son exploitation via des
outils collaboratifs (suivi de version, BTS, listes de diffusion,
IRC, ...) donc les collaborations trans-frontalières (y compris
les frontières de départements...)
Plusieurs faux problèmes ont été aussi exposés (par Sébastien Paumier
essentiellement) :
- pas d’incompatibilité avec des exploitations industrielles du fait
de la possibilité soit d’utiliser des licenses à copyleft faibles,
soit d’employer une double license (même si évidemment dans
certains cas ce peut être complexe à mettre en place) - pas de problème d’anonymat : les auteurs sont mentionnés comme tels
et la modification anonyme est interdite - pas de risque de perte du contrôle : dans le pire des cas
possibilité de protéger le nom "officiel" du logiciel (comme
pour Firefox, ...) - le secret de fabrication est un mythe : si ce que fait le logiciel
est vraiment utile, alors des concurrents apparaitront, même
lorsque le logiciel semble énorme (exemple d’OOo) - développer en
libre est donc une façon de bloquer la concurrence !
Mais quelques vrais problèmes ont aussi été identifiés :
- multiplicité des licences des bibliothèques (sans parler de
celles dont on ne connait pas la licence) complique quelquefois
le travail de détermination de la licence à employer - ce n’est pas parce qu’on diffuse sous une licence libre que
magiquement les utilisateurs (ou les contributeurs) affluent :
il faut faire l’effort d’être visible (présence dans des outils
de référencement, dans des forges publiques, animation de
communauté donc mobilisation d’outils pour se faire, ...) - être prêt (et donc un minimum disponible) pour faire de
l’assistance utilisateur (ou avoir développer une communauté
qui fera ce travail pour soi)
C’est sans conteste la question de la valorisation économique des
développement sous forme de LL qui aura reçu les réponses les moins
claires. De fait, le débat est un peu piégé par le fait que les services
de valorisation du CNRS ne semblent (au travers des interventions de
leurs représentants) considérer la mission de valorisation que sous
l’angle purement économique (et justifiant leur position de manière
tautologique en soulignant que la valorisation économique était
importante car les sommes en jeux étaient très importantes). C’est bien
sûr oublier que les qualités intrinsèques des LL (largement décrites par
ailleurs, cf. supra) constituent déjà la plus extraordinaire des
valorisation ou /rentabilisation/ envisageable. De l’art de poser de
faux problèmes. Par ailleurs, des intervenants de l’Université de
Compiègne à qui la question était posée (par le représentant des
services de valorisation du CNRS justement) de savoir si leur logiciel
n’aurait pas ramené plus d’argent s’il avait fait l’objet d’un transfert
de technologie et d’une publication privatrice ont fait remarquer que le
caractère particulièrement innovant de leur logiciel (ils ont parlé de
/disruptive innovation/), parce qu’il impliquait de ses utilisateurs de
réorganiser drastiquement leur méthodes de travail, n’aurait pas pu
s’imposer auprès de ceux-ci s’il n’avait pas bénéficier de l’aura de
confiance que lui a conféré la communauté d’entreprises partenaires qui
s’est constitué progressivement autour de lui, communauté qui n’aurait
pu être constituée avec une publication sous licence privatrice.
Pour en finir sur ce point de la valorisation, le représentant de la
cellule stratégique de politique industrielle du CNRS a indiqué que pour
autant, l’avis des auteurs était systématiquement demandé quant au mode
de diffusion et que cet avis était suivi à 98% : dont acte.
Sur les aspects juridiques, Sébastien Canevet, juriste spécialiste en
PI, au sein d’une longue intervention qui a balayé peut-être trop
rapidement de trop nombreuses questions pour en faire un compte-rendu
intéressant ici (je vous engage à aller voir la vidéo de sa présentation
quand elle sera disponible sur le site du projet Plume), a néanmoins
fait remarquer qu’en matière de droit d’auteur appliqué aux logiciels
développés par des agents de l’État dans le cadre de leur travail,
l’administration restait titulaire des droits même si le fonctionnaire
restait l’auteur. Il appartenait donc à l’administration de décider du
régime de diffusion avec cette contrainte que le droit au nom de
l’auteur ne pouvait être bafoué. Attention ! Les thésards et plus encore
les stagiaires ne sont pas soumis à cette contrainte : leur travail leur
appartient en propre (voire à l’entreprise dans le cas de bourses CIFRE)
si aucune convention ne stipule le contraire. Une fiche assez bien faite
est consacrée à cette question sur le site web du projet Plume.
Incidemment, S. Canevet a rappelé que la GPL était tout à fait
applicable en France et que la licence CeCILL ne présentait donc guère
d’intérêt à ses yeux (d’autant que la question de son applicabilité à
l’étranger pourrait se poser [1]). Il a également fait valoir un point
de vue que je n’avais encore jamais entendu sur la multiplication des
licences libres : loin d’y voir un inconvénient, il y voit une force car
la chute de l’une d’elle devant les tribunaux laisserait les autres
intactes.
Plusieurs intervenants ont par ailleurs insisté à juste titre sur la
nécessité de considérer la question de la licence dès le démarrage du
projet (en tous cas avant sa première mise à disposition). En cas
d’absence de licence, c’est le droit commun, ici le droit d’auteur, qui
s’applique (les licences sont assimilées en France à des contrats qui,
en tant que tels, ne peuvent pas contrevenir à la loi mais peuvent, dans
son respect, en préciser les modalités d’application). Une FAQ est
également disponible sur le site de Plume sur ces questions de licences.
Ont été également évoqués en vrac et sélectivement :
- une fiche sur les serveurs de référencement
- différentes structures internes destinées à favoriser les
rencontres et les collaborations entre acteurs du développement ou
de l’administration système dans la communauté ESR - un projet de création d’une forge ESR (je n’ai pas trop compris
pourquoi SourceSup ne convenait pas, peut-être parce qu’elle
n’accueille que les projets publics, pas les projets internes) - les dépôts de brevets, licences, dépôts APP, etc, coûtent 10
millions d’euros par an au CNRS (les bénéfices globaux n’ont pas
été donnés, eux)
Voilà ! Désolé pour le style tour à tour télégraphique ou emberlificoté
mais je n’ai pas le temps présentement de faire mieux, ni de relire
d’ailleurs.
pp
