compte-rendu

Compte-rendu d'une réunion, d'un évènement, de tests ...

Du patrimoine culturel à la production scientifique : aspects juridiques - Formation ArScAN - Juin 2013

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

Du patrimoine culturel à la production scientifique : aspects juridiques - Formation ArScAN - Juin 2013

Cette carte héuristique (diffusé sous licence CC-BY-SA v3) représente le contenu de la formation "Du patrimoine culturel à la production scientifique : aspects juridiques" effectuée par Anne-Laure Stérin et Lionel Maurel le 17 juin 2013 et organisée par l'équipe du programme « ArcheoNum. Archéologie dans les Humanités numériques », de l'unité de recherche ArScAn (CNRS UMR7041). Elle a eu lieu à l'Université de Paris Ouest Nanterre La Défense.

Les points suivants ont été abordés :

  • le droit d’auteur,
  • le droit des bases de données,
  • le droit de l’image des personnes et des biens,
  • le droit des données personnelles,
  • le droit des archives,
  • le droit à la réutilisation des informations publiques.

Voir pour plus d'informations la page de A.-V. Szabados : http://archeonum.hypotheses.org/91

Free/Open Access - L’accès libre à la science et le LIGM. Présentation du 6 mars 2012

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

Free/Open Access - L’accès libre à la science et le LIGM. Présentation du 6 mars 2012

Cette présentation a été realisée dans le cadre de la journée logiciels du Laboratoire d'informatique Gaspard-Monge (Université de Marne-la-vallée) et a pour but d'analyser les questions du libre accès sur la production scientifique du laboratoire.

La production du laboratoire consiste principalement en articles (et autres publications scientifiques) et logiciels, mais il y a aussi les ressources linguistiques produites par l'équipe d'Informatique linguistique, et une autre production plus recente sur "l'Internet of things", travail en cours de I. Salhi.

La première partie de la présentation, dédiée aux logiciels, analyse les deux définitions sur le libre accès aux logiciels : celle du logiciel libre donnée par la FSF et celle du logiciel open source donnée par l'OSI et montre des différences entre les objets définis. Cette section continue avec les données sur les logiciels LIGM présentés sur PLUME.

La deuxième partie, dédiée aux articles, étudie les diverses définitions sur l'open access qui apparaissent dans le domaine des publications scientifiques. Certaines de ces définitions ont été étudiées lors de la matinée sur l'Open access gold - Un enjeu majeur pour les publications en physique. Certaines définitions apparaissent lors des déclarations, par exemple la Déclaration de Berlin ou la Déclaration de Budapest.

Cette deuxième partie analyse aussi la situation du libre accès et de l'édition scientifique au CNRS, en particulier la situation paradoxale dans la production d'articles, leur édition, l'achat des revues où ces articles sont publiées, et l'évaluation de l'activité des chercheurs. Cette situation est assez similaire dans les autres organismes de recherche en France, et pour approfondir sur ces thèmes nous invitons en particulier à la lecture de ces documents :

En conclusion on peut affirmer que l'édition scientifique est dans une situation très bouleversée actuellement, et son fonctionnement est en (r)évolution. La politique de diffusion, avec des licences Creative Commons (CC-by-nd), de la revue Logical Methods in Computer Science est étudié.

Nous attirons aussi l'attention du lecteur sur l'utilisation du terme open access dans le domaine des publications scientifiques : traduit souvent en français par libre accès, il peut y avoir des significations très distinctes, comme celle d'une licence CC-BY, celle donnée par la déclaration de Budapest ou celle qui indique un accès gratuit pour le lecteur d'un article, mais qui a été publié de façon payante pour son auteur. Il est donc important de clarifier le contexte avec la définition utilisée et les licences impliquées, c'est-à-dire, sur le modèle de la diffusion de logiciels.

Autres références utiles :

Et sur les politiques des revues scientifiques :

Fichier attachéTaille
2012_6mars_journeelogisligm_tgd.pdf493.01 Ko

Quels droits pour les auteurs de logiciels ?

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

Quels droits pour les auteurs de logiciels ?

  • Type de ressource : compte-rendu, événement
  • Date de publication du document ou de l'événement : 3 mai 2011
  • Auteur(s) ou responsable(s) : Soizic Lefeuvre, SAIC, Université Paris-Sud 11
  • Contact pour plus d'informations : SAIC, Université Paris-Sud 11

Présentation sur les droits d'auteur des logiciels faite par Soizic Lefeuvre dans les Matinales du SAIC le 3 mai 2011 au Laboratoire de recherche en informatique (LRI) de l'Université d'Orsay.

Des points extraits du plan de la présentation :

- Le logiciel, une oeuvre de l'esprit
- La notion d'auteur
- L'auteur salarié et les droits patrimoniaux
- Des droits moraux aménagés
- Protection par brevet
- Les auteurs inventeurs
- QUIZ
- Sur les droits patrimoniaux

Fichier attachéTaille
2011_3mai_MatinaleSAIC_Orsay_LEFEUVRE.pdf994.04 Ko

L'agence de protection des programmes (APP) et le registre Inter Deposit Digital Number (IDDN)

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

L'agence de protection des programmes (APP) et le registre Inter Deposit Digital Number (IDDN)

  • Type de ressource : article, compte-rendu, événement
  • Date de publication du document ou de l'événement : 13 avril 2010
  • Auteur(s) ou responsable(s) : Les matinales du SAIC, Université Paris-Sud 11
  • Contact pour plus d'informations : http://app.legalis.net/, http://www.iddn.org/

Ce texte recueille les notes prises lors de la présentation "Logiciels : Inscription au registre IDDN", par Sylvie Rozenfeld, de l'Agence de Protection de Programmes (APP) et une partie des réponses aux nombreuses questions qui ont été posées... Cette présentation a été organisée par le Service des Activites Industrielles et commertiales (SAIC) de l'Université Paris-Sud 11 dans le cadre "Les matinales du SAIC" le 13 avril 2010.

Ces notes peuvent être inexactes, incomplètes et désorganisées, et refléter les centres d'intérêt d'une informaticienne du CNRS. Elles ont été parfois complétées. Aucune erreur dans ce texte ne peut être attribuée à Sylvie Rozenfeld ou à l'APP, ou aux organisateurs de cette matinale. Elles ont été relues par Pascal Janots, responsable du SAIC de l'UPEMLV (service de valorisation de la recherche de l'université Paris-Est Marne la Vallée) et par Anne-Catherine Letournel (LRI).

La confèrence commence, Sylvie Rozenfeld se présente : elle est juriste et son travail consiste à apporter de l'assistance juridique aux déposants à l'Agence de Protection de Programmes (APP). L'APP est une association selon la loi de 1901 et a été créée en 1982, avant que la loi de 1985 ne protège formellement le logiciel par le droit d'auteur.

Une première précision : le logiciel est protégé par la loi, pas par l'Agence de Protection des Programmes. Le logiciel est protégé du seul fait de la création, contrairement aux marques et brevets où le dépôt est constitutif de droits : il n'a pas de titre (ou document de propriété) établi ni un monopole d'une certaine durée.

Le logiciel est protégé par le droit d'auteur (N.B. voir le Code de la propriété intellectuelle - CPI). Le droit d'auteur avait été initialement conçu pour protèger la création artistique, et y faire rentrer les logiciels dans ce cadre a généré la surprise des experts juridiques. Le cadre juridique international est donné par la convention de Berne.

Le dépôt APP consiste en une déclaration sur l'honneur, ce n'est pas un titre de propriété.

Dans une oeuvre, on distingue l'originalité de la nouveauté : l'originalité est protégée par le droit d'auteur, on protège l'empreinte de la personalité de l'auteur, son style ; la nouveauté (d'un procédé) est protégée par le brevet. Il y a une seule condition pour que le droit d'auteur s'applique (et cela automatiquement) : c'est l'originalité de l'oeuvre qui représente l'apport personnel de l'auteur.

