dév de logiciels

Développement (production) de logiciels (libres pour la plupart)

Conference FOSSA - Grenoble - 8-10 nov 2010

La seconde conférence FOSSa (Free Open Source Academia Conference), FOSSA2010, se tiendra à Grenoble du 8 au 10 novembre 2010. PLUME est partenaire de cet événement.

Consultez le site de la conférence pour avoir le programme.

L'inscription est gratuite mais obligatoire, sur la page d'inscription.

Extrait du site Web :

The goal of fOSSa (Free Open Source Academia Conference) is to reaffirm the underlying values of open source software: innovation & research in software development. The first edition aimed at providing valuable information about the open Source model at large (Benefits, Business Models, Legal Issues, Quality...), the second edition will focus on specific aspect we feel are key in a renovation of FOSS: Development, innovation & research, Community management & promotion, Public sector, Education.

This conference is achieving a prominent role in the Free Open Source Software arena year by year.

The current debates between Google and Oracle demonstrate the crucial rolethat open source software is playing nowadays in information andcommunication technologies.

At the same time, looking at the major software organizations only, theevolution of open source software appears incomplete, since this modelis spreading rapidly on an ever-growing number of territories. TheArduino project, which is open source applied to hardware, is a clear example.

Considering the strategic actions that the most important industries areundertaking nowadays, after having understood the important role thatopen source software is playing in their business, the second edition of fOSSa conference presents this phenomenon as a new social paradigm. It aims at answering the following questions:

  • How does open source software work? 
  • How can we build its future, creating a common useful ecosystem, supported by academia, industry and citizens?

fOSSa 2010 will welcome various European decision makers and well-known free software organizations, such as Apache, Arduino, Debian, Gnome, Eclipse Foundation, Mozilla, Ubuntu, Engineering Group, Fraunhofer Fokus, Irill, Plume, QualiPSo and FossBazaar. Moreover, the conference includes several workshops, such as install parties and demos. 

IPRA (Intellectual Property Rights Analysis) : pour renforcer la confiance dans les logiciels issus de la recherche

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

IPRA (Intellectual Property Rights Analysis) : pour renforcer la confiance dans les logiciels issus de la recherche

  • Type de ressource : compte-rendu
  • Date de publication du document ou de l'événement : 6 juillet 2010
  • Auteur(s) ou responsable(s) : Patrick Moreau, Direction du Transfert et de l'Innovation de l'INRIA, en collaboration avec Magali Fitzgibbon et Luc Grateau.

Cette fiche résume et recueille la présentation de Patrick Moreau, Direction du Transfert et de l'Innovation de l'INRIA : L'analyse IPR (Intellectual Property Rights) pour renforcer la confiance dans les logiciels issus de la recherche. Cette présentation a été organisée par le Service des Activites Industrielles et commerciales (SAIC) de l'Université Paris-Sud 11 dans le cadre "Les matinales du SAIC" le 6 juillet 2010.

Ce document est distribué sous licence CC.

En voici quelques notes extraites de la présentation.

IPRA: Intellectual Property Rights Analysis.

L'analyse IPR est une « photo » à un moment de la vie du logiciel visant à qualifier le statut juridique d'un logiciel c'est-à-dire son intégrité juridique.

La situation légale d'un logiciel est déterminée par l’identification :

• des auteurs / ayant-droits
• de la nature du logiciel (premier, dérivé, composé)
• des contrats ayant une incidence sur le logiciel (modes contractuels et de financements du développement des différents modules constitutifs du logiciel, licences des composants…)
• d’autre disposition légale ou règlementaire applicable
• des autres droits de PI (propriété intellectuelle) opposables

Cette définition donne un ensemble minimum d’éléments, qui ont un impact sur la façon dont le logiciel pourra être utilisé.

Méthodologie IPRA

Elle s'articule en 4 étapes et 6 phases :

1. STRATEGIE / PREPARATION
• Description "haut niveau" du logiciel : Architecture, fonctionnalités, modules et composants
• Définition des objectifs et de la portée du dispositif de suivi / de l'analyse

2. COLLECTE DES FAITS
• Détermination Statut juridique : dresser une liste des composants du logiciel, en précisant leur licence

3. ANALYSE / CORRECTIONS
• Identification des problèmes et évaluation des risques
• Résolution des problèmes critiques

4. PREPARATION DE L'EXPLOITATION
• Packaging et Dissémination / Transfert

Les bonnes pratiques de développement

Elles s'articulent en trois phases :

1. Lors de la phase initiale de développement
• Codage
• Utilisation de la Forge
• Entête
• Sur la propriété du logiciel ?
• Dépôt APP (Agence de Protection des Programmes)
• Envisager une licence

