Arrivée de Julien Peloton

Cette réunion a été l’occasion d’annoncer l’arrivée en janvier 2018 de Julien Peloton, successeur de Christian Arnault sur les projets de calcul distribué avec Spark pour l’astrophysique.

Dans ce concours, 3 bons candidats avaient émergé: Julien, Alexandre du CDS, et Christophe de l’IAS (ancien de ROMEO). Si Julien ne partait pas initialement favori, il a su faire une très bonne impression au jury lors de son oral, ce qui a finalement fait pencher la balance en sa faveur.

Au niveau parcours, Julien a suivi le master NPAC, puis fait une thèse astroparticules au laboratoire APC sur l’analyse des données de l’expérience Polarbear, complétée par un post-doc de 3 ans à l’université de Sussex sur des sujets similaires, obtenu grâce à un prix. Il souhaitait revenir en France pour des raisons personnelles.

Il sera aussi l’un des premiers ingénieurs recrutés par le LAL à ne pas bénéficier de la Prime de Fonctions Informatiques (PFI), supprimée à l’occasion du passage à la RIFSEEP…

Nouvelles de SVOM

Antoine a passé deux jours au CNES pour un événement autour de SVOM, expérience spatiale rejointe par le LAL il y a quelques mois, mais dont l’existence est plus ancienne (quelques années).

SVOM est une expérience d’astrophysique franco-chinois visant à suivre des sursauts gamma par une combinaison d’instruments sur orbite et au sol. L’instrument spatial devrait être lancé de la Chine courant 2020.

Du côté français, on attend notamment des contributions de Florent Robinet et Nicolas Leroy du groupe Virgo, et d’Antoine et Marc du service informatique. Antoine y fait l’interface avec l’entreprise chargée du marché de gestion de la qualité pour l’astrophysique au CNRS, et en particulier au CNES.

Antoine rapporte quelques divergences culturelles intéressantes dans cette collaboration logicielle franco-chinoise. Il est ainsi étonamment difficile de proposer l’utilisation d’outils logiciels d’origine américaine, même open-source, dans un projet chinois.

Nouvelles de PSPA

Redesign de l’interface utilisateur

Après examen des différentes options possibles, PSPA va finalement sous-traiter la refonte de son interface utilisateur à une entreprise privée. Ce dernier sera chargé de l’essentiel du front-end web, le LAL continuant le développement du back-end.

Une entreprise potentielle a été trouvée par Christian Helft. Après quelques discussions, elle a fait une proposition. La décision finale est en attente d’un appel d’offre, qui devrait être lancé en 2018.

Le projet a été présenté au Conseil Scientifique du LAL. Un financement mixte LAL + IN2P3 est envisagé afin d’élargir le cadre du projet PSPA et éviter qu’il ne reste trop centré au LAL.

Grigory a demandé si la sous-traitance d’un tel projet ne nous entraînait pas sur la pente glissante d’une sous-traitance de l’informatique au CNRS. Antoine a répondu que le projet avait longuement cherché l’expertise de conception d’interface utilisateur en interne à l’IN2P3, ainsi qu’en contactant des écoles d’ergonomie et en proposant des projets pour le Google Summer of Code, mais que tout cela n’avait pas été concluant.

Philippe mentionne qu’il existe des personnes ayant ce genre de compétences à l’IN2P3, car ils en ont trouvé pour ThomX, mais que ce n’est effectivement pas ce qu’il y a de plus répandu.

Serge aurait été partant pour une approche où l’on partirait de bibliothèques d’interface web distribuées par des designers professionnels, en les adaptant aux besoins de PSPA quand c’est nécessaire. Il regrette que le projet n’ait pas trouvé d’autres labos à l’IN2P3 avec lesquels collaborer sur cette question.

Il semble y avoir ici un besoin de compétences qui n’est pas satisfait, peut-être devrait-on chercher à le combler à l’occasion de la fusion ?

Dans tous les cas, ce projet de développement du front-end et du back-end permettra de motiver des améliorations importantes de PSPA, telles que la formalisation de l’interface entre ces composants.

Choix d’une licence open-source

Actuellement, le code du projet PSPA n’est distribué sous aucune licence logicielle. Cela signifie qu’il est de facto propriétaire: si il est légal de le lire et d’en faire des copies privées, personne n’a le droit d’en redistribuer une version modifiée, ou un binaire en découlant, ce qui interdit par exemple tout développement basé sur les forks à la GitHub / Gitlab (puisque le propriétaire d’un fork distribue de fait une version modifiée du code).

Une licence open source vise à autoriser un certain nombre de scénarios de redistribution du code source. Il en existe un grand nombre, leur prolifération et les incompatibilités subtiles qui existent entre elles est d’ailleurs un problème. Pour cette raison, il existe depuis quelques années un certain nombre d’initiatives visant à inviter la communauter à se recentrer sur un nombre réduits d’entre elles. Parmi elles, on peut mentionner la liste « Popular Licenses » de l’Open Source Initiative (OSI) et le guide « Choose a License » de GitHub.