L'APP ne détermine pas l'originalité d'un logiciel, on accepte le postulat de l'originalité de l'oeuvre déposée. En cas de procès, c'est un juge qui doit prendre la décision sur l'originalité de l'oeuvre (et donc de sa protection ou pas par le droit d'auteur) : si l'on suspecte une oeuvre B d'être une copie d'une oeuvre initiale A, l'auteur de l'oeuvre B peut argumenter que l'oeuvre A n'est pas une oeuvre originale et qu'elle n'est donc pas protégée par le droit d'auteur. Le juge nomme un expert pour réaliser une étude, et décide en fonction des conclusions de cette étude si l'oeuvre A est originale (et donc protégée) et si B est une copie d'A.

Définition : Qu'entend-on par "logiciel" (en termes juridiques) ? L'arrêté du Ministre de l'Industrie du 22 décembre 1981 relatif à l'enrichissement du vocabulaire de l'informatique donne la définition suivante : « 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 ». C'est donc un concept large.

Dans la réalisation d'un logiciel, depuis l'idée initiale (qui n'est pas protégeable par le droit d'auteur en soi-même) à sa réalisation finale, il y a une étape à partir de laquelle le logiciel va pouvoir faire l'objet d'un dépôt APP. Les idées ne sont pas protégeables par la loi pour éviter que celle-ci soit un frein à l'innovation. La loi protège la forme, la manière dont une idée va être mise en forme. Le cahier des charges, les algorithmes ne sont pas non plus protégeables. Ce qu'on protège donc dans un logiciel est le code (code objet, code source), ainsi que le matériel préparatoire. Les fonctionnalités d'un logiciel ne sont pas protégeables par le droit d'auteur, c'est plus du ressort des brevets.

Le dépôt APP d'un logiciel n'est pas exigible par la loi. Ce dépôt peut faire partie d'une stratégie de "Pre-constitution de moyens de preuve" : on peut déposer un produit quand il est finalisé, mais on peut aussi commencer par le déposer dès les premières versions du logiciel (cahier des charges...) et renouveler le dépôt avec des versions successives. Cela sert à établir des dates associées au logiciel, le plus tôt possible est le mieux. Cela oblige les possibles adversaires (dans le cas d'un problème juridique) à fournir l'effort de prouver que leur création est antérieure : le dépôt APP peut donc constituer un avantage juridique. Le seul dépôt d'un cahier des charges (en tant que matériel préparatoire) n'est pas utile s'il n'a pas un produit logiciel associé par la suite.

Quelques remarques sur les logiciels libres qui ne sont pas "libres de droits" : aux USA, les logiciels sont protégés par le "copyright" qui relève du droit économique. Le droit d'auteur (en France) donne plus de droits puisqu'il y a la distinction entre les droits patrimoniaux ("monnayables", et que l'on peut céder) et les droits moraux (qui sont éternels et non cédables, par exemple les héritiers de Victor Hugo peuvent toujours opposer le droit d'auteur à certaines oeuvres pour défendre l'oeuvre de leur ancêtre). Il n'y a pas cette distinction entre les droits moraux et patrimoniaux dans le droit du copyright. Donc les licences de logiciels libres cèdent beaucoup de droits qui, aux USA, appartiennent à l'auteur (contrairement à ce qui arrive avec le droit d'auteur en France). En France, tout droit qui n'est pas explicitement octroyé est interdit.

Le droit d'auteur protège les créateurs, mais dans le cas d'un logiciel, il arrive souvent qu'il y ait plusieurs développeurs. Le CPI distingue, entre autres types, les oeuvres collectives, dont les droits (d'auteur) appartiennent à la personne morale qui initie l'oeuvre (N.B. On prend souvent l'exemple d'un dictionnaire pour ce type d'oeuvre : les auteurs des définitions ne sont pas auteurs de l'oeuvre collective).

Sauf dispositions particulières, c'est l'employeur d'un développeur qui est propriétaire des droits patrimoniaux du logiciel. Par exemple, des dispositions contraires à cette clause peuvent être incluses dans un contrat.

En matière de logiciel, le dépôt n'est pas prévu par la loi. En plus de l'APP, il y a d'autres possibilités pour établir des preuves (principalement sur la date associée au logiciel pour déterminer son orginalité). Il faut être certain de la fiabilité de ces preuves d'un point de vue légal. En voici quelques possibilités (N.B. j'ai complété la liste) :

On mentionne parfois l'enveloppe Soleau, produit de l'Institut National de la Propriété Industrielle (INPI) comme moyen de constituer une preuve de date pour une création, mais cette enveloppe ne doit pas comporter de “corps durs” (par exemple un CD, ou autre moyen contenant les sources d'un logiciel). Ce moyen sert donc à dater une description (texte) ou une reproduction en deux dimensions (schémas, dessins, photos, etc.) de votre logiciel.

L'APP compte plus de 12.000 adhérents : entités, particuliers, laboratoires, toute sorte de public peut adhérer l'APP (N.B. Des entités comme le CNRS, l'INRIA sont adhérentes à l'APP).

Pour déposer un logiciel, l'APP propose à ses adhérents deux enveloppes en plastique scellées qui vont contenir des CDROM à l'intérieur avec un (même) numéro d'ordre. Une fois que ce type d'enveloppe est fermé, son ouverture implique son déchirement et l'enveloppe perd sa valeur juridique. Le numéro d'ordre indique l'inscription du logiciel contenu dans le CDROM au repertoire IDDN (Inter Deposit Digital Number). Une enveloppe sera gardée en lieu sûr par l'APP, l'autre reste aux mains de l'adhérent. L'expert mandaté par un juge peut ouvrir l'enveloppe scellée de l'adhérent pour effectuer une étude. Une nouvelle enveloppe sera utilisée après l'étude pour contenir à nouveau le logiciel sous enveloppe scellée. Lorsqu'un expert est mandaté par un juge pour réaliser une expertise juridique, il mettra en place des séances de travail pour confronter les deux parties.

L'utilisation de CDROMs pose le problème de la pérennité du support. Il y a d'autres moyens pour dater un logiciel, mais la personne ou entité doit garder le logiciel (son contenant) dans un lieu sûr, à l'abri des incendies, vols et autres incidents.

Un dépôt APP consiste donc en :

  • un logiciel dans une enveloppe plastique scellée (en deux exemplaires),
  • un formulaire avec une demande de dépôt et la déclaration sur l'honneur,
  • un numéro IDDN (Inter Deposit Digital Number),
  • et un certificat délivré par l'APP.

On peut réaliser plusieurs types de dépôts : un dépôt de diffusion (attention : cette procédure ne permet pas l'accès contractuel aux sources), un dépôt des sources (permet un accès aux sources sous réserve d'une autorisation explicite écrite), ou un dépôt controlé (qui garantie que le dépôt a fait l'objet d'une vérification par un tiers, c'est un service payant de l'APP). L'APP propose aussi une procédure de référencement de logiciel, moins chère que le dépôt. Il faut adhérer à l'APP pour pouvoir réaliser un dépôt.

Le formulaire à remplir donne des actes juridiques, indique le nom du logiciel, qui fait le dépôt... En cas de plusieurs titulaires des droits, il y a un un seul déposant (appellé mandataire), indépendamment des accords de pourcentages de titularité que les propriétaires ont décidés. Le dépôt est effectué par les détenteurs des droits patrimoniaux (ie. les propriétaires du logiciel). La seule date garantie par le dépôt est la date du dépôt (pas la date du contenu du CDROM), le dépôt retro-actif n'est pas possible. C'est un acte déclaratif et pas constitutif de droit. On déclare ce qu'on peut prouver.

Dans un dépôt APP, il est possible d'inclure du code externe (qui n'appartient pas aux déposants). Alors on utilise la formule "sous réserve de droits de tiers" qui indique qu'on ne revendique pas des droits sur le code dont on n'a pas la propriété.

Dans le cadre d'une collaboration internationale pour le développement d'un logiciel, il faut la signature des partenaires étrangers détenteurs de droits. Il peut arriver que le dépôt APP soit utile dans une procédure juridique étrangère, mais aussi que ce dépôt ne soit pas reconnu par un tribunal étranger.

Une question a été posée sur un logiciel obtenu de la traduction d'un premier dans un autre language informatique. C'est la même situation que dans la traduction d'un livre, il s'agit d'une oeuvre dérivée : le traducteur apporte son empreinte, mais s'appuie dans une oeuvre pré-existante. L'auteur de la première oeuvre est aussi auteur de l'oeuvre derivée.

Une autre question a été posée sur le dépôt d'accès aux sources : si l'entreprise disparaît, les utilisateurs peuvent aller à l'APP pour recupérer le code source déposé si c'est ainsi prévu dans le contrat.

Ma conclusion personnelle est qu'il est très important d'associer une première date à tout logiciel (ou à son matériel préparatoire), et aussi aux différentes versions du logiciel, surtout s'il y a apport de nouvelles fonctionnalités importantes. Ces dates doivent avoir une valeur juridique pour pouvoir faire face à des problèmes légaux (assez rares dans notre communauté d'Enseignement Supérieur et Recherche, mais possibles).

Il me semble aussi important de faire attention à la documentation (et aux dates des versions différentes) qui doit accompagner le logiciel, et qui est soumise (article L113-9 du CPI) aux mêmes conditions que le logiciel lui même en termes de détenteurs de droits patrimoniaux.

Plusieurs moyens sont à la disposition des propriétaires des logiciels pour établir ces dates, chacun doit prendre le moyen le plus adapté à sa situation et à ses moyens économiques. Dans les laboratoires, il est possible d'utiliser le cahier du laboratoire (voir par exemple http://www.cnrs.fr/infoslabos/cahier-laboratoire/) pour inscrire et dater les évolutions d'un logiciel.

