Qu’est-ce qui définit les logiciels libres/l’open source ?

Le logiciel libre est le : « logiciel distribué avec l’intégralité de ses programmes-sources afin que l’ensemble des utilisateurs qui l’emploient puissent l’enrichir et le redistribuer à leur tour. Un logiciel libre n’est pas nécessairement gratuit et les droits de la chaîne des auteurs sont préservés » (Vocabulaire de l’informatique, JORF n°93 du 20 avril 2007, p. 7078, texte n°84).

Le mouvement du logiciel libre a été initié en 1983 afin de construire un système d’exploitation complet et entièrement libre compatible avec Unix (système d’exploitation) appelé GNU (« Gnu’s Not Unix »). Ses règles d’utilisation sont encadrées et formalisées dans un contrat de licence appelé la Licence Publique Générale dite GNU (GNU GPL) dont il existe des déclinaisons.

Les quatre prérogatives de l’utilisateur final du logiciel libre sont :

• Utiliser/ exécuter le logiciel
• Etudier son fonctionnement
• Le modifier via son code source rendu accessible
• Le redistribuer, et redistribuer des versions modifiées

Ensuite, le système d’exploitation non-propriétaire « Linux » a été créé et sera suivi de nombreux autres logiciels dits « open source », à code ouvert. La licence open source doit répondre à plusieurs critères. Un logiciel est considéré comme open source, au sens de l’Open Source Initiative , s’il remplit les conditions suivantes :

• Permettre la libre distribution du logiciel ;
• Mettre à disposition le code source ;
• Permettre les dérivés du logiciel ;
• Respecter l’intégrité du code source ;
• Respecter la non-discrimination entre les groupes et les personnes ;
• Respecter la non-discrimination entre les domaines d’application ;
• La licence s’applique sans obligation d’obtenir une licence supplémentaire ;
• La licence ne doit pas être spécifique à un produit ;
• La licence d’un logiciel ne doit pas s’étendre à un autre ;
• La licence doit être neutre technologiquement.

En résumé, les critères de l’Open Source Initiative sont plus nombreux que ceux de la GNU et certains critères sont identiques entre les deux.

Attention aux idées reçues

– le logiciel libre ne veut pas forcément dire gratuit. En effet, le propriétaire du logiciel peut décider de rendre payant certains services associés au logiciel, ou même d’avoir une double stratégie de diffusion en libre et en mode propriétaire avec rétribution.

– le logiciel libre ne veut pas dire libre de droits. Comme pour le logiciel propriétaire, le logiciel libre est protégé par le droit d’auteur et un utilisateur devra accepter et respecter les termes du contrat de licence. Sa particularité repose sur les droits étendus conférés aux utilisateurs et le fait que le code source du logiciel libre est rendu accessible à tous, alors que l’accès au code source du logiciel propriétaire sera modulable selon la stratégie de commercialisation.

– Il ne faut pas confondre le logiciel libre avec :

• le « freeware », logiciel propriétaire distribué à titre gratuit ;
• le « shareware », logiciel propriétaire gratuit pendant la période d’essai ;
• le « freemium », stratégie commerciale alliant accès gratuit et services complémentaires payants.

Qu’est-ce que le copyleft/la compatibilité des licences ?

Au sein des licences libres, Il existe plusieurs types de licences libres. Une distinction usuelle est faite entre les licences dites « copyleft » et les licences permissives (non copyleft).

• Les licences copyleft vont imposer aux utilisateurs subséquents à concéder systématiquement les mêmes libertés que celles qu’ils ont reçu selon un niveau variable, qui va du copyleft fort (contaminant) au copyleft dit standard (non-contaminant).
• Pour les licences permissives, il y a peu et moins d’obligation, l’obligation principale étant généralement de citer la paternité de l’œuvre.

Cette classification aide à analyser la compatibilité des licences entre elles.

Lorsqu’il y a compatibilité le code distribué sous une licence donnée pourra être intégré dans un logiciel qui sera distribué sous une autre licence, sachant que l’auteur peut changer les conditions de la licence ou y apporter des aménagements. Cela laisse donc plus de latitude sur les conditions d’utilisations et d’exploitation du nouveau code développé.

Dans une situation de copyleft fort, le nouveau code se verra à priori imposer l’ensemble des termes de la licence du logiciel préexistant, le nouveau code sera donc contaminé par les termes de la licence initiale ce qui contraindra les modalités d’exploitation et d’utilisation du nouveau code.

La difficulté de l’analyse auquel peut être confronté le développeur est d’avoir recours à des briques logiciels ayant des régimes de licence différents, ce qui peut conduire à des conflits de licence (entre logiciels libres et/ou logiciels libres et logiciels propriétaires). Leur combinaison possible ou non, demande une analyse fine et une lecture complète de leurs clauses respectives.

