référentiel

Qui fait référence

Applications et méthodes de monitoring Java

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 19/09/13
  • Correction mineure : 19/09/13
Mots-clés

Applications et méthodes de monitoring Java

  • Type de ressource : article, référentiel, résumé
  • Date de publication du document ou de l'événement : Avr 2013
  • Auteur(s) ou responsable(s) : Stéphane Deraco
  • Contact pour plus d'informations : java@services.cnrs.fr

Que faut-il surveiller ?

Surveiller une application peut vouloir dire plusieurs choses selon les besoins et le contexte de l'application. Par exemple, une application contrôlant un élément d'un accélérateur de particules ne sera pas surveillée de la même manière qu'une application chargée d'envoyer un mail dès qu'une page d'un wiki est modifiée.

La surveillance peut être technique (est-ce que mon application fonctionne correctement, est-ce que les performances sont acceptables, combien y a-t-il d'utilisateurs en ce moment) ou fonctionnelle (combien de factures ont été traitées ce mois-ci, pour quel montant).

Quels outils pour surveiller ?

Les outils de surveillance d'une application Java peuvent se diviser en deux catégories : les outils fournissant des données instantanées, et les outils permettant de conserver un historique des données, certains outils fournissant les deux.

Beaucoup d'outils utilisent la fonctionnalité JMX, qui permet d'exposer des informations via des MBeans.

Logs

La mise en place de logs est le minimum à faire dès lors que l'on souhaite surveiller une application.

La solution la plus basique est d'utiliser la méthode System.out.println pour écrire les lignes de logs dans la console. Le problème avec cette solution est qu'elle n'est pas évolutive : on ne peut pas choisir les niveaux de logs, ni quels composants logger.

C'est pour cela que l'on utilise un cadriciel (framework) de log. Les plus courants sont les suivants :

  • JUL (java.util.logging) : c'est le framework de logs implémenté dans la JVM. Il n'est pas beaucoup utilisé, car il n'a été introduit dans Java qu'à partir de la version 1.4.
  • Apache Log4J : c'est l'un des framework de logs les plus utilisés.
  • Logback : c'est un framework écrit par l'auteur de Log4j, qui apporte des améliorations par rapport à ce dernier.
  • Apache Commons Logging et SLF4J : ce sont des façades permettant de choisir l'implémentation de logs. L'utilisation de façade est utile car dans un projet Java utilisant plusieurs librairies tierces, chacune peut utiliser un framework de logs différent. La façade permet d'unifier cela.

Les avantages à utiliser un framework de logs sont les suivants :

  • Pouvoir choisir le niveau de logs à logger.
  • Pouvoir choisir, composant par composant, quel est le niveau de logs.
  • Les données loggées ont ainsi des priorités différentes.
  • Possibilité d'utiliser des destinations différentes pour les logs (fichiers, base de données, JMS, etc).

Avoir une librairie de logs ne suffit pas pour pouvoir surveiller efficacement son application Java. Le choix de ce qu'il faut logger est très important. Il n'en faut pas trop pour ne pas noyer les informations importantes, ni trop peu pour en avoir assez.

Il peut être intéressant d'avoir plusieurs destinations de fichiers de logs, selon les besoins :

  • un fichier full qui contient tous les logs,
  • un fichier securité contenant les logs relatifs à la sécurité (tentatives de connexions, actions sensibles, etc.),
  • un fichier audit pour pouvoir tracer les événements qui surviennent dans l'application.

Il est intéressant de noter que la destination des logs peut être autre chose que des fichiers, et qu'un même message de logs peut être envoyé vers plusieurs destinations. La plupart des librairies de logs permettent d'envoyer les logs en base de données, sur une file d'attente JMS, sur une socket, par mail ou encore sur le système de log Linux syslog. Cependant, il faut en général toujours envoyer les logs critiques au moins dans un fichier, pour être sûr qu'ils soient disponibles (une base de données peut ne pas être montée, le broker JMS peut être saturé, etc.).

L'utilisation de logs permet de surveiller ce qui se passe en temps quasi réel, mais aussi d'accéder à l'historique.

JMX

http://fr.wikipedia.org/wiki/JMX

JMX est une spécification Java permettant d'exposer des MBeans présents dans la JVM. Un MBean est simplement une classe Java exposant des getters et des méthodes.

Cela permet par exemple d'accéder à des attributs de la JVM tels que le temps total de compilation. On peut également appeler des méthodes.

Il est donc possible d'ajouter dans notre programme Java des MBeans afin de les exposer via JMX. Cela permet de remonter des valeurs, ou d'appeler des méthodes de notre programme. Par exemple, Tomcat expose les MBeans User, Role, mais aussi le nombre de requêtes pour chaque servlet. On peut également stopper un port donné, expirer une session, etc.

Utiliser JMX dans une application Java permet donc facilement, avec les outils adéquats, d'interagir avec l'application et de surveiller ce qui se passe dans la JVM, aussi bien au niveau technique qu'au niveau fonctionnel (il suffit d'écrire les MBeans correspondant).

La plupart des outils suivants se basent sur JMX pour remonter les informations.

JConsole

http://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html

JConsole est présent dans le JDK. C'est une interface graphique affichant des graphes décrivant le fonctionnement de la JVM. On y trouve par exemple un graphe affichant la mémoire Heap utilisée, le nombre de threads actifs, ou encore le pourcentage d'utilisation du CPU.

JConsole permet également de consulter les MBeans exposés par la JVM.

JConsole permet de se connecter à une JVM locale, mais également à une JVM distante (il faut effectuer une configuration au niveau de la JVM distante).

Dans le cas où le réseau bloque les ports empêchant JConsole de se connecter à une JVM distante, il est possible d'utiliser un tunnel SSH. Pour cela, on peut utiliser PuTTY :

  • Aller dans la section Connection/SSH/Tunnels, puis dans Add new forwarded port, renseigner un numéro de port quelconque dans Source port (ce sera le port du proxy SOCKS), puis sélectionner Dynamic.
  • Cliquer sur Add. Dans le tableau au dessus, une ligne doit s'ajouter avec le numéro de port préfixé par la lettre D.
  • Se connecter au serveur distant en SSH avec PuTTY.
  • Lancer JConsole avec la commande suivante : jconsole.exe -J-DsocksProxyHost=localhost -J-DsocksProxyPort=10000 (avec 10000 le port renseigné dans PuTTY).

JConsole permet de voir ce qui se passe à un instant donné dans l'application, mais ne permet pas de consulter l'historique. JConsole ne conserve que l'historique depuis son démarrage.

JVisualVM

http://docs.oracle.com/javase/7/docs/technotes/tools/share/jvisualvm.html

JVisualVM est également présent dans le JDK. Il reprend les fonctionnalités de JConsole sur l'affichage de graphes sur les mesures internes de la JVM.

JVisualVM ne permet pas de base d'accéder aux MBeans de la JVM. Cependant, il a un mécanisme de plugins qui permet de rajouter un onglet MBeans (VisualVM-MBeans) offrant les mêmes fonctionnalités que JConsole.

De plus, d'autres plugins sont intéressants :

  • Visual GC : affichage précis des différents pools de mémoire de la JVM, ainsi que les temps utilisés par le Garbage Collector.
  • Tracer-JVM Probes : sondes permettant d'afficher des graphes sur des comportements internes de la JVM (utilisation des Collections, les buffers NIO, etc.).

JVisualVM permet de se connecter à une JVM locale, mais également à une JVM distante (il faut effectuer la même configuration au niveau de la JVM distante que pour JConsole).

Dans le cas où le réseau bloque les ports empêchant JVisualVM de se connecter à une JVM distante, il est possible d'utiliser un tunnel SSH de la même manière que pour JConsole. Il suffit, après avoir activé le proxy SOCKS, d'aller dans JVisualVM dans le menu Tools > Options > Network (proxy SOCKS).

JVisualVM permet de voir ce qui se passe à un instant donné dans l'application, mais ne permet pas de consulter l'historique. JVisualVM ne conserve que l'historique depuis son démarrage.

JMX Term

http://wiki.cyclopsgroup.org/jmxterm

C'est un outil en ligne de commande permettant d'accéder aux MBeans. L'avantage c'est que l'on peut l'utiliser même si on n'a pas d'interface graphique (sur un serveur Linux sans X11 par exemple). Il est fourni sous forme d'un Jar exécutable.

Une fois le Jar lancé, on se connecte à une JVM locale, puis on navigue dans les domaines et les MBeans, pour enfin afficher les valeurs, les renseigner, ou appeler des méthodes.

JMX Term offre également la possibilité d'être utilisé via des outils de scripts, tels que Perl ou un shell. Voici par exemple un extrait du site de JMX Term :

open JMX, "| java -jar $jar -n";

 print JMX "help \n";

 my $host = "localhost";

 my $port = 9991;

 print JMX "open $host:$port\n";

 print JMX "domains\n";

 print JMX "close\n";

 close JMX;

JMX Term ne conserve pas d'historique.

jmxtrans

https://github.com/jmxtrans/jmxtrans

Cet outil a pour objectif d'extraire des informations de différentes JVMs, puis de les envoyer vers d'autres outils pour leur traitement. Il a pour vocation d'être performant avec un grand nombre de JVMs à analyser.

Il fonctionne en tâche de fond. Une fois lancé, il lit des fichiers de configuration écrits en JSON ou YAML, dans lesquels sont décrits les serveurs à analyser, le port JMX, les objets MBeans à interroger, et la façon dont envoyer les données des MBeans.

Par exemple, il est possible de lui demander d'interroger le MBean java.lang:type=OperatingSystem, et de récupérer les valeurs des attributs SystemLoadAverage et FreePhysicalMemorySize, puis d'envoyer ces valeurs dans un fichier texte.

La façon dont JMXTrans traite les données récupérées se fait par la notion de Writer. Il existe des Writers pour écrire les données sur la console, dans un fichier texte, mais aussi vers Graphite (outil web de visualisation de données), ou encore vers des fichiers de type RRD (utilisés entre autre par Nagios, Cacti).

JMXTrans permet donc de surveiller un ensemble de JVMs (sur des attributs de notre choix), et d'envoyer ces données à d'autres outils pour affichage ou analyse.