Des institutions comme le CNRS et l'INRIA utilisent les dépôts APP pour connaître et gèrer leur patrimoine logiciel, mais nous pensons que cette procédure n'est pas très bien adaptée à tous les types de logiciel qui sont développés aux laboratoires (voir par exemple le Guide laboratoire pour recenser ses développements logiciels).

Une question intéressante associé à ce sujet : quelle est la valeur légale des dates associées à un logiciel par une forge ?

Bilan à trois ans de PLUME : les services rendus aux laboratoires de recherche et aux universités - septembre 2010

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

Bilan à trois ans de PLUME : les services rendus aux laboratoires de recherche et aux universités - septembre 2010

Bilan à trois ans de PLUME : les services rendus aux laboratoires de recherche et aux universités

Jean-Luc Archimbaud (Animateur du projet PLUME)
Geneviève Romier (Responsable du Comité Technique PLUME)

Ce document dresse un bilan du projet et de la plateforme PLUME en tant que service après trois ans de production. Un autre document présentera les évolutions et l'organisation envisagées à partir de ce bilan. Vous pouvez aussi imprimer une version PDF, sans liens HTML.

Le projet PLUME (http://www.projet-plume.org), Promouvoir les Logiciels Utiles Maîtrisés et Economiques dans l'Enseignement Supérieur et la Recherche, lancé en 2007, met en œuvre un outil stratégique pour l'efficacité des laboratoires et services des universités et organismes de recherche. Cet outil, une plate-forme web qui propose aujourd'hui 760 fiches, sert de support à une réelle production d'informations : 568 descriptions de logiciels utilisés ou développés dans les laboratoires, descriptions rédigées et relues par 610 contributeurs et 184 fiches ressources (cours, articles...). 185 nouvelles fiches sont en cours de rédaction ou de relecture. La progression annuelle en terme de production, contribution et accès est de l'ordre de 60 %. Des journées thématiques, écoles et autres actions de formation et d'animation de la communauté complètent ce dispositif.

Cette dynamique de progression a conduit PLUME à devenir la principale plate-forme de description et de référencement des logiciels métier utilisés ou produits dans les laboratoires de recherche et les universités, à la fois base de connaissances en appui aux scientifiques et outil de valorisation du patrimoine logiciel. Elle assure à la communauté enseignement supérieur et recherche une économie de moyens en fournissant un service mutualisé et pluridisciplinaire aux informaticiens, chercheurs et enseignants des laboratoires de recherche et universités qui recherchent un logiciel validé par leurs pairs pour supporter leurs activités scientifiques et techniques. Son rayonnement, au-delà de la communauté enseignement supérieur recherche, et la qualité du contenu proposé en font une vitrine reconnue des développements internes pour les directions et services de valorisation des laboratoires, instituts, universités, organismes de recherche.

Les paragraphes suivants décrivent plus en détails les objectifs, les services rendus, la production actuelle, et l'organisation.

Les objectifs

Le projet PLUME, Promouvoir les Logiciels Utiles Maîtrisés et Economiques dans l'Enseignement Supérieur et la Recherche, a pour objectifs principaux de :

  • mutualiser les compétences sur les logiciels, la plupart libres, utilisés ou créés dans les laboratoires et les universités créant ainsi une économie de moyens,

  • valoriser les développements logiciels effectués dans les laboratoires quelle que soit la discipline scientifique.

Ces objectifs sont poursuivis en s'appuyant sur une plate-forme web (http://www.projet-plume.org/) ouverte en octobre 2007 sur laquelle sont publiées actuellement 568 fiches descriptives de logiciels. Ces descriptions sont rédigées par des utilisateurs intensifs (logiciels validés)ou des développeurs du logiciel présenté, puis suivent un processus similaire à la publication scientifique (relecture par des personnes du domaine, indexation, bon à publier). Ceci est possible grâce à une organisation humaine répartie.

Les services rendus aux laboratoires de recherche et aux universités

PLUME offre maintenant un service pour :

  • les informaticiens (ou utilisateurs éclairés de l'informatique) des laboratoires et universités qui doivent choisir, installer, utiliser des logiciels pour le travail de recherche, d'enseignement et de services. C'est un catalogue actualisé de logiciels validés par des personnes de l'Enseignement Supérieur et la Recherche. A ce catalogue s'ajoutent des journées de formation thématiques dont les présentations enregistrées sont disponibles sur le site PLUME ainsi que des écoles thématiques.

  • les chercheurs et enseignants de toutes les disciplines qui veulent faire connaître leurs développements logiciel, lier des contacts avec leurs homologues pour partager leurs idées, leurs codes ou démarcher des entreprises pour initier des collaborations : PLUME est un filtre et une référence pour présenter, indexer, valider la production des développements logiciels.

  • les directions de laboratoires qui peuvent ainsi référencer et valoriser la production logicielle de leur laboratoire ; il en est de même, avec le même objectif, pour chaque institut du CNRS ou service de valorisation d'université ou d'organisme de recherche comme le CNRS. Par exemple, la DPI, Direction de la Politique Industrielle, devenue DIRE du CNRS soutient fortement ce projet. PLUME est une vitrine pour le patrimoine logiciel des laboratoires maintenant reconnue des professionnels du logiciel, et son rayonnement s'étend au-delà de la recherche publique et au-delà du territoire national. PLUME est très bien référencé par les moteurs de recherche comme Google (une recherche de 'plume' dans ce moteur de recherche place le projet en premier site proposé).

En focalisant les compétences du domaine, avec finalement une économie de moyens notable, PLUME peut être désormais considérée comme la plate-forme de description et de référencement des logiciels métier utilisés ou produits dans les laboratoires de recherche, à la fois base de connaissance stratégique pour l'efficacité dans les laboratoires et vitrine reconnue des acteurs du secteur.

L'ouverture vers l'international

La plate-forme est à la base en français. Cependant un portail en anglais est en place destiné à la valorisation des développements des laboratoires avec une cinquantaine de fiches présentées. Des contacts ont été pris avec d'autres pays pour des référencements croisés... Ce portail anglophone est, faute de moyens, actuellement insuffisant à notre avis. Il constitue un des axes prioritaires d'évolution.

La production et les contributeurs

Mi-septembre 2010 sont présentés sur la plate-forme :

Ces descriptions de logiciels ou de ressources liées aux logiciels sont publiées sous forme de fiches avec des champs imposés et des mots-clés permettant la recherche.

Les fiches PLUME sont des documents rédigés spécifiquement pour PLUME. Elles constituent donc une réelle production d'information importante reposant sur l'expérience utilisateur du rédacteur sur la mise en oeuvre du logiciel dans nos environnements et pas simplement un référencement d'informations existantes ou un assemblage de copier-coller comme de nombreux serveurs le font.

Les fiches sont rédigées par des utilisateurs très réguliers ou des développeurs du logiciel présenté, après proposition spontanée de leur part, même si un des rôles des responsables thématiques est de favoriser cette spontanéité. Ces contributeurs sont des chercheurs, enseignants-chercheurs, ingénieurs de laboratoires CNRS mais aussi INRA, INRIA, CEA,... et des universités et grandes écoles. Il y a actuellement 610 contributeurs (rédacteurs ou relecteurs).

Après la saisie, les fiches suivent un processus similaire à la publication scientifique : relecture et ajouts par
des personnes compétentes du domaine, indexation, bon à publier de l'auteur... S'ajoute une mise à jour régulière des fiches qui est demandée aux auteurs, avec un archivage des fiches non mises à jour.

Chaque fiche est rattachée à un ou plusieurs thèmes (activité scientifique/métier : biologie, formation, développeur...) géré par des responsables thématiques (cf ci-dessous l'organisation).

La formation et l'animation de la communauté Enseignement Supérieur - Recherche

En parallèle, des journées thématiques sont organisées à raison actuellement de deux-trois par an. Chaque journée a réuni entre 80 et 100 personnes en présentiel, au moins 50 à distance (les journées sont retransmises sur Internet) avec enregistrement et mise en ligne des vidéos. Les intervenants sont les contributeurs qui ont rédigé ou relu les fiches descriptives des logiciels présentés. Les thèmes traités ont été :

La prochaine journée est prévue à Paris, le 22 novembre 2010, sur le thème 'Les outils libres de base utiles à tout ASR', ASR pour Administrateur Système et Réseau.

Deux écoles thématiques (une semaine, 80 participants développeurs dans des laboratoires), ANGD dans le jargon CNRS, ont été organisées en septembre 2008 et 2010, appelées ENVOL : formation pour le dEveloppemeNt et la ValOrisation des Logiciels en environnement de recherche.

L'organisation

La plate-forme matérielle consiste en deux serveurs ordinaires hébergés au Centre de Calcul de l'IN2P3 de Lyon, dans de très bonnes conditions : très bons débit réseau, sauvegarde, climatisation, surveillance 24h/24... Ce centre de calcul est partenaire PLUME.

Le personnel noyau dur PLUME est constitué de :

  • Geneviève Romier, ingénieur permanent CNRS, responsable du comité d'exploitation de la plate-forme et co-responsable du comité technique PLUME qui regroupe les responsables thématiques (cf ci-dessous).

  • Jean-Luc Archimbaud, ingénieur permanent CNRS, directeur du projet et rédacteur en chef.

  • Teresa Gomez Diaz, ingénieur permanent CNRS du laboratoire LIGM, avec une convention pour qu'elle travaille à 70 % dans PLUME, en charge de la partie valorisation des logiciels de laboratoires.

  • Laurent Pasquali, ingénieur CDD valorisation jusqu'en mars 2011, sur un poste affecté à PLUME par la DPI du CNRS (devenu DIRE, Direction Innovation et Relations avec les Entreprises), sur la présentation des logiciels de laboratoires dans PLUME.

Un poste d'ingénieur en informatique et un autre d'assistant-gestionnaire-communication ont été demandés au CNRS pour 2011.

25 responsables thématiques assurent le rôle de référent pour certains thèmes. Ils acceptent les propositions de fiches, sollicitent certaines contributions, relisent, valident les fiches et coordonnent leur mise à jour. Un thème est un domaine scientifique, un domaine informatique ou un métier. Les thèmes couverts actuellement par des responsables thématiques sont : biologie, maths, chimie, documentation-IST, développement, administration système, formation, informatique personnelle, patrimoine logiciel de laboratoire, travail coopératif, sciences humaines et sociales, sécurité des systèmes d'information. Astronomie, physique, SI de laboratoire sont des thèmes sur les rails. Ces responsables thématiques sont généralement des ingénieurs en informatique qui consacrent 10 à 15 % de leur temps à PLUME. Ils travaillent dans un laboratoire ou une université dans la thématique qu'ils ont en charge et donc connaissent les logiciels, les besoins et les autres laboratoires du domaine qu'ils couvrent.

Le noyau dur et les responsables thématiques constituent l'équipe PLUME.

Pour terminer 290 personnes ont déjà rédigé des fiches PLUME et 320 en ont relu. Ces 610 contributeurs apportent leur connaissance et leur compétence au projet chacun dans le domaine de sa pratique professionnelle.

La valeur ajoutée et le retour sur investissement

Le retour sur investissement est difficile à évaluer. Quel gain de temps pour un informaticien qui trouve immédiatement dans PLUME le logiciel utile pour son travail parce qu'il a été décrit par des collègues d'autres laboratoires, par rapport à une recherche à l'aveugle sur Internet, suivie de tests plus ou moins concluants ? Quel impact pour un chercheur et par extension un laboratoire qui décrit ses développements logiciels dans PLUME ? Combien de personnes bénéficient des informations disponibles dans PLUME ? Cependant, l'impact et la portée du service rendu peuvent être évalués à travers certains éléments factuels comme la participation, la pluridisciplinarité, la production, la consultation du site, la notoriété et les partenariats-soutiens :

  • Participation : 1400 membres PLUME sont inscrits sur le site, 610 contributeurs (+ 67 % en un an) : rédacteurs ou relecteurs des fiches. La forte participation et son évolution montre l'intérêt.

  • Pluridisciplinarité : une douzaine de thèmes principaux qui couvrent plusieurs disciplines scientifiques, d'autres étant en cours de création.

  • Production : en un an (août 2009 - août 2010) le nombre de fiches publiées est passé de 440 à 760 (+ 72 %). Environ 180 fiches sont en cours de rédaction ou de relecture (non encore publiées).

  • Consultation du site : l'accès mensuel en juin 2010 a été de 200 000 pages lues et 1 360 000 hits (+ 50 % en un an). Ce nombre a baissé durant juillet-août , vacances obligent.

  • Notoriété : les membres de l'équipe PLUME sont de plus en plus sollicités pour présenter PLUME et ses productions dans des conférences (une quarantaine dans la dernière année), certaines internationales.

  • Partenariats et soutiens : De nombreux laboratoires, universités et entités liées à la recherche soutiennent officiellement le projet (cf ci-dessous). La DIRE (Direction Innovation et Relations avec les Entreprises) du CNRS, a ainsi attribué un ingénieur valorisation d'un an au projet en 2010.

Le pilotage et les entités soutiens-partenaires

Le projet a été initié par l'UREC en 2007, Unité Propre de Service (UPS) du CNRS et a été porté par le CNRS à travers l'UREC. Cette unité a été intégrée dans la DSI du CNRS en juillet 2010. Le projet continue, toujours soutenu par le CNRS.

Mais la portée de PLUME s'étend à un ensemble large de l'enseignement supérieur et de la recherche qui participe et bénéficie des services de PLUME. Ainsi il est soutenu officiellement par 45 soutiens-partenaires :

  • des laboratoires importants (CC-IN2P3, LAAS, INIST, ICJ, LIGM, LAL...)

  • des universités ou grandes écoles (INSA Lyon, association des DSI des universités...)

  • des instituts ou services du CNRS (INSMI, DIRE, DGD-R...)

  • des services d'organismes de recherche (ESRF, INRA, INRIA, IRD...)

  • des structures transverses (RENATER, MRCT réseaux métiers CNRS...)

  • des structures industrielles (OW2, System@tic...)

Ces soutiens se sont manifestés progressivement selon les collaborations. Plusieurs d'entre eux ont été force de proposition et le service est devenu stratégique pour leur activité. Deux structures de pilotage sont en place : un comité de suivi et d'orientation avec les membres de l'équipe PLUME parmi les plus impliqués et un comité stratégique récemment créé qui regroupe dix directeurs des entités soutiens et partenaires. Une réflexion est en cours pour monter une structure pérenne, représentative et ouverte pour le service PLUME, et sera présentée dans un  autre document.

 

 

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

Retour d'expérience d'une installation Shibboleth (Fournisseur d'identités)

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

Retour d'expérience d'une installation Shibboleth (Fournisseur d'identités)

  • Type de ressource : article, compte-rendu
  • Date de publication du document ou de l'événement : Septembre 2009
  • Auteur(s) ou responsable(s) : Samuel Godey (CNRS/UREC)
  • Contact pour plus d'informations : samuel.godey@urec.cnrs.fr

La fiche

Document de base pour la rédaction de cette fiche

Date : JUIN-DECEMBRE 2009
Auteur : Samuel Godey (CDD Ingénieur d'étude de 6 mois)
Commanditaire : Patrice Koch (Directeur du CRI Université de Franche-Comté à Besançon)

Nature de la fiche

Cette fiche expose mon expérience sur l'installation du serveur fournisseur d'identités à l'université de Franche-Comté en 2009 et explique comment réaliser la mise à jour des briques logicielles nécessaires à son fonctionnement. La partie fournisseur de services ne sera pas traitée. Certaines informations dans ce texte ont été volontairement remplacées par des termes génériques. La configuration décrite ici est dépendante de l'architecture déjà en place à l'université de Franche-Comté, cependant la majorité des grandes structures utilise des technologies similaires. Les paramètres peuvent varier et sont certainement incompatibles avec votre situation. N'attendez de ce texte qu'un point de départ ou une source d'inspiration pour votre propre fournisseur d'identités.
Attention : ce document ne garantie pas le bon fonctionnement de votre installation.

Public destinataire

Cette note est à l'attention des administrateurs d'un service "fournisseur d'identités" avec la technologie Shibboleth. Veuillez prendre en considération que des connaissances sur LDAP ainsi que sur le service SSO CAS sont nécessaires pour suivre cette fiche, bien que ces services ne soient pas obligatoires pour utiliser Shibboleth. Le serveur fournisseur d'identités a été ajusté pour la fédération éducation-recherche de Renater. Je considère que les utilitaires GNU/Debian sont maîtrisés.

Complément d'information

Les supports techniques utilisés pour réaliser l'installation initiale ainsi que d'autres documentations pour l'installation sont disponibles à l'adresse : https://federation.renater.fr
Les noms des programmes mentionnés dans ce document peuvent se trouver sous la forme "logiciel-x.x.x.foo". Veuillez prendre en considération la version des programmes stables à jour afin d'adapter ce document dans le temps. Par exemple, remplacez x.x.x par 2.3.1 si la version du logiciel "logiciel" est actuellement en version 2.3.1.

Fiches PLUME en lien avec ce retour d'expérience

Pré-requis

Serveur :

  • Lenny/Debian/GNU/Linux

Application Debian non-free/contrib :

  • sun-java-6

Applications Debian main :

  • Apache 2.2
  • mod_ssl
  • mod_proxy_ajp
  • OpenSSL
  • NTP-server
  • Maven

Applications externes :

  • Apache-tomcat6
  • Shibboleth-idp
  • CAS-client

Plan

1) Introduction

1.1) Présentation des chemins d'accès
1.2) Sources des programmes

2) Procédure de mise-à-jour de la brique Shibboleth-idp

2.1) Procédure de mise-à-jour de la brique CAS-client

3) Procédure de mise-à-jour et d'installation de Tomcat
4) Configuration de Apache2.2 (lenny/debian)
5) Configuration de Shibboleth-idp