Pour vous aider pour une première analyse, nous avons établi un tableau comparatif des principales licences. Une bonne analyse permettra d’anticiper l’impact de l’utilisation de logiciels libres dans un projet de recherche.

Type de licence : Licence-type libre ou persistante

État du Copyleft : Copyleft fort Contaminante

Description : Toute utilisation de sources sous cette licence l’étend aux développements associés. Elle interdit l’utilisation du code source au sein d’une application propriétaire. Exemple : GPL (« GNU General Public License »), CeCILL (« Cea Cnrs Inria Logiciel Libre »). La même licence libre s’applique à toute redistribution du logiciel initial, modifié ou non, et s’étend à la distribution d’une création à laquelle il est intégré.

Compatibilité : Copyleft standard

Incompatibilité :Sans copyleft Licence propriétaire

Conseil : Cette licence est pour les logiciels à vocation académique et / ayant vocation à servir de référence 

Type de licence : Licence-type semi-libre ou diffusive

État du Copyleft : Copyleft standard

Description : Permet de redistribuer le logiciel -modifié ou non- sous la licence initiale en y a adjoignant des nouveaux éléments sous d’autres licences, voire sous-licences propriétaires. Ce sont des logiciels hybrides, modulaires, qui mêlent licences libres et propriétaires. Exemple : MPL (« Mozilla Public License »), LGPL (« Licence publique générale limitée GNU ») ou CECILL-C. Ainsi, la licence libre s’applique uniquement à la redistribution du logiciel initial et ne s’étend pas aux créations auxquelles il est intégré, et qui peuvent être redistribuées sous d’autres licences libres ou propriétaires.

Compatibilité : Sans copyleft Licence propriétaire

Incompatibilité : Copyleft fort

Conseil : Ces licences sont généralement utilisées pour les bibliothèques

Type de licence : Licence-type permissive 

État du Copyleft : Sans copyleft

Description : Peu d’obligations du licencié (surtout respect de la paternité). Compatible avec tout autre licence permissive ou propriétaire reprenant les obligations qu’elle contient. Possible de réutiliser et inclure un code sous licence permissive dans un logiciel propriétaire. Exemple : BSD («Berkeley Software Distribution »), ASF (« Apache Software Licence ») ou CeCILL-B. La redistribution du logiciel initial ainsi que des versions modifiées est libre et peut se faire sous une autre licence. Cela permet le développement d’un logiciel propriétaire à partir de ses composants.

Compatibilité : Copyleft standard, Licence propriétaire

Incompatibilité : Copyleft fort

Type de licence : Logiciel propriétaire 

Description :  Les limitations, obligations, droits sont déterminés par les ayants droits

Compatibilité : Copyleft standard Sans copyleft

Incompatibilité : Copyleft fort

Conseil : Lorsque le logiciel est au cœur de l’activité 

Quel est l’impact de l’open source sur l’exploitation du logiciel escompté / créé ?

Aussi, l’une des questions majeures à se poser lors de l’élaboration du projet est l’existence ou non d’éléments open source dans la construction du logiciel/ des logiciels au sein du projet. Il est important de les identifier précisément, c’est-à-dire de savoir quels éléments sont soumis à une licence open source.

Cela demande une transparence de toutes les parties dans un projet sur ces éléments.

Si des éléments open source/libres ne sont pas identifiés en connaissance antérieure ou si des logiciels générés dans la collaboration passent open source : Le risque est que le partenaire qui finance la collaboration puisse légitimement penser que le logiciel qui sera créé pourra être un logiciel propriétaire, alors qu’il serait en totale contradiction avec les licences open source/libres qui régissent des briques du logiciel (lorsqu’au moins deux licences des briques logicielles à inclure dans un nouveau logiciel imposent des obligations contradictoires). Un contentieux est possible (exemple : dénonciation du contrat de collaboration).

Lorsqu’il existe des briques logiciels open source/ libres, il convient d’informer les parties du projet de ce risque et en cas de présence de licences open source/ libres, il faudra vérifier la compatibilité avec la stratégie de valorisation par l’entreprise. Souhaite-t-elle exploiter les résultats du projet uniquement via une licence propriétaire ou via une licence open source/ libre ? La réponse à cette question pourra être notamment dépendante du plan de développement économique de l’entreprise

Notre conseil est de ne pas utiliser des connaissances antérieures qui ne seraient pas connues des autres partenaires d’un projet collaboratif et seraient donc sous une licence imposant au futur logiciel une licence dont le partenaire ne voudrait pas. Il faut ainsi les lister dès la phase des pourparlers et avant la mise en signature, voire dès le montage du projet. Il est donc important de connaître dès le départ ces éléments car ils peuvent énormément impacter la négociation du contrat avec le partenaire du projet.