Gestion de logs avec la stack ELK

Gestion de logs avec la stack ELK

Lorsqu’il y a une erreur dans un système informatique global, le premier endroit où chercher des indices pour identifier des solutions se trouve dans les logs (fichiers journaux).

Bien souvent, la quantité d’informations produites est énorme, et le temps passé à déboguer un système peut s’avérer considérable pour un seul technicien. La solution qui se dégage consiste alors à collecter les logs de manière centralisée plutôt que de disposer de nombreux logs dispersés.

 

Chez IDFOR Solutions, nous sommes toujours soucieux de fournir un service, une expertise et des produits qui facilitent la vie de nos clients, et leur permettent de gagner en productivité et fiabilité.

 

Nous avons donc décidé de vous reparler de la stack ELK. Elle fournit un ensemble d’utilitaires et d’applications -chacun ayant un objectif spécifique- qui, une fois combinés, créent une puissante plateforme de recherche et d’analyse pour votre entreprise. La solution ELK est une plateforme SaaS utilisant Elasticsearch, Logstash et Kibana. Il s’agit d’un puissant système de gestion de logs, centralisé, traité par un système central. On l’utilise pour générer confortablement des informations à des fins de rapport et d’audit -entre autres-.

La gestion centralisée des journaux d’événements identifie facilement les problèmes de serveurs ou d’applications, car elle permet de naviguer dans tous vos logs, à un seul endroit. Elle permet également d’identifier tout problème touchant plusieurs serveurs, en corrélant tous les journaux apparus dans une période précise. Logstash est un outil qui collecte et stocke les journaux, pendant que Kibana, une interface Web, permet d’afficher et de rechercher les journaux déjà indexés.

Grâce à la stack ELK, nos clients sont en mesure de parcourir toutes les données collectées, tout en générant rapports, tableaux de bord, et graphiques à différentes échelles.

Chaque entreprise ou service informatique a, à un moment donné, été confronté aux défis que représente l’infrastructure de journalisation centralisée. Mais en utilisant Kibana et Elasticsearch, il est possible de disposer d’une stack opérationnelle très rapidement, en utilisant des agents préconçus, des bibliothèques de code … ou avec des API propres.

 

Aujourd’hui, de nombreuses grandes entreprises ont recours à Elasticsearch.

Par exemple, le géant des médias « Netflix » dispose de nombreux clusters Elasticsearch, qui extraient des informations en temps réel, à très grande échelle. Les besoins divers en données de Netflix incluent notamment la nécessité de stocker, rechercher et indexer des documents.

L’utilisation d’Elasticsearch chez Netflix au cours des deux dernières années a rapidement augmenté, passant de quelques déploiements isolés à une utilisation actuelle à grande échelle.

Quant à « Medium » (une plateforme de publication de billets de blog, très populaire), elle accueille des millions de lecteurs uniques ainsi que des dizaines de milliers de publications chaque semaine. Selon l’équipe technique de Medium, ELK est utilisé pour résoudre les problèmes de production. La société utilise également la stack Elasticsearch, Logstash et Kibana pour détecter les anomalies DynamoDB.

Le réseau social professionnel « LinkedIn » fait partie des précurseurs. L’équipe de LinkedIn utilise ELK pour surveiller les performances et la sécurité de leur plateforme. L’équipe informatique intègre ELK à Kafka pour supporter la charge en temps réel. Leurs traitements ELK transitent par plus de 100 clusters répartis dans plus de vingt équipes et six datacenters !

 

Si vous souhaitez en savoir plus sur les avantages d’une solution ELK pour votre entreprise, contactez-nous dès aujourd’hui !  💌

 

Source de l’image d’illustration de l’article : «Fichiers Papier Bureau Formalités Administratives» de «myrfa» sur Pixabay.

 

.

Valeur juridique de la signature électronique

Valeur juridique de la signature électronique

“Commencez par signer, que je sache dans quel sens ça se regarde”.

La définition à laquelle faisait référence Auguste Rodin lors d’un échange avec Pablo Picasso, était celle de la marque apposée par un artiste sur son oeuvre afin de certifier qu’il en était l’auteur.
Pourtant, la signature, au-delà de sa vocation artistique, possède une définition fonctionnelle d’un point de vue juridique.

En effet, la signature a deux objectifs, comme l’atteste l’article 1367 du Code civil :

  • D’une part, l’identification de la partie signataire.
  • D’autre part, le consentement de la partie signataire.

Elle permet donc de répondre à la question : Qui consent ?

 

Qu’en est-il de la légalité de son alter ego électronique ?

Pour vous rassurer immédiatement, la signature électronique est légale, et elle est recevable comme preuve en justice car elle bénéficie du principe de non-discrimination, selon certaines conditions, conformément aux dispositions de l’article 1366 du Code civil.


La signature électronique est effectivement reconnue depuis la loi du 13 mars 2000 portant adaptation du droit de la preuve aux technologies de l’information et relative à la signature électronique.

Elle est définie par l’article 1367 du Code civil comme un “usage d’un procédé fiable d’identification garantissant son lien avec l’acte auquel elle s’attache”.

 