5.1) attribute-resolver.xml
5.2) attribute-filter.xml

6) Droits et sécurité

6.1) Shibboleth-idp
6.2) Tomcat
6.3) Certificat SSL Apache
6.4) Ajout des certificats non valides

1) Introduction

Veuillez considérer ce document comme un complément d'information pour un service "fournisseur d'identités" déjà en exploitation ou en test avec les briques LDAP et CAS configurées. Il est inutile d'essayer de réaliser une nouvelle installation en s'appuyant sur ce document. Si vous souhaitez installer ce service pour la première fois, il est conseillé d'utiliser les supports techniques fournis par Renater et la documentation officielle de Shibboleth :
- Support technique Renater : https://federation.renater.fr
- Documentation officielle de Shibboleth-idp : https://spaces.internet2.edu/display/SHIB2/

Dans le cas d'une mise-à-jour à cause d'un problème de sécurité ou encore parce que de nouvelles fonctionnalités sont nécessaires, il est important de conserver une copie de la configuration en cours et de procéder à une installation standard. Dès que la mise-à-jour est terminée, il faut vérifier vos fichiers de configuration et les remplacer si nécessaire par vos sauvegardes.

Remarque très importante : si vous hésitez à réaliser une mise-à-jour et que vous préférez utiliser un SNAPSHOT (point de sauvegarde instantanée) de votre machine virtuelle, vous devrez impérativement re-synchroniser l'horloge (avec ntptime) de la machine virtuelle. En effet, une petite dérive temporelle peut supprimer les sessions actives des utilisateurs. Dans le pire de cas, un redémarrage suffit est reste une valeur sûre.

