référentiel

Qui fait référence

Pourquoi référencer son développement logiciel dans une fiche PLUME

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

Pourquoi référencer son développement logiciel dans une fiche PLUME

Ce court texte explique, de manière synthétique pourquoi il peut être intéressant pour vous, développeur dans un laboratoire de recherche ou une université, de décrire votre logiciel dans une fiche PLUME. Il s'inscrit dans l'objectif du projet RELIER de PLUME de référencer les développements de laboratoires et d'universités. Pour être clair, c'est un document promotionnel pour PLUME-RELIER.

Il est aussi destiné aux responsables de laboratoires, d'universités ou aux chargés de valorisation car faire connaitre les logiciels développés dans un environnement contribue à élargir les possibilités de collaboration avec d'autres entités : organismes de recherche et industriels.

En résumé, publier une fiche PLUME vous permet de faire connaître votre logiciel (donc de le valoriser). Etant contributeur PLUME il vous permet aussi d'intégrer une communauté de développeurs avec des outils et des documents de référence pour ce métier. Si vous êtes convaincu de l'intérêt : après être devenu membre (si vous ne l'êtes pas encore), proposez votre logiciel...

Faire connaître et valoriser votre logiciel

Si c'est un logiciel libre, le document Fiche Plume 'Pourquoi diffuser un logiciel développé dans un laboratoire ou une université avec une licence libre ?' explicite les raisons pour diffuser en libre. La plupart des arguments de ce document peuvent être repris pour montrer l'intérêt de publier une fiche PLUME :

  • Participer à la recherche sur le modèle des publications scientifiques.
  • Lier des contacts, initier des coopérations.
  • Améliorer la qualité de votre développement grâce aux utilisateurs qui vont le tester dans des contextes divers.
  • Améliorer les fonctionnalités du programme grâce à des utilisateurs qui proposeront des améliorations.
  • Continuer et pérenniser votre travail.
  • Mutualiser les efforts de développement.
  • Diffuser vos connaissances, ce qui est une des missions des organismes de recherche publique.
  • Avoir une notoriété engendrant une reconnaissance implicite de la qualité de votre travail.
  • Toucher les entreprises.
  • Avoir des retours économiques.
  • Elargir l'environnement de travail : toucher d'autres communautés de recherche, des entreprises...

On se référera au document ci-dessus qui développe ces points.

Si votre logiciel est développé sous licence propriétaire, PLUME vous donne une vitrine pour des cliénts potentiel et vous aidera à lier des contacts et elargir les possibilites de collaboration.

Les avantages de PLUME pour valoriser un logiciel

A noter que sauf à travers une fiche PLUME, il n'y a actuellement pas vraiment de moyen très efficace pour faire connaître vos développements. Vous pouvez le décrire sur le Web du laboratoire mais il ne sera pas très visible sur les moteurs de recherche, comme une aiguille dans une meule de foin. Vous pouvez aussi penser que la forge est un bon moyen de le faire connaître mais ce n'est pas vraiment un outil de diffusion d'information : généralement 80 à 90 % des projets dans les forges sont morts (données de sourceforge), cela limite la pertinence des informations.
Il faut évidemment déposer son logiciel sur une forge et le référencer sur le Web de son laboratoire ou de son université mais ce ne sera pas très efficace pour le faire connaître.

Revenons aux points forts de PLUME :

  • Un outil disponible
    En effet, cette plateforme est ouverte depuis novembre 2008. Y sont décrits, en octobre 2009, déjà 217 logiciels validés (qui peuvent être des développements de laboratoires), 78 développement Ens Sup - Recherche et une dizaine de fiches en anglais. Tout est en place pour vous permettre de rédiger et publier une fiche descriptive de votre logiciel : consulter cette page d'aide.
  • Un soutien officiel de plusieurs entités importantes du monde de la recherche
  • Une centralisation, élément essentiel pour une bonne promotion
    Sont décrits sur le serveur PLUME des logiciels de toutes les disciplines scientifiques et de tous les métiers de l'Enseignement Supérieur et la Recherche. Ces logiciels sont dans différents états (de 'en projet' jusqu'à 'validés' car en fonctionnement sur plus de 3 sites). Cette concentration fait que PLUME est devenu un serveur de référence connu par les personnes qui recherchent un logiciel. Avec cette concentration, PLUME est aussi pointé par de nombreux autres sites et Google qui met en avant ce qui est le plus référencé indexe maintenant très bien les fiches PLUME qui apparaissent souvent en première page des réponses (tapez 'plume' sur google par exemple). Quand on veut faire connaitre son logiciel, c'est un argument...
  • Des processus simples pour publier avec efficacité
    La plateforme PLUME dispose de workflows de saisie de la fiche en ligne, relecture par d'autres personnes, demande de Bon à publier à l'auteur, publication...avec mise à jour par l'auteur au bout de quelques mois. De plus, en bas de chaque fiche figure le nombre de lectures pour évaluer sa diffusion.
  • Un outil professionnel avec des descriptifs de qualité
    Les fiches PLUME sont rédigées et relues par des professionnels du monde de l'Enseignement Supérieur et la Recherche, les noms de ces contributeurs sont indiqués, les fiches sont classées avec des labels simples mais efficaces (validé, à valider...) et elles sont mises à jour régulièrement. Ces principes garantissent une bonne qualité des informations, produites par des personnes qui utilisent les logiciels dans leur activité professionnelle. De plus ces informations sont à jour. Ces principes font que PLUME est vu comme un serveur professionnel avec des informations de très bonne qualité.
  • Un guide de description
    Lorsque vous décrivez un logiciel dans PLUME, les champs imposés que vous devez saisir vous obligent à donner toutes les informations nécessaires aux personnes potentiellement intéressés. En effet, souvent sur les sites de téléchargement de logiciel il est difficile d'avoir une description concise, pertinente et utile à l'utilisateur potentiel du logiciel. La grille de saisie PLUME permet de 'ne rien oublier'.
  • Des mot-clés
    Toutes les fiches dans PLUME sont tagguées avec des mots-clés choisis car utilisés par les professionnels et enrichis quand de nouvelles fiches logiciels apparaissent. Cela permet une recherche par mot clé très performante et des sélections faciles.
  • Des outils de diffusion
    PLUME a mis en place des outils de diffusion : listes, fils RSS (qui annoncent les nouvelles fiches...),... maintenant très connus par les professionnels. Ces outils augmentent la diffusion d'information.
  • Un portail anglophone
    Le portail PLUME-FEATHER permet de diffuser les fiches en anglais, fiches traduites par leurs auteurs, et indexées avec des mots-clés anglais. Ce portail est destiné spécifiquement aux anglophones et n'affiche que des informations en anglais. Inutile de détailler l'intérêt de cette ouverture internationnale.
  • Pages de présentation par laboratoire, institut, organisme...
    L'indexation avec des mots-clés permet de créer simplement des pages qui listent les fiches PLUME de développements pour un laboratoire (exemple : page laboratoire LIGM), une université, un institut... Le Web du laboratoire, les rapports scientifiques peuvent pointer vers les URL de ces pages.