Trois niveaux de signature

 

La France reconnaît 3 niveaux de signature, notamment du fait de l’entrée en vigueur du décret du 28 septembre 2017 relatif à la signature électronique, et du règlement eIDAS du 23 juillet 2014.

Il existe d’une part, la signature électronique simple correspondant, selon le règlement eIDAS, à l’ensemble des “données sous forme électronique, qui sont jointes ou associées logiquement à d’autres données sous forme électronique et que le signataire utilise pour signer”. Par exemple, le fait de cocher une case pourrait être assimilé à une signature électronique simple. Cependant, rien ne permet de connaître la véritable identité du signataire du document avec ce type de signature, et elle n’est donc pas nécessairement recommandée.

Le règlement eIDAS définit, en son article 26, le deuxième niveau correspondant à la signature électronique avancée. Celle-ci doit être liée au signataire de manière univoque, elle doit permettre l’identification du signataire, elle doit avoir été créée grâce à des données de création de signature électronique que le signataire peut utiliser sous son contrôle exclusif, et elle doit être liée aux données associées à cette signature de telle sorte que toute modification ultérieure des données soit détectable. Ainsi, ce niveau nécessite une identification du signataire par une autorité agréée, qui doit décerner un certificat de signature électronique nominatif de niveau LCP (light) si cette identification est faite à distance et QCP (qualifié) si c’est en face à face.

Enfin, le décret du 28 septembre 2017 définit le troisième niveau, la signature électronique qualifiée, comme “une signature électronique avancée, conforme à l’article 26 du règlement [eIDAS] et créée à l’aide d’un dispositif de création de signature électronique qualifié répondant aux exigences de l’article 29 du règlement [eIDAS], qui repose sur un certificat qualifié de signature électronique répondant aux exigences de l’article 28 [du] règlement [eIDAS]”. Ce type de signature (et uniquement celui-là), bénéficie d’une présomption de fiabilité (présomption simple, il est donc possible pour le présumé signataire de prouver qu’il n’a pas signé le document) conformément aux dispositions de l’article 1367 du Code civil. Ce niveau nécessite une identification du signataire en face à face par une autorité agréée, qui doit décerner sur un support physique un certificat de signature électronique qualifié nominatif de niveau QCP QSCD. Le signataire doit alors utiliser un système spécifique pour apposer ce certificat.

Un niveau intermédiaire (entre la signature électronique avancée et la signature électronique qualifiée) existe en pratique, bien qu’il ne soit pas défini légalement. Ce troisième niveau officieux, correspond à la signature électronique certifiée, consistant à sceller et horodater le document signé et à bâtir un dossier de preuve sur l’identité du signataire et la conclusion du contrat, grâce à un certificat électronique de niveau QCP.

 

Merci à Victor Havette (profil LinkedIn).

 

Consultez notre page dédiée à la signature électronique, pour davantage d’informations ! 😉

 

Trophées De L’Innovation 2018, Clermont-Ferrand

Trophées De L’Innovation 2018, Clermont-Ferrand

Le Journal De L’Eco

Le Journal De L’Eco est un média économique incontournable couvrant l’ensemble de l’actualité de la Région Auvergne-Rhône-Alpes. Avec une édition Clermontoise, et une du grand Lyon, il diffuse des informations sur divers canaux digitaux, à plus d’un million de lecteurs locaux et nationaux annuels.

 

Les Trophées De L’Eco Innovation

Parmi diverses de ses initiatives visant à encourager le business, Le Journal De L’Eco a organisé la quatrième édition des « Trophées De L’Eco Innovation Clermont Auvergne« , ce jeudi 15 Novembre 2018, devant la salle comble de l’amphithéâtre du Polydôme de Clermont-Ferrand. L’objectif de cette soirée: récompenser les entreprises et organismes du territoire les plus innovants. 26 candidats de différents secteurs, tels que : le commerce, l’industrie, les services, les sciences & recherche ont déposé des dossiers de candidature. Un jury composé d’experts et de chefs d’entreprise a élu, à huit clos, les grands lauréats récompensés pour chaque catégorie.

 

La soirée

Plus de 450 acteurs étaient réunis et à l’écoute du journaliste Marc-Alexis Roquejoffre, animateur de cette grande soirée, et entouré de personnalités, parmi lesquelles :

  • Alain Paulet, vice-président à l’Économie Riom Limagne & Volcans,
  • Pierre-François Mangeon, adjoint au directeur délégué Clientèle et Territoires d’Enedis,
  •  Valérie Monier, vice-présidente CCI du Puy-de-Dôme et présidente de la commission CCI Numérique,
  • Gilles Flichy, président de l’Interclubs de Clermont-Ferrand,
  • Jean-Marc Morvan, vice-président de Clermont Auvergne Métropole.

Au travers des Trophées de l’Innovation, nous voulons récompenser, toujours avec bienveillance, les entreprises les plus ambitieuses, celles finalement qui ont su placer l’innovation au cœur de leur stratégie de développement.” Lionel Chaumeil, président du Journal De L’Eco.