1.1) Présentation des chemins d'accès

Je vous encourage à prendre en considération les chemins ci-dessous pour la lecture de ce document car je les ai déterminés arbitrairement. Par ailleurs, ces derniers peuvent ne pas être les plus judicieux. À vous de choisir des emplacements confortables.

Shibboleth-idp : /opt/shibboleth-idp
configuration de Shibboleth : /opt/shibboleth-idp/conf
certificats de Shibboleth : /opt/shibboleth-idp/credentials
méta-données (éducation-recherche) : /opt/shibboleth-idp/metadata

Données complémentaires :

fqdn shibboleth-idp : idp.mondomaine.fr
chemin source idp : /opt/shibboleth-identityprovider-x.x.x
chemin brique logicielle : /opt/shibboleth-identityprovider-x.x.x/lib/cas-client-core-x.x.x.jar
config compil : /opt/shibboleth-identityprovider-x.x.x/src/main/webapp/WEB-INF/web.xml
configuration Renater : https://services-federation.renater.fr/exemples/co...
méta-données Renater : https://services-federation.renater.fr/metadata/re...
certificat fédération Renater : https://services-federation.renater.fr/metadata/me...

Remarques :

idp.mondomaine.fr a besoin uniquement des ports 448 et 8448. Ils doivent être accessibles et sont nécessaires au bon fonctionnement du service.
À vos pare-feu : 448 et 8448 ouverts en entrée sur idp.mondomaine.fr

1.2) Sources des programmes :

shibboleth-idp url : http://shibboleth.internet2.edu/downloads/shibbole...
shibboleth-idp nom de l'archive : shibboleth-identityprovider-x.x.x-bin.zip
cas-client url : http://www.ja-sig.org/downloads/cas-clients/
cas-client nom archive : cas-client-x.x.x-release.zip
tomcat6 url : ftp://ftp.inria.fr/pub/Apache/tomcat/tomcat-6/v6.x...
tomcat6 nom archive : apache-tomcat-6.x.xx.tar.gz

2) Procédure de mise-à-jour de la brique Shibboleth-idp

  • Arrêtez shibboleth-idp :

    /etc/init.d/tomcat stop
  • Faites une copie de sécurité de la configuration :

    tar zcvf ~/shib-conf.tgz /opt/shibboleth-idp/conf
  • Téléchargez la dernière version :

  • Décompressez :

    jar -xf shibboleth-identityprovider-2.1.5-bin.zip
  • Éditez le fichier de compilation :

    Par commodité, je vous conseille de faire des copies de sécurité de la configuration d'accès à votre serveur CAS. À chaque nouvelle version de Shibboleth, vous devrez adapter le fichier de compilation "web.xml" avec votre système d'authentification. Le but est d'intégrer la brique "cas-client" pré-configurée sur votre réseau en ajoutant les informations locales de votre service.

    Exemple d'un fichier /opt/shibboleth-idp/cas_web.xml à adapter suivant vos besoins :

    <!-- CAS Filter Configuration -->
    <context-param>
    <param-name<serverName</param-name>
    <param-value>https://idp.mondomaine.fr</param-value>
    </context-param>
    <!-- CAS Authentication Filter -->
    <filter>
    <filter-name>CAS Authentication Filter</filter-name>
    <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
    <init-param>
    <param-name>casServerLoginUrl</param-name>
    <!-- votre page de login -->
    <param-value>https://cas.mondomaine.fr/cas/login</param-value>
    <!-- <param-value>https://federation.cru.fr/sac-cas/login</param-value> -->
    </init-param>
    </filter>
    <!-- CAS Validation Filter -->
    <filter>
    <filter-name>CAS Validation Filter</filter-name>
    <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
    <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <!-- Votre page de réception de ticket -->
    <param-value>https://cas.mondomaine.fr/cas</param-value>
    <!-- <param-value>https://federation.cru.fr/sac-cas</param-value> -->
    </init-param>
    </filter>
    <!-- CAS HttpServletRequest Wrapper Filter -->
    <filter>
    <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
    <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>
    </filter>
    <!-- CAS Assertion Thread Local Filter -->
    <filter>
    <filter-name>CAS Assertion Thread Local Filter</filter-name>
    <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class>
    </filter>
    <!-- CAS Filter for Shibb RemoteUser -->
    <filter-mapping>
    <filter-name>CAS Authentication Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>
    <filter-mapping>
    <filter-name>CAS Validation Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>>
    <filter-mapping>
    <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>
    <filter-mapping>
    <filter-name>CAS Assertion Thread Local Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>

    C'est dans le fichier : /opt/shibboleth-identityprovider-2.x.x/src/main/webapp/WEB-INF/web.xml
    que vous devez reporter : /opt/shibboleth-idp/cas_web.xml. Pour ce faire, ajoutez le contenu du fichier "/opt/shibboleth-idp/cas_web.xml" juste en dessous de "</listener>"

  • Copiez le client CAS dans les bibliothèques des sources de Shibboleth :

    cp /opt/cas-client-3.x.x/modules/cas-client-core-3.x.x.jar /opt/shibboleth-identityprovider-2.x.x/lib/
  • Lancez la procédure d'installation :

    cd shibboleth-identitypovider-2.x.x
    chmod +x install.sh
    ./install.sh
  • Faites le choix d'installation :

    Where should the Shibboleth Identity Provider
    software be installed ? [/opt/shibboleth-idp]
    [Acceptez ce choix] the directory '/opt/shibboleth-idp' already exists.
    Would you like to overwrite this shibboleth configuration ?
    (yes, [no]) no => Naturellement c'est "no"

    C'est maintenant terminé, vous devez avoir en bas de votre terminal un message du type :

    BUILD SUCCESFUL
    Total time : 8 seconds
  • Synchronisez l'horloge :

    ntptime
  • Vérifiez la date :

    date
  • Relancez Shibboleth :

    /etc/init.d/tomcat start
  • Contrôlez le bon fonctionnement :

    tail -f /opt/shibboleth-idp/logs/idp-process.log

2.1) Procédure de mise-à-jour de la brique CAS-client

  • Téléchargez l'achive :

    wget http://www.ja-sig.org/downloads/cas-clients/cas-cl... -O /opt/cas-client-3.1.10-release.zip
  • Décompressez :

    cd /opt
    jar -xf cas-client-3.x.x-release.zip
  • Déplacez vous dans le répertoire :

    cd cas-client-3.x.x/cas-client-core
  • Compilez :
    mvn package
    /!\ Si vous avez une erreur => "Failed to resolve artifact"
    à propos du JAR org.opensaml:opensaml:jar:1.1b
    => Utilisez la version demandée ici 1.1b
  • Déplacez-vous ici :

  • Retournez dans le repertoire cas-client :

    cd cas-client-3.x.x/cas-client-core
  • Compilez avec la commande :

    mvn install :install-file -DgroupId=org.opensaml -DartifactId=opensaml -Dversion=1.1b\
    -Dpackaging=jar -Dfile=/opt/opensaml-1.1b.jar
  • Maintenant vous devez obtenir :

    "BUILD SUCCESSFUL"

    en bas de votre écran.

    Attention l'idp n'aura aucune connaissance de cette nouvelle version de CAS-client. Pour prendre en compte cette mise-à-jour vous devez faire l'upgrade de votre idp, cf. le paragraphe 2) Procédure de mise à jour de la brique Shibboleth-idp.