Par sa nature, JMXTrans permet de conserver l'historique : il tourne en tâche de fond, et les Writers accumulent les données reçues. C'est à la charge des outils externes (Graphite, Nagios, etc.) d'afficher ces données historisées.

Jolokia

http://www.jolokia.org/

Cet outil permet de récupérer les données des attributs de MBeans par des services web REST. Il se greffe dans une JVM et est ensuite interrogeable par une URL, dans laquelle on indique les MBeans à interroger (pour récupérer des valeurs d'attributs, ou appeler des méthodes). Le format retourné par l'URL est du JSON.

La façon d'intégrer Jolokia dans une JVM peut se faire de différente manière : via un war à mettre dans Tomcat, un bundle OSGi, ou un agent Java (spécifié dans la commande java lançant l'application).

Jolokia permet donc de faciliter l'interrogation d'une JVM pour obtenir des données sur son fonctionnement. Il est ensuite facile d'utiliser un autre outil tel que Nagios pour automatiser la récupération d'informations via Jolokia.

Jolokia fournit un instantané de ce qui se passe dans la JVM, c'est à la charge des outils qui l'utilisent d'historiser les données.

HawtIO

http://hawt.io/

C'est une webapp déployable sous un conteneur de servlet (Tomcat par exemple), qui permet de se connecter à une JVM locale ou distante (la connexion à une JVM distante se fait en utilisant Jolokia - Jolokia doit donc être installé sur la JVM distante).

HawtIO met à disposition une interface web permettant de consulter les données exposées (par JMX ou Jolokia) d'une JVM. Il est possible de consulter les données, mais également d'afficher des graphes pour des données numériques.

Ce projet est en plein développement, mais semble prometteur. Il a un système de plugin permettant d'afficher des vues spécifiques selon les frameworks utilisés dans la JVM. Par exemple, s'il détecte qu'il y a le broker ActiveMQ, alors il va rajouter un onglet spécifique facilitant la consultation des données du Broker. De même, si Tomcat est détecté, alors un onglet dédié permettra d'arrêter des applications, de voir les sessions, etc.

HawtIO permet de grapher les données numériques, mais l'historique se limite à la durée de connexion à HawtIO.

YourKit & JProfiler

http://www.yourkit.com/

http://www.ej-technologies.com/products/jprofiler/overview.html

Ces deux outils permettent, comme JConsole et VisualVM, de se connecter à une JVM locale et distante, et d'afficher des informations sur cette JVM.

La force de ces outils est de proposer des méthodes pour détecter ce qui consomme le plus de ressources dans le programme.

Notamment, la détection de fuites mémoire est grandement facilitée avec ces outils, qui montrent le nombre d'instances de chaque objet, et quels sont les objets qui gardent une référence sur ceux-ci, empêchant le garbage collector de les supprimer.

Eclipse MAT

http://www.eclipse.org/mat/

Cet outil est assez similaire dans les objectifs à YourKit et JProfiler, mais il fonctionne sur un Heap Dump. C'est à dire que son utilisation est plutôt post mortem.

Cette page explique comment générer un Heap Dump sur une application existante, et quels paramètres fournir à Java pour qu'il génère automatiquement un Heap Dump en cas de OutOfMemoryError. Cela permettra d'analyser a posteriori les causes d'une fuite mémoire sur un système en production.

Apache JMeter & Gatling

http://jmeter.apache.org/

http://gatling-tool.org/

Ce sont des outil de tests de performance, permettant de tester la résistance d'applications sous différents cas d'utilisation. Les tests de performances peuvent être de différents types, par exemple : tests de charge, tests de stress, tests d'endurance, etc. Cette page explique les différents types de tests.

Ils ne permettent pas d'analyser directement le fonctionnement d'une JVM (ni en cours de fonctionnement, ni à partir d'un Heap Dump), mais ils permettent de s'assurer que notre application (Java ou autre) réponde bien à différents scénarios. Ils produisent par contre des rapports et des graphiques permettant de s'assurer que notre application répondra correctement dans ces cas d'utilisation.

SourceSup : plate-forme pour l'hégergement de projets logiciels

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 24/07/13
  • Correction mineure : 24/07/13
Mots-clés

SourceSup : plate-forme pour l'hégergement de projets logiciels

Cette fiche est une nouvelle version de la fiche archivée suivante.

  • SourceSup est une plate-forme web de gestion de projet, destinée aux établissements d'enseignement supérieur (universités, écoles d'ingénieurs, ...) et aux organismes de recherche français. Un projet hébergé par SourceSup peut être diffusé publiquement ou bien être privé, il dépend d'un établissement, mais des utilisateurs d'autres établissements peuvent y contribuer. SourceSup est un service inclus dans la fédération éducation supérieure - recherche.
  • Les outils proposés sont :

    • Hébergement et gestion collaborative de sources par Subversion, git.
    • Serveur d'intégration continue Jenkins.
    • Serveur d'analyse de code Sonar.
    • Listes de diffusion.
    • Forums de discussion.
    • Outil de rapport de bogues, de demande de fonctionnalité, de gestion de patch, gestion de tâches.
    • Gestion de documentation, gestion de sondages, hébergement de pages web.
  • Le service SourceSup est gratuit et ouvert à tous les membres de l'éducation supérieure et la recherche.
  • Le service SourceSup est fédéré, toute personne ayant un compte dans la fédération d'identité nationale de l'éducation supérieure - recherche peut y accéder. Des comptes CRU peuvent aussi être utilisés dans des cas particulier.

Logiciels utilisés en démarche qualité

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 29/04/13
  • Correction mineure : 29/04/13
Mots-clés

Logiciels utilisés en démarche qualité

  • Type de ressource : article, référentiel
  • Date de publication du document ou de l'événement : Avril 2013
  • Auteur(s) ou responsable(s) : Henri Valeins (RMSB/CNRS)
  • Contact pour plus d'informations : Henri dot Valeins at rmsb dot u-bordeaux2 dot fr

Cette page liste les catégories de logiciels utilisés dans une démarche qualité en Recherche. Pour chaque catégorie, la liste des logiciels proposés est non exhaustive.

Préambule

La démarche qualité est avant tout un outil d'organisation, dans ce cadre il est nécessaire, entre autres, de :

  • gérer les ressources (matérielles et humaines) avec par exemple des outils de gestion de projet ou de gestion documentaire,
  • d'assurer la traçabilité de l'ensemble des actions avec par exemple des outils de gestion de stock,
  • de mesurer la satisfaction des "clients" avec par exemple des outils d'enquête.

Informations Générales

Diagnostic Qualité

Organisation

Gestion de ressources

La qualité est un outil organisationnel, il faut donc gérer les ressources (humaines et matérielles). On peut ainsi utiliser des logiciels comme :

Gestion de projet

Dans l'organisation, il faut suivre les actions. Pour cela, les outils de gestion de projet sont parfaits, comme par exemple :

Il faut aussi décrire les processus, pour ce faire, les logigrammes ou les cartes heuristiques peuvent être très efficaces :

Gestion Documentaire

On peut mentionner ces outils pour la gestion documentaire :

Suivi

Satisfaction client

En terme de statisfaction client, les outils de sondage sont utiles, comme par exemple :

Inventaire

La démarche qualité nécessite également des outils de gestion d'inventaire, avec des logiciels comme :

Traçabilité

Enfin, la traçabilité doit être gérée, avec par exemple :

VNC : prise en main de poste distant

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 23/10/12
  • Correction mineure : 04/02/13
  • Auteur : Dirk Hoffmann (Centre de Physique des Particules de Marseille (CPPM-IN2P3))
Mots-clés

VNC : prise en main de poste distant

Introduction

VNC désigne à la fois un protocole de prise en main d'un poste (sous Windows, Linux, MacOS, etc.) et les logiciels qui l'implémentent. Cette fiche ressource se veut générique dans le sens où elle décrit le protocole VNC ainsi que les caractéristiques communes aux logiciels qui l'implémentent.
Cette fiche reprend délibérément le format d'une fiche logiciel, plus exhaustif (et contraignant) qu'une fiche ressource.

Un site générique pour VNC en tant que protocole n'existe pas. Le domaine historique vnc.com renvoie vers le site de la société RealVNC, issue d'une partie de l'équipe initiale des développeurs et détenteur de la marque déposée VNC™. Voir plus loin pour les sites des différentes implémentations, commerciales ou libres, du protocole VNC.

Fonctionnalités générales