Photos d'IDFOR Solutions qui illustrent notre article de blog au sujet des Trophées De L'Eco Innovation 2018, au Polydôme de Clermont-Ferrand

Les lauréats

  • « Commerce » : Trophée pour la société Urby,
  • « Industrie » : Trophée remis à Carbiolice,
  • « Services » : Récompense pour UDeal,
  • « Sciences et Recherche » : Récompense pour Solu’Nature,
  • Trophée « Coup de Cœur » : Carbiolice.

 

IDFOR Solutions était, cette année, présente, et heureuse de faire le plein de nouvelles rencontres au sein d’un écosystème entrepreneurial de plus en plus riche et innovant. Nous serons ravis de participer à d’autres initiatives proposées par Le Journal De L’Eco !

 

  1. Photo d’illustration de l’article :  »Person holding light bulb », par Diego PH.
  2. Source : https://lejournaldeleco.fr/
Redelivery exponentiel avec Camel et ActiveMQ

Redelivery exponentiel avec Camel et ActiveMQ

Lorsque vous utilisez des routes Apache Camel pour votre intégration et qu’un problème se produit, une démarche classique consiste à réessayer l’envoi du message. C’est particulièrement le cas pour les erreurs  plutôt « temporaires ». Par exemple, si vous avez une panne de réseau, vous tenterez de renvoyer les messages, dans l’attente d’un retour de réseau.

Dans Apache Camel, cette règle de redistribution est configurée dans le gestionnaire d’erreurs. Ce dernier peut effectivement prendre en charge de telles erreurs.
Cependant, par défaut, le message à redistribuer est stocké en mémoire. De ce fait, les nouveaux échanges ne sont pas transmis, car le premier n’est pas signalé comme «pris en charge» !

Cela pose souci et perte du message dans le cas, par exemple, d’un redémarrage du conteneur hébergeant la route Camel (comme Apache Karaf). De plus, en termes de performances, il est intéressant d’assurer une continuité des échanges.

Plusieurs palliatifs existent, et nous allons justement illustrer dans cet article une stratégie de redelivery exponentiel.

 

Les routes Apache Camel

 

Commençons par des routes pour illustrer notre cas. Nous utilisons le DSL Camel Blueprint dans cet exemple, car notre conteneur préféré est Apache Karaf (évidemment 😉) !

La première route est assez simple: elle écoute les requêtes HTTP entrantes (à l’aide du composant Camel Jetty), les convertit en strings et les stocke dans une queue JMS.

La deuxième route lit des messages de la file d’attente JMS, prépare un JSON utilisant un processeur (enregistré en tant que service dans Karaf) et appelle un service REST.

 

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:cxf="http://camel.apache.org/schema/cxf">
 
  <reference id="connectionFactory" interface="javax.jms.ConnectionFactory"/>
  <reference id="jsonProcessor" interface="org.apache.camel.Processor" filter="(name=json)"/>
 
  <cxf:rsClient id="rsClient" address="http://localhost:8181/cxf/test/"/>
 
  <camelContext xmlns="http://camel.apache.org/schema/blueprint">
     <route id="first">
        <from uri="jetty:http://0.0.0.0:9090/first"/>
        <convertBodyTo type="java.lang.String"/>
        <wireTap uri=jms:queue:second?connectionFactory=connectionFactory"/>
        <setBody><constant>OK</constant></setBody>
     </route>
     <route id="second">
       <from uri="jms:queue:second?connectionFactory=connectionFactory"/>
       <process ref="jsonProcessor"/>
       <setHeader headerName="operationName"><constant>updateResource</constant></setHeader>
       <setHeader headerName="CamelCxfRsUsingHttpAPI"><constant>false</constant></setHeader>
       <setHeader herderName="CamelAcceptContentType"><constant>application/json</constant></setHeader>
       <to uri="cxfrs://bean://rsClient?synchronous=true"/>
     </route>
  </camelContext>
 
</blueprint>

Redelivery exponentiel

 

Par défaut, lorsque vous créez une route Camel, ce dernier active automatiquement le gestionnaire d’erreurs par défaut. Celui-ci intercepte alors un échange, lorsqu’il contient une exception.

Après avoir donc arrêté le message en erreur, il attend le signalement de prise en charge et réessaie l’échange.

 

Dans notre cas, nous souhaiterions :
  1. Conserver le message pour pouvoir le redistribuer, même en cas de redémarrage ou d’erreur de la plateforme ;
  2. Supprimer le message de la file d’attente JMS uniquement lorsqu’il a réellement été traité avec succès ;
  3. Relancer le message plusieurs fois, ou à l’infini ;

Pour ce qui est du point N°1, il est déjà pris en charge dans Camel, qui met les messages JMS en persistants par défaut. Cela signifie donc que les messages sont stockés dans la mémoire de persistance kahadb d’ActiveMQ.
Même si nous redémarrons ActiveMQ, ces messages ne sont pas perdus.

