CR Journées Plume Septembre 2009

Education | CR Journées Plume Septembre 2009

Compte-rendu succint des Journées Plume de Septembre 2009

Les 22 et 23 septembre 2009 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 Économiques 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 les 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 logiciel libre 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 logiciels libres 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 logiciels libres 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 logiciel libre, 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 licences à copyleft faibles, soit d'employer une double licence (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 :

• la multiplicité des licences des bibliothèques de programmes (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 ce faire, ...)
• être prêt (et donc un minimum disponible) pour faire de l'assistance utilisateur (ou avoir développé une communauté qui fera ce travail pour soi)

C'est sans conteste la question de la valorisation économique des développement sous forme de logiciels libres 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 logiciels libres (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 pour masquer les vrais. 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 leurs méthodes de travail, n'aurait pas pu s'imposer auprès de ceux-ci s'il n'avait pas bénéficié 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 elle-même 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 video 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 ). 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 à l'agance de Protection des Programmes, etc, coûtent 10 millions d'euros par an au CNRS (les bénéfices globaux n'ont pas été donnés, eux)

---