article

Article

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

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.

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

UML : langage graphique de modélisation

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

UML : langage graphique de modélisation

  • http://www.uml.org/
  • Type de ressource : article
  • Date de publication du document ou de l'événement : Juin 2009
  • Auteur(s) ou responsable(s) : Laurent Perochon (INRA)
  • Contact pour plus d'informations : laurent.perochon@clermont.inra.fr

Unified Modeling Langage : UML

Historique

Au début des années 90, une cinquantaine de méthodes d'analyse et de conception objet existaient. Parmis elles, trois étaient considérées comme les plus importantes : BOOCH de Grady Booch, OMT de James Rumbaugh et enfin OOSE d'Ivar Jacobson. Ces trois auteurs ont ensuite décidé d'unir leurs efforts au sein de la société Rational Software et en 1996 la version 0.9 d'Unified Modeling Langage (UML) est proposée. Deux éléments importants sont à noter : 1) le terme unified signifie que les auteurs ont essayé de regrouper les éléments importants des concepts objets, 2) le terme langage montre qu'il s'agit d'un langage de modélisation et non d'une méthode! Les principaux acteurs du secteur informatique ont ensuite participé à cet effort, et UML 1.0 a été proposé à l'Object Management Group (OMG). Cet organisme international chargé de définir des standards dans le domaine de l'objet normalise UML 1.1 en 1997. Cette norme a depuis continué d'évoluer et nous en sommes aujourd'hui à la norme 2.2 sortie en le 02/2009. UML est un langage qui permet de modéliser non seulement des applications informatiques ou des structures de données, mais également les activités d'un domaine : mécanique, biologie, processus métier ...

UML en bref

Ce langage est tout d'abord graphique et basé autour d'entités et de relations. Contrairement à d'autres formalismes reposant sur un seul type de diagramme, tel que par exemple celui des systèmes dynamiques de J. Forrester (http://www.hypergeo.eu/spip.php?article384), un modèle est ici représenté selon différents aspects, chacun à l'aide d'un type de diagramme particulier. Il peut être utilisé aussi bien durant les phases d'analyse, de conception, ou d'implémentation. Enfin, ce langage n'est pas formel. Certains termes sont flous, voir peuvent être considérés comme redondants. Certains y voient une facilité permettant de mieux modéliser les systèmes, d'autres une lacune. UML permet de modéliser des comportements synchrones et asynchones, cette modélisation est parfois complexe car elle n'est pas formelle. C'est le cas des systèmes temps réels qui utilisent souvent l'approche synchrone et asynchrone, la compréhension est parfois complexe et demande une certaine pratique pour la rédaction des diagrammes de séquence et des machines à état. Dans les projets complexes, il devient indispensable d'utiliser des outils de simulation afin de comprendre le cas nominal et les cas dégradés.

Les diagrammes

Ils sont au nombre de treize, de 3 types : - les diagrammes de structure : diagramme de classe, diagramme composite, diagramme de composants, diagramme de déploiement, diagramme d'objets, diagramme de package - les diagrammes de comportement : diagramme d'activité, diagramme de cas d'utilisation, diagramme d'état-transition - les diagrammes dynamiques : diagramme de séquence, diagramme de communication, diagramme global d'interaction, diagramme de temps Les diagrammes les plus utilisés sont les suivants : cas d'utilisation, diagramme de séquence, diagramme de classe, diagramme de package, diagramme composite, diagramme d'état-transition. Certains utiliseront UML durant tout le cycle de développement du logiciel, d'autres seulement durant une certaine partie.

Les principaux diagrammes

Il s'agit des diagrammes les plus fréquemment utilisés. Comme les exemples d'utilisation d'UML dans le domaine informatique sont nombreux, il a été choisi ici d'utiliser des domaines différents.

1) Le diagramme de cas d'utilisation

En ingénierie informatique, ce diagramme est principalement utilisé durant l'analyse des besoins. Il définit les principales fonctionnalités (cas d'utilisations) que le logiciel fournit à des types d'utilisateurs. D'un point de vue plus général, il montre les interactions entre un système et son environnement. L'exemple (A. Lisec et al. 2008) montre les types d'acteurs (les personnages) et les cas d'utilisation (ovales). Un type d'acteur peut-être un humain, un système informatique externe, un système biologique ....

diagramme de cas d'utilisation

Diagramme de cas d'utilisation dans le domaine de la vente

2) Le diagramme de classe

Ce diagramme décrit la structure du logiciel. Les entités (classes) et leurs liens (associations) sont décrits. L'exemple (J.L. Drouet et L. Pagès, 2003 et 2007) montre l'évolution d'un modèle grâce à deux diagrammes de classes. Les croix indiquent la suppression de classes comparé à la deuxième version (à droite) et la ligne verticale marque le découpage effectué qui n'existait pas dans la première version.

diagramme de classe

Evolution d'un modèle mis en évidence par diagrammes de classes

3) Le diagramme d'activité

Met l'accent sur la modélisation des comportements. L'exemple (L. Pérochon et al. 12001) présente pour une seule entité l'ensemble des activités qu'elle peut réaliser. On peut aussi montrer sur un même diagramme plusieurs entités en interaction.

diagramme d'activite

Diagramme d'activités d'un agent animal (système multi-agents)

4) Le diagramme d'état-transition

Il s'agit d'une variante orientée objet des diagrammes de Harel (statecharts). Un état représente une situation dans laquelle se trouve un élément du modèle, par exemple une instance. Une situation peut être dynamique, comme lorsqu'une activité est réalisée, ou statique comme l'attente d'un signal. L'exemple (A. Lisec et al, 2008) permet de comparer les états de deux animaux : le rat et la puce.