Dans notre besoin N°2, nous modifions le mode d’ACK (acquittement) JMS. Par défaut, Camel utilise auto ack: cela signifie que l’ack est envoyé au broker dès que le message est lu, donc juste après l’endpoint JMS de la route Camel.
Si un échec a lieu dans la route Camel, le message est déjà supprimé de la file d’attente … et vous devez donc faire avec !

Mais, en basculant le mode ack pour ack client, nous décidons d’accuser réception uniquement à l’heure d’achèvement de l’échange. Ainsi, le message ne sera retiré de la file d’attente que s’il a été traité complètement et avec succès.

Voici comment nous modifions le mode d’ack sur l’URI de l’endpoint JMS :

 

<from uri="jms:queue:second?connectionFactory=connectionFactory&amp;acknowledgementModeName=CLIENT_ACKNOWLEDGE"/>

 

Et enfin, pour notre 3ième point, nous allons modifier l’URL fournisseur dans la connection factory d’ActiveMQ. Par défaut, la factory ActiveMQ redistribue un message 7 fois au maximum.
Le nombre de tentatives de redelivery peut être modifié sur l’URL utilisée par la connection factory.
Par exemple, pour définir un nombre maximum de redistributions à 10, vous pouvez faire :

 

<bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
    <property name="brokerURL" value="tcp://localhost:61616?jms.redeliveryPolicy.maximumRedeliveries=10" />
</bean>

 

Vous pouvez également redistribuer un message indéfiniment (jusqu’à la date d’expiration du message, en réalité), en utilisant -1 pour maximumRedeliveries:

 

<bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
    <property name="brokerURL" value="tcp://localhost:61616?jms.redeliveryPolicy.maximumRedeliveries=-1" />
</bean>

Backoff delivery avec ActiveMQ

 

Dans la section précédente, nous avons donc utilisé une stratégie de redelivery via ActiveMQ. C’est très pratique, mais dans un souci d’optimisation du nombre de tentatives, il peut s’avérer souhaitable de mettre en place un certain délai entre les deliveries.
Et plus nous avons des redistributions, plus nous voulons augmenter ce délai. C’est ce que nous appelons le backoff delivery.

Cela se configure également dans la connection factory en utilisant :

  • useExponentialBackOff permet un backoff exponentiel. Il est désactivé par défaut ;
  • backOffMultiplier : permet de choisir la façon d’augmenter le délai. Par défaut, le «nouveau» délai est 5 fois plus élevé que le «précédent» ;
  • initialRedeliveryDelay est le délai de delivery initial. C’est le temps de démarrage du backoff. Par défaut, c’est 1000L, soit 1 seconde ;
  • maximumRedeliveryDelay est le délai maximum que nous pouvons avoir. Par défaut, c’est -1, ce qui signifie qu’il n’y a pas maximum ;

Voici donc comment mettre à jour l’URL de la connection factory pour permettre un backoff delivery :

 

<bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
    <property name="brokerURL" value="tcp://localhost:61616?jms.redeliveryPolicy.maximumRedeliveries=-1&amp;jms.redeliveryPolicy.useExponentialBackOff=true&amp;jms.redeliveryPolicy.initialRedeliveryDelay=2000L&amp;jms.redeliveryPolicy.backOffMultiplier=2" />
</bean>

 

Dans cet exemple, nous avons une politique de backoff delivery qui doublera le délai pour chaque tentative, en commençant par 2 secondes (2000L).

Grâce à tout cela, nous conservons donc une route Camel assez simple, et bénéficions d’une redistribution correcte et exponentielle, avec gestion du backoff.

 

Merci à Jean-Baptiste Onofré (blog.nanthrax.net/?p=820 – twitter.com/jbonofre)

Jean-Baptiste Onofré travaille quotidiennement sur les projets Apache utilisés dans divers produits. Technical Advisor, membre de l’Apache Software Foundation, il est également committer et membre PMC (Project Management Committee) d’une vingtaine de projets Apache, et a travaillé sur des projets majeurs comme Archiva, Camel, Karaf ou encore ServiceMix.

 

Photo d’illustration de la publication par Andrey Larin via Unsplash.

 

.

Introduction à l’Open Source

Introduction à l’Open Source

“Le pouvoir de l’Open Source est le pouvoir du peuple. Le peuple gouverne”.

Cette phrase de l’entrepreneur Philippe Kahn pourrait suffire à résumer la philosophie de l’Open Source.

Néanmoins, il convient d’être beaucoup plus explicite sur cette notion qui désigne avant tout un état d’esprit.

 

La philosophie du mouvement Open Source

Pour expliquer au mieux l’Open Source, il convient de reprendre une analogie d’un spécialiste de la question, Jim Jagielski, qui prenait l’exemple du cookie (le gâteau, pas le témoin de connexion) afin d’exprimer la philosophie du mouvement Open Source¹.
Cependant, afin de ne pas plagier un des cofondateurs de l’Apache Software Foundation, et parce que nous sommes (un peu) chauvins, nous utiliserons l’exemple du Saint-Nectaire, incluant sa recette.