Prendre la main (vue de l'écran et contrôle du clavier et de la souris) sur une machine distante, pour faire par exemple de l'administration ou de l'assistance utilisateur. VNC utilise le protocole RFB (remote frame buffer), qui peut s'appliquer à tous les systèmes affichage "en fenêtres" (dont Windows, le protocole X11 et Macintosh). De par sa conception extensible, il a permis aux différentes implémentations (depuis la fin des années 1990) de rester largement compatible entre elles.

Plate-formes et interopérabilité

Fonctionne sur toutes les plate-formes majeures (Windows, Linux, MacOS, etc.), sans problème d'interopérabilité. Cela signifie qu'un client à partir d'un système d'exploitation donné peut se connecter à un serveur tournant sur un autre système d'exploitation. Cependant, l'interopérabilité entre les différents logiciels VNC (saveurs) n'est pas toujours donnée, surtout quand le logiciel serveur et le logiciel client ont des dates de fabrication trop éloignée l'une de l'autre.

Contexte d'utilisation dans mon laboratoire/service

  • serveur VNC sur un serveur Windows pour l'administration à distance,
  • serveur VNC sur des postes clients pour faire de l'assistance à distance,
  • serveur VNC sous Linux, des clients VNC permettent aux utilisateurs d'accéder à cet environnement depuis des PCs Windows.

Limitations, difficultés, fonctionnalités importantes non couvertes

Le protocole est vulnérable à certains types d'attaques, quoique le mot de passe et la transmission des données soient cryptés. Des solutions à base de tunnels SSH ou de VPN sécurisés permettent de pallier cette faiblesse.

Distributions dans lesquelles ce logiciel est intégré

Quasiment toutes les distributions Linux intègrent un client/serveur VNC.

Logiciels implémentant le protocole VNC

  • RealVNC: http://www.realvnc.com/, existe en version gratuite "Free" (licence propriétaire), "Personal" et "Enterprise Edition". La version Free est distribuée pour Windows, Linux x86, Solaris 7, HP-UX 11, code source (Unix) et code source pour le Viewer en Java et pour Windows.
  • TightVNC: http://www.tightvnc.com/, entièrement gratuit (octobre 2011) en licence GPL. Dernière version (2.5) serveur + client disponible pour Windows. Une version précédente (1.3) également en saveur "Unix-like", ainsi que source et "binaire" en Java pour un Viewer en version 2.6.
  • TigerVNC: http://tigervnc.sourceforge.net/, est un fork de TightVNC fondé par un ancien co-développeur de TightVNC pour diverses raisons. Ce dérivé se veut " high performing, stable and generic". Est disponible gratuitement en licence GPL.
    Je n'ai pas pu le tester, mais il est distribué avec Fedora 13 par exemple.
  • UltraVNC: http://www.ultravnc.fr/, gratuit en licence GPL, donations possibles, pour Windows.
  • Vine Server/Client : http://www.testplant.com/support/downloads/vine/, précédemment distribué sous le nom OSXvnc, est un couple serveur/client VNC libre et open-source de TestPlant, Inc., vendu également avec un service support par la même entreprise.

Des fiches logiciels pour ces applications n'existent pas actuellement dans PLUME. Si vous êtes utilisateur régulier d'une de ces "saveurs" de VNC, contactez l'auteur de la fiche pour contribuer à la collection avec votre description du logiciel.

Autres logiciels aux fonctionnalités équivalentes

  • Symantec pcAnywhere (client et serveur payants).
  • Windows Terminal server (payant) et client RDP (intégré à Windows ou rdesktop, FLOSS pour Unix)
  • Nomachine NX, logiciel commercial, mais version gratuite "Free Edition" disponible qui est limitée à deux utilisateurs (comptes) déclarés simultanément sur la machine serveur. (Voir NX-Freenx pour une implémentation gratuite.)

Historique et Éléments de pérennité

Le protocole a été développé à l'origine dans les laboratoires de recherche joints des sociétés Olivetti et Oracle. Les laboratoires ont été vendus en 1999 à la société AT&T, qui ferma les activités de recherche en 2002. Suivant cette fermeture, plusieurs développeurs du projet ont fondé RealVNC, afin de pouvoir continuer à produire le code open source et commercial sous ce nouveau nom. Les sources ont été mises sous licence GPL et réutilisées (forked) par plusieurs autres équipes de développement.
Aujourd'hui, de (trop ?) nombreuses implémentations du client/serveur disponibles sur la majorité des plate-formes existent.
Protocole éprouvé et très répandu.

Références d'utilisateurs institutionnels

  • ATLAS control room management / sysadmins (CERN).
  • Accès à distance local (labo) et international (collaborations) au CPPM (CNRS).
  • Utilisation de VNC pour l'administration et l'intervention à distance sur les postes gérés par les ASR du LAAS (CNRS).

Augmentation de la sécurité du protocole

Le protocole VNC n'était pas un protocole sécurisé à la base, et malgré des progrès récents, surtout dans des versions commerciales de l'implémentation, il convient de donner quelques conseils pour augmenter la sécurité.

Serveur VNC sous Windows

  • Via la base de registre côté serveur, il est possible de n'autoriser que certaines adresses ou plages d'adresses IP à se connecter à un serveur VNC en paramétrant une valeur "AuthHosts" ou "Hosts" selon l'implémentation de VNC utilisée ("AuthHosts" VNC et UltraVNC , "Hosts" pour RealVNC).

  • Le paramétrage d’AuthHosts est une clé de type REG_SZ employée pour indiquer un ensemble de masques d’adresses IP que les connexions entrantes doivent respecter afin d’être acceptées. Par défaut, le masque est vide et les connexions de tous les centres serveurs sont acceptées. Le masque est de la forme :
    +[masque d’IP]
    ?[masque d’IP]
    -[masque d’IP]

Explications :

Le [masque d’IP] représente l'adresse IP ou le masque de sous-réseau qui doit être pris en compte. Il peut être de la forme 192.168.1.10 (et désignera alors une adresse IP précise), ou 192.168 (et désigner l'ensemble du sous-réseau 192.168.x.x et toutes les adresses IP en faisant partie).

    • le symbole "+" indique que le [masque d’IP] correspondant est autorisé.
    • le symbole "-" indique que le [masque d’IP] correspondant est interdit.
    • le symbole "?" indique que le [masque d’IP] correspondant doit être accepté côté serveur par l'intermédiaire d'une fenêtre de dialogue.
    • le symbole ":" (VNC) ou "," (RealVNC) sert de délimiteur, permettant ainsi de définir plusieurs valeurs.

On aura donc par exemple comme valeur de clé :
HKEY_LOCAL_MACHINE\Software\RealVNC\WinVNC4
"AdminPassword"=hex:dc,c6,6b,58,6d,e4,19,7c
"Hosts"="+192.168.82.0/255.255.254.0,?192.168.0.0/255.255.0.0,-255.255.255.255/0.0.0.0"

Serveur VNC sous Linux ou Windows avec SSH

Il est possible de rediriger les ports utilisés par VNC vers la machine locale à travers un tunnel SSH afin d'en sécuriser la connexion : ainsi les mots de passe VNC ne transitent pas en clair sur le réseau.

ssh $SSH_SERVER -L$LOCALPORT:$VNC_SERVER:$VNCPORT

Le cadriciel cygwin peut fournir un serveur SSH pour une machine équipée de Windows.

Equivalents libres de certains logiciels commerciaux

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 26/09/12
  • Correction mineure : 09/10/12

Equivalents libres de certains logiciels commerciaux

Le Groupe Logiciel a lancé une enquête afin d'identifier les logiciels scientifiques commerciaux utilisés dans la communauté Enseignement Supérieur et Recherche, et qui feront l'objet d'un marché national "logiciels". Les besoins et résultats de cette enquête ont été synthétisés dans ce document.

Une collaboration entre PLUME et le Groupe Logiciel est par ailleurs en place afin entre autres de proposer des alternatives non propriétaires aux solutions logicielles commerciales. Ainsi, les logiciels équivalents cités ci-dessous sont uniquement ceux qui sont présents sur PLUME, donc cette liste n'est certainement pas exhaustive.

A noter également que cette liste n'est pas à considérer comme une préconisation d'utilisation d'un logiciel libre à la place d'un logiciel commercial, mais comme une information, au titre de la collaboration précitée.

EGI Applications Database (AppDB)

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 13/02/12
  • Correction mineure : 04/07/13
Mots-clés

EGI Applications Database (AppDB)

  • http://appdb.egi.eu/
  • Type de ressource : base de données, référentiel
  • Date de publication du document ou de l'événement : 2010
  • Auteur(s) ou responsable(s) :

    La communauté des utilisateurs et partenaires d'EGI.eu pour le contenu, certains partenaires pour le portail.

  • Contact pour plus d'informations :

    Le contact technique pour le portail est hg-02-iasa@iasa.gr

    Pour des renseignements sur le contenu, si vous travaillez en France, vous pouvez vous adresser, selon le cas, à l'équipe France Grilles qui participe à EGI ou à un représentant d'une communauté d'utilisateurs en France. Vous trouverez ces contacts sur le site de France Grilles.

EGI a mis en place une "Applications Database", dite AppDB, pour publier des informations concernant des outils de calcul scientifiques validés pour une utilisation sur l'infrastructure européenne d'EGI, "European Grid Infrastructure" et d'autres infrastructures européennes distribuées, "European Distributed Computing Infrastructures" (DCI). Les développeurs sont indiqués.

C'est un peu le pendant de Plume pour les infrastructures distribuées. A noter que les descriptifs sont rédigés par les développeurs et mis en ligne à leur initiative. Il n'y a pas de relecture de ces descriptifs ni de mise à jour systématique.

L'objectif est de promouvoir la réutilisation de ces outils pour éviter la duplication des efforts et faciliter l'usage de ces infrastructures.

Le contenu de la base est en anglais.

Article vs. Logiciel : questions juridiques et de politique scientifique dans la production de logiciels

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 14/10/11
  • Correction mineure : 31/05/13
Mots-clés

Article vs. Logiciel : questions juridiques et de politique scientifique dans la production de logiciels

Cet article est sous licence CC by-nc-nd. Il s'agit d'un document long, en voici une version PDF du 24 septembre 2012.

Introduction