diagramme d'états-transitions

Comparaison des états de deux animaux par diagramme d'état-transition

5) Le diagramme de séquence

Décrit les séquences d'échanges au cours du temps entre instances. En phase d'analyse des besoins, on l'utilise pour montrer les échanges entre un acteur et le système. L'exemple (C. Linard et al., 2009) montre l'envoi de messages (flèche) entre instances (rectangle).

diagramme de sequence

Interaction entre un acteur et son environnement par diagramme de séquence (multi-agents)

Pour aller plus loin

Références bibliographiques

Informatique

L. Doldi. UML2 Illustrated, Developing Real-Time and Communication Systems. TMSO

J. Gabay et D. Gabay. UML 2 Analyse et Conception. Mise en oeuvre guidée avec études de cas. Dunod. 226 p. 2008.

P. Roques et G. Renault. UML2 par la pratique: Etudes de cas et exercices corrigés. Eyrolles. 367 p. 2008.

J. Rumbaugh, I. Jacobson, G. Booch. UML 2.0 Guide de référence. Campus Press. 774 p. 2004.

Autres domaines

L. Debrauwer et F. V. der Heyde. UML2. Initiation, exemples et exercices corrigés. Ed. ENI. Coll. Informatique Technique. 274 p. 2005

J.L. Drouet et L. Pagès . 2003. GRAAL : a model of the Growth, Architecture and carbon Allocation during the vegetative phase of the whole maize plant . Model description and parameterisation. 2003. Ecological Modelling, 165 pp. 147-173.

J.L. Drouet et L. Pagès . 2007. GRALL-CN: A model of the Growth, Architecture and Allocation for the Carbon and Nitrogen dynamics within whole plants formalised at the organ level. Ecological Modelling, 206 pp.231-249.

C. Linard, N. Ponçon, D. Fontenille, E. F. Lambin. 2009. A multi-agent simulation to assess the risk of malaria re-emergence in southern France. Ecological Modelling 220, pp. 160-174.

A. Lisec, M. Ferlan, F. Lobnik, R. Sumrada. 2008. Modelling the rural land transaction procedure. Land Use Policy, 25 pp. 208-297.

P. J. Papajorgji et P. M. Pardalos. Software engineering Techniques Applied to Agricultural Systems. An Object-Oriented and UML Approach. Springer. Applied Optimization. 247 p. 2006

L. Pérochon, P. Carrère, R. Baumont, B. Dumont, C. Mazel, C. Force, D.R.C. Hill, P. D’Hour, F. Louault, S. Prache, J.F. Soussana, M. Petit. Design of a spatial multi-agent model of a perennial grassland ecosystem grazed by a herd of ruminants. ESS01. 13th european simulation symposium. Simulation in industry. SCS, pp. 509-513. 2001.

Etendre UML (stéréotype / profils)

Il est possible de spécialiser UML à un domaine particulier à travers un profil.

Un profil UML est un ensemble cohérent de stéréotypes et de règles dédiés à un aspects métier ou technique

L'OMG a normalisé ou est en train de concevoir les profils suivants :

OMG Systems Modeling Language (SysML); PIM and PSM for Smart Antenna; UML Profile for CORBA®; UML Profile for CORBA® Component Model (CCM); UML Profile for CORBA®  & CORBA® Component Model (CCCMP); UML Profile for Data Distribution; UML Profile for Enterprise Application Integration (EAI); UML Profile for Enterprise Distributed Object Computing (EDOC); UML Profile for Modeling and Analysis of Real-time and Embedded Systems (MARTE); UML Profile for Modeling QoS and Fault Tolerance Characteristics and Mechanisms; UML Profile for Schedulability, Performance and TimeUML Profile for Software Radio; UML Profile for System on a Chip (SoC); UML Profile for VoiceUML Testing Profile.

D'autres profils sont développés par ailleurs. Ce mécanisme est utilisable par tous.

Détail pour deux de ces profils

OMG SysML pour la conception de systèmes: Il constitue un moyen de rassembler dans un même modèle commun à tous les corps de métier impliqués, les spécifications, les contraintes et les paramètres de l’ensemble du système.

 UML Profile for Enerprise Application Integration (EAI) fournit une norme d’échange de méta-données pour des informations sur des Interfaces Homme Machine d’accès à des applications. L’objectif est de faciliter l’intégration d’applications en normalisant des ùéta-données d’applications pour appeler et échanger des informations entre applications.

Quelques outils