L’Open Source pourrait apporter 3 droits à votre Saint-Nectaire.

  • D’une part, le droit d’utiliser votre Saint-Nectaire, à votre guise, notamment en le mangeant ou en utilisant la recette afin de faire votre propre fromage.
  • D’autre part, le droit de modifier la recette de votre Saint-Nectaire pour le rendre plus crémeux, plus ferme, ou plus fort selon vos goûts. De même, il vous sera possible de modifier son état en le congelant ou en le faisant chauffer au four par exemple.
  • Enfin, le droit de partager votre Saint-Nectaire ainsi que sa recette à tous.

En résumé, une licence Open Source vous autorise à utiliser, copier, modifier et diffuser un logiciel. La seule différence avec le Saint-Nectaire que vous ne pouvez pas partager indéfiniment, est que le logiciel peut être copié sans fin.
Selon Bruce Perens, le cofondateur de l’Open Source Initiative, l’Open Source est un moyen pour les individus de collaborer sur des logiciels sans être affectés par les inconvénients liés aux droits de propriété intellectuelle, et sans avoir à négocier des contrats².

 

Une philosophie provenant d’une imprimante défectueuse

Cette volonté de pouvoir copier, modifier et diffuser le logiciel provient du Free Software Movement initié par Richard Stallman dans les années 1980.
En effet, le laboratoire d’intelligence artificielle du Massachusetts Institute of Technology (MIT) dans lequel il travaillait, acquit une imprimante déficiente, sujette à des problèmes de bourrage papier, qu’il souhaitait améliorer en modifiant son logiciel pilote. Néanmoins, celui-ci n’était pas fourni avec l’imprimante, du moins pas sous une forme intelligible (il était disponible sous forme binaire, c’est-à-dire composé de 0 et de 1), et la société commercialisant le périphérique (Xerox pour ne pas la nommer), refusa de délivrer le code source du pilote à Richard Stallman afin qu’il corrige ce défaut lui-même.
Cet incident rendit Richard Stallman hostile à la logique des logiciels sous licence “propriétaire”.
Ainsi naquit le projet GNU (acronyme récursif de “GNU’s Not Unix”) et sa licence publique générale GPL, ainsi que la Free Software Foundation.
Richard Stallman réécrivit alors chaque programme un par un et d’autres personnes vinrent contribuer à cette réécriture massive, si bien qu’en 1991, presque tous les programmes avaient été retranscrits en programmes libres.

 

printer gif

Cette imprimante en parfait état de marche n’aurait sûrement pas pu donner naissance au mouvement du libre.

« Hey Arnold Nick Splat GIF » par @heyarnold sur Giphy : http://gph.is/2yrcSse

Logiciels libres ou Open Source ?

Cependant, une confusion existait dans l’esprit du public sur le terme “free”, signifiant à la fois “libre” et “gratuit”.
La Free Software Foundation précise, grâce à un célèbre exemple, que ces logiciels sont “libres” à l’image de la liberté d’expression et non “gratuits” comme pourrait l’être une bière gratuite³.
En effet, un logiciel libre n’est pas nécessairement gratuit, bien que ce soit majoritairement le cas.
Si le code source du logiciel est disponible gratuitement, son code exécutable peut être accessible en contrepartie d’un paiement. Pour reprendre une analogie musicale du Président de l’Association Francophone des Utilisateurs de Linux et des Logiciels Libres (AFUL), cela reviendrait à acquérir la partition sans bourse délier (code source), mais à acheter la version enregistrée du morceau (code exécutable)⁴.

Cette incertitude sur le terme “free” est l’une des raisons pour laquelle l’Open Source Initiative fut fondée en 1998.
En effet, ces licences libres et Open Source autorisent toutes deux la même chose : pouvoir utiliser, modifier, copier et diffuser le logiciel en question.
Néanmoins, les motivations du Free Software Movement et de l’Open Source Initiative diffèrent.
Selon Richard Stallman, l’Open Source Initiative met l’accent sur la communauté d’utilisateurs pouvant coopérer, afin d’échanger et d’améliorer un logiciel pour qu’il soit puissant et fiable. La mise en commun des savoirs des contributeurs est donc le socle de l’Open Source Initiative.
Le Free Software Movement, quant à lui, se fonde sur la liberté.
La liberté de pouvoir échanger, la liberté de pouvoir avoir une communauté, et la liberté de pouvoir modifier.
Néanmoins, Bruce Perens déclarait que l’Open Source s’inspirait principalement des travaux de Richard Stallman.
Afin de régler cette divergence et de regrouper ces logiciels à la philosophie commune, l’acronyme FOSS, pour “Free and Open Source Software”, a été créé.

 

Les différentes licences Open Source

La Free Software Foundation et l’Open Source Initiative ont chacune précisé des critères permettant de définir des FOSS.

En effet la Free Software Foundation a indiqué 4 libertés⁵ :

  • la liberté d’utiliser le logiciel comme vous le souhaitez, pour n’importe quelle finalité (liberté 0).
  • La liberté d’étudier la façon dont le logiciel fonctionne, et de le modifier afin d’aménager vos outils informatiques comme vous le souhaitez (liberté 1). L’accès au code source étant une condition préalable pour cette liberté.
  • La liberté de redistribuer des copies afin d’aider les autres (liberté 2).
  • La liberté de distribuer des copies de vos versions modifiées aux autres (liberté 3). En faisant cela, vous permettez à l’entière communauté de bénéficier de vos modifications. L’accès au code source étant une condition préalable pour cette liberté.

