Open source software : problématiques générales et enjeux pour l’entreprise
C’est en 1989 que la première version de la licence GNU/GPL fut publiée[1]. Depuis maintenant plus de vingt ans, elle a été corrigée plusieurs fois dans le sens d’un « copyleft » de plus en plus fort, a engendré des licences connexes[2], et ne cesse de s’adapter à l’évolution de la technique[3].
Cette évolution des textes est le reflet d’une utilisation croissante de modules logiciels open-source dans des contextes multiples: sociétés du CAC 40, PME, pôles universitaires, laboratoires de recherches, individus isolés, etc…
Il convient sans doute de préciser alors de quoi nous parlons. Un logiciel est d’abord écrit par l’Humain dans un langage technique mais intelligible pour celui qui connaît ce langage. L’ensemble de cette écriture forme le code source. Ce code source fait ensuite l’objet d’une traduction en langage binaire (une suite de 0 et de 1) afin de pouvoir être exécuté par une machine. Le code source ainsi traduit en langage binaire se nomme le code objet, ou bien le code exécutable. Traditionnellement, l’auteur et/ou le distributeur d’un logiciel ne donne accès qu’au code objet uniquement. En conséquence, le schéma « traditionnel » ne permet à l’utilisateur que l’exécution du logiciel. L’analyse des différentes fonctions et composantes du logiciel implique nécessairement l’accès au code source. C’est là le dénominateur commun à tous les logiciels open-source : un tel logiciel devrait au moins permettre – dans une licence d’utilisation du logiciel distribuée avec le logiciel - l’accès au code source par l’utilisateur pour être qualifié d’ « open-source ».
Nous nous en tiendrons à cette définition sémantique du logiciel open-source.
Il existe de nombreux termes pour désigner ce type de logiciel : open-source, logiciel libre, free software, open software. Open-source software a le mérite d’être descriptif et fonctionnel : le code source est ouvert. Cette dénomination évite également toute confusion avec la notion de gratuité, qui n’est pas nécessairement consubstantielle à la démarche de permettre l’accès aux sources.
Il existe aujourd’hui plusieurs dizaines de licences logicielles open-source. Même si chacune a sa spécificité, il est toutefois possible de distinguer deux grands types de licences open-source : les licences de type GPL[4] (General Public License) et les licences de type BSD[5] (Berkeley Software Distribution) : les deux types de licence permettent des prérogatives très importantes pour les utilisateurs. La différence se situe principalement dans les obligations que l’utilisateur s’engage à respecter lors de la distribution du logiciel: les licences de type BSD n’imposent quasiment pas d’obligation à la charge du distributeur, tandis que les licences de type GPL peuvent se révéler contraignantes. Il est donc important de comprendre que le terme « licence open-source » recouvre plusieurs réalités, ce qui peut nuire à la fluidité des relations entre les entreprises, voire au sein même des entreprises, en interne
De la distinction des droits et des obligations appliquée à l’open source software : entre opportunités techniques et difficultés stratégiques pour l’Entreprise
Les licences open source permettent à peu près toutes les mêmes droits : celui d’accéder au code source, de le modifier, et de le redistribuer (A). Mais toutes les licences ne répondent pas pour autant à la même philosophie, et cela se traduit par des obligations juridiques variées (B).
A/ Des droits toujours très étendus pour les utilisateurs : les opportunités techniques
Les droits dont peut jouir l’utilisateur d’un logiciel open source sont à peu près communs à toutes les licences qui existent. Le concept originel est de permettre à ces utilisateurs la modification du logiciel qu’ils utilisent et la redistribution de ces modifications afin d’en faire profiter une communauté d’utilisateurs.
L’exemple le plus largement connu de cette pratique – et relevant de la success story - est le système d’exploitation Linux. Cet « operating system » repose à sa création sur les contributions d’ingénieurs ou passionnés à partir du noyau originel créé par Linus Torvald. A force de retouches multiples et ouvertes, le système d’exploitation Linux devient tout à la fois plus fiable, plus résistant, et plus polyvalent que les systèmes d’exploitation propriétaires que proposent par exemple Microsoft ou Apple. Aujourd’hui, le noyau Linux (le Kernel) est intégré dans de très nombreux produits grands publics tels que les GPS, Smartphones, Set-top box, Gateways, et plus généralement ordinateurs et serveurs en tous genres.
Pour l’entreprise, la possibilité de pouvoir intégrer dans leurs produits des logiciels open sources « prêt à l’emploi » permet un gain de temps éminemment vertueux lors de la phase de conception des produits. Si l’on reprend le cas de Linux, il s’agit en général d’apporter quelques modifications mineures à un Kernel qui a déjà fait ses preuves pour l’adapter à un produit spécifique.
Il existe surtout des milliers de petits et lourds logiciels open-source dans tous les domaines, de l’application au correctif, ludique ou technique[6].
Face à un tableau aussi idyllique, pourquoi le monde n’est-il pas fait de logiciels open-source ?
B/ Des obligations très variables pour les distributeurs : les enjeux stratégiques
Nous n’avons pour l’instant fait qu’évoquer les droits relatifs aux logiciels open source. Ces droits constituent la partie la plus lumineuse du sujet. Il est facile de se montrer dithyrambique sur la question si l’on s’en tient à cette vision des choses.
Mais depuis l’avènement des Comics Marvel nous savons que « de grands pouvoirs impliquent de grandes responsabilités » ! Si l’utilisation quasi-systématique des logiciels open source procure assurément de grands pouvoirs à ceux qui savent les employer, qu’en est-il des responsabilités ?
Face à cette interrogation bien théorique, il est aisé de se contenter d’une réponse tout aussi théorique : le distributeur prend la responsabilité de respecter les obligations stipulées dans la licence.
En matière de logiciel open-source, la notion de « distributeur » doit être interprétée largement : ainsi, le fait de distribuer un logiciel open-source peut consister en l’intégration d’un tel logiciel dans un produit qui lui-même est distribué (gratuitement ou non), ou bien en la distribution du logiciel en lui-même, sous sa forme code objet ou code source. En outre, la qualité de distributeur est totalement indépendante de la notion de « public » : il suffit de distribuer le logiciel à une seule personne pour être un distributeur au sens des licences open-source et être tenu de respecter les obligations liées à la distribution du logiciel.
Les obligations inhérentes à la distribution d’un logiciel open-source sont variées ; elles peuvent consister en de simples « formalités » qui reprennent en réalité des grands principes du droit commun : respecter la paternité de l’œuvre logicielle open source[7] par exemple. Autant dire que c’est le seuil vital minimum avant que l’œuvre logicielle ne soit attribuée au domaine public ![8]
En dehors de ces obligations très importantes mais peu contraignantes, il existe aussi des licences au « copyleft » beaucoup plus prononcé. De nombreuses licences font peser sur le distributeur l’obligation de distribuer également l’ensemble des modifications effectuées et intégrées dans le code source[9]. On dit alors en général que la licence est « contaminante » : cela veut dire que si une brique logicielle propriétaire est utilisée pour modifier un logiciel opensource dont la licence est contaminante (par exemple GPLv.2), alors l’ensemble du logiciel modifié devra être distribué sous la même licence (GPL v.2 ou v.3 dans notre exemple). Cela implique de distribuer le code source d’une brique logicielle qui à l’origine était propriétaire !
On comprend dès lors la difficulté pour l’entreprise : d’une part les licences des logiciels open-source leur permettent un gain de temps et de coût de R&D important, mais d’autre part ces mêmes licences peuvent les contraindre à divulguer les résultats de leurs propres recherches et secrets techniques.
Nous n’entrerons pas pour le moment dans le détail des techniques de modification et de liens entre des logiciels open source et propriétaires. Une même technique peut avoir des conséquences juridiques différentes selon la licence en cause, pouvant aboutir à l’obligation de divulgation du code source dans son ensemble.
Une entreprise dont la valeur repose au moins en partie sur ses créations logicielles doit être en mesure d’analyser les risques et les avantages qu’elle peut tirer de l’utilisation de logiciels open-source.
Virgile Maruani publié le 03/01/2011 (Home Le Veilleur)
[1] http://www.gnu.org/licenses/gpl-1.0.txt
[2] Par exemple : http://www.gnu.org/licenses/lgpl-2.1.html
[3] Par exemple : http://www.gnu.org/licenses/agpl-3.0.html
[4] ibid
[5] http://www.freebsd.org/copyright/freebsd-license.html
[6] Pour avoir une idée de l’ampleur, voir par exemple http://sourceforge.net/
[7] Les licences étant généralement écrites en anglais c’est d’avantage la notion de « copyright » qui domine. Pour une licence open-source dont la langue officielle est le français, voir par exemple les licences dites « Cecill » : http://www.cecill.info/
[8] Pour un exemple de suite logicielle open source appartenant au domaine public : SQlite : http://www.sqlite.org/
[9] Notamment les licences GPL, LGPL, AGPL, Apache, Mozilla, public license, cecill, pour les plus connues