Intégrer une communauté de développeurs avec des outils et des documents de références à travers PLUME

De fait, PLUME regroupe les développeurs Enseignement  Supérieur - Recherche
Les contributeurs de fiches dév ESR dans PLUME sont les développeurs des logiciels décrits. Les logiciels qu'ils ont développé sont diffusés, donc ils ont un critère de qualité. Ils viennent de toutes les disciplines scientifiques. Et de fait, à travers des listes de diffusions, des actions spécifiques (ci-dessous) PLUME met en relation ces développeurs performants.

A travers PLUME vous pouvez accéder mais aussi participer à la rédaction et à la mise en oeuvre de

Donc, rédigez une fiche...

Si cet argumentaire vous a convaincu, devenez membre  et  proposez votre logiciel...

RELIER

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

RELIER

Le but du projet RELIER et des fiches "Développement Enseignement Supérieur Recherche" est d'encourager l'affichage, la diffusion et les échanges autour de des logiciels développés dans les laboratoires de recherche et des expertises qui leur sont associées (modèles, méthodes numériques, algorithmes ...).

Formations, ressources et tutoriaux autour des logiciels libres

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

Formations, ressources et tutoriaux autour des logiciels libres

Formations

 

Tutoriaux

Guide laboratoire pour recenser ses développements logiciels

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

Guide laboratoire pour recenser ses développements logiciels