freedom gif open source blogpost article de blog

                     Le libre donne des ailes.            

          « Free Freedom GIF » par madamecelebi.tumblr.com sur Giphyhttp://gph.is/1a1EJbz

L’Open Source Initiative a, quant à elle, défini 10 points à respecter⁶ :

  • La licence ne doit empêcher quiconque de vendre ou de donner le logiciel en tant que composant d’une distribution de logiciels constitués de programmes provenant de différentes sources. La licence ne doit pas exiger de droits d’auteur ou d’autres commissions sur une telle vente.
  • La licence doit permettre l’accès au code source.
  • La licence doit pouvoir autoriser les modifications et la distribution des travaux dérivés dans les mêmes conditions que la licence du logiciel original.
  • La licence doit respecter la paternité de l’auteur et en cas de modifications, celles-ci doivent être indiquées ou la licence doit porter un nom ou un numéro distinct.
  • La licence ne doit pas être discriminatoire envers certaines personnes ou certains groupes.
  • La licence ne doit pas être discriminatoire envers certains usages et certaines structures utilisant le logiciel.
  • Les droits attachés au logiciel doivent s’appliquer à tous ceux à qui le logiciel est redistribué, sans qu’il soit nécessaire d’appliquer une licence supplémentaire.  
  • La licence ne doit pas être spécifique à un produit en particulier.
  • La licence ne doit pas contaminer d’autres logiciels. La licence ne doit pas imposer de restrictions sur d’autres logiciels distribués avec le logiciel licencié. Par exemple, la licence ne doit pas exiger que tous les programmes distribués sur le même support soient des logiciels Open Source.
  • La licence doit être technologiquement neutre. Aucune disposition de la licence ne peut aller à l’encontre d’une quelconque technologie ou style d’interface.

Bien qu’il y ait quelques divergences entre les deux associations américaines, elles définissent plus ou moins la même chose, et approuvent pratiquement les mêmes licences comme libres ou Open Source⁷.
Cependant, ces licences, bien qu’étant des licences Open Source, autorisant toutes l’utilisation, la copie, la modification et la diffusion du logiciel, peuvent avoir des caractéristiques propres.

Il serait fastidieux de lister chaque licence et de soulever leurs spécificités, mais il peut être intéressant de reprendre une classification de Jim Jagielski, qui catégorisait les licences Open Source en 3 modèles⁸.

D’une part, les licences de type “Give me Credit” (Permissives) comme la licence Apache 2.0, la licence Berkeley Software Distribution (BSD-3-Clause) ou la licence Massachusetts Institute of Technology (MIT) qui n’imposent que la mention du droit d’auteur.

Par exemple, IDFOR Solutions propose sa solution KAT sous licence Apache 2.0. Cela signifie que vous avez accès gratuitement au code source de KAT, que vous pouvez le distribuer, le modifier, le commercialiser à la seule condition de mentionner notre nom. Vous pouvez ainsi distribuer KAT, KAT modifié ou intégré à un autre projet sous une autre licence et sans le code source en indiquant notre nom, conformément à l’article 4 de la licence Apache.

keep-administration-trivial-kat-logo-product-idfor

  KAT, le compagnon à quatre pattes d’IDFOR, sous licence Open Source.

 

D’autre part les licences de type “Copyleft” (Copyleft faible) comme la Mozilla Public License 2.0 ou l’Eclipse Public License qui imposent, en plus de la mention du droit d’auteur, que le logiciel ou sa version modifiée soient distribués sous cette même licence.
Par exemple, en téléchargeant le navigateur web Mozilla Firefox, vous êtes soumis à la Mozilla Public License 2.0 ce qui vous permet d’utiliser, copier, distribuer et modifier le code source de Firefox, mais aussi de distribuer vos versions modifiées, à la condition, en plus de la mention du droit d’auteur, de redistribuer le logiciel ou sa version modifiée sous cette même licence Mozilla Public License 2.0. Cependant, de nouveaux composants peuvent être ajoutés sous d’autres licences voire sous des licences propriétaires. Ainsi, la licence attachée au travail dérivé peut ne pas respecter le copyleft.
Enfin les licences de type “For lack of a better name” (Copyleft fort) comme la GNU General Public License (GPL) imposant que la redistribution du logiciel, modifié ou non, et de ses composants associés ne peut se faire que sous la licence initiale.

Par exemple, la solution Dolibarr (pour laquelle IDFOR Solutions propose son expertise) est sous licence GNU GPL, ce qui signifie qu’elle ne pourra pas être distribuée sous une autre licence que la GNU GPL tout comme son travail dérivé.

 

L’Open Source, générateur d’incompatibilités