3) Procédure de mise-à-jour et d'installation de Tomcat

Je tiens à préciser qu'il est impératif de fonctionner avec Tomcat en version 6 au minimum. La version 5.5 rien ne marchera pas avec la plupart des navigateurs hormis mozilla-firefox, puisqu'il y a un problème de compatibilité avec les COOKIES. Dans certain cas Tomcat6 n'est pas proposé avec les distributions stables de linux, il faut donc récupérer une version binaire pré-compilée sur le site officiel de la fédération Apache.

L'installation n'a rien de compliqué mais nécessite de prendre quelques précautions pour éviter de donner un accès global au serveur. J'indique ici comment mettre Apache2.2 en frontal de Tomcat6 avec une configuration optimale, aussi bien pour Apache2.2 que pour Tomcat6.

En résumé, Apache2.2 constitue la porte d'entrée et de sortie vers l'extérieur. Apache communique directement avec Tomcat via un proxy accessible uniquement depuis la boucle locale. Tomcat s'occupe juste d'exécuter les applications web Java (webapps). Ici il est question de "idp.war".

C'est donc Tomcat6 qui doit avoir les droits nécessaires de lecture des fichiers de configuration et d'écriture des logs de Shibboleth. De façon à soulager Tomcat, la gestion de SSL/TLS est prise en charge par Apache2.2.