2. Lors de la diffusion ou transfert du logiciel
• Décision de diffusion
• Situation juridique du logiciel
• Choix de la licence
• Packaging et redistribution
• Autres droits opposables

3. Lors des évolutions du logiciel
• Codage
• Changement de licence
• Entêtes
• Gouvernance
• Dépôt APP

Comme exemple, l’analyse des licences sur un gros logiciel développé sur plus de 15 ans a nécessité le travail d’une personne à plein temps pendant 6 mois.

L'INRIA souhaite, à terme, l'analyse de tous ses logiciels, pour maîtriser la situation légale et renforcer la confiance dans les logiciels issus de l'INRIA.

Fichier attachéTaille
IPRA_Moreau_juillet2010.pdf536.25 Ko

Journée' Diffusion et valorisation des logiciels' pour les laboratoires et les universités à Nancy 17 sept 2010

Une journée 'Diffusion et valorisation des logiciels' pour les laboratoires de recherche et les universités' est organisée à Nancy le 17 sept 2010 par le réseau métier DevelopR6. Une présentation de PLUME y sera faite.

L'inscription est gratuite mais obligatoire.

Pour plus d'informations, consultez la fiche PLUME...

Cours 'Introduction au langage OCaml'

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

Cours 'Introduction au langage OCaml'

Caml est un langage de programmation généraliste, conçu pour garantir la sûreté et la fiabilité des programmes. Il est très expressif et néanmoins facile d'apprentissage et d'emploi. Caml se prête à la programmation dans un style fonctionnel, impératif ou orienté objets. Il est développé et distribué par l'INRIA depuis 1985.

Ce support de cours entièrement rédigé peut être utilisé pour assurer une formation introductive pratique au langage Objective-Caml (OCaml). Il peut également servir pour une auto-formation.

Il se base sur le plan du livre Développement d'applications avec Objective-Caml et contient plusieurs exercices d'application des principes et constructions évoqués.

IPOL : Image Processing On Line : algorithmes de traitement d'images en ligne

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

IPOL : Image Processing On Line : algorithmes de traitement d'images en ligne

IPOL est une revue en ligne de traitement d'images, visant à faciliter l'échange et la reproductibilité des travaux de recherche.

La publication des algorithmes, aussi précise et complète que possible, comprend :

  • une page web (sous licence libre Creative Commons) contenant une description détaillée de l'algorithme publié, de sa bibliographie, ainsi que des exemples commentés et d'une analyse des limites de l'algorithme ;
  • une implémentation en C ou C++, portable et documentée, sous licence libre GPL, BSD... ;
  • une interface web de démonstration, où l'algorithme peut être testé sur des ensembles de données téléchargées par les utilisateurs ;
  • une archive contenant l'historique des expériences en ligne ;
  • un forum de discussion sur l'algorithme, avec les messages des rapporteurs.

L'objectif limité de IPOL est de rendre accessible à la communauté scientifique les algorithmes dans leur forme la plus détaillée.
Les auteurs IPOL ne sont pas nécessairement les inventeurs de l'algorithme qu'ils publient. Ils peuvent n'être que les auteurs d'une implémentation de l'algorithme particulier et de sa description précise. IPOL publie des algorithmes nouveaux comme des algorithmes classiques.

IPOL propose également aux laboratoires partenaires la mise en place d'ateliers de traitement d'image.

Officiellement lancé le 29 avril 2010, IPOL contient au 02 juin 2010 ces algorithmes, en ateliers ou proches de la publication :

Pour en savoir plus : description du projet IPOL, contenu d'IPOL, procédure de soumission d'un algorithme, politique de copyright et licence, fils RSS/Atom

Theme Patrimoine logiciel d'un laboratoire

Nouveau thème dans PLUME : patrimoine logiciel d'un laboratoire qui a pour objectif de faciliter et de promouvoir la gestion du patrimoine logiciel des laboratoires de recherche, et de regrouper les fiches et les informations publiées sur la plate-forme PLUME qui sont utiles à cette gestion : consultez la page...

Link checker : vérification d'hyperliens

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

Link checker : vérification d'hyperliens