Cette diversité de licences Open Source n’est pas nécessairement un avantage. S’il est possible de concevoir un logiciel personnalisé dont les composants sont soumis à différentes licences, il peut toutefois y avoir des problèmes de compatibilité entre ces licences lors de la distribution du code, et la réalisation de ce logiciel sur-mesure peut s’avérer être un véritable casse-tête.

Toutefois, cette compatibilité n’est qu’à sens unique.
En effet, l’association Veni, Vidi, Libri a défini la compatibilité comme “la caractéristique que possède une licence sous laquelle du code est distribué, à pouvoir intégrer ce dernier dans un projet logiciel plus grand qui sera distribué sous une autre licence”⁹.
En effet, il faut se demander si, à partir d’une licence A, il est possible de distribuer un logiciel sous une autre licence B.

Par exemple le projet Tor, acronyme de “The onion router”, est développé sous licence BSD modifiée, licence permissive imposant seulement la mention du droit d’auteur. Cela signifie, qu’à partir de cette licence BSD, vous pouvez distribuer Tor sous une autre licence, notamment sous licence GNU GPL.
En revanche, l’inverse n’est pas possible puisque la GNU GPL impose la redistribution sous cette même licence. Ainsi, si Tor était distribué sous licence GNU GPL, il vous serait impossible de distribuer le projet sous licence BSD.

L’exemple qui vient de vous être énoncé est toutefois relativement basique puisque la licence BSD semble être la plus permissive, tandis que la licence GNU GPL semble être la plus contraignante.

wildebeest gnou gnu gif idfor solutions

    Les gnous sont à la GNU GPL ce que le coq est à La French Tech !

      « Argument Crossing GIF » par 4gifs.tumblr.com sur Giphyhttps://gph.is/XLHKvs

 

Il existe des tableaux illustrant la compatibilité des différentes licences entre elles pour vous aiguiller. Cependant, comme le soulevait Mélanie Clément-Fontaine, Maître de conférences et codirectrice du Master 2 PIDAN à l’Université de Versailles-Saint-Quentin-Paris Saclay, “chaque intégration nécessite le plus souvent une analyse au cas par cas, soit que la licence est peu répandue et donc n’est pas répertoriée dans ces tableaux, ce qui n’est pas rare, soit que l’intégration entre dans un cas particulier de la licence qui appelle une interprétation plus nuancée que celle permise à partir de la lecture d’un tableau”¹⁰ (vous pouvez voir un exemple de tableau en vous rendant sur cette page).
Il y a également d’autres solutions comme le multilicenciement permettant à l’utilisateur de choisir parmi différentes licences prédéterminées.
De même, certaines licences mentionnent directement leur compatibilité avec d’autres licences au sein de clauses.
Par exemple, la licence publique de l’Union Européenne (EUPL) possède une clause de compatibilité, indiquant que “si le licencié distribue ou communique des œuvres dérivées ou des copies de telles œuvres basées à la fois sur l’œuvre et sur une autre œuvre concédée sous une licence compatible, la distribution ou la communication peut être faite aux conditions de cette licence compatible”.
Elle précise également, en appendice, les licences compatibles parmi lesquelles la GNU General Public License, l’Eclipse Public License ou encore la Mozilla Public License.

 

L’angle juridique de l’Open Source

Open Source ne signifie pas que tout est permis et que vous êtes en mesure de faire tout ce que vous souhaitez. Il y a effectivement un cadre juridique autour des logiciels Open Source, du fait de la loi, mais également de la licence qui leur est rattachée.

En effet, le logiciel Open Source est en premier lieu un logiciel, et peut donc être considéré comme une oeuvre de l’esprit au regard de l’article L.112-2, 13° du Code de la propriété intellectuelle, sous réserve de son originalité, c’est-à-dire s’il porte la marque intellectuelle de son auteur.
Il bénéficie alors d’une protection par le droit d’auteur se divisant en deux grandes catégories de droits.
D’une part les droits moraux, qui sont incessibles, inaliénables et imprescriptibles, l’auteur ne pouvant les céder ou y renoncer, qui sont :

  • le droit de divulgation permettant à l’auteur de pouvoir décider de rendre son œuvre publique ou non, ainsi que du moment et des modalités de la première communication de son œuvre ;
  • le droit de paternité permettant à l’auteur d’avoir son nom ou son pseudonyme apposé à l’oeuvre ;
  • le droit au respect de l’intégrité de l’œuvre permettant à l’auteur de s’opposer à toute modification, suppression ou ajout susceptible de modifier son œuvre initiale ;
  • les droits de retrait ou de repentir permettant à l’auteur de faire cesser la diffusion de son oeuvre, à tout moment et sans avoir à justifier son choix, en contrepartie d’une indemnisation préalable.