Voici la procédure à suivre :

  • Emplacement de réception :

    cd /opt/
  • Récupérez l'archive "

    wget ftp://ftp.inria.fr/pub/Apache/tomcat/tomcat-6/v6.x... -O /opt/apache-tomcat-6.x.xx.tar.gz
  • Décompressez l'archive :

    cd /opt
    tar zxvf apache-tomcat-6.x.xx.tar.gz
  • Supprimez les binaires et scripts pour windows :

    cd apache-tomcat-6.x.xx
    rm bin/*.exe bin/*.bat
  • Créez un lien symbolique par commodité :

    cd /opt
    ln -s /opt/apache-tomcat-6.x.xx tomcat
  • Activez le connecteur PROXY AJP pour Tomcat :

    Ajoutez à la section <Service name="Catalina"> du fichier /opt/tomcat/conf/server.xml le connecteur comme ci-dessous :

    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
  • Commentez le connecteur sur le port 8080 dans le fichier /opt/tomcat/conf/server.xml :

    <!--
    <Connector executor="tomcatThreadPool"
    port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />
    -->
  • Supprimez les webapps de base offerts avec Tomcat :

    rm -rf /opt/tomcat/webapps/*
  • Ajoutez la webapp Shibboleth-idp dans le fichier /opt/tomcat/conf/Catalina/localhost/idp.xml

    <Context
    docBase="/opt/shibboleth-idp/war/idp.war"
    privileged="true"
    antiRessourceLocking="false"
    antiJARLocking="false"
    unpackWAR="false" />

    Remarque : vous pouvez ajouter l'attribut autoDeploy="true". Dans ce cas l'application sera chargée au lancement de Tomcat.

  • Par mesure de sécurité, supprimez les utilisateurs qui peuvent s'authentifier sur Tomcat :

    Retirez simplement le contenu de l'instance : tomcat-users dans le fichier /opt/tomcat/conf/tomcat-users.xml comme ci-dessous :

    <?xml version="1.1" encoding='utf-8 ?>
    <tomcat-users>
    </tomcat-users>
  • Lancez Tomcat au démarrage :

    Aucun script "System V" n'est fourni avec la distribution de Tomcat. Vous allez donc devoir en créer un. Par ailleurs ce procédé permet de simplifier la maintenance, mais aussi d'assurer le lancement automatique de Tomcat au démarrage du serveur. Cela permet aussi d'en profiter pour initialiser les variables d'environnement.

    Créez le fichier /etc/init.d/tomcat comme ci-dessous :

    #!/bin/sh

    RETVAL=$?
    JAVA_HOME=/usr/lib/jvm/java-6-sun
    JAVA_OPTS="-Xmx1000m -XX:MacPermSize=512m"
    CATALINA_HOME=/opt/tomcat
    IDP_HOME=/opt/shibboleth-idp

    export JAVA_HOME
    export JAVA_OPTS
    export CATALINA_HOME
    export IDP_HOME

    case "$1" in
    start)
    if [ -f $CATALINA_HOME/bin/startup.sh ];
    then
    echo $"Starting Tomcat"
    /bin/su -p -s /bin/sh tomcat $CATALINA_HOME/bin/startup.sh
    fi
    ;;
    stop)
    if [ -f $CATALINA_HOME/bin/shutdown.sh ];
    then
    echo $"Stoping Tomcat"
    /bin/su -p -s /bin/sh tomcat $CATALINA_HOME/bin/shutdown.sh
    fi
    ;;
    *)
    echo $"Usage: $0 {start|stop}"
    exit 1
    ;;

    exit $RETVAL

    Maintenant il ne reste plus qu'à positionner le script dans les differents niveaux de démarrage comme ci-dessous :

    chmod 755 /etc/init.d/tomcat
    update-rc.d tomcat default
  • Lancez Tomcat avec un utilisateur spécifique :

    Il est préférable de lancer Tomcat avec un utilisateur spécifique avec des privilèges limités. Le script suivant vous aidera à le créer :

    #!/bin/sh

    if ! id tomcat > /dev/null 2>&1 ; then
    adduser --system --home /opt/tomcat --no-create-home \
    --ingroup nogroup --disable-password --shell /bin/false \
    tomcat
    fi

4) Configuration de Apache2.2 (Lenny/Debian)

  • Activez les ports d'écoute dans le fichier :

    /etc/apache2/ports.conf

    Vérifiez que Apache écoute bien les deux ports comme ci-dessous :

    Listen 443
    Listen 8443
  • Configurez vos deux accès :

    - Créez le fichier /etc/apache2/sites-available/idp ci-dessous :

    <IfModule mod_ssl.c>
    <VirtualHost _default_:443>
    ServerName idp.mondomaine.fr:443
    SSLEngine On
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:SSLv2:+EXP
    SSLProtocol all -SSLv2
    SSLCertificateFile /etc/ssl/certs/idp.mondomaine.fr.pem
    SSLCertificateKeyFile /etc/ssl/private/idp.mondomaine.fr.key
    SSLCertificateChainFile /etc/ssl/certs/globalsign_ct_root.pem
    SSLCACertificateFile /etc/ssl/certss/sureserverEDU.pem
    SSLOptions +StdEnvVars

    SetEnvIf User-Agent "*.MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    <IfModule mod_proxy_ajp.c>
    ProxyRequests Off
    <proxy ajp://localhost:8009>
    Allow from all

    ProxyPass /idp ajp://localhost:8009/idp retry=5
    </IfModule>
    </VirtualHost>
    </IfModule>

    - Créez le fichier /etc/apache2/sites-available/idp-aa ci-dessous :

    <IfModule mod_ssl.c>
    <VirtualHost _default_:8443>
    ServerName idp.mondomaine.fr:8443
    SSLEngine On
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP
    SSLProtocol all -SSLv2
    SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt
    SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key
    SSLVerifyDepth 10
    SSLOptions -StdEnvVars +ExportCertData

    SetEnvIf User-Agent "*.MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    <IfModule mod_proxy_ajp.c>
    ProxyRequests Off
    <proxy ajp://localhost:8009>
    Allow from all
    </proxy>
    ProxyPass /idp ajp://localhost:8009/idp retry=5
    </IfModule>
    </VirtualHost>
    </IfModule>

  • Activez les deux accès :

    a2ensite idp idp-aa
  • Activez le module ssl :

    a2enmod ssl
  • Activez le module proxy_ajp :

    a2enmod proxy_ajp
  • Relancez le server Apache2:

    apache2ctl -t
    apache2ctl -k restart

5) Configuration de Shibboleth-idp

Il s'agit de la configuration principale et donc celle que vous devrez utiliser pour administrer Shibboleth. Elle se trouve dans deux fichiers :

- Fichier de génération d'attributs : /opt/shibboleth-idp/conf/attribute-resolver.xml

Ce fichier est nécessaire pour configurer les connecteurs, LDAP, BDD et Statique. Il sera aussi très pratique pour déterminer les attributs nécessaires aux ressources.

- Fichier de contrôle de la propagation d'attributs : /opt/shibboleth-idp/conf/attribute-filter.xml

Ce fichier détermine quels attributs seront fournis aux ressources.

Le support technique Renater offre des fichiers d'exemples qui servent de base à la fédération. Pour une utilisation classique, il faut naturellement changer la configuration des connecteurs et filtrer la propagation des attributs, le but étant d'avoir le contrôle de son fournisseur d'identités.
Fichiers de configuration d'exemples Renater : https://services-federation.renater.fr/exemples/co...

5.1) attribute-resolver.xml

Modifiez attribut-resolver.xml à partir de la section "Data connectors" comme ci-dessous :
(Ces connecteurs sont obligatoires pour mondomaine.fr)

<resolver:DataConnector id="StaticAttributes"
xsi:type="Static"
xmlns="urn:mace:shibboleth:2.0:resolver:dc">

<Attribute id="eduOrgLegalName">
<Value>
Idp MonDomaine.fr
</Value>
</Attribute>

<Attribute id="EduPersonEntitlement">
<Value>
urn:mace:dir:entitlement:common-lib-terms
</Value>
</Attribute>

</resolver:DataConnector>

<resolver:DataConnector id="votreLDAP"
xsi:type="LDAPDirectory"
xmlns:"urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://ldap.mondomaine.fr"
baseDN="ou=people,dc=mondomaine,dc=fr"
principal="cn=cri,ou=services,dc=mondomaine,dc=fr"
principalCredential="VotreMotDePasse">

<FilterTemplate>
<![CDATA[
(uid=$requestContext.princpalName)
]]>
</FilterTemplate>

</resolver:DataConnector>

<resolver:DataConnector id="computedID"
xsi:type="ComputedID"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
generatedAttributeID="computedID"
sourceAttributeID="uid"
salt="VotrePointeDeSel">

<resolver:Dependency ref="votreLDAP" />

</resolver:DataConnector>

5.2) attribute-filter.xml

Ce fichier est indispensable pour l'ajout d'un fournisseur de services. Les fournisseurs de services mentionnés dans ce fichier seront accessibles. Voici un exemple pour ajouter un fournisseur de services :

  • Déplacez vous dans la partie suivante :

    <AttributeFilterPolicy id="releaseAttributesToSelectedSP">
  • Ajoutez le fournisseur dans "PolicyRequirementRule" :

    <PolicyRequirementRule xsi:type="basic:OR">
    <basic:Rule xsi:type="basic:AttributeRequesterString" value="url_fournisseur_a" />
    <basic:Rule xsi:type="basic:AttributeRequesterString" value="url_fournisseur_b" />

    <!-- Mettez à la suite les fournisseurs de services -->
    <!-- Remplacez url_fournisseur_a par l'url de votre fournisseur
    exemple http://www.cairn.info
    -->
    </PolicyRequirementRule>

  • Les paramètes suivants sont les attributs propagés aux fournisseurs url_fournisseur_x :

    <!-- Ex nom complet sans accent d'une personne -->
    <AttributeRule attributeID="commonName">
    <PermitValue xsi:type="basic:ANY" />
    </AttributeRule>

    <!-- Ex nom complet avec accents -->
    <AttributeRule attributeID="DisplayName">
    <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>

  •  Attention Pour que vos modifications soient appliquées il faut impérativement relancer Tomcat.
    /etc/init.d/tomcat stop
    /etc/init.d/tomcat start

6) Droits d'accès et sécurité

Les droits d'accès peuvent être réglés avec beaucoup de souplesse. Voici un ensemble de règles pour protéger le service et les informations sensibles.

6.1) Shibboleth-idp

Shibboleth doit être accessible par Tomcat :

chown -R tomcat logs metadata credentials
chmod 755 logs metadata
chmod 750 credentials
chown tomcat conf/attribute-filter.xml
chmod 660 conf/attribute-filter.xml

chmod 444 /opt/shibboleth-idp/credentials/metadata-federation-renater.crt
chown tomcat /opt/shibboleth-idp/credentials/idp.key
chgrp root /opt/shibboleth-idp/credentials/idp.{key,crt}
chmod 440 /opt/shibboleth-idp/credentials/idp.key
chmod 644 /opt/shibboleth-idp/credentials/idp.crt

6.2) Tomcat

D'origine les droits sont bien réglés, mais assurez-vous que l'utilisateur "tomcat" est bien le propriétaire de :

/opt/tomcat

chown -R tomcat /opt/tomcat

6.3) Certificat SSL Apache

Les certificats SSL permettent d'identifier le serveur via une procédure de signature. Les échanges d'identités entre les utilisateurs et les ressources seront chiffrées. Protégez vos certificats :

chown root:root /etc/ssl/private/idp.mondomaine.fr.key
chmod 640 /etc/ssl/private/idp.mondomaine.fr.key

chown root:root /etc/ssl/certs/globalsign_ct_root.pem
chown root:root /etc/ssl/certs/idp.mondomaine.fr.pem
chown root:root /etc/ssl/certs/sureserverEDU.pem

chmod 640 /etc/ssl/certs/globalsign_ct_root.pem
chmod 640 /etc/ssl/certs/idp.mondomaine.fr.pem
chmod 640 /etc/ssl/certs/sureserverEDU.pem

 Attention Remarque : le prestataire qui assure la sécurité des certificats peut changer. Ce qui précède est donc valable jusqu'à la réception de nouveaux certificats (sauf si vous passez par GlobalSign).

Veuillez prendre note des modifications suivantes pour les nouveaux certificats.

  • Afin de simplifier la gestion des certificats, réalisez un document.cnf : /etc/ssl/idp.mondomaine.cnf. Ce document permet de conserver les paramètres utilisés lors de la création du certificat requête.

    Ci-dessous son contenu :

    [req]
    default_bits = 1024
    default_keyfile = idp.mondomaine.fr.key
    distinguished_name = req_distinguished_name
    prompt = no

    [ req_distinguished_name ]
    C = FR
    O = Mon Etablissement
    CN = idp.mondomaine.fr
    emailAddress = idpmaster [at] mondomaine [dot] fr

  • Maintenant si vous voulez générer un certificat requête avec votre clé privée correspondante, vous pouvez utiliser le script ci-dessous (fichier /root/bin/req) :

    #!/bin/sh
    # Fourni dans le répertoire courant :
    # la clé (pour Apache)
    # idp.mondomaine.fr.key
    # le certificat requête (pour votre RSSI)
    # idp.mondomaine.fr_req.pem
    openssl req -new -nodes -out idp.mondomaine.fr_req.pem\
    -config /etc/ssl/idp.mondomaine.fr.cnf

  • Vous devez remplacer la clé "RSA PRIVATE KEY" par la nouvelle clé :

    cat ./idp.mondomaine.fr.key > /etc/ssl/private/idp.mondomaine.fr.key
  • Pour terminer, il faut remplacez les chaines de certificats. Vous devez adapter les chaînes de certificats selon votre prestataire.

6.4) Ajoutez des certificats non valides

Malheureusement un bon nombre d'aministrateurs n'utilise pas SSL dans les règles de l'art. Les serveurs mal administrés ne sont pas considérés comme dignes de confiance et Java ou les navigateurs internet n'accepteront pas les connexions avec ces serveurs. Pour résoudre ce problème et forcer Java à utiliser ces serveurs, vous devez ajouter manuellement les certificats dans son KeyStore de la façon suivante :

  • Téléchargez le programme Java suivant :

  • Compilez le programme :

    javac InstallCert hostname

     Attention Pour mondomaine.fr hostname=cas.mondomaine.fr

  • On vous demande d'ajouter les certificats. Ajoutez les tous.

    Enter certificate to add to trusted keystore or 'q' to quit: [1]

     Attention 1 pour certificat numéro 1, recommancez autant de fois que vous avez des certificats, cf. le paragraphe 3).

  • Copiez le KeyStore Java "jssecacerts" crée dans le répertoire courant ici :

    cp jssecacerts $JAVA_HOME/jre/lib/security
  • Vérifiez les droits ou fixez les :

    chown root:root $JAVA_HOME/jre/lib/security/jssecacerts
    chmod 644 $JAVA_HOME/jre/lib/security/jssecacerts
  • Pour finir, relancer Tomcat :

    /etc/init.d/tomcat stop
    /etc/init.d/tomcat start

    Remarque : si vous souhaitez que ces certificats soient reconnus comme de "confiance" par toutes vos applications Java et pas seulement JSSE, écrasez "cacert" avec "jssecacerts".

Bilan 2009 et projets 2010 du projet et de la plate-forme PLUME

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

Bilan 2009 et projets 2010 du projet et de la plate-forme PLUME

BILAN 2009 de la plate-forme et du projet PLUME

  • Evolution de la production : en savoir plus En savoir plus

    251 nouvelles fiches pour atteindre un total de 529 (+ 90 % par rapport à 2008)

    121 anciennes fiches mises à jour par leurs rédacteurs

    19 fiches en anglais (aucune en 2008)

    168 nouveaux contributeurs (rédacteurs ou relecteurs) pour un total de 438 (+ 60 %)

    1 millions de hits / mois en moyenne (+ 65 %)

 

PROJETS pour 2010

Organisation : En savoir plus

  • Mettre en place un comité stratégique, avec un groupe représentatif des soutiens-partenaires actuels
  • Créer un comité éditorial : informations mises en ligne et diffusées, présentation-ergonomie, mots-clés
  • Stabiliser et renforcer l'organisation qui repose sur quelques personnes

Développements internes (Ens Sup - Recherche) En savoir plus

  • Référencer tous les développements des laboratoires CNRS avec la valorisation associée. Un ingénieur valorisation, Samuel Godey, financé par la DPI du CNRS, sera en CDD pour un an à partir de mi janvier 2010
  • Pour le référencement des développements logiciels, continuer les actions de promotion au niveau des délégations régionales et services de valorisation du CNRS, organismes-départements-instituts, laboratoires, universités
  • Pages de développements internes / laboratoire, organisme de recherche, institut, université

Projets connexes En savoir plus

  • Aider à la mise en place d'un réseau national de compétences pour les développeurs : DEVLOG
  • Lancer et participer au projet de Forge Ens Sup Recherche nationale dont le périmètre est à définir

Formation En savoir plus

 Plate-forme

  • Réorganiser les mots-clés existants et ajouter un nouvel ensemble de mots-clés 'scientifiques'
  • Mettre en place le processus de mise à jour des fiches ressources, des fiches dév ESR, logiciels à valider et logiciels en tests
  • Mise en place de nouveaux thèmes : chimie, électroniciens, astronomie...
  • Positionner le portail anglophone dans les serveurs internationaux et dans des projets européens

Travail 'de fond'

  • Enrichir la base des descriptions de logiciels validés, à valider, en tests, dév ESR et les ressources associées en motivant des contributeurs. Mettre en place de nouveaux thèmes avec des responsables thématiques
  • Tenir à jour la base existante
  • Rechercher de nouveaux soutiens et réaliser des partenariats à ce projet et à cette plateforme
  • Mettre en place de nouveaux projets connexes et aider à l'évolution de ceux déjà lancés

"Les logiciels libres : soumis au droit d'auteur, dans un contexte international, une jurisprudence en émergence, des défis à relever" RMLL'09

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

"Les logiciels libres : soumis au droit d'auteur, dans un contexte international, une jurisprudence en émergence, des défis à relever" RMLL'09

Voici quelques notes sur la présentation de Bernard Lamon Les logiciels libres : soumis au droit d'auteur, dans un contexte international, une jurisprudence en émergence, des défis à relever faite aux RMLL 2009, thème Entreprise.
Le video de cette présentation est disponible : lien 1, lien 2.
Ces notes peuvent être inexactes, incomplètes et refléter les centres d’intérêt d’une informaticienne du CNRS. Aucune erreur dans ce texte ne peut être attribuée au conférencier ou aux organisateurs des RMLL.
Cette fiche est un complément à la Fiche Plume FAQ : licence & copyright pour les développements de logiciels libres de laboratoires de recherche.

Plan de la présentation

I - Le droit d'auteur et la propriété intellectuelle : notions essentielles

II - Les aspects juridiques du logiciel libre

III - La licence GPL

IV - La jurisprudence

V - Conclusion

Notes

Après avoir commenté le titre, l'orateur mentionne d'abord le document qu'il vient de signer et qui approuve la transmission de la conférence et la diffusion des transparents : le libre va au delà du logiciel.
Bernard Lamon est spécialiste de ce sujet depuis 10 ans, il fait des présentations depuis 6 ans pour des entreprises (et très récemment pour l'Université de Bretagne) qui utilisent et/ou produisent du logiciel : il fournit aussi une assistance juridique et une représentation dans des contentieux.

Jusqu'à récemment il y avait un désintérêt total des entreprises sur le sujet, mais depuis un ou deux ans, s'est produite  une évolution très importante dans l'attitude de ce public, évolution dûe principalement à une maturité de l'offre (de la part du logiciel libre) et à une évolution dans la perception des entreprises du logiciel libre (cela existe en mieux et en plus c'est gratuit). Il y a aussi une évolution juridique de la société (de plus en plus de lois). Avant on associait libre à "libre de tout droit" (et "on peut faire tout ce qu'on veut"), mais l'open source ou logiciel libre répond à des règles juridiques très bien rédigées, ce qui montre une compréhension profonde du problème juridique associé.

La licence est un contrat entre l'auteur d'un logiciel et les utilisateurs, elle définit les règles d'utilisation. Le fait que ce contrat ne soit pas signé ne pose pas de problème juridique : c'est un accord de bonne volonté entre l'auteur et les utilisateurs. Si vous prenez le logiciel libre, ce contrat entre automatiquement en fonctionnement. Mais un contrat entre qui? : c'est le casse-tête des avocats, puisqu'il arrive qu'il n'y ait pas de personne physique ou morale bien définie, surtout quand il s'agit d'un collectif de développeurs.

Le concept "logiciel libre" n'est pas un concept juridique, d'où l'importance des décisions juridiques.

Les trois lignes (GPL v2) qui posent le problème viral : « You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. »
Quand on dit que plus de 70% du logiciel libre est sous licence GPL, cela correspond à un chiffre assez réaliste, et c'est la conséquence directe de ces trois lignes (l'orateur a parlé d'un projet génial et pervers à la fois). Les questions que ces lignes soulèvent :

  • Compatibilité avec les droits FR, BE, EU, ... (les décisions juridiques montrent que ce n'est pas la question centrale).
  • Concept "logiciel dérivé" qui donne la frontière entre ce qui sera un logiciel sous GPL ou un logiciel propriétaire (on parle de logiciel lié dynamiquement - dynamic linking). Cette question est très délicate du point de vue technique et juridique.
  • Concept "distribution" : clé du procès en cours sur la Freebox (embedded distribution).

Les pistes actuellement étudiées en ce moment pour éviter cet aspect viral dans le développement de logiciels sont :

  • le nettoyage du code (re-écrire tout code GPL utilisé comme brique),
  • ne pas diffuser le code (SaaS - Software as a Service).

Les licences libres évoluent pour éviter que les sociétés qui proposent des services basés sur les logiciels libres soient contraintes de diffuser les évolutions du code. Un exemple est la GNU Affero General Public License.
L'orateur propose d'écrire la lettre qui demande le code source si l'on trouve un problème dans ce type de services (ici il fait la liaison avec R. Stallman, utilisateur mécontent d'un pilote d'impression).

Les jurisprudences mentionnées sont clairement présentées dans le document .pdf, elles ne seront pas reprises ici. On note que :

  • Les deux jurisprudences en France correspondent à des logiciels libres développés dans la comunauté enseignement supérieur et recherche, et dont le transfert vers des sociétés d'exploitation a posé des problèmes.
  • Les jurisprudences mentionnées ne posent aucune question sur la validité de la GPL, elles reconnaissent la licence GPL et l'appliquent.
  • H. Welte, fondateur de gpl-violations.org, est à l'origine du procès sur la Freebox en France, cette affaire n'est pas encore résolue.

Référence : libre blanc "Le droit des licences Open Source - Quelles règles pour les entreprises ?", sous la direction de Me B. Lamon.

Mon commentaire : de même que dans le Séminaire "Construire son projet sur du libre : quelles précautions prendre ?", je trouve dommage l'insistance sur l'effet viral de la GPL, alors qu'elle apporte un réel bénéfice à la société. L'utilisation des logiciels libres est un choix, qui est accompagné des contraintes, comme tout autre choix.
Complément sur ce commentaire : il y a un vrai problème légal derrière cet effet viral de la GPL, c'est donc normal que les avocats insistent sur ce point.

OSSIR : Observatoire de la Sécurité des Systèmes d’Information et des Réseaux

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

OSSIR : Observatoire de la Sécurité des Systèmes d’Information et des Réseaux

L'Observatoire de la sécurité des systèmes d'information et des réseaux (OSSIR) est une association à but non lucratif (loi de 1901) existant depuis 1996 qui regroupe les utilisateurs intéressés par la sécurité des systèmes d'information et des réseaux.
L'association comprend actuellement :

  • quatre groupes de travail régionaux :
    • Paris depuis 1987, issu de la fusion du groupe Windows et SUR (Sécurité Unix et Réseau) en 2008 ;
    • RéSIST (Toulouse) depuis 1997 ;
    • Bretagne depuis 2007 ;
    • Rhônes-Alpes depuis 2009.
  • un groupe de réflexion technico-juridique

Les réunions permettent des échanges et des présentations techniques de solutions et d'expériences en sécurité. La participation aux groupes de travail est gratuite et libre d'accès. Les groupes se réunissent, en général, une fois par mois.
Chaque année, l'association organise la Journée de la Sécurité des Systèmes d'Information (JSSI). La JSSI'2010 se déroulera le mardi 16 mars 2010.
Les supports des présentations effectuées lors des réunions des groupes régionaux ou lors de la JSSI sont disponibles sur le site.

L'OSSIR assure la gestion et l'animation de listes électroniques :

  • une liste par groupe de travail réservée aux informations relatives au groupe ;
  • une liste réservée aux annonces des différents événements et manifestations concernant la sécurité ;
  • une liste de discussion modérée sur la sécurité.
Syndiquer le contenu