Link checker (http://validator.w3.org/checklink) est un service en ligne de vérification des hyperliens dans une page web ou dans un site.
C'est un des services offert par le W3C décrit dans la fiche PLUME : Les services de validation (Web) offerts par le W3C.

La vérification peut être récursive.

Il est possible de faire un robot en écrivant un script qui génère les requêtes au service HTTP.

Pour vérifier la page http://www.projet-plume.org/fiche/plugin-visual-ed..., il suffit de faire la requête suivante :
http://validator.w3.org/checklink?uri=http%3A%2F%2...

De plus, il est possible de vérifier les hyperliens d'un document en le chargeant directement ou en indiquant son URL:
http://validator.w3.org/

Diffuser un logiciel de laboratoire : recommandations juridiques et administratives

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 11/04/10
  • Correction mineure : 27/05/13

Diffuser un logiciel de laboratoire : recommandations juridiques et administratives

Cet article n'est pas un document officiel d'un organisme ou d'une autre entité. Il continue l'étude commencée avec les documents qui sont décrits dans : Documents de référence PLUME pour mieux gérer les développements logiciels, les diffuser et les valoriser dans un laboratoire Fiche Plume, en répondant aux questions :

  • Quelles sont les bonnes pratiques à suivre lorsqu'on prépare la diffusion d'un logiciel ?
  • Quelles sont les démarches à faire ?
  • Quels sont les documents importants à conserver (la traçabilité est une question essentielle !) ?
  • Quelles notions importantes du droit d'auteur s'appliquent ?

À la différence des documents cités, ce texte prend la perspective de l'auteur ou responsable d'un logiciel dans un laboratoire ou une institution de recherche.

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), Vincent Guhur (DAJ CNRS). Des versions de ce document ont été aussi relues par : M.-P. Béal, directrice du LIGM, Véronique Baudin, Pascal Dayre, Samuel Godey, Konrad Hinsen.

Ce texte a été motivé par l'étude d'un cas qui nous a été soumis, et qui est illustratif : regulièrement, des développements logiciels dans les laboratoires de recherche font surgir des problèmes analogues.

Cas d'étude

Un projet logiciel a abouti. Le projet a été dirigé par un professeur (laboratoire L1) et un maître de conférences (laboratoire L2) de l'Université G1. Un premier logiciel a été développé par un stagiaire, lors d'un stage gratifié (S1) de deux mois en 2008. Ce premier logiciel n'a pas été diffusé, mais il a été complètement repris par un nouvel étudiant lors d'un deuxième stage en 2009 gratifié par le CNRS (S2) : ce deuxième stage a donné lieu à un logiciel abouti. Le professeur prépare la diffusion du logiciel sous licence libre, une publication associée et sa présentation pour un prochain congrès. De nouvelles évolutions du logiciel sont prévues, avec l'intervention de nouveaux stagiaires.

Ma réponse

Ceci ne constitue pas une réponse officielle ; c'est mon opinion, sans aucun engagement de ma responsabilité ou celle des différents relecteurs de cette fiche.

Le logiciel du stage S1 ne peut pas être modifié sans l'accord explicite du premier stagiaire, pour le second stage, le stagiaire doit donc repartir à zéro (au niveau du code). Si l'on prévoit de diffuser le logiciel du stage S2, le mieux est de le faire sous une licence libre, avec l'accord (signé) de tous les intervenants au projet, ceci avant de lancer la soumission à publication ou la présentation au congrès. Cela simplifie les évolutions futures du logiciel, et en particulier tous les collaborateurs pourront le faire évoluer sans obstacle légal. L'Université G1 intervient dans la décision de licencier ce logiciel, même si on détecte souvent l'oubli de ce point. Je pense que les tutelles des laboratoires doivent définir leurs politiques sur les logiciels et fournir des procédures simples et adaptées pour permettre la diffusion rapide des logiciels sous licence libre.

Même si les responsables du projet n'ont pas écrit de code, ils ont proposé le projet et le code n'aurait pas pu s'écrire sans leur expérience et leur savoir-faire. C'est parfois difficile de décider quels sont les auteurs d'un logiciel. Etablir une liste d'auteurs, en leur assignant un pourcentage de participation, est la solution adoptée par d'autres projets (voir la présentation Développer en logiciel libre : Empaquetage et diffusion par exemple) : c'est une très bonne solution. Je n'ajouterais pas le premier stagiaire comme auteur du logiciel : ce sont des briques logicielles indépendantes, je recommanderais de simplement citer ce premier travail.

Deuxième cas d'étude

Lors de la rédaction de cette fiche, un autre cas nous a été posé, sur un projet logiciel proposé à des étudiants, ce type de projets étant nécessaire pour valider leur diplôme. Les étudiants n'ont pas le statut de stagiaires. La rédaction de la proposition explicite que le logiciel obtenu sera soumis à une licence libre.

Ma réponse

Dans ce cas il n'y a pas de convention de stage ni de contrat. Il me semble qu'un document signé qui établit l'accord des étudiants sur leur participation au développement d'un logiciel libre est indispensable. Ce document doit indiquer le nom du logiciel, décrire le projet, indiquer qui en est le responsable et quelle est la licence prévue ainsi que la liste des participants et la durée du projet. Ce document doit être daté et signé par tous les participants.