Quand on s’en tient à ces licences populaires, le choix se fait principalement autour de ce qu’on veut autoriser les autres à faire avec son code. En effet, les licenses les plus permissives, comme la BSD et la MIT, ont un certain nombre d’effets pervers connus que l’on peut souhaiter décourager:

• Si une entreprise décide de prendre un logiciel gratuit sous licence BSD et d’en vendre une version à peine modifiée, les auteurs originaux ne peuvent réclamer aucune rétribution financière,  ni demander à avoir accès aux versions modifiées du code source. Ce comportement parasite est entièrement autorisé par la licence.
• Dans les pays comme les Etats-Unis où les brevets logiciels sont répandus et utilisés comme instruments de guerre commerciale, une entreprise peut aussi tout à fait tenter de faire une copie d’un logiciel sous licence BSD, breveter son comportement, puis accuser l’auteur original de violation de brevet. Bien sûr, le brevet est alors totalement illégal puisque le parasite n’a pas la paternité du logiciel, mais le prouver à un tribunal demande une lutte juridique longue et des moyens financiers conséquents, et de nombreux « petits » développeurs finiront par préférer abandonner et payer le racketteur faute de moyens…

La licence Apache tente de lutter contre cette utilisation abusive des brevets logiciels en forçant l’auteur du logiciel et son utilisateur à signer un pacte de non-agression. L’auteur confère à l’utilisateur une licence non-révocable pour tous les brevets liés au logiciel sous licence Apache, tandis que l’utilisateur accepte que tout procès de violation de brevet intenté à l’auteur causera un arrêt immédiat de sa licence d’utilisation du logiciel.

Les licences dites « copyleft », comme la GPL, vont plus loin en imposant une redistribution du code source de tout logiciel basé sur le code sous licence copyleft, et en interdisant toute redistribution sous une licence plus restrictive. Cette approche interdit au maximum les comportements parasites, au prix parfois d’interdire aussi des utilisations du logiciel jugées légitimes par l’auteur du logiciel. Par exemple, veut-on qu’une entreprise soit forcée de redistribuer le code source complet de son application simplement parce qu’elle utilise une bibliothèque libre ?

Pour ceux qui souhaitent éviter ce genre d’effet pervers, mais tiennent aux garanties anti-parasites du copyleft, il existe le compromis du « copyleft faible », comme les licenses LGPL et MPL. Destinées à des bibliothèques, ces licences disent grosso modo qu’une version modifiée de la bibliothèque doit être redistribuée en open-source, mais qu’une application basée sur la bibliothèque n’est pas forcée d’utiliser la même licence. Ces licences ne diffèrent que dans leur définition d’une bibliothèque et des utilisations autorisées sans qu’une licence particulière soit imposée à l’application hôte.

Les licences précédentes ont été conçues pour le droit américain, ce qui conduit certains juristes à affirmer que leur transposition au droit français et européen n’est pas évident. Pour ceux qui sont inquiets de cet aspect légal, il existe des variantes « régionales » des licences précédentes, adaptées au droit français (CECILL) ou européen (EUPL). Le prix à payer est une collaboration potentiellement plus difficile avec des projets internationaux, qui feront à ces licences le reproche inverse d’être insuffisamment adaptées au droit américain…

Si l’on a besoin de l’aide d’un juriste sur ces questions légales, cela peut être difficile à trouver au CNRS, le service valorisation de la DR4 n’étant pas très doué sur ces questions. Philippe mentionne l’existence d’un juriste très compétent à l’échelle nationale, la difficulté étant de le contacter en esquivant l’échelon intermédiaire… Grigory mentionne aussi la présence d’un bon juriste à Polytechnique, qu’on peut aussi contacter en cas de problème avec la délégation régionale.

Revues numériques Diamond

Nous avons pu tester pendant un certain temps la version numérique des revues des éditions Diamond (GNU/Linux mag, Hackable, Linux pratique, Misc). La période d’essai arrive maintenant à son terme, et Philippe souhaiterait savoir si ces éditions nous intéressent suffisamment pour que ça vaille le coup d’acquérir un abonnement.

On nous a proposé l’accès en ligne aux versions numériques (base documentaire) pour 607,5€/an, et le papier en plus pour 825,03€/an. Cet abonnement, appelé « L+ », inclut les numéros de l’ensemble des quatre revues, ainsi que leurs hors-séries. Pour les autres devis possibles, un générateur de devis est disponible en ligne.

Au moment de la réunion, le faible nombre de retours (Adrien seulement) suggérait qu’il serait peut-être mieux d’en rester là.

Autres sujets en vrac

Serge mentionne l’organisation possible d’une formation Symfony 3 au CNRS, en cours de discussion sur la liste DevLog.

Le bureau de Christian Helft est maintenant vde, et prêt à être transformé en salle de repos pour le service informatique.

Pour la prochaine réunion sur le fonctionnement du SI (20/11), quelques sujets commencent à émerger:

• Veille technologique
• Évolution du format des réunions développeurs
• Fréquence élevée des réunions exploitation
• Projet de réunion orienté utilisateurs, sur le même principe que le COMUTI mais davantage orienté développement