Et d’autre part, les droits patrimoniaux, constitués du droit de représenter l’oeuvre et du droit de la reproduire.
Les artisans des logiciels Open Source n’abandonnent pas leur droit d’auteur afin qu’ils tombent dans le domaine public, et leur usage est donc restreint.
Cependant, le droit d’auteur relatif aux logiciels a été spécialement aménagé, particulièrement au niveau du droit moral.
En effet, si les dispositions de l’article L.121-4 du Code de la propriété intellectuelle accordent à l’auteur d’une oeuvre de l’esprit un droit de repentir ou de retrait, l’article L.121-7 du même Code ne le permet pas pour l’auteur d’un logiciel, sauf arrangement contractuel.
Lorsque le logiciel a circulé de façon massive, il semble difficile d’exercer son droit de retrait ou de repentir surtout s’il faut indemniser tous les détenteurs légitimes du logiciel¹¹.
De plus, le droit au respect de l’intégrité de l’oeuvre est limité aux cas où la modification serait préjudiciable à l’honneur ou à la réputation de l’auteur.
Ce dernier droit est cependant écarté par la licence Open Source, qui autorise la modification du logiciel.

Cette licence Open Source vous engage contractuellement avec l’éditeur du logiciel.
En effet, la licence est un contrat entre le titulaire de droits de propriété intellectuelle et la personne autorisée à utiliser ces droits, gratuitement ou en contrepartie d’un paiement.
Concrètement, lorsque vous achetez un des jeux vidéos les plus vendus de l’histoire, GTA V¹², l’éditeur, Rockstar Games, vous autorise à utiliser le jeu pour votre usage personnel, mais vous interdit notamment de le vendre ou de le louer (comprenez ainsi que vous ne pouvez pas vendre le logiciel permettant l’exécution du jeu vidéo, mais vous pouvez tout à fait vendre le support physique que vous avez acquis) mais aussi de le copier ou de le modifier¹³.
La licence régit alors l’utilisation d’un logiciel par son utilisateur.
Cependant, l’exemple qui a été donné précédemment correspond à une licence dite “propriétaire”, et diffère de la licence Open Source sur différents points, que nous avons vus précédemment.

 

Épilogue

Si l’Open Source vous offre une multitude de possibilités, il faut prendre garde aux éventuelles incompatibilités entre les licences, et prendre en considération le cadre juridique qui a été installé autour de l’Open Source.

L’esprit Open Source semble se perdre selon certains, qui insistent sur le fait que les individus doivent avant tout être contributeurs plutôt que d’être de simples consommateurs des FOSS¹⁴.

Toutefois, il paraît primordial de retenir la devise sur laquelle reposent les mouvements du libre et de l’Open Source, servant notamment à Richard Stallman lorsqu’il définit les logiciels libres : “Liberté, Égalité, Fraternit锹⁵.

 

Voici un tableau présentant les différentes possibilités des licences open source

      Tableau récapitulatif des apports des licences libres/open source.

.

¹ : POSSCON, “Open Source Licenses”, 13 mai 2013, https://www.youtube.com/watch?v=FoCHY4tnERA.
² : J. T. S. Moore, “Revolution OS”, 2001.
³ : GNU Operating System, “What is free software ?”, https://www.gnu.org/philosophy/free-sw.html.
⁴ : Y. Bailly, La protection juridique des logiciels libres, Mémoire – Université Robert Schuman Strasbourg, 1999, p. 4.
⁵ : GNU Operating System, “What is free software ?”, https://www.gnu.org/philosophy/free-sw.html.
⁶ : Open Source Initiative, “The Open Source Definition”, https://opensource.org/osd.
⁷ : Open Source Initiative, “Open Source Licenses by Category”, https://opensource.org/licenses/category, GNU Operating System, “Various Licenses and Comments about Them”, http://www.gnu.org/licenses/license-list.html.
⁸ : POSSCON, “Open Source Licenses”, 13 mai 2013, https://www.youtube.com/watch?v=FoCHY4tnERA.
⁹ : Veni, Vidi, Libri, “Compatibilités de licences”, http://vvlibri.org/fr/compatibilite-licences.
¹⁰ : M. Clément-Fontaine, “ L’entreprise et l’open source : stratégie de la valorisation”, RLDI, n° 102, 1er Mars 2014.
¹¹ : M. C. Fontaine, “Creative Commons face au droit moral” in Le droit moral au 21ème siècle, s. dir. F. Brison et al., ed. Larcier, 2015, p. 201.
¹² : W. Audureau, “Quel est le jeu vidéo le plus vendu de l’histoire ?”, Le Monde, 5 fév. 2016, https://www.lemonde.fr/pixels/article/2016/02/05/quel-est-le-jeu-video-le-plus-vendu-de-l-histoire_4860322_4408996.html.
¹³ : Rockstar Games, “Accord de Licence”, 27 juil. 2018, https://www.rockstargames.com/eula?locale=fr.
¹⁴ : C. Chenet, “Les logiciels libres meurent lentement sans contributions”, 29 août 2018, Framablog, https://framablog.org/2018/08/29/les-logiciels-libres-meurent-lentement-sans-contributions/.
¹⁵ : Association Intelli’N, “RMLL 2011 – Interview de Richard STALLMAN – Créateur logiciel libre, GPL et GNU”, 12 juil. 2011, https://www.youtube.com/watch?v=Mhq_amvz_6o&t=30s
Photo d’illustration de l’article par Olia Gozha, via Unsplash.

.