Liste de logiciel

  • http://uml.developpez.com/outils/
  • http://www.objectsbydesign.com/tools/modeling_tools_fr.html
  • http://www.objectsbydesign.com/tools/umltools_byProduct.html
  • libres (100 % licence GPL ou EPL) 

    BoUML (linux, windows)  http://bouml.free.fr/

    Open ModelSphere (windows) http://www.modelsphere.org/fr/open_modelsphere.html

    Umbrello UML Modeller (Linux) http://uml.sourceforge.net/

    Plugins Eclipse (Eclipse tourne sous windows ou linux) http://www.eclipseplugincentral.com/ sous partie UML

    Papyrus et topCased UML Editor (vont fusionner, Eclipse)

    UMLet-Fast UML  Editor (Eclipse)

    Violet UML Editor for Eclipse (Eclipse)

    Outils commerciaux (certains tournent aussi sous Eclipse)

    A noter : pour l'enseignement, certains offrent des conditions avantageuses voir la gratuité

    MagicDraw http://www.magicdraw.com/

    Plugin UML sous NetBeans (linux, windows) Fiche Plume

    Objecteering (Softeam) http://www.objecteering.com/

    Poseidon (Gentleware) http://www.gentleware.com/

    Simulateur UML TAUG2  http://www.telelogic.fr

    Rational Software Modeler (IBM) http://www-01.ibm.com/software/awdtools/modeler/swmodeler/

    Together (Borland) http://www.borland.com/us/products/together/index.html

    Visual Paradigm http://www.visual-paradigm.com/news/vpsuite40/vpuml70.jsp

     

    Utilité de ces logiciels

    Tout d'abord, ils permettent de pouvoir gérer efficacement tous les éléments créés en UML. Ceux-ci sont en effet trés nombreux, et une aide pour assurer une cohérence d'ensemble est bienvenue. A partir de ces outils, on peut générer un squelette du futur code source. Par squelette il faut entendre les noms des classes, méthodes, attributs, associations provenant principalement des diagrammes de classe. Il faudra ensuite compléter directement dans le code les parties manquantes (par exemple le contenu des méthodes). Une autre possibilité pouvant être offerte est la retro-ingénierie (ou ingénierie inverse), qui permet à partir d'un code source de générer des diagrammes de classe. Certains logiciels permettent d'aller plus loin avec par exemple des diagrammes de séquence montrant les échanges entre classes obtenus à partir de l'activation d'une méthode donnée. Parmis les langages couverts par ces différentes possibilités, on peut noter principalement Java et C++. On touche ici une des limites de ces outils. En effet, les modifications futures du code source se feront directement sur lui et non dans les diagrammes UML, d'ou une perte de cohérence entre diagrammes et code, qui risque de s'accentuer avec le temps. Avec la retro-ingénierie on peut conserver cette cohérence, mais uniquement à un même niveau d'abstraction : celui du code source. Les premiers diagrammes UML obtenus durant l'analyse, de plus haut niveau d'abstraction, ne seront eux pas mis à jour automatiquement. Il reste donc la possibilité de les modifier soi-même, ou alors d'adopter une démarche d'ingénierie dirigée par les modèles (J.M. Favre et al. 2006). Model Driven Architecture (MDA) est la solution proposée par l'OMG (X. Blanc 2005).

    X. Blanc. 2005. MDA en action. Ingénierie guidée par les modèles.Eyrolles. 269 pages.
    J.M. Favre, J. Estublier, M. Blay-Fornarino. 2006. L’ingénierie dirigée par les modèles. Au-delà du MDA. Lavoisier. 227 pages.

    Les méthodes de gestion de projet

    L'OMG laisse à chacun libre choix de la méthode à utiliser. Voici donc quelques liens permettant de rechercher votre méthode idéale (si elle existe) :

    pcapr.net : pour explorer des paquets réseau

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

    pcapr.net : pour explorer des paquets réseau

    pcapr.net est un service qui permet d'explorer des paquets réseau. Il est décrit sur le site http://www.bortzmeyer.org/pcapr.html

    Ci-dessous, un extrait de ce site

    Examiner en détail, au niveau des champs qui le composent et même des bits sous-jacents, des paquets capturés sur le réseau est une occupation essentielle pour l'étudiant en réseaux informatiques, pour le programmeur réseau, pour l'administrateur réseaux... et pour celui qui s'intéresse à la sécurité des réseaux. Des outils pour programmeur comme Scapy ou des outils graphiques très riches comme Wireshark permettent de rendre cette tâche bien plus efficace, pour les paquets qu'on a capturé soi-même. Mais il peut être instructif d'explorer les paquets capturés sur des réseaux différents du sien, par exemple pour apprendre des protocoles dont on n'a pas de mise en oeuvre disponible. C'est l'un des buts de pcapr (http://www.pcapr.net), le Flickr des paquets.
    Le principe est simple : vous vous enregistrez (gratuit mais obligatoire) et vous pouvez ensuite envoyer vos propres traces et/ou regarder celles envoyées par les autres membres. Du fait de l'inscription obligatoire, certains liens dans cet article ne seront pas accessibles tant que vous n'aurez pas un compte pcapr (actuellement, un visiteur anonyme peut avoir une idée des paquets mais pas les examiner en détail).
    Vous pouvez chercher une trace (un ensemble de paquets) par date (http://www.pcapr.net/browse) ou par mot-clé (des étiquettes - "tags" -, comme dans del.icio.us). Si je m'intéresse à BGP et que le RFC 4271 ne me suffit pas, je peux chercher http://www.pcapr.net/browse?proto=bgp. Si je préfère LDAP, j'ai http://www.pcapr.net/browse?proto=ldap.
    Une fois la trace trouvée, je peux regarder les paquets, voir leur représentation binaire, ou bien voir une dissection des paquets (apparemment faite par tshark).
    Cela permet déjà d'innombrables possibilités. On ne peut pas déployer tous les protocoles chez soi pour les essayer mais pcapr (http://www.pcapr.net/) permet d'accéder à des tas de protocoles différents. On peut aussi télécharger les traces chez soi au format Pcap pour les étudier plus à loisir, par exemple avec ses propres programmes en C (http://www.bortzmeyer.org/libpcap-c.html) ou en Python (http://www.bortzmeyer.org/libpcap-python.html).
    Mais pcapr a une autre possibilité : on peut modifier les paquets, via l'interface Web et copier ensuite la version modifiée (une sorte de Scapy sur le Web).
    Terminons sur un avertissement : les traces Pcap peuvent contenir des informations confidentielles. Par exemple, les adresses IP permettent de retrouver une personne, celle qui utilisait cette adresse et sont donc considérées à juste titre par la CNIL comme des données personnelles (http://www.cnil.fr/index.php?id=2244), relevant de la loi Informatique & Libertés. Pcapr étant situé aux États-Unis, qui n'ont pratiquement aucune protection légale de la vie privée, il faut donc n'envoyer que des traces :

    • anonymisées, par exemple par un programme qui a remplacé chaque adresse IP par une valeur prise dans 192.0.2.0/24 ou 2001:DB8::/32, voire l'a supprimée totalement (option -h de dnscap (https://www.dns-oarc.net/tools/dnscap) si on l'a utilisé pour la capture). Attention, avec les autres informations, il est parfois possible de retrouver quand même les identificateurs (http://www.schneier.com/blog/archives/2007/12/anon...) qui avaient été anonymisés.
    • ou des traces ne montrant que des adresses IP « à vous », locales à votre réseau. (Ou encore, ce qui est fréquent lors des attaques, des adresses IP que l'on sait usurpées, et qui sont bien indiquées comme telles dans les commentaires de la trace. Voir par exemple http://www.pcapr.net/view/bortzmeyer+pcapr/2009/0/....)

    FAQ : licence & copyright pour les développements de logiciels libres de laboratoires de recherche

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

    FAQ : licence & copyright pour les développements de logiciels libres de laboratoires de recherche

    Attention !Ce document est actuellement et revision, voici la version stable du 7 août 2012 (dont la date de sa première publication est le 10 février 2009).

    Préambule

    Cette FAQ est destinée aux développeurs de logiciels dans les laboratoires de recherche (CNRS, universités, INRA...) qui se posent des questions sur la licence à mettre sur leur développement, la propriété de ces développements et les contacts à avoir avec les services de valorisation. Elle peut aussi s'appliquer aux développeurs dans les services de ces organismes (services informatiques, CRI, DSI...).

    Elle n'est pas un document officiel mais peut être prise comme des informations de bonne pratique et des éléments pour aider à prendre des décisions.

    Elle a été initialisée par Teresa Gomez-Diaz (chargée du référencement des développements de son laboratoire LIGM, responsable thématique PLUME) et Jean-Luc Archimbaud (responsable du projet PLUME) et publiée par la première fois en février 2009. Cette version a compté avec des contributions importantes de Thierry Aimé (auteur du Guide pratique d'usage des logiciels libres dans les administrations entre autres), Nathalie Argoud (chargée de valorisation au CNRS) et Pascal Janots (responsable du SAIC UPEMLV).

    Anne Durand (responsable thématique PLUME), Etienne Dublé (développeur d'un logiciel libre diffusé), Matthieu Herrb (contributeur très actif du monde libre), Benjamin Egret (juriste, Droit de l’informatique et des TIC) et Geneviève Romier (responsable thématique PLUME) ont fait une relecture attentive et ont apporté des améliorations.

    Depuis 2009 nous avons mieux compris les concepts importants qui sont expliqués dans ce document, une nouvelle version s'impose et est actuellement en cours (décembre 2012) ; elle fait l'object d'une relecture attentive par des personnes d'horizons divers de la communauté ESR.

    Si vous voulez indiquer une erreur, quelque chose qui manque ... ajoutez un commentaire (bouton en fin de fiche) ou contactez l'auteur principal.

    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. Elle fait partie maintenant du thème PLUME Patrimoine logiciel d'un laboratoire, ou vous trouverez d'autres documents qui traitent ce sujet, en particulier Article vs. Logiciel : questions juridiques et de politique scientifique dans la production de logiciels.

    Ce document a été présenté lors d'une journée PLUME avec transparents et vidéo disponibles.

    1. Introduction

    Quelles questions se poser avant la diffusion d'un logiciel ?

    Un logiciel que vous avez écrit ou auquel vous avez collaboré doit être diffusé avec une licence et un copyright. Pour choisir, il faut pouvoir répondre aux questions suivantes :

    • Qui sont tous les auteurs ? Pour qui travaillent-ils ? Dans quel cadre ont-ils contribué (professionnel, personnel) ?
    • Certaines parties du logiciel ont-elles été réalisées dans le cadre d'un contrat conclu à titre onéreux (marché public), d'un contrat de collaboration de recherche avec une entreprise, un autre organisme de recherche, d'un contrat européen, d'autres types de contrats ou subventions (ANR...) ?
    • Qui sont les détenteurs des droits patrimoniaux (c'est-à-dire, les propriétaires légaux du logiciel) ?
    • Existe-t-il des matériaux préparatoires (cahiers de laboratoire, spécifications, ...) permettant de dater, d'identifier le ou les auteurs du logiciel, de suivre l'activité créatrice et de constituer une preuve d'antériorité ?
    • Quelles sont les "briques logicielles" utilisées pour le développement et leurs licences ? Ces licences sont-elles compatibles avec les utilisations prévues ?, ont-elles des clauses de réciprocité à respecter (citation, héritage de licences, ...) ?
    • Quelle licence choisir ? Plutôt une licence de droit français ou de droit anglo-saxon ?
    • Est-ce que le choix de la licence est en accord avec la politique scientifique du laboratoire et des tutelles ?
    • Est-ce que tous les détenteurs des droits patrimoniaux sont d'accord sur la licence ?
    • Quelles sont les erreurs à éviter ?

    Cette FAQ est une aide pour répondre à ces questions dans le cas de développements logiciels de laboratoires de recherche.

    2. Définitions

    Qu'est-ce qu'un logiciel ?

    Selon l'article L. 112-2 du Code de la propriété intellectuelle en France (CPI), un logiciel est une oeuvre de l'esprit protégée par le droit d'auteur.

    L'arrêté du Ministre de l'Industrie du 22 décembre 1981 relatif à l'enrichissement du vocabulaire de l'informatique complète cette définition : 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.

    D'un point de vue légal, un logiciel est donc une oeuvre de l'esprit, avec un titre, des auteurs et des droits qui sont automatiquement associés à l'oeuvre dès sa création. C'est un concept large, et contient le code source, le code compilé et peut contenir la documentation.

    Remarque : la définition qui s'applique n'est pas mathématique ni informatique, elle est juridique. Elle s'applique inévitablement (et parfois bien malgré nous) dans toute sa dimension lors de la diffusion d'un logiciel.

    Qu'est-ce qu'un logiciel libre ?

    Suivant la définition de free software de la Free Software Fondation (FSF), un logiciel est libre (free software) lorsque ces 4 libertés sont garanties :

    • liberté d'exécuter le logiciel (utilisation à l'infini),
    • liberté d'étudier et de modifier le fonctionnement (ce qui implique la disponibilité du code source),
    • liberté de redistribuer des copies,
    • liberté de publier les modifications.

    Note : il n'y a pas d'obligation de publication des modifications apportées à un logiciel libre.

    Si une de ces quatre libertés mentionnées n'est pas garantie le logiciel n'est pas libre. Un logiciel qui n'est pas libre est dit propriétaire (RMS préfère le terme privatif).

    Un logiciel libre n'est pas libre de droits. L'auteur d'un logiciel libre n'abandonne pas ses droits d'auteur mais concède à chacun les libertés indiquées dans la définition.

    Autre concept : un logiciel commercial est un logiciel dont le contrat de licence prévoit une contrepartie financière à l'utilisation.

    Attention : un logiciel libre n'est pas forcément un logiciel gratuit, et un logiciel gratuit n'est pas forcément libre. Un logiciel libre peut être un logiciel commercial. Un logiciel distribué en code source n'est pas forcément un logiciel libre. Un logiciel diffusé sans licence n'est pas un logiciel libre, au contraire.

    Des logiciels libres existaient (TeX, le système BSD) avant la création par Richard M. Stallman de ce concept dans les années 1980, c'est un concept né dans les milieux universitaires.

    Qu'est-ce qu'un logiciel open source ?

    L'utilisation du mot free pose certains problèmes, surtout dans des milieux proches des entreprises et des activités commerciales, et à la fin des années 1990 l'Open Source Initiative (OSI) défine l'open source software ou les logiciels à code (source) ouvert. Il s'agit d'une définition en 10 points, dont le deuxième (Source code) implique la disponibilité du code source.

    Comment sait-on qu'un logiciel est libre ?

    Un logiciel est libre lorsqu'il est diffusé avec au moins une licence garantissant les 4 libertés énoncées plus haut. Pour connaître si une licence vérifie ces conditions.

    Comment sait-on qu'un logiciel est open source ?

    Un logiciel est open source s'il est diffusé avec une licence approuvée par l'OSI, voici la liste de ces licences.

    Quelles sont les différences entre les logiciels libres et les logiciels open source ?

    D'un point de vue juridique, il n'y a pas de différence importante entre ces deux concepts, les deux types de licences font intervenir les droits de utiliser, modifier et re-distribuer un logiciel. Par ailleurs, la plupart des licences utilisées sont reconnues à la fois libres (par la FSF) et open source (par l'OSI).

    Cependant il s'agit bien de deux concepts différents (et de deux philosophies différentes). Par exemple, la licence NASA version 1.3 est une licence approuvée par l'OSI, mais elle n'est pas une licence de logiciel libre.

    Un autre exemple qui devient de plus en plus courant est celui qui empêche la modification de l'executable d’un logiciel dans un support numérique physique. Le logiciel peut vérifier toutes les conditions d'un logiciel open source, mais la liberté de utilisation n'est pas respectée.

    Terminologie PLUME

    La terminologie PLUME ne prend pas en compte en général ces differences entre logiciel libre et logiciel open source, voir les définitions des mots clés libre et propriétaire.

    3. Propriété du code

    Qui est propriétaire du code (informations de copyright) ?

    Le logiciel est une oeuvre de l'esprit protégée par le droit d'auteur à condition qu'il soit original. Il peut être également protégé par un brevet s'il est un élément d'une invention technique brevetable (attention dans ce cas à la confidentialité), contactez les services de valorisation pour avoir plus d'information sur cette question.

    Les éléments du logiciel protégés au titre du droit d'auteur sont l'architecture des programmes, le code source, le code objet, les différentes versions, les écrans et les modalités d'interactivité s'ils sont originaux et le matériel de conception préparatoire. Les algorithmes, les interfaces et les langages de programmation relèvent du domaine de l'idée et ne sont pas protégeables au titre du droit d'auteur. Comme pour toute autre oeuvre, la protection est automatique dès la création, aucun dépôt n'est nécessaire, cependant il est possible de faire des dépôts à l'Agence de Protection de Programmes (APP), contactez les services de valorisation pour avoir plus d'information sur cette question.

    Concernant la propriété, en français on parle de droits patrimoniaux, en anglais de copyright ; ces deux concepts sont proches.

    L'article L113-9 alinéa 1 du Code de Propriété Intellectuelle précise : « Les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l'exercice de leur fonction ou d'après les instructions de leur employeur sont dévolus à l'employeur qui est seul habilité à les exercer ». Donc sauf accord spécifique, dans la fonction publique, le propriétaire des droits patrimoniaux sur le code est l'employeur du développeur.

    Les contrats de collaboration, de commande, ... peuvent déterminer les détenteurs des droits patrimoniaux des logiciels résultants du contrat.

    Le propriétaire est indiqué dans le code source par une ligne d'information de "copyright" ou "droits patrimoniaux" ou "droits reservés".

    Du point de vue juridique, seul le titulaire des droits patrimoniaux peut décider de la diffusion du logiciel. Similairement, donner une licence à un logiciel fait intervenir des droits patrimoniaux, il faut donc l'accord du propriétaire légal du logiciel.

    Les auteurs du logiciel conservent leurs droits moraux, mais ils sont assez réduits dans le cas d'un logiciel, voir par exemple Quels droits pour les auteurs de logiciels ?

    Dans le cas de participation de stagiaires, de doctorants (avec financement exterieur à l'établissement), de personnel non salarié, la jurisprudence n'est pas claire en ce qui concerne les droits patrimoniaux. Contactez les services de valorisation des tutelles de votre laboratoire pour plus d'information, voir aussi le document Diffuser un logiciel de laboratoire : recommandations juridiques et administratives.

    4. Licences

    Qu'est-ce qu'une licence ?

    Une licence est un contrat entre les auteurs du logiciel et les utilisateurs.

    A quoi sert une licence ?

    Une licence indique qui peut utiliser un logiciel et pour quelle utilisation. Elle établit le cadre légal d'utilisation, modification et (re-)distribution pour le logiciel et complète le cadre légal (établit par le droit d'auteur) qui s'applique automatiquement lors de la création du logiciel.

    Une licence (libre ou propriétaire) sert à protéger les auteurs, les utilisateurs, les éventuels collaborateurs au développement, les propriétaires des droits patrimoniaux.

    Elle peut entraîner des obligations sur l'utilisation du code comme brique de nouveau code ou avoir des clauses de reciprocié qui sont à respecter.

    Pourquoi choisir une licence ?

    Le fait de ne pas indiquer de licence ne garantit pas les 4 libertés d'un logiciel libre, bien au contraire, cela soumet le logiciel aux droits d'auteur stricts. Juridiquement parlant, cela veut dire (entre autres) que personne ne peut utiliser ce logiciel sans le consentement de son propriétaire, c'est-à-dire, des auteurs et/ou de ses employeurs (en cas de travail salarié).

    Si vous mettez votre logiciel disponible en téléchargement, il n'est libre que s'il est accompagné d'une licence libre.

    Quand choisir une licence ?

    La licence doit être mise en place avant la diffusion du logiciel.

    Dans le cas de développements réalisés dans le cadre de marchés publics, il faut anticiper dans les documents contractuels CCAP (cahiers des clauses administratives particulières) et CCTP (cahier des clauses techniques particulières) le transfert des droits patrimoniaux du titulaire vers la personne publique mais aussi le respect des 4 libertés du logiciel libre. En particulier il faudra être très attentif aux licences des briques logicielles utilisées.

    Qui décide du type de licence libre ?

    La licence doit être mise en place avec l'accord de tous les détenteurs des droits patrimoniaux ou propriétaires des logiciels et/ou les auteurs. Il est nécessaire de connaître la politique scientifique du laboratoire et de ses tutelles, contactez la direction du laboratoire et les services de valorisation des tutelles pour plus d'information.

    La réutilisation de codes sous diverses licences peut limiter le choix des licences libres (cf ci-dessous) nécessaire à la diffusion du logiciel.

    Il est également possible d'étudier une licence propriétaire, contactez les services de valorisation pour plus d'information.

    Une licence est associée à une version précise du logiciel. Une nouvelle version du logiciel peut être diffusée sous une licence différente des versions précédentes (en restant cependant compatible avec les licences des briques utilisées). Cela permet d'envisager une version commerciale différente à un certain moment en parallèle des versions sous licences libres.

    Comment choisir une licence en fonction du droit ?

    Le choix peut se faire selon le :

    Note : les licences CeCILL sont des licences adaptées au droit français, la licence CeCILL v2 comporte par exemple une clause de compatibilité avec GNU GPL v2. La jurisprudence en France nous montre, entre autres, que la licence GNU GPL établit un cadre juridique que les juges n'hésitent pas à appliquer, 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.

    Comment choisir une licence selon les obligations des briques logicielles utilisées ?

    Selon la notion de copyleft ou exigence de réciprocité, un programme sous licence copyleft peut être copié, utilisé, étudié, modifié et distribué dans la mesure où ces possibilités restent préservées. Le concepteur n'autorise donc pas que son travail puisse évoluer avec une restriction de ces possibilités. Autrement dit, les programmes réalisés à partir d'éléments sous copyleft héritent de cette caractéristique, et s'ils sont diffusés, leur licence doit respecter cette clause de réciprocité.


    Ce tableau (extrait d'une présentation de Thierry Aimé) illustre les choix en matière de licence pour un logiciel AB, utilisant un composant A, suivant la nature de la licence couvrant ce dernier.

    • Lorsque le composant A est sous une licence sans copyleft, c'est-à-dire sans exigence de réciprocité, rien n'est imposé pour la licence du logiciel AB qui contient A.
    • Lorsque le composant A est sous une licence copyleft faible, la licence de A est conservée dans le logiciel AB, y compris près modification, mais rien n'est imposé pour la licence du composant B.
    • Lorsque le composant A est sous une licence copyleft fort, celle-ci s'impose à l'ensemble du logiciel AB contenant le composant A lors de sa diffusion.

    Exemples de licences selon le degré de copyleft :

    • sans copyleft : Apache, BSD, MIT, CeCILL-B
    • avec copyleft faible : MPL, GNU LGPL, CeCILL-C
    • avec copyleft fort : GNU GPL, CeCILL v2

    Lors des Journées PLUME 22-23/09/09 : Pourquoi et comment diffuser un développement logiciel de laboratoire ou d'université en libre ?, Sébastien Canevet (voir sa présentation sur la page) a utilisé le vocabulaire : persistentes, diffusives, évanescentes pour décrire ces trois types de licences.

    On peut diffuser des logiciels sous plusieurs licences, ce qui aide à traiter les problèmes de compatibilité lorsque plusieurs briques sont incluses dans un projet. Par ailleurs, des parties d'un logiciel peuvent être diffusées sous licences différentes (parfoir le terme semi-libre est utilisé dans ce cas, je préfère l'éviter puisqu'il est mal défini et peut générer beaucoup de confusion).

    Dans l'ensemble des logiciels libres diffusés dans le monde, 6 licences sont majeures : GNU GPL (69 %), GNU LGPL (10 %), BSD (9 %), MIT (2 %), Apache (1 %), MPL (1 %) (voir la présentation de Thierry Aimé). A noter qu'en France, dans la communauté Ens Sup Recherche les pourcentages sont différents, avec une présence assez forte des licences CeCILL.

    Qu'est-ce une licence contaminante ou virale ?

    On parle des licences contaminantes dans le cas de copyleft fort : en cas de diffusion, tout logiciel dérivé d'une brique logicielle sous GNU GPL doit être diffusé sous licence GNU GPL. On parle aussi de licences "copyleftées" (et "non-copyleftées") ou de "héritage des licences".

    Les termes contaminant ou viral, souvent utilisés de façon très péjorative dans certains milieux, sont bannis des communautés des logiciels libres, mais ils restent assez utilisés dans les présentations des juristes, à utiliser donc avec mesure.

    Que veut dire incompatibilité de licences ?

    On parle d'incompatibilité de licences si au moins deux licences des briques logicielles à inclure dans un nouveau logiciel imposent des obligations contradictoires.

    Des logiciels comme FOSSology ou OSLC peuvent aider à déterminer des conflits entre les licences des différentes briques logicielles. Utiliser des formats SPDX ou Open source cartouche pour communiquer les informations de licence et copyright d'un logiciel peut simplifier la gestion de ces informations et améliorer le fonctionnement de OSLC ou FOSSology.

    Quelles sont les erreurs à ne pas commettre dans la conception-diffusion de logiciel dans un laboratoire ?

    • Diffuser le logiciel sans licence ou sans avoir traité correctement les informations de droit d'auteur.
    • Engager une coopération avec un partenaire exterieur autour d'un logiciel sans formaliser la coopération par un contrat.
    • Utiliser des briques logicielles sans connaître leur origine, leur licence.
    • Ne pas respecter des clauses de réciprocité des licences des briques logicielles que vous avez incluses dans le logiciel que vous venez de mettre à disposition de toute la toile depuis votre page web.
    • Diffuser sans licence des éléments glanés sur le net, ou les diffuser avec une licence incompatible avec celle d'origine, y compris après modification.
    • Modifier les informations de droit d'auteur ou de licence des éléments glanés sur le net.

    Que faire si la licence d'un logiciel ne convient pas à l'usage prévu ?

    Contacter les auteurs ou les responsables du logiciel pour en avoir une autre.

    5. Dans le code

    Comment indiquer les détenteurs des droits patrimoniaux (propriétaires) du code ?

    La notice de copyright va établir qui sont les personnes morales ou physiques qui détiennent les droits patrimoniaux :

    Copyright (ou ©, ou Droits patrimoniaux, ou Droits reservés) + année(s) + nom de la personne morale ou physique

    Les termes "Tous droits reservés" ou "Quelques droits reservés" sont aussi utilisés.

    Comment mettre en place la licence couvrant le code source ?

    Il faut que les ayants droit et/ou les auteurs se mettent d'accord sur la licence à utiliser, et vérifier que la licence est en accord avec les contrats de commande, de collaboration ou autres s'ils concernent le logiciel. Également il faut faire attention à l'héritage ou la compatibilité de la licence avec celles des briques logicielles incluses. Les informations doivent être mises en place avant la diffusion du logiciel.

    Les lignes insérées dans les fichiers sources seront en accord avec la licence choisie, par exemple : http://www.gnu.org/licenses/gpl-howto.html, http://www.cecill.info/placer.fr.html et https://twiki.cern.ch/twiki/bin/view/EGEE/EGEEgLiteSoftwareLicense.

    Donc, préparer un en-tête pour tous les fichiers avec :

    • Nom du fichier, nom du logiciel
    • Copyright (ou ©, ou Droits patrimoniaux) + année(s) + nom de la personne morale ou physique
    • Auteur(s) : les noms des auteurs, une adresse de contact
    • Licence(s)
    • Utile : date de création, date de la dernière version
    • Utile : format SPDX ou Open source cartouche

    Les entêtes pour chaque fichier sont complétées par un fichier de licence (nommé par exemple COPYING, LICENCE, README) ajouté à l'ensemble des fichiers avec le texte complet de la licence ou une URL.

    L'utilisation des formats pour donner les informations sur les droits d'auteur et la licence facilite la gestion automatique de ces informations.

    En plus :

    • mentionner les "briques logicielles" utilisées et leurs licences,
    • indiquer clairement la licence et les auteurs du logiciel dans la documentation, dans le site web : certains utilisateurs potentiels n'iront pas plus loin s'ils n'ont pas compris quei le logiciel est libre, et par ailleurs il est souvent très difficile de trouver les auteurs d'un logiciel,
    • donner des licences aux documentations et au site web (GNU FDL, CC, LAL, ...),
    • parfois les logiciels sont diffusés accompagnés d'un ensemble de données (structurées ou pas en bases de données), il est aussi possible d'accompagner ces données de licences, voir par exemple le logiciel Unitex, dont les données sont accompagnées de la licence LGPLLR.

    6. La direction du laboratoire et les services de valorisation

    Quand contacter les services de valorisation ?

    Adressez-vous aux services SAIC (Services d’activités industrielles et commerciales) de votre université tutelle et aux services de valorisation des organismes tutelles de votre laboratoire (CNRS, INRA...) si les logiciels sont concernés par :

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

    Comment informer le laboratoire et les tutelles de la diffusion d'un logiciel sous licence ?

    Beaucoup de procédures sont possibles, cela doit être décidé en conseil de laboratoire.

    Dans tous les cas, la direction du laboratoire doit être informée du projet de diffusion de logiciel produit par des membres du laboratoire avec la(les) licence(s) choisie(s).

    Le document Guide laboratoire pour recenser ses développements logiciels étudie un exemple de procédure en place au laboratoire (et approuvée au conseil) LIGM pour la diffusion des logiciels (libres) du laboratoire.

    Dans le cas de licence propriétaire, il est impératif de contacter les services de valorisation des tutelles du laboratoire.

    7. Références

    Droit d'auteur

    Licences

    Guides et bonnes pratiques

    CNRS

    Divers

    Fichier attachéTaille
    faq_licence_copyright10fev2009.pdf145.72 Ko

    MATHRICE : réseau d'échanges des informaticiens des laboratoires de mathématiques

    Fiche ressource Article, événement, site web...
    • Création ou MAJ importante : 18/12/08
    • Correction mineure : 22/03/13

    MATHRICE : réseau d'échanges des informaticiens des laboratoires de mathématiques

    Le Groupement De Service CNRS (GDS 2754) Mathrice regroupe les informaticiens administrateurs système et réseau des laboratoires de mathématiques du CNRS, des universités et écoles d'ingénieurs françaises. De manière générale, les informaticiens des laboratoires de mathématiques sont aussi "mathriciens". Le réseau a été créé en 2000 et est devenu un GDS en 2004.

    Mathrice est à la fois un lieu d'échange et d'entraide pour ces informaticiens et un soutien fort à la recherche mathématique par la mise à la disposition de l'ensemble de la communauté de multiples services (annuaire, jetons, plateforme en ligne (la PLM) ...).

    Mathrice est un réseau participant à la fédération des réseaux d'administrateurs systèmes et réseaux RESINFO

    MODELIA : Modélisation et Logiciels d’intérêt commun appliqués à l’Agriculture

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

    MODELIA : Modélisation et Logiciels d’intérêt commun appliqués à l’Agriculture

    Ce site est le site de travail du Réseau Mixte Technologique Modélisation et Logiciels d'intérêt commun appliqués à l'Agriculture. Ce réseau a pour vocation à organiser les échanges autour de la modélisation pour l'agriculture entre la recherche publique, les instituts et centres techniques agricoles et l'enseignement.

    Les ressources informatiques du site modelia sont diffusées dans sa rubrique « Ingénierie d’un projet informatique ». Elles concernent la valorisation et le transfert des modèles agronomiques issus de travaux de recherche.

    Ces ressources informatiques comprennent des fiches (fiches d'informations, de synthèse, de recommandations…) traitant de thèmes d'ingénierie de projet informatique, génie logiciel, méthodologie de développement, technologies informatiques.

    A titre d’illustration, quelques sujets abordés : réutilisation logicielle, qualification logicielle, valorisation, transfert, modélisation, UML, aspects juridiques et licences informatiques, méthodologie et processus de développement, avant-projet, montage de projet, développement logiciel, documentation, choix informatiques, forge, dispositifs d’accompagnement en développement informatique et en valorisation logicielle…

    Ces ressources informatiques comprennent également quelques supports de formation.

    IPv6 et les langages de programmation

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

    IPv6 et les langages de programmation

    Ce document de 48 pages en anglais "IPv6 Compliance with C/C++, Java, Python, Perl" a été écrit dans le cadre du projet européen de grille de calcul EGEE.

    Le but de ce document est de répondre aux deux questions suivantes, pour chacun des langages les plus utilisés dans le middleware de EGEE (gLite), c'est à dire C/C++, Java, Python, et Perl :

    • Comment écrire un serveur et un client compatible à la fois IPv4 et IPv6, basé sur les sockets TCP ?
    • Quelles sont les limites de compatibilité IPv6 des applications écrites dans ce langage ?

    De façon à les comparer, un serveur et un client de test ont été créés dans chacun des langages. Ces examples sont de bons points de départ pour programmer des applications plus évoluées en veillant à la compatibilité IPv4 et IPv6.

    Syndiquer le contenu