Ce document continue et complète les études déjà publiées sur PLUME (voir le thème PLUME : Patrimoine logiciel d'un laboratoire) sur les logiciels développés dans les laboratoires et autres entités de la communauté d'enseignement supérieur et recherche. Il reprend des concepts exposés dans d'autres documents PLUME ; ils sont repris ici parce qu'on souhaite avoir une vision la plus complète possible, mais aussi parce qu'on change la perspective de l'étude.

L'objectif de ce document est donc l'étude de cet objet complexe, "logiciel d'un laboratoire" (ou d'un organisme d'enseignement ou de recherche). Il s'agit de comprendre les conditions de développement dans les laboratoires, et les questions que ces développements soulèvent. Les questions étudiées sont d'ordre juridique ou décisionnel.

D'après le travail mené dans PLUME depuis 2007, nous pouvons classer les différents points à prendre en compte lors du développement et de la diffusion d'un logiciel dans notre communauté comme suit :

  • formation, support
  • techniques : outils, briques, méthodes de développement, fiabilité, ...
  • communauté : gestion, prise de décisions, communication interne, résolution de conflits, communication externe, ...
  • (v) administratifs : dépôt APP, ...
  • (v) financement : contrats, postes, projets, ...
  • (v) juridiques : propriété intellectuelle et droit d'auteur, licences, brevets, contrats, ...
  • (v) politique scientifique : celle des laboratoires, celle des tutelles, propriété du code, contrats quadriennaux, reproductibilité de la recherche, libre accès, définition de procédures (de recensement, de diffusion, d'évaluation, de gestion du patrimoine), ...
  • politique/législatif : définition de standards, législation sur les brevets, ...

Les points signalés avec une (v) sont liés à la valorisation des logiciels et de la recherche. Dans la plupart de ces éléments on peut mentionner les bonnes pratiques qui sont à connaître, à utiliser, ou tout simplement à mettre en place. Ces problèmes se posent indépendamment du type de licence qu'on choisira pour la diffusion du logiciel ou du modèle d'exploitation.

Ce document considère l'étude de deux aspects : le point de vue juridique, lié au droit d'auteur et aux licences, et le point de vue de la politique scientifique. Pour cela, je compare les logiciels aux publications de recherche, plus particulièrement aux articles de recherche, pour mieux comprendre tous les aspects concernant la propriété intellectuelle, mais aussi pour saisir les aspects orientés vers la valorisation, l'évaluation de la recherche et la définition des politiques scientifiques. Lorsqu'on étudie les aspects juridiques, ce document fait référence au Code de la propriété intellectuelle (CPI) en France.

Je ne suis pas juriste, mais je m'intéresse à ce sujet depuis qu'une "mission logiciels" relative à la visibilité des logiciels du laboratoire m'a été confiée au sein de mon unité, le laboratoire d'informatique Gaspard-Monge (LIGM). Cette expérience s'est renforcée depuis mon intégration dans PLUME en décembre 2008. D'autres documents PLUME liés à cette étude sont classés dans le thème PLUME Patrimoine logiciel d'un laboratoire.

Des versions préparatoires de ce document ont été relues par Pascal Janots, responsable du SAIC de l'UPEMLV (service de valorisation de la recherche de l'université Paris-Est Marne la Vallée), Geneviève Romier (responsable thématique PLUME), Laurette Chardon (GREYC), Eric Barbry (Cabinet Alain Bensoussan), Konrad Hinsen (CBM), Florence Petit (IGM), Véronique Baudin (responsable thématique PLUME), Jean-Luc Archimbaud (rédacteur en chef PLUME en 2011), Emmanuel Courcelle (responsable thématique PLUME). Merci à ces personnes (et d'autres qui resteront anonymes), elles m'ont aidée à valider ce texte tant sur le fond que sur la forme.

Le contenu de ce document a fait l'objet de plusieurs présentations tout au long des années 2010 et 2011, principalement lors de FOSSA 2010 (Grenoble) et Solutions Linux/Open source 2011 (Paris). Ce document donne parfois mon opinion, mais il tente surtout de répondre aux nombreuses questions qui se posent sur ce sujet actuellement. Aucune erreur dans ce texte ne peut être attribuée aux relecteurs.

Si vous souhaitez réagir au contenu de ce document, ou y ajouter des nouveaux points, vous pouvez écrire des commentaires (en bas de cette page) ou contacter l'auteur.

Pour les lecteurs pressés

Ce document se résume succinctement dans les trois tableaux suivants :

Vous pouvez y repérer les points qui vous intéressent puis vous y rapporter dans le texte, chaque point est traité de façon assez indépendante du reste, mais il faut lire d'abord le point Définition : il est traité en premier et établit le cadre de comparaison.

Les points de comparaison entre articles scientifiques et logiciels

Ce document étudie 19 points de comparaison entre les articles scientifiques et les logiciels. Ces points sont classés en deux grandes sections : les aspects juridiques et les aspects décisionnels et relatifs à la politique scientifique. Ces 19 points sont présentés de manière synthétique dans le tableau suivant.

Article vs. Logiciel
Aspects légaux Aspects relatifs à la
politique scientifique
Droit d'auteur
Oeuvre
Auteurs
Propriétaires
Dates
Évolution de l'oeuvre
Travaux précédents
Diffusion
Droits
Licences
Définition
Signature
Références
Liste des oeuvres d'un laboratoire
Libre accès
Validation
Qualité et évaluation
Motivation
Objet
Table 1. Les 19 points de comparaison entre articles et logiciels.

Les points sont ordonnés selon une certaine logique. Dans les aspects juridiques, les points relatifs au droit d'auteur sont traités avant ceux associés aux licences, le point Auteurs est à traiter avant le point Propriétaires, les points Diffusion, Droits et Licences sont à étudier ensemble. L'ordre n'est pas trop important dans la section de politique scientifique : le point Définition est le plus important de cette liste, il est aussi utilisé pour donner le point de départ de ce document.

Le cadre de comparaison

Le point Définition est classé dans les aspects de politique scientifique, il est traité en premier pour fixer le cadre de la comparaison et définir les objets à comparer.

Définition

En général, un article de laboratoire est un article publié dans une revue scientifique dont un des signataires appartient à un laboratoire. C'est, en général, un objet bien compris qui ne pose pas de question.

Un "logiciel de laboratoire" continue à être un objet mal compris : j'entends par logiciel de laboratoire tout programme ou fragment de programme utile pour faire avancer la recherche et qui a été produit avec la participation d'un ou plusieurs membres du laboratoire. Ce qui est utile pour faire avancer la recherche comprend un large spectre. Cette définition peut s'élargir pour inclure des programmes développés pour des besoins d'enseignement, pour améliorer la gestion (contrats, bibliographie, recrutement, ...). Pour information, la définition de logiciel en termes juridiques est donnée par l'arrêté du Ministre de l'Industrie du 22 décembre 1981 relatif à l'enrichissement du vocabulaire de l'informatique : « Ensemble des programmes, procédés et règles, et éventuellement de la documentation, relatifs au fonctionnement d'un ensemble de traitement de données ».

Pour mieux faire le parallèle entre article et logiciel, on considère dans ce document uniquement les programmes qui ont été développés pour étudier un objet scientifique ou faire un calcul et qui ont donné lieu à des publications scientifiques (donc avec un "article de laboratoire" associé). On utilisera à ce propos le terme "logiciel de recherche" (comme traduction du terme anglais "scientific software") et le terme "logiciel académique" pour désigner un logiciel produit au laboratoire dans son interprétation la plus large.

Un logiciel de recherche reste, malgré la définition donnée, un objet mal défini : les quelques lignes écrites pour vérifier un calcul dans des logiciels comme Matlab, Sage ou autres ne sont pas facilement comparables avec un logiciel réalisé par plusieurs personnes pendant des années pour comprendre et accompagner le développement d'une théorie. Des difficultés similaires apparaissent lors de la comparaison des publications scientifiques. De façon analogue au traitement d'articles dans un laboratoire, les responsables des équipes et des laboratoires décident quand un programme (ou un article) fait partie de la production scientifique du laboratoire.

Mais cette décision peut ne pas être réduite au périmètre du laboratoire puisque, en général, les tutelles d'un laboratoire sont les propriétaires des logiciels qui y sont produits (voir le point Propriétaires) ; la définition doit donc être établie en fonction de la politique scientifique du laboratoire et doit prendre en compte l'avis et la politique scientifique des tutelles.

Aspects légaux

On étudie dans cette section des aspects liés au droit d'auteur et aux licences, en regardant les différences et similitudes entre les articles et les logiciels. On introduit aussi du vocabulaire juridique. Pour approfondir ces notions légales il faut se référer au Code de la propriété intellectuelle (CPI) ou aux spécialistes ; vous pouvez aussi consulter les informations sur La protection des logiciels par le droit d'auteur, par la Direction des Affaires Juridiques du CNRS ou le Framabook : Option Libre. Du bon usage des licences libres, par B. Jean. Ces références traitent, pour les logiciels, certains points esquissés ici.

Droit d'auteur

Les droits protégés par le Code de la propriété intellectuelle (CPI) sont automatiquement associés à l'auteur lors de la création de l'oeuvre, sous condition de son originalité. L'oeuvre doit aussi être mise en forme (texte, video, tableau, ...) : les idées, les concepts ne peuvent pas être protégés.

Le droit d'auteur ne s'applique pas de la même façon aux articles et aux logiciels, ces derniers bénéficient d'un traitement spécial.

Pour les articles comme pour les oeuvres en général, les droits d'auteur se divisent en deux classes :

  • Droits moraux : ces droits concernent la maîtrise de l'oeuvre ; ce sont des droits imprescriptibles, inaliénables, incessibles, et en général ils sont associés à des personnes physiques (les auteurs ou ses héritiers). Il y en quatre :
    • Droit à la paternité, relatif à la mention de l'auteur.
    • Droit de divulgation, relatif au moment et aux conditions de livraison.
    • Droit de repentir et de retrait, qui permet de revenir sur la cession des droits (patrimoniaux) d'une oeuvre.
    • Droit au respect de l'oeuvre, qui permet de s'opposer aux modifications.
  • Droits patrimoniaux : ces droits concernent l'exploitation de l'oeuvre, et sont des droits monnayables, cessibles, temporaires. On considère qu'il y a deux types d'exploitation : la représentation (par exemple d'une oeuvre de théâtre) et la reproduction (musique sur CD par exemple). Ces droits sont souvent associés à des personnes morales (à la suite des cessions effectuées par les auteurs) qui peuvent avoir (en fonction des contrats négociés) un monopole d'exploitation de l'oeuvre. On parle alors de détenteurs des droits patrimoniaux.

Pour les logiciels, il y a également des droits patrimoniaux et des droits moraux mais avec des différences par rapport à l'application du droit aux articles et aux oeuvres en général. Les différences que je souhaite mentionner dans ce document sont les suivantes :

  • Droits moraux (article L. 121-7 du CPI) : l'auteur ne peut (sauf stipulations contraires) s'opposer à la modification de l'oeuvre ou exercer son droit de repentir ou de retrait, sauf si ces modifications causent un préjudice à l'honneur ou à la réputation de l'auteur.
  • Droits patrimoniaux (article L. 113-9 du CPI) : ces droits sont (sauf stipulations contraires) dévolus à l'employeur.

Les droits moraux ne fonctionnent pas de la même façon pour les logiciels que pour les oeuvres en général. On parle donc de droits d'auteur (moraux) réduits pour les logiciels :

  • le droit à la paternité reste intact ;
  • le droit de divulgation remonte automatiquement à l'employeur (dans le cas des auteurs salariés, voir le point Propriétaires) ;
  • le droit de repentir devient non applicable ;
  • le droit au respect de l'oeuvre est réduit aux cas des modifications préjudiciables à l'honneur ou à la réputation de l'auteur.

L'originalité d'une oeuvre se manifeste au travers de « l’empreinte de la personnalité » de son auteur. Ce concept a été re-défini pour les logiciels selon le terme de «l ’apport intellectuel » : faire preuve d’un effort personnalisé allant au-delà de la simple mise en œuvre d’une logique automatique et contraignant (arrêt Pachot, 7 mars 1986).

Lorsqu'on ne connait plus de personne physique (auteur ou héritier d'auteur) associée aux droits moraux d'une oeuvre, on parle d'oeuvre orpheline. Les oeuvres (article L. 123-1 du CPI) entrent dans le domaine public lorsque la durée des droits patrimoniaux est atteinte, c'est-à-dire 70 ans après la mort de l'auteur d'un article. Le guide pratique PME : pensez propriété intellectuelle !" indique que la durée des droits patrimoniaux pour les logiciels est de 50 ans, donc par exemple, pour qu'un logiciel passe dans le domaine public en 2011, il faut que son auteur (s'il y a un unique auteur) soit décédé en 1961. Après ce délai l'oeuvre devient librement exploitable (en ce qui concerne les droits patrimoniaux), il n'y a plus de monopole d'exploitation. Un logiciel entré dans le domaine public n'est pas nécessairement un logiciel libre.

Il faut aussi remarquer que ce terme "logiciel du domaine public" est parfois utilisé, à tort, pour des logiciels avec des licences du type BSD ou sans copyleft. Rappelons aussi qu'en droit anglo-saxon, il y beaucoup plus de droits qui sont cessibles qu'en droit français, où toute cession comprenant des droits moraux est contraire au droit d'auteur. Le terme "logiciel du domaine public" a donc tout son sens en terminologie anglo-saxone. Le terme res derelictae semble aussi approprié.

Oeuvre

Dans le cas des articles, l'objet protégé par la loi est évident : c'est l'article.

Lorsqu'on parle d'un logiciel il faut savoir que le périmètre de protection est plus large et comprend le programme (code source, code compilé), le matériel de conception, la documentation, les interfaces, son titre.

Le matériel de conception et le titre d'un article sont aussi protégés par le droit d'auteur, mais à ma connaissance, ce type de question pose rarement de problème dans la communauté scientifique.

Auteurs

D'un point de vue légal, l'auteur d'une oeuvre est celui qui la réalise : celui qui écrit pour une oeuvre écrite, celui qui peint pour une peinture, ...

Les auteurs d'un article sont les signataires du document publié : l 'article L. 113-1 du CPI indique que la qualité d'auteur appartient, sauf preuve contraire, à celui (ou à ceux) sous le nom de qui l'oeuvre est divulguée. Ces personnes ont, d'un point de vue légal, le même pourcentage de participation à l'oeuvre, même si parfois l'ordre de la liste d'auteurs est interprété autrement dans la communauté scientifique (selon les différentes communautés).

En ce qui concerne le logiciel, déterminer si un contributeur à un logiciel en est l'auteur peut être un problème légal (voir par exemple Méthode pour tracer la propriété intellectuelle dans des codes logiciels). Ce n'est pas le cas d'une grande partie des logiciels des laboratoires, mais il peut y avoir des cas compliqués, en voici quelques-uns.

  • Des contributeurs qui n'ont corrigé que quelques lignes de code.
  • Des contributeurs qui ont beaucoup apporté à un logiciel mais leur partie a été entièrement re-écrite par une autre personne quelques années plus tard.
  • Des développeurs dont la contribution a été filtrée par un responsable du logiciel : cette contribution peut être plus ou moins modifiée lors de son intégration au code principal.
  • Des personnes travaillant en équipe qui expliquent et donnent les instructions pour écrire un programme : sans leur apport le programme n'existerait pas.
  • Les codes générés automatiquement : qui en est l'auteur ? Est-ce le programme qui les génère, l'ordinateur où ils ont été générés, l'auteur du code générateur ? Si la génération automatique du code peut se comprendre (d'un point de vue légal) de façon similaire à la compilation d'un code, l'auteur du code générateur est aussi auteur du code généré automatiquement.
    Je souhaite citer ici le cas de l'ordinateur Shalosh B. Ekhad qui signe des articles publiés.
  • Les codes traduits (par exemple de Fortran à C) : l'auteur du code original, est-il l'auteur du code traduit ? Il s'agit d'une oeuvre dérivée ou composite (article L. 113-2 du CPI), l'auteur de la traduction a des droits moraux et patrimoniaux sur la traduction, sous réserve des droits de l’auteur de l’œuvre initiale. Par exemple, les oeuvres de J. K. Rowling sont toutes signées du même auteur, et ce sont les contrats entre les éditeurs et les traducteurs qui négotient la page où on mentionne l'auteur de la traduction. Mais la question est compliquée dans le cas des logiciels en fonction de nouveaux apports qui peuvent être effectués lors de la traduction. À noter que la traduction de toute oeuvre (similairement à toute adaptation, transformation, arrangement ou reproduction) nécessite le consentement de l'auteur de l'oeuvre initiale (ou de ses ayants-droit, voir l'article L. 122-4 du CPI).

On pourra trouver bien d'autres exemples pour illustrer la nature intrinsèquement complexe de la définition d'auteur d'un logiciel. De plus, la génération de droits d'auteur pour ces contributions est soumise, comme pour toute oeuvre, à la condition d'originalité.

Pour éviter des possibles problèmes légaux, il convient d'avoir un document, actualisé régulièrement, qui mentionne les auteurs du logiciel et leur pourcentage de participation. Avoir un document daté et signé est un plus légal.

Pour tester la compréhension de ce concept difficile, on a posé la question suivante : est-il possible de faire un logiciel de façon anonyme ? L'anonymat ou l'utilisation d'un pseudonyme sont liés au droit moral de paternité. Cela correspond donc à un choix exclusif de l'auteur.

Sur cette question d'anonymat je souhaite citer les oeuvres publiées du célèbre mathématicien Nicolas Bourbaki : nom de plume d'un groupe de mathématiciens qui ont travaillé de façon anonyme et dont les oeuvres ont révolutionné la pensée mathématique mondiale. Une telle liberté scientifique, est-elle possible lorsqu'on parle d'un logiciel ? Sera-t-elle nécessaire un jour ?

Un autre exemple qui teste les limites du droit d'auteur est la célèbre encyclopédie Wikipédia.

Propriétaires

Pour un article, les auteurs sont propriétaires ou détenteurs des droits patrimoniaux de l'oeuvre d'un point de vue légal et partagent le même pourcentage de propriété. Par exemple, ce sont les auteurs qui signent les contrats de transfert des droits (d'exploitation) vers les éditeurs, aussi appelés cession de droits d'auteur (sur ce sujet il est intéressant de lire Avis du Comité d’éthique du CNRS (COMETS) sur les relations entre chercheurs et maisons d’édition scientifique et Avis de M. Farge pour le Comité d’éthique du CNRS sur les relations entre chercheurs et maisons d’édition scientifique, voir aussi Je publie, quels sont mes droits ? par la DIST).

Cela ne s'applique pas aux logiciels, qui font l'objet d'un traitement spécial par le droit d'auteur. Les propriétaires d'un logiciel sont ses détenteurs des droits patrimoniaux. L'article L. 113-9 du CPI stipule : "Sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur sont dévolus à l'employeur qui est seul habilité à les exercer."

Dans notre communauté, cela indique en général que les tutelles d'un laboratoire sont les propriétaires des logiciels, et ce sont elles qui doivent prendre les décisions qui impliquent les droits patrimoniaux associés aux logiciels : par exemple, le choix de la licence d'un logiciel, son exploitation, sa diffusion, ... Lorsque plusieurs auteurs d'établissements différents participent à un même logiciel, le pourcentage de propriété d'une tutelle se dérive du pourcentage de participation des auteurs employés par cette tutelle.

Par ailleurs, les auteurs qui n'ont pas un régime salarié (stagiaires, professeurs émerites, ...) sont aussi propriétaires du logiciel, en fonction de leur participation, sauf s'il existe des dispositions qui précisent ces droits dans un contrat ou autre document, (voir Méthode pour diffuser un logiciel de laboratoire : recommandations juridiques et administratives).

Les contrats (de collaboration, de commande, ...) qui sont parfois établis peuvent indiquer qui est le propriétaire du logiciel obtenu.

En conclusion, les détenteurs des droits patrimoniaux ou propriétaires d’un logiciel sont établis en fonction de :

  • les auteurs,
  • leur statut et leur mode de participation,
  • les contrats entre employeurs et les salariés qui participent au développement,
  • tout autre contrat qui traite du développement de logiciel (par exemple les contrats de collaboration, de commande),
  • dans le cas particulier d'un laboratoire, les conventions entre tutelles (ou le droit conférant à un mandataire unique, voir l'article R. 611-13 du CPI) peuvent décider du traitement de ces droits patrimoniaux.

Dates

Pour un article, les dates importantes sont la date de soumission et la date de publication.

Pour un logiciel, une des dates importantes est celle associée au matériel de conception. En effet une oeuvre est protégée par le droit d'auteur si elle est originale ; déterminer si une oeuvre est originale peut demander l'intervention de juges et autres experts. D'autres dates importantes pour un logiciel sont celles des versions qui indiquent des fonctionnalités importantes ajoutées ou des évolutions notables, toujours soumises par le droit d'auteur à une condition d'originalité.

Le matériel préparatoire peut servir à dater un article, mais en général la communauté scientifique évite cette question en publiant rapidement une première version du travail.

Au milieu du bazar que peut constituer le développement d'un logiciel (voir l'article La Cathédrale et le Bazar), on peut comprendre les difficultés auxquelles les juges font face lorsqu'ils doivent prendre des décisions : l'existence de dates clairement établies et d'une valeur légale irréfutable est importante. Ceci explique pourquoi les dépôts APP, les registres IDDN et autres (voir L'agence de protection des programmes (APP) et le registre Inter Deposit Digital Number (IDDN)) sont appréciés par les tutelles et le monde juridique. D'autres moyens existent, mais il faut veiller à leur valeur juridique.

Évolution de l'oeuvre

Sans aucun doute l'évolution d'un article est en général un autre article, c'est-à-dire une nouvelle oeuvre, avec ses auteurs, son titre et son contenu, tout-à-fait indépendante de l'article précédent (d'un point de vue juridique).

L'évolution d'un logiciel est en général une nouvelle version du même logiciel. S'agit-il d'une nouvelle oeuvre (indépendante de la précédente, dans le même sens que pour les articles) ? Je n'ai pas de réponse à cette question, et je crois pouvoir affirmer que dans le monde du logiciel, beaucoup d'aspects restent encore mal compris.

Une chose est claire, à chaque nouvelle version d'un logiciel, il faut tout revoir : la liste d'auteurs et leur pourcentage de participation, la description de l'oeuvre et l'originalité des nouveaux apports, les propriétaires et les dates associées.

Travaux précédents

Dans un article on cite les oeuvres précédentes et les oeuvres liées au travail en cours. Cela ne pose pas en général de problème juridique.

Un logiciel peut incorporer et modifier d'autres briques logicielles. Les problèmes légaux peuvent apparaître lorsque l'on étudie la compatibilité des licences des briques utilisées et l'héritage de licence envers le logiciel en cours. Les licences et droits d'utilisation doivent être regardés avant l'utilisation des briques, puisque le fait de les utiliser implique que leurs licences ont été acceptées et que le contrat que ces licences représentent est en application.

Des logiciels comme FOSSology, OSLC et les formats de description des informations de licence et copyright SPDX et Open source cartouche peuvent être utiles pour éclaircir les questions de compatibilité et héritage de licences dans la gestion des cas compliqués.

Diffusion

La diffusion d'un article se fait normalement par les éditeurs d'une revue. Depuis quelques années, la diffusion se fait aussi en utilisant le web, par les éditeurs, les auteurs ou bien par le moyen des pages web personnelles et des sites comme ArXiv, HAL et autres.

Les logiciels se diffusent souvent par le web, en utilisant parfois des forges. Avant sa diffusion, il faut réfléchir à la licence qui va accompagner le code.

D'un point de vue légal, diffusion signifie donner l'oeuvre à quelqu'un, peu importe le support (citons par exemple l'affaire sur la FreeBox en cours de jugement, voir par exemple Séminaire "Construire son projet sur du libre : quelles précautions prendre ?). Il est souhaitable d'avoir des licences en place ou bien des contrats de collaboration avant tout échange de logiciel.

Droits

Tout le monde peut lire un article. Il peut y avoir une barrière scientifique, mais il n'y a pas de barrière légale. Copier une oeuvre peut être illégal, à la différence de la citer (article L. 122-5 du CPI).

De façon similaire, il est possible de lire un code, tout au moins essayer. Il peut y avoir aussi des barrières scientifiques et peut être de langage (de programmation). Mais l'utilisation d'un code sans avoir le droit explicitement donné (voir l'article L. 335-2 du CPI et la page 3 du Guide pratique d’usage des logiciels libres dans les administrations) relève de la contrefaçon, et similairement pour la modification d'un code, sa copie, sa redistribution, ... Il est utile de donner des licences aux logiciels pour établir clairement les droits octroyés.

Licences

On utilise de plus en plus de licences du type CC et autres pour les documents diffusés par le web, même pour des articles publiés dans des revues scientifiques, voir par exemple la politique de copyright de la revue Logical Methods in Computer Science ou la politique Oxford Open.

On donne des licences aux logiciels, en particulier des licences libres. Toute licence qui n'est pas libre est une licence propriétaire. Il existe donc des logiciels libres ou propriétaires (les termes logiciel privatif ou logiciel non-libre sont aussi utilisés) en fonction de la licence qui les accompagne. Un logiciel peut être accompagné de plusieurs licences et donc, il peut être libre et propriétaire à la fois. L'utilisation de licences multiples donne aux utilisateurs le choix de licence à utiliser et aide à traiter des problèmes de compatibilité. Lorsque plusieurs licences sont présentes sur une brique logicielle, la plus permissive l'emporte.

De plus, différentes parties d'un logiciel peuvent être associées à des licences différentes (comme les interfaces graphiques). Le terme "logiciel semi-libre" est parfois utilisé dans ce cas, je préfère l'éviter : mal défini, il reste ambigu et peut donner lieu à des interprétations contradictoires.

Les licences font intervenir des droits patrimoniaux, elles doivent se mettre en place avec l'accord de tous les détenteurs de ces droits (qui demandent souvent, en pratique, l'avis des auteurs).

Les licences donnent des droits et imposent des obligations qui sont à respecter.

Nées dans le milieu scientifique, les licences libres sont particulièrement utiles pour les logiciels de recherche (voir par exemple "Pourquoi diffuser un logiciel développé dans un laboratoire ou une université avec une licence libre ?). Prenons par exemple le cas où des stagiaires sont intervenus dans un développement, ils sont détenteurs des droits patrimoniaux au même titre que les employeurs des collaborateurs salariés. Dans ce cas, la licence libre permettra l'évolution du logiciel au laboratoire et aussi à l'exterieur (si les stagiaires souhaitent continuer leur projet après la fin du stage) dans le respect des droits de tous les ayants droits impliqués dans ce logiciel. Un autre cadre où les licences libres sont particulièrement utiles est celui des collaborations internationales ou encore celui où les développeurs prévoient une forte mobilité (entre employeurs).

Certains juristes semblent ne pas décider si les licences libres sont ou non des contrats. D'autres juristes (voir par exemple la thèse "Les oeuvres libres" de Mélanie Clément-Fontaine à l'Université de Montpellier 1, 2006) affirment que ce sont des contrats entre les auteurs et les utilisateurs ou les lecteurs : ce sont des contrats passés à titre gratuit et qui ont une vocation internationale. Des jurisprudences en France confirment que c'est de cette deuxième façon que les juges comprennent et appliquent ces licences (voir par exemple "Les logiciels libres : soumis au droit d'auteur, dans un contexte international, une jurisprudence en émergence, des défis à relever" RMLL'09).

Tableau récapitulatif sur les aspects légaux

Voici un tableau qui récapitule les 10 points traités :

Article vs. Logiciel : aspects légaux

Article Logiciel
Droit d'auteur oeuvre protégée :
droits moraux,
droits patrimoniaux
oeuvre protégée mais traitement spécial CPI :
droits moraux réduits,
droits patrimoniaux dévolus à l'employeur
Oeuvre article code source, code objet,
documentation, matériel de conception, ...
Auteurs signataires,
même %
notion complexe, problème légal,
établir un % de participation
Propriétaires -
Droits patrimoniaux
auteurs,
même %
tutelles en général, mais dépend
du régime salarié des auteurs et
des contrats (de collaboration, de commande, ...)
Dates soumission, publication matériel de conception, versions
Évolution de l'oeuvre oeuvre indépendante œuvre indépendante ?
il faut revoir auteurs, dates, licences, ...
Travaux précédents références, citations briques logicielles :
compatibilité et héritage de licences
Diffusion éditeur, web web, forges
besoin de licence
Droits lire, citer, ne pas copier lire, ne pas utiliser, ne pas modifier, ...
besoin de licence
Licences Creative Commons (web) droits et obligations,
libres ou propriétaires
Table 2. Les 10 points « aspects légaux » de comparaison entre articles et logiciels.

Ce tableau nous aide à mieux comprendre les différences entre le droit d'auteur des articles et le droit d'auteur des logiciels. On observe que le modèle légal des articles fonctionne bien dans les laboratoires et ne pose pas de problème en général.

Le cadre légal des logiciels est un peu plus compliqué, les logiciels bénéficient d'un traitement spécial par le droit d'auteur. La notion d'auteur d'un logiciel peut être complexe et donc relever d'un problème légal. En fonction du nombre d'auteurs et du cadre de collaboration, la gestion des droits patrimoniaux peut devenir aussi complexe. D'autres problèmes juridiques seront liés à la contrefaçon.

Un des moments les plus importants de la vie d'un logiciel est celui de la diffusion. Il faut réfléchir aux licences qui vont être données au code. Mais avant de s'occuper des licences, il faut avoir mis au clair tous les aspects liés au droit d'auteur (voir par exemple Méthode pour diffuser un logiciel de laboratoire : recommandations juridiques et administratives). Les licences doivent être mises en place avant la diffusion de l'oeuvre. C'est une question d'actualité, tant pour les articles (voir par exemple Journées du réseau Médici, Grenoble, MSH Alpes, 5 et 6 avril 2011 - Mutualiser les bonnes pratiques : quelles réalités et quel avenir pour l'édition scientifique publique ?) que pour les logiciels, liée à la diffusion de documents par le Web.

Les licences (en particulier les licences libres) sont utiles pour simplifier et clarifier le cadre juridique et les droits octroyés qui permettent l'utilisation, la modification et la redistribution d'une oeuvre. Les problèmes que les licences peuvent faire apparaître sont liés à la compatibilité (lorsque plusieurs briques logicielles sont utilisées), à l'héritage ou au non respect des licences.

Les lois sont propres à un pays, et ce qui est légal dans un pays peut être illégal dans un autre. La diffusion des documents et des logiciels en utilisant le web ne connaît pas ces frontières, ce qui complique parfois les aspects légaux associés à cette diffusion.

Aspects relatifs à la politique scientifique

La politique scientifique fait intervenir des décisions qui relèvent de niveaux différents, en voici un classement :

  • (C) les chercheurs, les développeurs, les auteurs, les membres d'un laboratoire
  • (L) un laboratoire, sa direction
  • (T) les tutelles et autres organismes financeurs de la recherche en France
  • (CSI) la communauté scientifique internationale au sens large, ce qui comprend par exemple la politique scientifique européenne, les politiques des revues scientifiques, et autres.

Les points traités dans cette section seront classés en fonction de l'intervention de ces quatre niveaux de décision.

Définition (L, T)

Ce point Définition est traité au début du document, il est classé (L, T). Pour un article, ce sont les laboratoires qui établissent les normes pour déterminer si un article fait partie de sa production scientifique. Cette décision est "validée" par les tutelles lors des évaluations des laboratoires. Pour un logiciel, à cause de la gestion des droits patrimoniaux, cette décision fait aussi intervenir les tutelles ou autres organismes financeurs.

Signature (C, T)

Un article est signé par ses auteurs. La signature de l'article contient donc les informations sur les auteurs suivant un certain format. On y mentionne leur affiliation : leur laboratoire, leur institution, une adresse. Le format à suivre pour cette signature est décidé par les tutelles d'un laboratoire. La signature d'un article par un membre d'un laboratoire ou d'une institution est, en général, un objet bien défini (voir par exemple Préciser la genèse des documents diffusés).

La ligne "Copyright ou Droits patrimoniaux" d'un logiciel doit mentionner ses propriétaires. Elle peut être facile à déterminer lorsque la liste d'auteurs est bien établie, ainsi que leurs affiliations ; mais parfois elle n'est pas évidente à déterminer. Considérons par exemple un laboratoire avec 3 tutelles. Quelle est la signature du logiciel fait par un doctorant qui est physiquement installé dans les locaux de la tutelle 1 et travaille sous la direction du professeur de la tutelle 2 et en collaboration avec un membre de la tutelle 3 ? Il faut se référer aux conventions entre les tutelles (contrats quadriennaux, ...) définissant le statut du laboratoire. De plus la notion d'"établissement hébergeur" peut être appliquée (voir l'article R. 611-13 du CPI).

La signature d'un logiciel est (à mon avis) un objet mal défini. On peut convenir d'appliquer aux logiciels des normes similaires à la signature d'articles à défaut des règles spécifiques, en associant les logiciels aux laboratoires dans lesquels ils sont développés.

Désormais les informations de licence d'une oeuvre dévraient faire partie de la signature de cette oeuvre.

Références (L, T)

En France, les archives HAL peuvent gérer les références d'articles, qui proviennent souvent d'un dépôt de l'article complet. Il est ainsi possible de récupérer la bibliographie d'un laboratoire.

La plateforme PLUME publie des fiches descriptives de logiciels produits dans les laboratoires de recherche. Grâce à son mécanisme d'indexation, on peut obtenir la liste des logiciels associés à un laboratoire ou à une institution.

Des sites bibliographiques gèrent des fiches d'articles : une référence complète suivie d'un résumé. L'objectif du projet RELIER est la publication des fiches de développements ESR pour décrire succinctement les logiciels produits dans les laboratoires.

Liste des articles/logiciels d'un laboratoire (L, T)

Chaque laboratoire gère et publie sa liste d'articles. Ce document est revu régulièrement et surtout mis à jour lors de l'évaluation du laboratoire.

La liste complète des logiciels d'un laboratoire existe rarement. Parfois il s'agit d'une liste bien gérée en interne et souvent quelques logiciels sont affichés dans le site web du laboratoire. La liste de logiciels d'un laboratoire est en général un objet inconnu.

Le document Guide laboratoire pour recenser ses développements logiciels est destiné à ceux qui souhaitent référencer des logiciels d'un laboratoire (ou d'une institution).

Libre accès (C, L, T, CSI)

Des politiques d'accès libre (free/open access en anglais) sont de plus en plus courantes dans la communauté scientifique internationale, des organismes français comme le CNRS, l'INRA, l'INRIA, l'INSERM, et la Conférence des Présidents d'Université ont signé la Déclaration de Berlin (nov. 2003) sur le libre accès à la connaissance.

Conformément aux conditions des subventions de l'Union européenne qu'ils reçoivent au titre du 7e PC (programme-cadre pour les activités de recherche, de développement technologique et de démonstration), les chercheurs sont censés déposer le texte intégral de leurs publications dans un référentiel public qui les rendra accessibles dans le monde entier de manière permanente. L'initiative OpenAire (Open Access Infrastructure for Research in Europe), lancée en novembre 2010, offre un réseau de bases documentaires publiques européennes donnant libre accès en ligne aux connaissances produites par ces scientifiques. En accord avec cette politique, l'ANR incite les chercheurs à intégrer leurs publications dans le système d'archives ouvertes HAL.

La déclaration de Berlin est suivie de la déclaration de Ghent (janv. 2011) qui renforce l'initiative du libre accès à la connaissance vers la création et l'utilisation des données ouvertes, des logiciels libres et des ressources éducatives ouvertes pour assurer l'intégration des quatre sections du développement libre : publications, données, logiciels et ressources éducatives dans les programmes de recherche de la Communauté européenne.

Pour les articles, la politique d'accès libre promue par les organismes financeurs de la recherche se met en place dans les revues scientifiques, voir par exemple les revues Logical Methods in Computer Science ou Bioinformatics qui affichent une politique de free/open acces. Le Comité d’éthique du CNRS (COMETS) a émis un avis sur le libre accès aux publications scientifiques (« open access »), le document PLUME Free/Open Access - L’accès libre à la science et le LIGM. Présentation du 6 mars 2012 étudie également les questions sur le libre accès.

La mise en place d'une politique en accord avec ces déclarations pour les logiciels de recherche correspond d'une part à l'adoption de licences libres et d'autre part au lancement des dépôts où les logiciels peuvent être accessibles (ce qui est, de plus, lié aux articles L. 131-2, R. 132-9, R. 132-10 du Code du patrimoine lorsque le logiciel est diffusé sur un support physique).

Sur ce deuxième point je souhaite mentionner que la plateforme PLUME recueille des informations sur les logiciels mais pas les logiciels eux mêmes. Les forges peuvent remplir ce rôle de diffusion de logiciels, l'initiative Projet de forge Ens Sup Recherche - le périmètre restant à définir est en cours.

Je l'ai déjà indiqué, les licences libres sont utiles pour clarifier et simplifier le cadre juridique des logiciels de recherche. L'adoption de politiques de licences (libres) par défaut par les tutelles simplifie la gestion et permet aux chercheurs une diffusion rapide de leur oeuvre, sans attendre des délais d'acceptation de licence qui ne seront pas très utiles pour la majorité des logiciels de recherche. Des versions plus évoluées du même logiciel feront peut-être intervenir des projets de collaboration ou auront besoin d'autres modèles de valorisation. L'adoption de licences libres à copyleft fort donne une garantie de plus pour le libre accès au logiciel et à ses oeuvres dérivées dès que sa diffusion est assurée.

Les licences (libres) ont donc une dimension juridique et une dimension de politique scientifique : deux dimensions bien différentes mais très entrelacées.

Assurer l'accès libre à la recherche fait intervenir tous les niveaux de décision, d'où le classement (C, L, T, CSI) de ce point.

Validation (C, L, T, CSI)

La publication d'un article fait l'objet généralement d'une procédure de soumission et de validation de contenu ("procédure de referee"). Le document soumis est évalué par des experts du domaine, ils indiquent des corrections si nécessaire et proposent ou non le travail à publication.

Qui valide un logiciel ? Une bonne batterie de tests peut indiquer qu'il fonctionne comme les auteurs l'attendent, mais il peut être peu évident que les résultats produits par un logiciel soient valables d'un point de vue scientifique.

PLUME aborde ce concept de logiciel validé au sens PLUME et établit des critères de validation basiques : pour contourner la difficulté d'une analyse fine du logiciel, ils sont basés sur l'utilisation du logiciel ou non dans un ou plusieurs sites en environnement de travail réel (en production).

Il arrive que des résultats publiés dans des articles soient obtenus avec des logiciels développés à cette intention. Si les logiciels ne sont pas diffusés, la reproductibilité de la recherche n'est pas garantie (voir par exemple Reproducible Research). Cela peut mettre en cause la validation d'un article publié sans accès au logiciel associé. Des réponses récentes à cette question sont proposées par exemple par les publications executables, ActivePapers ou RunMyCode.

L'amélioration de la validation des résultats de recherche fait intervenir des décisions à tous les niveaux, d'où le classement (C, L, T, CSI) de ce point.

Qualité et évaluation (C, L, T, CSI)

Une des mesures utilisées pour déterminer la qualité de l'article est son indice de citation et autres indicateurs bibliométriques (voir par exemple Du bon usage de la bibliométrie pour l'évaluation individuelle des chercheurs).

La qualité d'un logiciel peut se mesurer par celle des articles associés au logiciel, mais aussi par les utilisateurs qu'il est capable d'attirer, les collaborations et les contrats qu'il est capable de générer.

Des méthodes de développement logiciel peuvent aider à avoir des logiciels d'une meilleure qualité, mais un logiciel de recherche de bonne qualité scientifique ne veut pas dire que l'on a un logiciel de bonne qualité d'un point de vue technique. Il ne faut pas donc confondre ces deux concepts.

L'évaluation de l'activité scientifique est basée presque exclusivement sur la liste de publications ; il est nécessaire de définir des critères d’évaluation pour les autres réalisations de la recherche comme par exemple les logiciels (voir la page 34 de Du bon usage de la bibliométrie pour l'évaluation individuelle des chercheurs ou aussi le document L'évaluation individuelle des chercheurs et des enseignants-chercheurs en sciences exactes et expérimentales), les bases de données, les prototypes matériels, les molécules, ... En bref, pour toute la production scientifique d'un laboratoire différente des publications.

Motivation (C, L, T, CSI)

Quelle est la motivation pour écrire un article ? En général, l'article sert à la diffusion de connaissances, à montrer l'état d'avancement d'un travail de recherche. Le fait d'ajouter un élément à la liste de publications (personnelle, d'équipe) est aussi une bonne motivation.

Quelle est la motivation pour réaliser un logiciel (de recherche) ? En général, le logiciel a été fait pour comprendre un objet scientifique ou mener une étude, pour prouver une théorie, réaliser un calcul, pour obtenir des nouveaux résultats ou valider une publication. Il peut être vu aussi comme un canal de diffusion de connaissances. Mais, d'après mon expérience, le logiciel en lui-même est rarement la motivation principale dans le milieu de la recherche.

Ceci explique en partie le fait que les développeurs de logiciels scientifiques souhaitent rarement diffuser leurs codes : ils considèrent souvent qu'ils sont mal écrits et ils ne souhaitent pas perdre du temps à faire des codes plus structurés ou tout simplement documentés. De plus ces codes sont souvent écrits par des scientifiques qui n'ont pas de formation en développement de logiciels.

Le fait qu'il n'y ait pas une vraie procédure de validation renforce les motivations pour ne pas diffuser les logiciels de recherche.

Ces codes peuvent être mal écrits par des personnes avec peu de moyens (humains) ou peu de formation, mais cela ne devrait pas (à mon avis) être un obstacle pour reconnaître, apprécier et valoriser cette énorme quantité de travail de développement qui se fait dans les laboratoires. Les acteurs des décisions politiques à tous les niveaux devraient agir pour faire évoluer la situation, en particulier pour les logiciels associés aux articles de recherche, puisque leur diffusion est importante pour la validation des articles associés et nécessaire à la reproductibilité de la recherche, à son libre accès.

On comprend alors que si la motivation n'est pas de faire un logiciel, on s'occupera peu ou pas du tout de ses aspects légaux ou de sa diffusion.

Objet (C, L, T, CSI)

Tandis qu'un article est clairement un objet scientifique et que d'autres aspects de transfert de technologie sont gérés par des contrats et autres documents, un logiciel est un objet "3D" : il est à la fois un objet scientifique mais aussi potentiellement un objet de transfert de technologie, voire un objet industriel (voir Stratégie de l'INRIA sur le logiciel libre). Ces deux dernières dimensions sont mal connues et peu comprises dans les milieux scientifiques qui ont peu d'interaction avec les services de valorisation. Mais ces dimensions sont là, intrinsèques à l'objet, et il faut agir en conséquence.

Tableau récapitulatif des aspects relatifs à la politique scientifique

Voici un tableau qui récapitule les 9 points traités :

Article vs. Logiciel : aspects de politique scientifique
Article Logiciel
Définition (L, T) ok à définir
Signature (C, T) ok,
définie par les tutelles
à définir (ligne de copyright),
associer les laboratoires
Références (L, T) HAL PLUME
Liste des oeuvres
d'un laboratoire (L, T)
document à jour document inconnu,
PLUME peut être utile
Libre accès
(C, L, T, CSI)
politique (+/-) ok,
dépôt ok (HAL)
politique (licences) à définir,
dépôt à établir
Validation
(C, L, T, CSI)
procédure de referee,
reproductibilité
à définir
validé (au sens PLUME)
Qualité et évaluation
(C, L, T, CSI)
nombre de citations en fonction des articles associés,
capacité d'attirer d'utilisateurs, de contrats
Motivation
(C, L, T, CSI)
recherche, article recherche, pas le logiciel
Objet
(C, L, T, CSI)
scientifique 3D : scientifique, mais aussi potentiel
de transfert de technologie, industriel
Table 3. Les 9 points « aspects de politique scientifique » de comparaison entre articles et logiciels.

Ce tableau nous aide à mieux comprendre les différences dans les modèles de production d'articles et de logiciels dans un laboratoire. Le modèle des articles fonctionne bien, il est bien maîtrisé depuis des décenies. Le seul point rouge que j'ai signalé, la reproductibilité des résultats, est lié au logiciel (non diffusé) associé à un article publié : pour le moment, le rôle de ces logiciels dans la procédure d'acceptation de l'article n'est pas bien défini. Les publications executables proposent et autres des réponses à cette question, l'avenir nous dira si elles sont retenues par la communauté scientifique.

Pour les logiciels, des questions importantes comme la définition d'un logiciel de laboratoire (large ou avec des restrictions, avec ou sans diffusion, ...), sa signature, les conditions de sa diffusion, leur rôle dans l'évaluation de la recherche et autres sont encore à étudier et à faire évoluer.

Il n'y a pas, à ma connaissance, une procédure de validation des logiciels bien établie dans la communauté scientifique, même lorsque ces logiciels sont associés à l'obtention de résultats soumis à publication. Ceci n'aide pas à motiver les chercheurs à une diffusion de ce travail indispensable aujourd'hui pour faire évoluer la recherche.

Comprendre le logiciel en tant qu'objet complexe dans ses dimensions scientifique, de transfert de technologie et industrielle aidera à étudier et à décider les questions que le recensement complet des logiciels d'un laboratoire pose. Ces dimensions n'auront pas le même poids partout (en fonction souvent du thème scientifique, de l'objectif du logiciel, ...) mais leur analyse est nécessaire pour établir la stratégie scientifique d'un laboratoire.

Conclusion

On a étudié dans ce document les différences et similitudes entre articles et logiciels de recherche avec le double objectif de mieux comprendre les problèmes juridiques et décisionnels que les développements logiciels posent au sein des laboratoires et d'améliorer leur gestion. Nous avons étudié 19 points, et séparé les aspects légaux, relatifs au droit d'auteur et aux licences, des aspects relatifs à la politique scientifique.

Ces deux aspects sont communs à tout laboratoire avec une production logicielle, indépendamment de leurs thèmatiques scientifiques. Le fait de soulever ces questions apporte (je l'espère) un début de réponse qui sera à adapter pour chaque laboratoire en fonction de sa stratégie scientifique.

Pour mieux mener l'étude, la définition de logiciels a été restreinte ici aux logiciels associés aux articles de recherche, mais cette définition s'étend facilement à d'autres types de logiciels produits dans les laboratoires et plus largement aux logiciels produits dans la communauté d'enseignement supérieur et de recherche, appelés ici "logiciels académiques".

Il y a beaucoup de développements logiciels réalisés dans les laboratoires et les établisements de recherche, ces logiciels sont souvent peu connus, peu diffusés, peu visibles, peu accessibles ; ils sont parfois diffusés mais pas dans les meilleures conditions (pas de licence, aspects légaux insuffisamment traités). Il est indispensable de mieux considérer les aspects légaux intervenant dans la diffusion de ces logiciels. Par ailleurs, les développeurs dans les laboratoires ont besoin de motivation et de support (technique, légal) pour améliorer les conditions de la diffusion de ces logiciels.

PLUME et RELIER peuvent aider les laboratoires à mieux gérer et tirer partie de leurs développements logiciels. Avec les fiches de développements ESR, on peut montrer facilement les logiciels d'un laboratoire ou d'une institution. En associant à ces fiches les fiches de logiciels validés, on donne un statut de "validé (au sens PLUME)" à un logiciel.

Les laboratoires et institutions peuvent, en utilisant PLUME, améliorer la situation des logiciels académiques pour permettre et pour accompagner leur valorisation, pour augmenter leur visibilité et leur capacité à susciter des collaborations. En définissant des politiques et des procédures en matière de logiciels et de logiciels libres, on peut renforcer l'évaluation et la validation de la recherche ainsi que sa reproductibilité, son libre accès.

Les questions juridiques et décisionnelles traitées ici sur les logiciels apparaissent aussi dans d'autres productions de l'activité scientifique différentes des publications : les bases de données, les prototypes matériels, les molécules, ... Le cadre juridique appliqué peut être différent (par exemple le droit sui generis des bases de données), mais des licences libres des logiciels sont déjà utilisées pour des prototypes (voir par exemple Matériel OpenSource (OpenHardware) et la recherche). Les tableaux présentés ici peuvent donc s'élargir à d'autres productions et servir de base de réflexion.

La recherche de demain se construit avec les briques faites aujourd'hui, il est nécessaire que ces briques soient solides du point de vue technique, scientifique et légal.

Références

Sur les questions juridiques

Sur les questions de politique scientifique

Autres documents PLUME

Autres documents

Fichier attachéTaille
articlevslogiciel_19oct2011.pdf193.67 Ko
articlevslogiciel_24sept2012.pdf208.21 Ko

Comparateur de CMS

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 28/09/11
  • Correction mineure : 28/09/11
Mots-clés

Comparateur de CMS

CMSMatrix est un site web mettant à disposition un outil de comparaison d'une très longue liste de CMS (Content Management System, gestion de contenu).
Ce service est comparable à celui proposé par le site Fiche Plume WikiMatrix qui compare des wikis.

Les informations de description des différents CMS sont apportées par les auteurs des CMS ou par des utilisateurs de ces systèmes, et éventuellement corrigées et/ou complétées par les utilisateurs de CMSMatrix.

Une liste de critères de comparaison est proposée, et l'utilisateur peut sélectionner les points qui l'intéressent plus particulièrement.

Une liste de discussion est accessible, à la condition de s'inscrire sur ce site : http://www.cmsmatrix.org/discussion

Un ensemble de sites relatifs aux CMS en général est également disponible: http://www.cmsmatrix.org/links

Les informations fournies permettent de faire un premier tri en sélectionnant les critères représentatifs des besoins identifiés dans un contexte bien défini.

Antepedia : moteur de recherche de composants Open Source

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 31/08/11
  • Correction mineure : 12/10/11
Mots-clés

Antepedia : moteur de recherche de composants Open Source

Antepedia est un moteur de recherche de projets Open Source. Il donne l'ensemble des informations nécessaires aux équipes de développement pour retrouver la provenance du composant open source, sa licence et les archives dans lesquels le composant est intégré.

Le moteur de recherche se base sur la plus grande base de connaissances du monde de l'open source composée de plus de 205 millions de fichiers open source, issus d'un catalogue comprenant près de 940 000 projets.

Vous pouvez dès à présent rechercher vos composants sur http://www.antepedia.com.

Open source cartouche : standard pour échanger des informations sur les licences et les copyrights

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 20/05/11
  • Correction mineure : 20/05/11
Mots-clés

Open source cartouche : standard pour échanger des informations sur les licences et les copyrights

Nouveau standard pour échanger des informations sur les licences et les copyrights associés aux briques utilisées dans la construction d'un logiciel open source.

Il prend la forme d'un fichier XML qui décrit les aspects les plus importants de façon normalisée, en voici les spécifications et un exemple validé par http://validator.w3.org/.

A noter, un autre standard existe : SPDX, avec des buts similaires, mais peut-être plus compliqué à mettre en place.

Syndiquer le contenu