Cet article n'est pas un document officiel d'un organisme ou d'une autre entité. Il s'adresse principalement aux responsables de laboratoires, mais aussi aux chercheurs, développeurs et responsables des tutelles qui souhaitent mettre en place ou améliorer les procédures de recensement des logiciels de recherche (logiciels libres et logiciels propriétaires) développés dans le laboratoire (ou l'ensemble des laboratoires d'une tutelle).
Les logiciels sont devenus des éléments principaux dans les processus de recherche, aussi bien comme outil que comme résultat. Améliorer leur référencement dans le laboratoire est le premier pas pour leur mise en valeur.
L'auteur principal de cet article est Teresa Gomez-Diaz, chargée du référencement des développements de son laboratoire LIGM et responsable thématique PLUME, mais les procédures présentées ont été étudiées avec Pascal Janots, responsable du SAIC de l'UPEMLV (service de valorisation de la recherche de l'université Paris-Est Marne la Vallée).
D'autres ont ensuite relu et complété : Jean-Luc Archimbaud (UREC), Geneviève Romier (UREC), Nathalie Rousse (INRA).
D'autres contributions sur ce texte sont souhaitables, merci de contacter l'auteur ou d'ajouter un commentaire.
Note : ce texte se veut auto-contenu, mais les lecteurs sont supposés connaître le contenu de la FAQ PLUME Licence & copyright pour les développements de logiciels libres de laboratoires de recherche Fiche Plume.

Autres documents PLUME

Ce document est une des fiches d'information et de recommandations rédigées par des responsables thématiques PLUME et destinées aux développeurs (et personnes en charge de la valorisation) dans les laboratoires de recherche et les universités. Les autres sont :

Introduction

L'évaluation d'un laboratoire de recherche s'effectue sur la base du rapport scientifique qui présente les activités de recherche du laboratoire pendant les 4 dernières années. Une grande partie de ce rapport consiste à énumérer les références des publications produites par les membres du laboratoire, généralement classées en : articles de revues, actes de conférences et autres communications, livres et chapitres de livres, thèses et habilitations, divers.
De plus les laboratoires disposent en général de bons outils pour gérer une telle liste bibliographique, ils peuvent en particulier utiliser le serveur HAL.
Par contre, pour les logiciels, il n'y a aucun outil connu autre que celui proposé par le projet RELIER de PLUME. Or, les logiciels sont devenus des éléments principaux dans le développement de la recherche, aussi bien comme outil que comme résultat. Améliorer leur connaissance est le premier pas pour leur mise en valeur. L'objectif de ce document est ainsi de proposer des procédures pour la gestion de la liste de logiciels, souvent libres mais pas uniquement, produits par un laboratoire de recherche. Ces procédures peuvent être aussi étendues aux bases de données, souvent produites et utilisées dans les laboratoires de recherche (données linguistiques, astronomiques, biologiques, ...). En effet les problèmes qui se posent avec ces bases de données (droits d'utilisation, références, citations, ...) sont de même nature que ceux que nous avons rencontrés avec les logiciels.
Le concept de production scientifique d'un laboratoire doit donc être élargi pour tenir compte de ces autres productions.

Les logiciels d'un laboratoire

Dans ce document, on entend par logiciel du laboratoire tout programme ou fragment de programme utile pour faire avancer la recherche, au sens large, et qui a été produit avec la participation d'un ou plusieurs membres du laboratoire. Il arrive souvent que des publications de recherche soient associées à un logiciel. Selon l'intérêt et la politique du laboratoire, on peut englober les logiciels à l'état de projet (logiciels en préparation, non encore terminés) et les logiciels 'utilitaires' développés au laboratoire pour améliorer le travail en interne (par exemple un outil de gestion de bibliographie).
Cette définition incite à la comparaison entre logiciel de recherche et article de recherche, mais cela ne se fait pas sans difficulté. Comment mettre dans la même balance un logiciel qui implémente un algorithme pour étude et amélioration et un livre élaboré après des longues années avec l'intervention de plusieurs personnes ? Mais en fait, cette difficulté existe aussi entre les diverses catégories des publications de recherche : comment comparer un article préparé en quelques semaines à un livre longuement élaboré ? Le point clé est dans la bibliographie fournie par le laboratoire : la comparaison ne se fait pas, la référence de l'article et du livre sont données.
Donnons donc aussi une référence pour les logiciels. De façon similaire à celle d'un article, la référence logiciel doit contenir la liste de ses auteurs, une date, mais aussi un numéro de version, une licence, une adresse et d'autres informations clés pour identifier le logiciel.
L'élaboration de la liste de logiciels d'un laboratoire est un élément fondamental de sa politique scientifique : cette liste permet de mesurer la production logicielle et permet l'évaluation de la diversité des productions. Cette liste deviendra un élément clé dans l'évaluation d'un laboratoire, mais aussi dans la détermination de son futur stratégique.

Référencer les logiciels libres et les autres

Rappelons qu'un logiciel dit libre respecte les 4 libertés mentionnées, par exemple, par la FSF :

  • liberté d'exécuter le logiciel (utilisation à l'infini),
  • liberté d'étudier le fonctionnement (disponibilité du code),
  • liberté de redistribuer des copies,
  • liberté d'améliorer le logiciel et de publier ces améliorations.

On reconnait un logiciel libre par la présence d'une licence qui indique ce statut. Un logiciel qui n'est pas libre est dit propriétaire. Plus d'informations sont données dans la FAQ Fiche Plume Licence & copyright pour les développements de logiciels libres de laboratoires de recherche.
Les logiciels propriétaires d'un laboratoire de recherche font souvent l'objet de collaborations avec des partenaires non-académiques ce qui conduit parfois à des contrats avec ces partenaires, et souvent, ces contrats sont gérés par les services de valorisation (du CNRS, SAIC, ...) des établissements. Il n'est donc pas très difficile (en principe) d'obtenir la liste des contrats, mais une autre chose est d'obtenir la liste des logiciels qui ont abouti à la fin de ces contrats.
Faisons ici une petite parenthèse pour indiquer deux types de logiciels propriétaires, qui se trouvent parfois dans les laboratoires : ceux qui font l'objet de licences propriétaires et ceux qui ne sont pas accompagnés de licence (ou logiciel public sans licence). La diffusion d'un logiciel sans licence est à éviter.

Il est en général plus difficile d'obtenir la liste des logiciels libres. À notre connaissance, très peu de laboratoires peuvent produire une telle liste, ces logiciels ne se recensent pas systématiquement, les chercheurs ne les mentionnent parfois même pas dans leurs rapports de recherche. Or comme nous l'avons déjà souligné, les logiciels sont maintenant un patrimoine avec une valeur scientifique qui sera de plus en plus importante donc il faut les référencer.

La solution à ce problème est d'établir des procédures dans le laboratoire pour référencer tous les logiciels développés. Des procédures différentes sont possibles et chaque laboratoire doit décider en conseil de laboratoire la procédure qui s'adapte le mieux à sa situation, ses habitudes. Ce document propose un peu plus bas, deux procédures possibles pour servir d'exemple.

Les droits patrimoniaux

Ces procédures doivent respecter les détenteurs des droits patrimoniaux d'un logiciel. En effet, la plupart des logiciels d'un laboratoire sont développés, à un moment ou autre, dans un cadre de travail salarié, et les droits patrimoniaux reviennent aux employeurs des développeurs. Ces employeurs sont en général les tutelles du laboratoire.
Qu'arrive-t-il quand il y a plusieurs tutelles au laboratoire ? Comment gère-t-on la ligne copyright qui indique les détenteurs des droits patrimoniaux et qui apparaît dans l'en-tête de tout fichier du code source ?
Il arrive aussi que des étudiants ou stagiaires avec des financements extérieurs à l'établissement participent aux développements logiciels. Ils sont détenteurs, au même titre que l'établissement, des droits patrimoniaux.
Pour l'ensemble de ces questions, qui ne sont pas l'objet de cet article, on se référera au document Fiche Plume Licence & copyright pour les développements de logiciels libres de laboratoires de recherche.

Le projet RELIER

Le projet RELIER, sous-ensemble du projet PLUME, vise à REférencer les développements Logiciels Internes de l'Enseignement supérieur et de la Recherche. Ce projet permet à chaque membre de laboratoire (développeur...) de rédiger des descriptifs des logiciels produits dans le laboratoire sur la plate-forme PLUME qui sont ensuite publiés sous forme de fiches (appelées fiches Dév ESR) avec des mots clés pour la recherche. Cette plate-forme permet aussi de présenter la liste des logiciels produits par chaque laboratoire (voir par exemple http://www.projet-plume.org/fr/IGM-Labinfo/) et chaque tutelle. Cette plate-forme est donc un outil très intéressant et gratuit qui permet au laboratoire de faire un inventaire de ses logiciels et de les faire connaître donc les valoriser.

Une première procédure proposée

Cette procédure contient quatre étapes.
Mais avant, il faut identifier certains développements logiciel qui nécessitent des conseils des experts 'droits patrimoniaux, licences, valorisation...' et leurs appliquer le rappel ci-dessous.

Rappel : travaillez avec les services de valorisation.

Avant toute diffusion, avant toute collaboration, contacter le SAIC de l'université et/ou des services de valorisation des tutelles (cf annuaire des services SPV du CNRS) s'il y a développement de logiciels dans :

  • Une réponse à un appel à projets.
  • Un contrat.
  • Une participation au développement de personnes dont le financement est extérieur à l'établissement.
  • Un dépôt à l'Agence de Protection des Programmes.
  • Une rédaction de brevet.
  • Une recherche de partenaires industriels.
  • Une diffusion d'un logiciel sous licence propriétaire.

 

Étape 1 : Identification du logiciel à référencer (référence RELIER - fiche Dév ESR)

Une référence de logiciel doit pouvoir identifier le logiciel tout au long de sa vie, en tenant compte de ses possibles évolutions. La référence RELIER (fiche Dév ESR) comporte les champs suivants :

  • nom,
  • auteur(s),
  • propriétaires des droits patrimoniaux (tutelles et autres),
  • licence(s) (voir note),
  • version,
  • date,
  • mots clés,
  • fonctionnalités,
  • contexte d'utilisation,
  • publications liées au logiciel.

Note : Tout logiciel diffusé doit être sous licence, libre ou propriétaire.

Étape 2 : Notification des logiciels de recherche à la direction du laboratoire

La direction du laboratoire doit être notifiée du souhait de référencement de chaque logiciel de recherche (ainsi que de la licence choisie pour la diffusion). Cela comprend tous les logiciels en production au laboratoire. La publication des références de logiciels soumis à des clauses de confidentialité dans des contrats est à étudier.

Étape 3 : Notification aux tutelles et demande d'accord des détenteurs des droits patrimoniaux.

Cette étape concerne principalement les logiciels libres : avant sa diffusion et recensement, la ligne copyright, contenant les détenteurs des droits patrimoniaux  et qui est insérée dans le code du logiciel doit être établie. Plus d'informations sur le copyright sont données dans le document Fiche Plume Licence & copyright pour les développements de logiciels libres de laboratoires de recherche. La procédure proposée est que la direction du laboratoire adresse (par message électronique) aux tutelles une demande de validation de la mise en ligne du logiciel libre, avec une proposition de ligne copyright. Si elle n'obtient pas de réponse au bout de 30 jours, la direction du laboratoire considère sa demande de diffusion de logiciel libre et sa ligne copyright comme validée par les tutelles. Ce délai de réponse de 30 jours n'a pas été validé officiellement mais il nous parait raisonnable.
La situation courante actuelle est que les développeurs diffusent en libre sans forcément en référer aux tutelles, il faut que ceci évolue comme le propose cette procédure.

Pour les logiciels propriétaires qui font l'objet d'un contrat, la ligne copyright doit être définie dans le contrat.

Étape 4 : Saisie de la référence RELIER (fiche dév ESR de PLUME) et publication

La ligne copyright est insérée dans le code, la licence est établie pour le code source et/ou le code binaire du logiciel.
Un membre du laboratoire peut alors saisir la description du logiciel sur le serveur PLUME. Cela se fait en ligne, il faut d'abord devenir membre PLUME puis proposer une fiche et après acceptation saisir la fiche. Après relecture, la référence est publiée. Sur le serveur PLUME, ce nouveau logiciel est ajouté à la liste officielle des logiciels du laboratoire.

Sur cette première procédure

Cette procédure a été conçue pour respecter les détenteurs des droits patrimoniaux de chaque logiciel, et leur accorder un délai raisonnable pour la vérification des engagements des tiers ou contractuels que ces logiciels peuvent entraîner.
Par contre elle peut s'avérer inadéquate dans certaines occasions qui requièrent une diffusion rapide d'un logiciel sous licence libre. Par exemple une soumission d'article pour une conférence : pour valider les résultats de recherche de l'article il est souhaitable d'avoir un accès au logiciel, or une licence doit être mise en place avant toute diffusion d'un logiciel.
Cette procédure peut aussi s'avérer trop contraignante pour des chercheurs qui n'ont jamais reçu d'instruction sur cette question et qui ont toujours agi selon leur propre volonté.
Pour ces raisons nous proposons une deuxième procédure quand une clause spécifique a été ajoutée dans le contrat quadriennal.

Une deuxième procédure proposée

Cette procédure est envisageable si la ligne copyright d'un logiciel libre a été clairement définie lors de la signature du contrat quadriennal entre les établissements tutelles du laboratoire. En effet, lors de cette signature les tutelles arrêtent un accord sur la signature des articles de recherche, nous proposons que la ligne copyright des logiciels libres soit aussi discutée et définie, tout en respectant les détenteurs des droits patrimoniaux.
Il y a aussi, de même que pour les publications de recherche, une délégation implicite aux développeurs de la responsabilité des engagements (contrats, absence de contrefaçon...) concernant le logiciel.

Dans ce cas, les étapes rappel, 1 et 2 sont les mêmes que dans la procédure précédente, mais les deux dernières étapes sont interverties.

Étape 3 : Saisie de la référence RELIER (fiche Dév ESR) et publication

La ligne copyright est insérée, la licence est établie pour le code source et/ou le code binaire du logiciel. Le logiciel  est distribué sous licence libre. Le logiciel est décrit dans PLUME et la référence RELIER (fiche Dév ESR) est publiée. Un nouveau logiciel est ajouté à la liste officielle des logiciels du laboratoire.

Étape 4 : Notification aux tutelles.

La direction du laboratoire adresse aux tutelles (par message électronique) la notification de la mise à jour de sa liste officielle des logiciels.

Le parallèle entre publications et logiciels d'un laboratoire

En résumé on propose que la liste de logiciels d'un laboratoire de recherche soit produite et gérée de la même façon que celle de ses publications, c'est essentiel pour la connaissance et la pérennisation du patrimoine scientifique.
Pour la production de la bibliographie, les laboratoires peuvent utiliser le serveur HAL ; ils peuvent utiliser la plate-forme PLUME/RELIER pour le référencement des logiciels. Un lien depuis le Web du laboratoire vers la page laboratoire dans PLUME (ou la récupération d'un flux RSS de PLUME vers le Web du laboratoire) permet aussi d'accéder à ce référencement dans le Web du laboratoire et d'avoir une visibilité laboratoire.
De la même façon que la signature des publications est définie lors de la négociation des contrats quadriennaux des établissements, la ligne copyright pour identifier les détenteurs des droits patrimoniaux des logiciels libres peut être établie ; ceci facilite ensuite la diffusion rapide des logiciels libres des laboratoires.
Les publications de recherche sont souvent soumises à des procédures de validation (soumission et acceptation d'une publication) des résultats qui y sont publiés. Les logiciels n'ont pas ce type de procédure mais les publications associées à ces logiciels sont un élément pour leur validation. Et dans le cas des logiciels libres, la communauté d'utilisateurs qui accompagne habituellement ces logiciels renforce le processus de validation. Ces deux informations sont données dans les fiches PLUME-RELIER. Pour les logiciels propriétaires leur validation passe par les contrats qu'ils attirent.
La liste de publications d'un laboratoire permet son évaluation mais aussi la diffusion d'un savoir-faire qui alimente la recherche et contribue à son évolution permanente. De la même façon, la diffusion de la liste de logiciels d'un laboratoire peut conduire à leur incorporation comme brique logicielle dans d'autres développements, les laboratoires et les organismes de recherche doivent garantir les meilleures conditions pour ce processus de rayonnement.

Un correspondant logiciel dans le laboratoire ?

Chaque développeur peut suivre une des procédures proposées ci-dessus. Mais lorsque la production de logiciels est importante dans un laboratoire, la direction peut désigner une personne qui coordonne et éventuellement fasse le travail de saisie des descriptifs dans PLUME... En centralisant ce travail, cela permet d'homogénéiser l'ensemble des présentations, de gagner du temps et d'avoir une personne avec une vue d'ensemble de toutes les productions logicielles. C'est ce qu'a fait mon laboratoire en me désignant : cela a beaucoup facilité le référencement.
Le terme 'correspondant logiciel' s'inspire de celui de 'correspondant formation' utilisé au CNRS entre autres. En effet, un réseau de correspondants logiciels nous semble souhaitable et permettra la mise en place d'une vraie politique de valorisation de logiciels.

Si vous désirez mettre en place ce type de procédure et avez besoin de conseils relier-pilote [at] services [dot] cnrs [dot] fr (Ecrire à Plume à l'équipe RELIER).

Pourquoi diffuser un logiciel développé dans un laboratoire ou une université avec une licence libre ?

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

Pourquoi diffuser un logiciel développé dans un laboratoire ou une université avec une licence libre ?

  • Type de ressource : article, référentiel
  • Date de publication du document ou de l'événement : Aout 2009

Ce document essaie de répondre à la question 'Pourquoi diffuser un logiciel développé dans un laboratoire ou une université avec une licence libre ?'.
Il a été construit en compilant de nombreuses réponses à cette question, obtenues en interrogeant des développeurs (chercheurs, enseignants ou ingénieurs) comme [1-2-3] et des responsables de laboratoire ou de valorisation, puis en essayant de les structurer. Ce n'est donc pas une réflexion personnelle des auteurs dont le travail n'a été que de trier et classer des avis de personnes qui développent et diffusent des logiciels ou qui ont à se poser la question du mode de diffusion dans la communauté de l'Enseignement Supérieur et de la Recherche.

Les auteurs principaux sont Véronique Baudin (LAAS) et Jean-Luc Archimbaud (UREC). Il a été relu et complété par Geneviève Romier (UREC), Teresa Gomez-Diaz (LIGM), Nathalie Rousse (BIA INRA Toulouse).

Autres documents PLUME

Ce document est une des fiches d'information et de recommandations rédigées par des responsables thématiques PLUME et destinées aux développeurs (et personnes en charge de la valorisation) dans les laboratoires de recherche et les universités. Les autres sont :

Préambule

  • Selon la législation, pour un développement logiciel, le détenteur des droits patrimoniaux (c'est à dire l'employeur) décide du choix de la licence, et non pas uniquement l'auteur.
  • Si le logiciel est utilisé par plusieurs membres extérieurs (ou le sera), il faut qu'il fasse l'objet d' une licence (contrat entre les auteurs du logiciel et les utilisateurs). Une licence (libre ou propriétaire) sert à protéger les auteurs (et les éventuels collaborateurs au développement), les propriétaires des droits patrimoniaux, les utilisateurs.
  • Si le logiciel fait partie d'un contrat industriel ou peut être commercialisé, une licence libre est peut être impossible ou n'est peut être pas le bon choix. Cependant, la diffusion de votre logiciel sous licence libre n’empêche pas sa diffusion sous d’autres licences : ce double choix est parfois mieux adapté à des contrats de collaboration de nature différente (industriel/académique).

On se réfèrera au document 'FAQ : licence & copyright pour les développements de logiciels libres de laboratoires de recherche Fiche Plume ' qui explicite les points ci-dessus et indique comment choisir une licence, qui doit le faire, comment l'indiquer dans le code...

Pourquoi une licence libre ?

Diffuser un logiciel avec une licence libre permet de le faire connaitre et en autorise une très large utilisation. Pour vous, auteur du logiciel, cela peut vous permettre de :

  • Participer à la recherche sur le modèle des publications scientifiques
    Les connaissances scientifiques progressent principalement par la publication d'articles scientifiques, publications que tout le monde peut lire. Un logiciel est très similaire à un article et permet de faire avancer la science : pourquoi ne pas publier le code et le rendre lisible comme un article ?
    L'étude d'un code peut être aussi enrichissante que celle d'un article scientifique.
    Rendre disponible le code donne la possibilité aux "reviewers" des publications associées au logiciel de vérifier par eux-même les résultats présentés. Certaines revues demandent le code associé à la publication de résultats, et en font une condition stricte pour l'acceptation de l'article[4-5-6] . Un accès libre au code permettra aux lecteurs de votre article de reproduire vos résultats [7].Cette démarche constitue également un moyen simple de faire apparaitre votre travail dans des études comparatives de performances, de qualité des résultats, d'originalité des solutions proposées, .... contribuant ainsi à augmenter la diffusion de vos travaux.
  • Lier des contacts, initier des coopérations, avec des personnes qui travaillent sur des sujets identiques ou proches des vôtres. Votre code étant public, elles le découvrent lors de recherches par mots-clés sur internet... et peuvent être intéressées par l'utiliser ou contribuer au développement. En particulier les contacts avec des chercheurs ou ingénieurs d'autres thématiques scientifiques et d'autres pays qui ne sont donc pas dans votre sphère de connaissances habituelle sont rendus possibles avec un code public.
  • Améliorer la qualité de votre développement grâce aux utilisateurs qui vont le tester dans des contextes divers, académiques mais aussi industriels, et vous remonteront les erreurs ou dysfonctionnements rencontrés.
    Les communautés de contributeurs et d’utilisateurs autour d’un logiciel libre constituent un atout important garantissant une bonne réactivité à la découverte de bogues, et permettent/favorisent/encouragent l’expression de besoins nouveaux.
  • Améliorer les fonctionnalités du programme grâce à des utilisateurs qui proposeront des améliorations, voire de nouvelles idées et des contributions. Cela peut être l'occasion de créer un groupe d'utilisateurs réguliers et/ou de développeurs autour du logiciel.
  • Continuer et pérenniser votre travail.
    Si votre logiciel répond à un besoin général, en le diffusant en ligne sous une licence libre, il peut devenir très utilisé et devant un certain 'succès' vous trouverez plus facilement un support de vos tutelles pour le maintenir et le faire évoluer.
    Une licence libre vous assure de pouvoir utiliser et faire évoluer le logiciel 'quoiqu'il se passe' au niveau des droits patrimoniaux. En particulier, même si certains développeurs (stagiaires par exemple) quittent le projet ou si le laboratoire ou certaines tutelles qui détiennent des droits patrimoniaux se désengagent, vous pourrez continuer à utiliser et faire évoluer le code sans problème.
    De nombreux logiciels sont développés dans le cadre de travaux de thèse. Ce sont majoritairement des prototypes qui tombent dans l'oubli lorsque le doctorant quitte son équipe de recherche. Si ces logiciels sont développés sous licence libre, leur accessibilité est alors garantie, et selon l'intérêt de ceux-ci, ils pourront continuer à vivre.
  • Mutualiser les efforts de développement.
    Votre logiciel peut conduire à la création de communautés qui partagent le développement et la maintenance du logiciel, contribuent à son évolution et peuvent ainsi vous libérer au moins en partie de tâches de portage, d'adaptation, .......
  • Diffuser vos connaissances, ce qui est une des missions des organismes de recherche publique. Cela permet de faire œuvre utile pour la société. Les laboratoires de recherche et les universités sont un creuset très impressionnant d'idées et de réalisations innovantes, mais encore faut il les faire connaitre pour que ce bouillonnement soit utile. On peut se référer au document 'Guide laboratoire pour recenser ses développements logiciels Fiche Plume ' qui propose des exemples de procédures pour recenser et donc faire connaitre tous les développements logiciels d'un laboratoire.
  • Avoir une notoriété engendrant une reconnaissance implicite de la qualité de votre travail, ce qui est toujours apprécié et peut avoir des effets sur votre carrière [8]. La production logicielle n'entre pas actuellement dans les critères d'évaluation d'un chercheur ou d'un enseignant mais une notoriété reconnue d'un code ne passe pas inaperçue. La notoriété du code peut aussi rayonner sur l'établissement (laboratoire ou université) dans lequel vous effectuez vos travaux de recherche.
  • Toucher les entreprises.
    Les PME et les grands comptes (entreprises ou administration qui génèrent des volumes d'activité importants) se tournent de plus en plus vers les logiciels libres pour des raisons évidentes économiques mais aussi d'inter-opérabilité, de liberté vis à vis des éditeurs, de flexibilité et d’innovation [9]. Et le critère libre longtemps décrié comme 'affaire de gourou idéaliste qui ne connait pas les réalités de l'entreprise' devient maintenant un critère de qualité et d'assurance [10].
  • Avoir des retours économiques.
    Les logiciels scientifiques sont souvent très spécifiques, pointus et n'intéressent pas une large clientèle : le modèle de diffusion par licence propriétaire, qui peut être rentable sur des grands nombres, s'avère très mal adapté pour des petites quantités. En rendant le code public, le laboratoire ou l'université peut avoir d'autres retours économiques avec des services tels que la formation sur le logiciel, l'aide à l'installation, des développements spécifiques, ou l'aide à l' intégration dans d'autres environnements logiciels. Ces services sont légers à mettre en place et peuvent constituer des gains non négligeables.
    Ces services peuvent également être assurés par le biais de la création d'une entreprise (SSLL) , génératrice de création d'emplois.
  • Apporter votre pierre au monde du logiciel libre dans lequel vous devez certainement utiliser régulièrement des produits : donc donner un peu et pas toujours prendre. Vous contribuez ainsi à assurer une indépendance de la recherche en donnant accès à des solutions libres que d'autres pourront faire évoluer. "Toute pierre enrichit et consolide l'ensemble de l'édifice".

Références

FAQ : hébergement des développements logiciels de laboratoire : forges

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

FAQ : hébergement des développements logiciels de laboratoire : forges

  • Type de ressource : référentiel, résumé
  • Date de publication du document ou de l'événement : Septembre 2009

Cette FAQ est destinée à informer de manière pratique sur les questions liées à l'hébergement des projets logiciels.
Elle est destinée aux développeurs de logiciels dans les laboratoires de recherche (CNRS, universités, INRA…). Elle peut aussi s’appliquer aux développeurs dans les services de ces organismes (services informatiques, CRI, DSI…).

Cette FAQ n’est pas un document officiel d’un organisme ou d’un autre.

L'auteur principal est Violaine Louvet (ICJ). Elle a été relue et complétée par Jean-Luc Archimbaud (UREC), Matthieu Herrb (LAAS), Sébastien Campion (INRIA), François Elie (ADULACT).
Elle va évoluer avec d’autres contributions. Si vous voulez contribuer, contactez l’auteur. 

Autres documents PLUME

Ce document est une des fiches d'information et de recommandations rédigées par des responsables thématiques PLUME et destinées aux développeurs (et personnes en charge de la valorisation) dans les laboratoires de recherche et les universités. Les autres sont :

Qu'est-ce qu'une forge (informatique) ?

Définition

Une forge ou plate-forme d'hébergement de projets logiciels désigne un environnement Web constitué d'un ensemble d'outils du travail coopératif et du génie logiciel pour le développement collaboratif et distribué de logiciels.

Objectifs

L'objectif d'une forge est d'offrir un espace d’échange permanent et de collaboration en ligne aux développeurs de logiciels, et un espace de distribution (versions publiques des logiciels développés : paquets sources, pages web) pour les utilisateurs (pour tout un chacun si la forge est publique). Elle permet ainsi de rassembler des projets et des développeurs, mais aussi d'autres personnes travaillant sur ces projets (utilisateurs, traducteurs...).

Quels sont les services potentiellement disponibles dans une forge ?

Les outils offerts par une forge sont principalement :

  • système de gestion des versions,
  • gestionnaire de listes de discussion (et/ou de forums),
  • outil de suivi des bugs,
  • gestionnaire de documentation (souvent sur le principe du wiki),
  • gestionnaire de tâches,
  • gestionnaire des traductions en ligne.

La forge rassemble ces outils en un seul ensemble cohérent facilement accessible. Elle peut aussi permettre de présenter les projets grâce à des outils comme :

  • la présentation de copies d'écrans,
  • l'écriture de nouvelles,
  • la mise à disposition d'un hébergement ou de quelques pages descriptives,

qui peuvent être organisés comme une page de présentation du projet, rassemblant aussi la licence, les technologies utilisées, la compatibilité...

Sur quelle forge puis-je héberger mon projet?

Dans la communauté Enseignement Supérieur et Recherche en France, il existe un certain nombre de forges permettant d'héberger des projets logiciels. En voici quelques unes, sans être exhaustif. Attention, cela ne veut pas dire que toutes les forges ci-dessous acceptent tous les projets. Chacune a ses règles que nous avons essayé de résumer, mais il faut s'adresser au gestionnaire de la forge pour avoir une réponse claire.

La forge SourceSup : Ens Sup - Recherche

  • Cible : SourceSup est destinée aux établissements d'enseignement supérieur (universités, écoles d'ingénieurs, ...) et aux organismes de recherche français.

La forge INRIAGForge : INRIA

  • Cible : l'objectif de InriaGForge est de fournir à toutes les personnes travaillant à l'INRIA une infrastructure pour leurs collaborations scientifiques avec les partenaires internes ou extérieurs à l'institut.
  • Contraintes : tout projet hébergé sur InriaGForge doit donc être ouvert par un membre de l'INRIA. Pour plus d'informations, se reporter à la charte d'utilisation

La forge Adullact.net : administrations et collectivités françaises

  • Cible : toute personne peut ouvrir un compte, et proposer un projet, si celui-ci présente un intérêt pour la sphère du domaine public au sens large, c'est-à-dire principalement les administrations centrales ou territoriales.
  • Contraintes : ADULLACT est l'Association des Développeurs et des Utilisateurs de Logiciels Libres pour l'Administration et les Collectivités Territoriales. Adullact.net est un service d'hébergement et de travail collaboratif consacré au développement de logiciels libres métiers. L'Adullact se réserve le droit de refuser l'hébergement d'un projet qui ne serait pas sous une licence GPL-compatible ou reconnue par l'OSI.

La forge AdmiSource : n'existe plus

http://admisource.gouv.fr/
était une forge créée pour l'administration dans le cadre du projet Adèle. Elle n'existe plus, tous les projets ont été transférés sur Adullact.net (par convention DGME-ADULLACT).

La forge Mulcyber : INRA

  • Cible : Mulcyber est destinée aux membres du département MIA (Mathématiques et Informatique Appliquée) de l’INRA (Institut National de la Recherche Agronomique) et à leurs collaborateurs.
  • Contraintes : tout projet hébergé sur Mulcyber doit donc être porté par un membre du département MIA de l'INRA.

La forge de l'Ifremer

  • Cible : destiné aux membres de l'IFREMER.
  • Contraintes : les projets hébergés sur cette forge sont internes à l'IFREMER.

Espace de discussion sur les forges francophones : PlanetForge

Ce n'est pas une forge mais le wiki de PlanetForge est un espace de collaboration documentaire sur les forges.

Forge OSOR : administrations européennes (Open Source Observatory and Repository)

  • http://forge.osor.eu/
    OSOR.eu est une sorte de méta-forge de forges nationales en Europe, créant ainsi une fédération européenne de référentiel de logiciels open-source financés par de l'argent public (comprenant la forge Adullact.net, l'Adullact a inspiré ce projet à IDABC).
  • Cible : la forge OSOR.eu forge est ouverte aux projets de logiciels libres open-source à destination des administrations publiques, permettant ainsi le partage et la ré-utilisation de ces logiciels dans d'autres administrations publiques à travers toute l'Europe.
    Cette forge est donc réservée aux projets ayant un intérêt particulier pour les administrations publiques européennes et/ou développés dans ou pour le secteur public.
  • Contraintes: la forge OSOR.eu et l'ensemble de ses services sont exclusivement réservés aux échanges et collaborations sur des logiciels libres et open-source. Cette forge concerne les logiciels liés aux Systèmes d'Information des administrations.

Forge Sourceforge : Open source international

  • Cible : tout projet de développement. Cette forge est certainement la plus connue au niveau international.
  • Contraintes : le développement doit être OpenSource.

Autres forges internationales

(qui méritent peut être d'être mieux connues mais que nous n'avons pas étudiées)

Il existe un tableau comparatif sur wikipedia des principaux hébergeurs de projets open source.

Quelle forge choisir ?

Le choix doit être fait en concertation avec votre direction (du laboratoire, de l'université...) car ce n'est pas uniquement un choix technique, les aspects stratégiques et de visibilité peuvent aussi être importants dans le cas de développements majeurs.

Quelques réflexions :

  • Actuellement le CNRS n'a donné aucune directive à ses laboratoires, donc le choix est ouvert. PLUME envisage de proposer un projet de forge au CNRS en s'associant avec plusieurs partenaires.
  • Les forges correspondent généralement à une communauté (métier...) où les processus et les outils sont adaptés aux pratiques de cette communauté. Donc tournez-vous plutôt vers des environnements proches de vous.
  • Assurez-vous des services rendus par la forge, pas uniquement sur les outils techniques disponibles mais aussi sur l'équipe en place pour la gérer, à la garantie de service, aux délais de réponses...
  • Assurez vous de la pérennité de la forge. Si le projet est d'envergure, il sera très difficile de le migrer d'une forge à une autre.
  • Si votre développement est intégré dans un projet hors laboratoire, avec des partenaires (industriels, européens...), il est évident que le choix va être guidé par l'ensemble de ces partenaires.

Aucune de ces solutions ne me convient, que dois-je faire?

Si les hébergements existants ne conviennent pas, vous pouvez monter une forge (tout ou partie) au niveau de votre laboratoire, université... Deux choix :

  • Installer un logiciel complet de forge qui va permettre de déployer une plateforme importante. La page http://wiki.planetforge.org/index.php/Forges recense une liste non exhaustive de ces logiciel de forge, forge pris au sens d'outil de déploiement d'une forge.
  • Evitez d'installer un logiciel complet de forge mais très complexe, en ciblant précisément vos besoins et n'installez unitairement que les logiciels nécessaires. L'installation et l'administration seront beaucoup plus simples. Plume référence un certain nombre de ces outils (cf les liens ci-dessous), les plus utilisés dans notre communauté.

Outils de gestion de versions

Si votre besoin est essentiellement de gérer des versions successives de sources ou de documents, l'utilisation d'un outil de gestion de version peut suffire. Il en existe deux grandes classes : les outils traditionnels complètement centralisés et les outils décentralisés :

  • Outils à fonctionnement centralisé : subversion Fiche Plume , CVS...
  • Outils à fonctionnement plus décentralisé : mercurial, Fiche Plume git...

Le mot clé Fiche Plume "gestion de versions" permet d'identifier sur le serveur Plume les ressources liées à cette problématique.
Une liste non exhaustive des logiciels de gestion de versions est aussi accessible sur wikipedia

.

Outils de suivi de bogues et de tâches

Si votre besoin correspond plutôt à du suivi de problèmes (bug tracking) sur un logiciel ou du suivi de tâches sur un projet, des logiciels spécifiques existent.
Les plus connus sont :

Redmine et TRAC sont plus complets qu'un simple outil de suivi de bugs.
Une liste non exhaustive de ces logiciels est aussi accessible sur wikipedia

.

Outils de communication

Si vos besoins se limitent à la communication autour des logiciels, il existe de nombreux outils à finalités un peu différentes qui permettent d'y répondre :

Et plus globalement sur PLUME, une liste de fiches avec le mot-clé Fiche Plume outils de diffusion de l'information.

SSTIC : Symposium sur la Sécurité des Technologies de l'Information et des Communications

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

SSTIC : Symposium sur la Sécurité des Technologies de l'Information et des Communications

Le SSTIC (symposium sur la sécurité des technologies de l'information et des communications) est une conférence francophone sur le thème de la sécurité de l'information, ce qui comprend à la fois les vecteurs d'information (comme les systèmes informatiques ou les réseaux) et l'information elle-même (cryptographie ou guerre de l'information). Elle se tient tous les ans début juin à Rennes.
Les actes qui contiennent à la fois les présentations et les articles depuis l'édition de 2003 sont disponibles sur http://actes.sstic.org/.
Les articles sont conséquents et généralement d'un bon niveau. Ils constituent une excellente référence francophone dans le domaine de la sécurité des systèmes d'information.

ANSSI : Agence nationale de la sécurité des systèmes d'information

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 07/08/09
  • Correction mineure : 29/03/10
Mots-clés

ANSSI : Agence nationale de la sécurité des systèmes d'information

L'agence nationale de la sécurité des systèmes d'information (ANSSI) a été crée le 7 juillet 2009. Elle succède à l’ancienne direction centrale de la sécurité des systèmes d’information (DCSSI). Elle est la référence officielle en France en matière de SSI. Le portail de l'ANSSI contient :

  • l'organisation de la cyberdéfense en France (CERTA, COSSI, etc.) ;
  • un catalogue de produits de sécurité certifiés ;
  • la réglementation (documents interministériels, RGS, certification, signature électronique, cryptologie) ;
  • des outils méthodologiques (EBIOS, PSSI, etc.) ;
  • des offres de formation (stages, autoformation, etc.) ;
  • des publications scientifiques de l'ANSSI ;
  • des liens vers des sites traitant de la sécurité des systèmes d'information.

Lexique du vocabulaire concernant les formats

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

Lexique du vocabulaire concernant les formats

  • NORME (de jure standard) :
    Document qui référence un certain nombre de règles et de critères agissant sur l’état d’un produit (ou d’un service) afin de résoudre un problème redondant réel ou potentiel technico-commercial. Il permet alors son interopérabilité et l'amélioration de sa qualité. De plus, il n’est pas forcément adopté par un fabricant mais peut être requis par contrat ou par la loi.
    Une norme se différencie d’un standard par sa mise en place collective. En effet, elle provient d’un consensus entre différents organismes de normalisation.
    Toutefois une norme peut devenir un standard.
    Ministère de l'économie, de l'industrie et de l'emploi

 

  • ORGANISME DE NORMALISATION :
    Organisme public composé soit d’états (par le biais d’une institution de normalisation nationale), soit de cartels d’entreprises. Ensemble, les experts du domaine rédigent les normes puis de manière collégiale et à l’aide d’un vote, les membres les homologuent.
    Lorsqu'il y a accord, la norme établie est mise en place par les membres et publiée dans le but de la voir s’établir et maintenue à l’extérieur de l’organisation.
    Trois niveaux d’organisations se distinguent : national (AFNOR), européen (CEN) et international (ISO).

 

  • STANDARD (de facto standard) :
    Document qui référence un certain nombre de règles ou de caractéristiques (conditions ?) agissant sur l’état d’un produit (ou d’un service) afin de résoudre un problème redondant technique ou commercial (améliorer sa qualité ?).
    Un standard se différencie d’une norme par sa mise en place privée. En effet, il peut provenir d’une association privée ou du fournisseur prépondérant sur le marché qui le diffuse très largement et devient usuel pour la majorité des utilisateurs (standard « de fait »).
    De plus, il peut être « ouvert » (PDF Fiche Plume). Si ce n’est pas le cas le standard est dit « fermé » (par exemple le format de fichiers Microsoft Word Fiche Plume).
    Loi n°2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique (cf Article 4)

 

  • INTEROPERABILITE :
    Aptitude qu’a un système à communiquer avec d’autres différents, aussi bien par l’échange de ressources que par la capacité à fonctionner ensemble sans trop d’effort de la part de l’utilisateur.
    À noter que pour cela les standards ouverts sont souvent nécessaires.
    Association Francophone des Utilisateurs de Logiciels Libres

 

  • FORMAT :
    Manière dont les données sont codées et stockées en nombres binaires dans le but de représenter des fichiers tous types confondus.L'extension qui suit le nom du fichier permet souvent d'identifier le format.
    De plus, il peut être une norme ou un standard. Par conséquent, tout comme un standard, il peut être ouvert ou fermé. Un format peut également être propriétaire.

 

  • OUVERT :
    Se dit d’un format ou d'un standard dont les spécifications sont libres d’accès, d’utilisation gratuite et sans condition pour tous. Par conséquent, les logiciels libres s’appuient souvent sur eux car ils assurent l’interopérabilité et la pérennité des données échangées. De plus, leur emploi amoindrit la diffusion des virus.
    Openformats.org

 

  • FERMÉ :
    Se dit d’un format ou standard qui n’est pas ouvert, autrement dit si ses spécifications ne sont pas librement accessibles et son utilisation restreinte. Souvent, leur correcte lecture dépend de logiciels particuliers.
    À ne pas confondre avec propriétaire.

 

  • PROPRIÉTAIRE (standard ou format) :
    Se dit d’un standard ou format qui a été établi par un organisme privé dans un but commercial. Il peut donc être ouvert ou fermé selon le choix fait par l’entreprise.

 

  • LIBRE ou OPEN SOURCE (logiciel) :
    Se dit d’un logiciel dont la licence est libre, mais qui n’est pas forcément gratuit. "Libre" veut dire que l'utilisateur à la liberté d'exécuter, de copier, de distribuer, d'étudier et d'améliorer le logiciel. La possibilité d'accéder librement au code source du logiciel permet son étude, sa modification et l’éventuelle redistribution libre ou non de la version obtenue. Les conditions d'utilisation d'un logiciel libre peuvent être établies par une licence.
    Il repose souvent sur des formats libres et est opposé au logiciel propriétaire.

 

  • PROPRIÉTAIRE ou PRIVATEUR (logiciel) :
    Se dit d’un logiciel dont la licence n’est pas libre.
    Le choix de son utilisation et l’accessibilité à son code source appartiennent à l’éditeur du logiciel. Il rend alors impossible au moins l’un des critères du logiciel libre auquel le logiciel propriétaire s’oppose (ou demande une autorisation spécifique).
    Il repose souvent sur des formats fermés.

 

  • LICENCE (de logiciel) :
    Document qui permet au propriétaire des droits du logiciel de définir les droits et devoirs d’un tiers et de d’autoriser à l’utiliser.
    Projet PLUME : FAQ Fiche Plume

 

FrameIP : informations sur les protocoles TCP/IP, VoIP...

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

FrameIP : informations sur les protocoles TCP/IP, VoIP...

Le site FrameIP offre un grand nombre d'informations pertinentes concernant de façon générale le monde TCPIP. Il regroupe des documents généraux (modèles : Tcp, OSI, ......, fonctionnement : NAT, routage, ..., services DNS, DHCP, ..., VoIP et ToIP, ...), une liste d'outils utiles (en ligne ou à télécharger).
Cette fiche ressource se focalise essentiellement sur la téléphonie et la voix sur IP.

Le document Téléphonie sur IP décrit simplement le principe et de nombreux détails pratiques concernant en particulier :
- les aspects de migration de la téléphonie classique vers la téléphonie IP
- un panorama des produits disponibles commerciaux et Open Source

Le document Voix sur IP décrit de la même manière les principes de mise en oeuvre de la voix sur IP, et plus particulièrement :
- l'architecture VoIP incluant GateKeeper et Gateway
- les protocoles d'ouverture de session H323, SIP, les protocoles de transport de l'audio et de la vidéo RTP et RTCP

A noter
- pour chacun de ces documents le dernier paragraphe "Suivi du document" précisant les mises à jour et évolution de celui-ci
- l'existence d'un forum autour de la ToIP

Syndiquer le contenu