Procédure pour la diffusion d'un logiciel (résumé des paragraphes suivants, pour les lecteurs pressés)

Voici les principaux points de la procédure proposée qui sont explicités dans les paragraphes suivants (que nous vous conseillons de lire, même si vous êtes un lecteur pressé) :

(*) À revoir à chaque nouvelle version du logiciel.

Il est primordial d'établir une licence avant de diffuser un logiciel.

Il est important aussi d' informer la direction du laboratoire de cette diffusion. L'utilisation de sa fiche PLUME pour donner à la direction les informations sur le logiciel, nous semble un bon moyen :). Si une fiche est créée pour chaque nouveau logiciel du laboratoire, celui-ci pourra plus tard facilement accéder à toutes les fiches de logiciels développées et mettre un pointeur depuis son site Web vers cette liste (voir par exemple la liste de logiciels du LIGM).

À noter que toute cette liste de points s'applique aussi pour un développement diffusé avec une licence commerciale : il faut de même établir la liste des auteurs...

Droits d'auteur

Un logiciel est considéré comme une œuvre au sens du Code de la Propriété Intellectelle (CPI). D'après l'article L112-2 : "Sont considérés notamment comme œuvres de l'esprit au sens du présent code :

1° Les livres, brochures et autres écrits littéraires, artistiques et scientifiques ;
...
13° Les logiciels, y compris le matériel de conception préparatoire ;
..."

Toutefois, il est important de noter que seules les œuvres présentant un caractère original sont protégées par le droit d'auteur.

Puisque les logiciels ne connaissent pas les frontières, il est important de connaître que le cadre légal international est donné par la Convention de Berne pour la protection des œuvres littéraires et artistiques. Cette convention est gérée actuellement par l'Organisation mondiale de la propriété intellectuelle (OMPI).

Avant de pouvoir appliquer les règles établies par le CPI, il est essentiel de pouvoir répondre à tout moment à deux questions qui semblent innocentes :

  • qui est l'auteur ?
  • de quelle œuvre ?

L'œuvre

  • Il est nécessaire de nommer le logiciel. Le titre du logiciel bénéficie aussi de la protection par le droit d'auteur (s'il présente un caractère original). Il est important de choisir un nom qui ne porte pas atteinte aux droits des tiers (par exemple, il faut éviter de donner au logiciel un nom similaire à celui d'une marque désignant un autre logiciel). Afin de savoir si un nom est déposé en tant que marque vous pouvez consulter la Base de données des marques de l'Institut National de la Propriété Industrielle (INPI).
    Il est utile de choisir des noms faciles à prononcer (lbqavr-tsy n'est pas un bon nom de logiciel).
  • Il faut savoir qui en est le(s) propriétaire(s). Ce sont les détenteurs des droits patrimoniaux associés au logiciel. Selon la loi française, aucun propriétaire ne peut prendre l'initiative d'exploiter une œuvre sans l'autorisation explicite des autres propriétaires.
  • Le logiciel doit avoir un caractère original. Il faut rédiger un descriptif du logiciel avec : son contenu, ses foncionnalités, ses applications envisagées, en quoi est-il une nouvelle œuvre par rapport à l'existant (i.e. l'originalité apportée).
  • Il faut dater le logiciel. La protection par le droit d'auteur s'appliquant de plein droit du fait de la création de l'œuvre, il est nécessaire de pouvoir déterminer sa date de création. Plusieurs dates sont importantes : date du matériel préparatoire, date de diffusion, date de chaque version, dates des contrats et conventions liés au logiciel.
  • Il faut savoir localiser le logiciel (par une adresse ou un point de contact si l'œuvre n'est pas distribuée).
  • Il faut pouvoir citer le logiciel. Comme pour toute œuvre produite dans un laboratoire ou une institution de recherche, l'utilisation d'une référence est fondamental pour l'évaluation et la gestion du patrimoine scientifique (voir Préciser la genèse des documents diffusés).

Note : ni le lieu de développement (bureau, maison, avion...) ni l'heure (2 heures du matin) sont retenus comme des informations importantes dans la production d'une œuvre, en revanche il est tenu compte de ce que l'œuvre est en relation avec votre activité professionnelle.

La traçabilité du code

Face à un problème légal, il est essentiel de pouvoir tracer le code et de pouvoir apporter des preuves (sur les dates, le contenu, les auteurs, ...) Des organismes comme l'INRIA proposent d'effectuer des dépôts dans l'Agence de protection des programmes (APP) Fiche Plume pour renforcer cette traçabilité (entre autres objectifs), et cela à chaque version majeure ou à chaque départ d'un contributeur important.

Constituer un dossier de dépôt APP est un moment privilégié de communication entre les responsables d'un projet logiciel et les services de valorisation, et cette communication est nécessaire et doit se développer.

Il peut arriver néanmoins que les services de valorisation d'autres entités de recherche ne soient pas aussi bien établis que ceux de l'INRIA et que faire des dépôts APP peut s'avérer une tâche compliquée sans le soutien adéquat. Malgré cela, il peut être utile d'assurer la traçabilité du code en archivant le code d'un logiciel à chaque étape importante : nouvelle fonctionalité, arrivée ou départ d'un contributeur, modification du financement du code (contrats, ...) ; bref, à chaque évolution importante des données essentiels de l'oeuvre. Pour cela on peut par exemple garder des fichiers .tar.gz ou utiliser des forges.

Les auteurs

Il est parfois complexe de déterminer le ou les auteurs d'un logiciel notamment lorsqu'il s'agit d'un logiciel qui a été enrichi tout au long des années et des collaborations, cela peut demander l'intervention d'avocats dans des cas extrêmes (voir la page 28 du document Report on the proposed IPR tracking methodology, Deliverable A1.D2.1.4 du projet Quality Platform for Open Source Software (Qualipso) Fiche Plume). Voilà pourquoi il faut établir des documents qui clarifient la question. Il ne s'agit pas de prévoir toutes sortes de controverses possibles, mais de bien établir des documents qui peuvent s'avérer indispensables dans des utilisations imprévues et futures du logiciel.

Il faut donc établir une liste d'auteurs, avec le nom de leur laboratoire et leur statut (en particulier pour les stages, thèses, postdocs, ...). Il peut être utile d'associer à chaque auteur un pourcentage de collaboration (donc à ne pas oublier). Cette liste doit être revue à chaque version du logiciel, surtout s'il y a de nouveaux intervenants, ou un changement de responsable du projet logiciel.

L'auteur d'une œuvre est celui qui l'écrit, rien de plus clair... Cependant, un logiciel peut avoir plusieurs auteurs dans des cadres de collaboration très différents (stage, doctorat, collaboration avec des entreprises, ou entre plusieurs établissements de recherche). Le Code de la Propriété Intellectelle (CPI) définit dans son article L113-2 différentes catégories d'œuvres : œuvre de collaboration, œuvre collective, œuvre composite. Toutes ces catégories peuvent, suivant le cas, s'appliquer à un même logiciel.

Le concept d'œuvre de collaboration indique une collaboration "horizontale" : les collaborateurs participent au même niveau et sont tous considérés comme auteurs de l'œuvre (pourcentage égal de participation). L'œuvre collective correspond à une collaboration "verticale" : une seule personne sera auteure de l'œuvre. Dans le cas particulier des stages, le développement ne peut pas se faire sans l'expérience du responsable de stage : il y a à la fois une collaboration verticale et horizontale. Il est donc difficile d'utiliser une seule de ces catégories pour caractériser les logiciels quand des stages sont inclus.

La liste d'auteurs avec leur pourcentage de participation est ainsi un outil indispensable pour clarifier ce point.

Les droits patrimoniaux

L'article L113-9 du CPI stipule : "Sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur sont dévolus à l'employeur qui est seul habilité à les exercer."

Donc en cas de travail salarié, l'auteur d'un logiciel est différent du détenteur des droits patrimoniaux (qui est l'employeur). Cela ne s'applique pas dans le cas des stages car un stagiaire ne peut pas être assimilé à un salarié ou à un agent de l'Etat. Donc il est essentiel de connaître le statut des personnes ayant collaboré à la création du logiciel. La question "qui est propriétaire des droits patrimoniaux ?" est aussi complèxe que celle des auteurs et peut requérir la décision d'un juge.

Si le logiciel est lié a un contrat de collaboration, les droits patrimoniaux du logiciel produit peuvent y être attribués. Ces contrats peuvent aussi établir les licences qui lui seront associées. Les négociateurs du contrat doivent être attentifs sur ces deux points.

Concernant les autres contributeurs non salariés du laboratoire (bourses, stages non gratifiés, thèses sans rémunération... ) il est indispensable de leur faire signer un engagement comportant des clauses sur la propriété intellectuelle et des règles de confidentialité à respecter.

Finalement, la liste des détenteurs des droits patrimoniaux découle directement de la liste d'auteurs et de leur statut, d'où l'importance de bien établir cette première liste.

Note : la liste de détenteurs des droits patrimoniaux s'indique dans le code source du logiciel (ligne de copyright, voir la FAQ PLUME Licence & copyright pour les développements de logiciels libres de laboratoires de recherche Fiche Plume).

La documentation d'un logiciel et les droits patrimoniaux

On peut parfois considérer que la documentation d'un logiciel est soumise aux normes classiques de la propriété intellectuelle, or le CPI stipule que les règles des droits patrimoniaux s'appliquent aux logiciels et leurs documentations. En conséquence, toute décision qui fait intervenir ces droits patrimoniaux (licence, diffusion...) correspond aux détenteurs de ces droits.

La cession des droits

Le Code de la Propriété Intellectuelle traite dans son chapitre III de la cession des droits d'auteur, aussi appellée parfois cession des droits patrimoniaux. Il est impossible de céder les droits moraux, qui restent toujours associés aux auteurs d'une œuvre.

Récemment nous avons vu le cas d'une demande de cession des droits (disclaimer of rights) faite par la FSF (Free Software Fondation) à une Université, dans le cadre d'un stage d'un étudiant de l'Université dans un autre établissement pour faire évoluer le logiciel GCC.

Le logiciel GCC possède une longue liste d'auteurs, et donc il peut être très compliqué de contacter tous les propriétaires du logiciel face à un problème légal. La FSF pourra faire face au problème et représenter les intérêts de la communauté des développeurs si les cessions de droits sont faites. Voir How to contribute à GCC, GDB, Binutils et autres.

Le personnel d'un laboratoire de recherche

Dans cette section nous parcourons la liste des différents types de personnel d'un laboratoire et leur régime (salarié ou pas), ce qui déterminera les droits patrimoniaux associés à leur participation au développement d'un logiciel.

Note : pour les unités mixtes de recherche (UMR), le concept d'établissement hébergeur peut s'appliquer avec des conséquences importantes. Ce point s'étudie lors de la signature des contrats quadriennaux.

Régime salarié. L'auteur a la qualité d'employé ou d'agent de l'Etat, des collectivités publiques ou des établissements publics à caractère administratif. L'université ou l'établissement employeur est le détenteur des droits patrimoniaux associés à l'œuvre. Cette règle s'applique si l'auteur est :

  • chercheur (chargé de recherche, directeur de recherche),
  • enseignant-chercheur (maître de conférences et professeur des universités),
  • enseignant-chercheur associé (maître de conférences et professeur des universités associé ou invité),
  • ingénieur, assistant ingénieur, technicien,
  • un chercheur en accueil en délégation (CNRS, INRIA...),
  • un doctorant allocataire de recherche.

Même s'il s'agit des postes non-permanents, le régime salarié peut s'appliquer aussi pour les postes suivants :

  • post-doctorants,
  • attachés temporaires d'enseignement et de recherche (ATER),
  • doctorants : contrat doctoral, bourses CIFRE,
  • CDD.

Pour les doctorants et post-doctorants la source du financement est promordiale et il faut veiller à la signature de documents qui comportent des clauses sur la propriété intellectuelle et la confidentialité.

Lors des congés pour recherches ou conversions thématiques (CRCT), l'employeur ne change pas. Lors de la mise à disposition, du détachement, de disponibilité d'un agent, il faut étudier le cas d'un changement de régime (salarié/non-salarié) et le changement d'employeur (pour tenir en compte le détenteur des droits patrimoniaux associé à cette période).

L'auteur n'a pas la qualité d'employé. Dans ce cas, l'auteur est aussi le détenteur des droits patrimoniaux (en fonction du pourcentage de participation au projet logiciel). Cette règle s'applique si l'auteur a la qualité de :

  • professeur émérite, retraité,
  • boursier,
  • stagiaire (voir la Circulaire du 23 juillet 2009 relative à l'accueil des étudiants de l'enseignement supérieur en stage),
  • étudiant participant sur des projets sans le statut de stagiaire.

Ce dernier statut ne correspond pas, bien entendu, à des personnels du laboratoire, mais il apparaît souvent lié aux activités d'enseignement du personnel du laboratoire. L'étudiant pourrait, par exemple, être sous contrat d'apprentissage, ce qui est une forme de contrat de travail. L'étudiant peut suivre d'autre type de formation en alternance, selon des cadres juridiques différents tels que contrat de travail (entre entreprise et salarié), convention de stage (entreprise-stagiaire-université ou centre de formation), convention CIFRE (montage pluri-contractuel entreprise-salarié-université-ANRT), ou convention de formation continue (entreprise-université).

Le statut de retraité ne correspond pas non plus à des personnels d'un laboratoire, mais il arrive parfois que des personnes à la retraite continuent à s'impliquer dans des projets (logiciels) commencés lors d'un travail salarié.

En l'absence de dispositions prévues par convention signés par ces personnes (stage, d'accueil, cession de droit, ...), elles conservent les droits de propriété des logiciels auxquels elles ont participé (selon leur pourcentage de participation). Pour obtenir plus d'information sur les clauses des conventions nécessaires, on peut s'adresser aux services de ressources humaines ou aux services des affaires juridiques de vos établissements.

Vous l'aurez compris, ce sont des cas un peu hétéroclites qui posent des questions délicates. Il faut les traiter avec prudence, les conséquences légales pouvant s'avérer importantes.

La mobilité des personnels

La mobilité des personnels qui ont collaboré à un projet logiciel peut devenir un casse-tête lorsqu'il est nécessaire de contacter tous les acteurs intervenant aux décisions importantes dans son évolution. Bien que cela puisse sembler rare, cela arrive assez souvent et il vaut mieux en prévoir les conséquences.

Une possible solution est d'ajouter, dans le document d'accord de licence une adresse de contact pour chaque auteur et une clause qui indique l'engagement des parties à donner une nouvelle adresse de contact lorsque celle qui figure sur le texte ne fonctionne plus.

Lorsque les responsables d'un projet logiciel changent de laboratoire, il nous semble qu'une copie du dossier du logiciel doit rester au laboratoire. Pour la gestion de ces dossiers, la figure de correspondant logiciels du laboratoire est une solution à étudier.

Choisir une licence

Pour plus d'informations concernant les licences libres nous vous invitons à consulter la FAQ PLUME Licence & copyright pour les développements de logiciels libres de laboratoires de recherche Fiche Plume et la fiche PLUME Pourquoi diffuser un logiciel développé dans un laboratoire ou une université avec une licence libre ? Fiche Plume qui étudie les avantages des logiciels libres dans le monde scientifique. Ces deux documents vous seront peut-être utiles pour étudier la question du choix de licence.

Si le logiciel est lié à un contrat de collaboration, la licence sous laquelle le logiciel obtenu sera distribué peut y être indiquée et fait partie des négociations habituelles à la rédaction du contrat. Il peut y avoir des contrats différents qui financent un projet, il faut y indiquer quelles sont les parties du logiciel ou les fonctionnalités qui sont attachées au contrat et veiller à la "compatibilité" des contrats (ou des licences associées).

Si le logiciel est une œuvre dérivée d'un logiciel sous licence GPL, sa diffusion doit se faire en respectant cette licence : le logiciel dérivé sera diffusé en code source et sous licence GPL. Rien n'empêche l'utilisation simultanée de plusieurs licences qui seront peut-être utiles selon le cadre de collaboration mais cela n'est pas possible pour tous les types de licences des briques initiales.

Dans les autres cas, la licence doit être décidée avec les détenteurs des droits patrimoniaux. Pour les licences libres, les tutelles peuvent établir des procédures qui donnent un accord au préalable et simplifient la diffusion rapide des logiciels produits dans les laboratoires de recherche sous ce type de licence.

Il est utile d'établir un accord de licence daté et signé par tous les auteurs : << Les auteurs du logiciel X et signataires de ce document manifestent leur accord pour diffuser le logiciel (nom, description) sous la licence...>>

Respecter une licence

Si vous avez utilisé des briques logicielles dans votre logiciel, cela veut dire que vous connaissez quels sont les droits associés à ces briques (ie. que vous connaissez leurs licences) et quelles sont les obligations qui vous sont imposées (et que vous avez acceptées).

Il y a des licences qui indiquent qu'un logiciel est de libre utilisation pour la recherche mais pas pour des utilisations commerciales, d'autres indiquent qu'il faut citer un ouvrage lié au logiciel... Ces obligations doivent être respectées.

Les documentations des logiciels sont aussi soumises à des licences, qui à leur tour imposent des obligations à respecter.

Documents pour établir un dossier du logiciel

Voici donc la liste des documents à rassembler lors du développement d'un logiciel :

  • Matériel préparatoire : notes, articles... Il sert à dater le logiciel.
  • Document de description, avec nom, dates importantes, liste d'auteurs (avec pourcentage de participation) et leur affiliation.
  • Liste des briques logicielles avec leur licence (ou documents qui accordent des droits d'utilisation, de rediffusion, ...).
  • Document d'accord de licence avec liste d'auteurs, leur adresse de contact, leur signature...
  • Contrats
  • Conventions de stage, conventions d'accueil...

Ces documents sont à revoir à chaque nouvelle version du logiciel.

Les divers types de collaboration au développement d'un logiciel

La fiche PLUME Guide laboratoire pour recenser ses développements logiciels Fiche Plume étudie la question du recensement des logiciels produits dans les laboratoires de recherche.

La procédure proposée dans ce document étudie les logiciels qui sont développés complétement dans le cadre d'un ou plusieurs laboratoires de recherche, mais il arrive souvent que des chercheurs et des développeurs d'un laboratoire s'impliquent dans des projets logiciels libres et parfois externes aux établissements de recherche français. Dans ce cas, et en fonction de l'importance de la contribution, il est conseillé d'informer le laboratoire de cette contribution et de mentionner dans votre collaboration le détenteur des droits patrimoniaux de votre travail.

Comment gérer les collaborations de chercheurs de plusieurs laboratoires, y compris à l'étranger ? À notre avis, cette question doit se traiter de façon similaire à celle des publications du laboratoire, en faisant attention "à la signature" du logiciel : auteur (avec pourcentage de participation) et détenteur des droits patrimoniaux.

Références

Mots-clés

Enquete forge ESR réservée aux membres de la communauté Ens Sup - Recherche - printemps 2010

  • Brève mise en ligne le : 12/04/10

Annonce reservée aux membres de la communauté Ens Sup - Recherche :

Le projet PLUME, le groupe Calcul, et le réseau DevLog travaillent sur un projet visant à réaliser une étude prospective sur l'opportunité de proposer à la communauté Enseignement Supérieur - Recherche des solutions adaptées pour l'hébergement des développements des laboratoires de recherche.

Ce projet est décrit ici :
http://www.projet-plume.org/fr/ressource/projet-forge-esr

L'objectif est tout d'abord d'identifier les pratiques de développement dans la communauté Enseignement Supérieur et Recherche, au travers d'une enquête auprès de tous les membres de cette communauté amenés à développer du logiciel.

Cette enquête sera close le 15 Mai  2010, et les premiers résultats seront communiqués à partir de Juin 2010.

Si vous êtes membre de la communauté Enseignement Supérieur - Recherche, pour participer à cette enquête,  veuillez cliquer sur le lien :
http://calcul.math.cnrs.fr/ForgeESR/index.php?sid=68895&lang=fr

Nous vous engageons à diffuser ce mail auprès de vos collègues développeurs permanents ou occasionnels de la communauté Enseignement Supérieur - Recherche qui ne l'auraient pas reçu.

Nous vous remercions pour votre contribution.

Véronique Baudin , Violaine Louvet  : responsables du projet forgeESR

Loic Gouarin: groupe projet forgeESR

ARAMIS : réseau métier Admin Syst Réseau et Développeurs Rhône-Auvergne

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

ARAMIS : réseau métier Admin Syst Réseau et Développeurs Rhône-Auvergne

Logo ARAMIS

ARAMIS (Agrégation Rhône-Auvergne des Métiers de l'Informatique dans le Supérieur) est un lieu d'échange et de communication,
sous la forme d'un réseau d'administrateurs systèmes & réseaux et de développeurs de la région Rhône-Auvergne.

Objectifs :

  • faciliter la communication entre les informaticiens de la communauté enseignement supérieur et recherche, administrateurs systèmes et réseaux et développeurs,

  • permettre l'échange de compétences, mutualiser les expériences.

  • améliorer le service rendu aux utilisateurs dans une perspective de court, moyen et long terme.

  • échanger sur les aspects relationnels au sein des laboratoires, sur les aspects juridiques du métier, sur les évolutions et perspectives de carrières.

Périmètre (qui peut en faire partie ?) :

Les personnes concernées par ce réseau sont toutes celles exerçant des fonctions d'administration systèmes et réseaux ou de développement de logiciels dans le contexte enseignement supérieur et recherche (laboratoires de recherche, universités, grandes écoles...) de la région Rhône-Auvergne (triangle Lyon ↔ Clermont-Ferrand ↔ Saint-Étienne).

Mode de fonctionnement :

Le réseau est constitué de membres qui s'inscrivent volontairement par l'intermédiaire d'une liste de diffusion. Le réseau est animé par un « comité d'organisation », groupe restreint de personnes provenant des différents organismes entrant dans le périmètre du réseau (Enseignement supérieur/Recherche). Ce comité :

  • anime le réseau métier,

  • facilite la communication entre les membres du réseau,

  • propose et organise des rencontres thématiques régulières, aide à l'organisation d'ateliers,

  • communique au sujet du réseau auprès des différents organismes liés à l'enseignement supérieur et la recherche de la région.

Liens avec autres réseaux :

Aramis est membre du réseau métier d'ASR RESINFO et du réseau national des développeurs DEVLOG. Il communique également avec les autres réseaux métiers comme MATHRICE.

Fichier attachéTaille
logoARAMIS.jpg27.72 Ko
Syndiquer le contenu