Audit de licences : licences commerciales ou Open Source, un même combat ?
La gestion et l'audit de licences sont indissociables de l'usage croissant de logiciels édités par des tiers, qu'ils soient commerciaux ou open source. Le point sur les finalités différentes de ces audits et la manière de les gérer.
Face à la multiplicité de modèles de licensing, il est de plus en plus difficile pour les entreprises d'être conformes aux termes des licences de logiciels qu'elles ont souscrites, que ce soit dans le cadre de leur usage propre ou de la commercialisation de leurs produits et services. Le risque encouru est alors, classiquement, celui qui caractérise toute utilisation du logiciel en dehors des termes de sa licence : action en contrefaçon ou, alternativement, mise en conformité douloureuse. Cette menace est d'autant plus prégnante en présence de licences commerciales, celles-ci prévoient généralement au profit de la société éditrice des dispositifs d'audit et de pénalités rendant les négociations d'autant moins favorables au licencié¹.
Les pratiques abusives des uns sont hautement critiquables, la nonchalance des utilisateurs l'est presque autant. La société d'aujourd'hui permet en effet à tout un chacun de bénéficier d'une bibliothèque de logiciels colossale, mais avec comme contrepartie de respecter la propriété de ces tiers à l'origine desdits logiciels – qu'il s'agisse de solutions fermées commerciales ou encore libres et Open Source.
Ce billet cherche à faire le point sur l'exercice d'audit et de mise en conformité qui, nous semble-t-il, concerne tant les logiciels « commerciaux classiques » qu'Open Source, même si les moyens et finalités sont généralement différents. Notre observation nous amène à penser que la maturité du modèle Open Source séduit de plus en plus de sociétés qui cherchent par ce biais à fuir des dépenses de licences commerciales qu'elles peinent à réduire, mais qu'elles le font sans pleinement prendre en compte les spécificités des licences Open Source. Par manque de temps et pour ne pas risquer d'être incomplet sur un sujet à part entière, il n'évoque pas directement le Cloud et les modèles afférents, même si un certain nombre des développements abordés pourraient s'y étendre.
Le premier constat, facilement généralisable,
est que les entreprises se retrouvent confrontées, d'une part à la
rédaction trop souvent approximative ou ambiguë du contrat (souvent
contrats d'adhésion non négociables), et d'autre part à la
complexité du produit ou du modèle de licence.
En effet, en matière de licences de logiciels, la rédaction d'un contrat clair et précis est d'autant plus difficile qu'il convient de tenir compte de la technicité des produits, de leurs évolutions permanentes, ainsi que de la faible marge de négociation avec les éditeurs en situation de force. Ce, sans compter – là encore pour ce qui touche aux licences commerciales – les multiples documents et avenants qui s'ajoutent au fur et à mesure de la relation contractuelle (souvent éparpillés au sein des différents départements).
Les organisations sont ainsi contraintes de faire appel à des acheteurs combinant (ou accompagnés) des compétences techniques, métiers et juridiques, indispensables pour négocier et apprécier justement les différentes licences. Au-delà, ceux-ci doivent pouvoir reposer sur des outils permettant d'organiser, d'industrialiser et d'optimiser une telle gestion². Contrairement aux logiciels Open Source dont l'usage standard est peu problématique dans le cadre d'un SI, les solutions commerciales rendent complexe et cruciale la mesure (et l'encadrement) de l'usage interne du logiciel.
Notons à cet égard deux spécificités liées aux licences Open Source : les licences étant elles-mêmes gratuites (même si l'accès au logiciel peut être payant), elles ne nécessitent pas les validations classiques qui redirigent toutes nouvelles licences vers les services achats et/ou juridiques. Nous le verrons, l'enjeu est alors de prévoir, dans le cadre de l'usage de composants Open Source, une procédure spécifique qui assure une validation par les services compétents et une traçabilité de l'usage desdits composants. À l'inverse, les efforts d'harmonisation qui accompagnent les licences Open Source simplifient cet exercice (tel le label Open Source dès les années 2000, la mise en œuvre d'une identification unique des licences ou encore de gestion des composants tiers au sein de la chaîne d'approvisionnement au travers du projet SPDX en 2010).
Cet article aborde deux aspects bien différents de l'audit de licences, soulignant tous deux la nécessité d'y recourir de soi-même, que ce soit en organisant un audit proactif en cas d'utilisation de licences commerciales ou bien en procédant à une automatisation de l'audit s'étendant à tous les composants Open Source.
I – Usage des logiciels au sein de votre SI : pourquoi passer de l'audit subi à l'audit proactif ?
Confrontées à la nécessité de maintenir leur croissance, voire l'accroître afin de financer la R&D et rémunérer leurs actionnaires, les sociétés éditrices de solutions commerciales ont de plus en plus recours à des audits de conformité auprès de leurs clients afin de contraindre ces derniers à souscrire de nouvelles licences commerciales pour se mettre en conformité (en général au tarif public, l'addition devenant ainsi très vite salée).
Fondé sur l'usage réalisé en interne du logiciel, cet audit a vocation à contrôler le nombre de licences souscrites par la société utilisatrice et dont la tarification fixée par l'éditeur est généralement basée en fonction de la puissance machine ou du nombre de machines de l'entreprise, du nombre d'utilisateurs ou encore de la nature des droits concédés (licence d'utilisation, de développement, etc.). Chaque nouveau mode d'utilisation ou de distribution des logiciels (Cloud et SaaS notamment) entraîne un nouveau mode de calcul des redevances. Sans oublier que cela peut entraîner la coexistence au sein des entreprises clientes de plusieurs versions d'un même logiciel régies par des licences différentes. À la différence, les licences Open Source sont par définition gratuites et apportent une souplesse et une agilité bienvenues. Leurs effets peuvent néanmoins varier en fonction des modèles de distribution, ce qui impose de tracer précisément l'usage réalisé de chaque logiciel Open Source utilisé, ce que nous détaillerons dans la seconde partie.
Pour répondre à cette source d'insécurité juridique, l'entreprise doit veiller à ce que le contrat de licence (commerciale) prévoie précisément le montant des redevances initiales ou annuelles ainsi que les modalités de règlement applicables. Malheureusement, force est de constater que dans un nombre bien trop important de contrats, on ne trouve ni chiffrage ni stipulation expresse d'une méthode de calcul des redevances complémentaires exigibles en cas de régularisation. Dès lors, la base des tarifs publics trouve à s'appliquer et c'est ainsi que l'on en arrive à voir des sociétés contraintes de payer jusqu'à plusieurs millions d'euros³ au titre de la régularisation de leurs licences. Outil de pression et source complémentaire de revenus intéressante pour les éditeurs, on constate une augmentation considérable des audits réalisés en fin d'année (voir lors de la perte d'un marché) afin de contrôler la conformité de l'utilisation de leurs logiciels aux licences conclues. Désireux de combler leur manque à gagner généré par un modèle moins crise et la contrefaçon, les éditeurs voient dans ces programmes de licensing compliance⁴ la solution à leurs maux.
Ces derniers s'appuient sur leur propriétéintellectuelle, l'installation de logiciels hors cadre contractuel – par exemple en quantité supérieure à ce qui est prévu – étant constitutive d'une contrefaçon, laquelle peut être sanctionnée jusqu'à 3 ans d'emprisonnement et 300.000 euros d'amende⁵.
Les entreprises utilisatrices prennent ainsi progressivement – douloureusement – conscience des risques liés à l'utilisation de leurs logiciels, mais un décalage réel persiste entre d'une part les moyens déployés par les éditeurs pour contrôler le respect des termes de leurs licences et d'autre part, ceux mis en place par les clients pour s'assurer de ce respect. Les clients restent en effet souvent incapables de retrouver les contrats qui leur sont opposés (souvent perdus ou non archivés) alors qu'ils désirent se mettre en conformité. Indispensable, le recours à un outil d'inventaire ou de conformité logicielle n'est néanmoins pas suffisant en l'absence de processus appropriés ou d'accompagnement au changement adéquat⁶.
Il est donc primordial pour les entreprises, et plus particulièrement leurs DSI si elles en sont dotées, de repenser la gestion de leurs licences et de mettre en place un suivi de ces actifs. Qu'elle s'inscrive ou non dans un processus de certification⁷, cette gestion est indispensable afin de réduire les risques financiers encourus par l'entreprise.
Pour ces raisons et afin d'avoir une image claire
de leur situation, il est vivement conseillé de procéder à un
audit interne de leurs logiciels, lequel peut se dérouler à travers
plusieurs étapes :
- appréhension des éléments fournis : dans un premier temps, l'entreprise doit rassembler un certain nombre de données : l'ensemble des contrats, les conditions générales de vente successives, l'historique des achats, etc.⁸
- évaluation des risques dans le contexte présent : une fois les éléments à la disposition de l'entreprise réunis, il faut établir la comptabilisation précise de l'usage réel du produit ainsi qu'un bilan de conformité via l'inventaire du parc logiciel⁹ en recourant pour ce faire à des outils systèmes spécifiques permettant d'inventorier les installations logicielles.
- identification des licences et examen des contraintes associées¹⁰ : il s'agit ici de vérifier la conformité au regard des stipulations contractuelles à partir de l'étude des documents contractuels (conditions générales, conditions particulières, bons de commande, avenants, factures, etc.).
- mise en place de règles de bon fonctionnement : désignation d'une équipée chargée de s'assurer de l'utilisation conforme par les salariés des logiciels sous licences propriétaires, de les former au respect de ces règles, établissement de bonnes pratiques¹¹, inscription sur la charte informatique de l'entreprise, mise en place d'une politique d'achat pour le futur, etc.
Seule une meilleure connaissance par les entreprises de leurs logiciels peut leur permettre de rééquilibrer leurs relations avec les éditeurs et de se défendre en cas d'audit commandité par ces derniers, ce qui passe nécessairement par le contrôle du périmètre de l'utilisation logicielle et l'inventaire de l'ensemble de la documentation contractuelle applicable. En cas de risque de litige, afin de garantir le bon déroulement de l'audit et par souci de transparence, il peut être recommandé à l'entreprise de recourir à un auditeur indépendant n'ayant aucun intérêt dans l'affaire présente et bénéficiant d'une expérience réelle en matière de gestion des changements et des configurations.
L'intérêt d'un tel audit est aussi, pour les entreprises, de plus facilement comparer les diverses solutions s'offrant à elles : notamment quant à la question de continuer sur des logiciels commerciaux « classiques » (éventuellement renégociées) ou de se tourner – au moins partiellement – vers les logiciels libres et Open Source. Ces derniers offrent une liberté bien plus importante, mais entraînent de ce fait l'entreprise dans des situations qu'il lui faut aussi comprendre et gérer.
II – Usage des logiciels à d'autres fins : pourquoi automatiser l'audit de licences associées aux composants Open Source ?
En parallèle des développements qui précèdent, il est nécessaire d'aborder les risques et le contrôle nécessaire liés à l'usage de composants Open Source.
En effet, l'environnement économique difficile conjugué à ce durcissement de la relation client-fournisseur contribuent à l'orientation des entreprises vers les solutions logicielles proposées par l'Open Source. Les difficultés auxquelles elles sont confrontées (changement de stratégie d'entreprise, réduction des coûts, gestion des informations, évolution des usages...) les incitent de plus en plus à regarder si des solutions alternatives existent et permettent d'apporter des réponses satisfaisantes pour résoudre ces difficultés, minimiser les contraintes et les adhérences. De plus en plus, les logiciels libres sont envisagés comme une alternative pertinente face aux solutions propriétaires. Pour reprendre les propos du CIGREF, « l'esprit du libre » se propage dans l'entreprise¹².
Pour autant, l'usage de logiciels libres et Open Source présente aussi des avantages et des inconvénients. Les libertés offertes par ces licences Open Source ouvrent aussi de nouvelles perspectives qui dépassent le seul rôle de la DSI et qui sont conditionnées au respect de certaines conditions et obligations devant être respectées par l'entreprise sous peine d'entraîner larésiliation automatique de la licence.
Parmi les bénéfices déjà évoqués lors des développements relatifs aux licences commerciales classiques, notons la disparition de la plupart des contraintes citées : les entreprises n'ont plus à tenir compte de la puissance de leurs machines ou du nombre d'utilisateurs des logiciels, etc. Les licences Open Source opérant une cession des droits très large incluent tous ces usages sans fixer de seuil d'utilisation – facilitant ainsi la réutilisation et le déploiement des logiciels au sein d'une même structure ou d'un même groupe. Cela est consubstantiel à la qualité de logiciel Libre/Open Source : en vertu de l'Open Source Definition (OSD), pour que le logiciel puisse être qualifié comme tel, il doit remplir au moins dix critères¹³. Trois de ces critères peuvent être évoqués : le 3e critère, selon lequel les dérivés des œuvres sont permis ; le 5e relatif à l'absence de discrimination entre les personnes ou les groupes (en vertu duquel toute personne détentrice d'une copie du logiciel bénéficie des termes de la licence tant qu'il s'y conforme lui-même) ; ou bien encore l'absence de discrimination entre les domaines d'application (6e critère en vertu duquel la licence se limite à la propriété intellectuelle et ne peut pas réguler de domaine politique).
Ainsi, l'usage standard de logiciels Open Source dans le cadre d'un SI peut être une vraie source de souplesse et d'économie pour l'organisation (rendant à cet égard la transition au profit de l'Open Source d'autant plus simple puisque les seuls coûts de licences résiduels diminuent au fur et à mesure de cette adoption) et la mise en place d'une politique Open Source (et de validation des licences Open Source) à l'échelle du groupe au sein de la DSI se traduira donc quasi-systématiquement par une autorisation par principe de la plupart des logiciels libres.
Les licences Open Source sont néanmoins parfois aussi une source de rigidité compte tenu de la faible marge de négociation possible avec l'éditeur d'un logiciel Open Source (s'il existe) compte tenu des engagements auxquels celui-ci est lui-même soumis vis-à-vis des composants que sa solution utilise¹⁴.
Dans de plus rares cas, les licences peuvent aussi être jugées comme insuffisamment sécurisées juridiquement (citons les licences Beerware, DWTFYW, « shall be used for Good, not Evil », etc.)¹⁵. Par ailleurs, l'entreprise utilisatrice de tels logiciels (ou ses développeurs) peut être tentée par les autres libertés qui lui sont offertes par la licence (notamment celles de modifier et redistribuer le logiciel – modifié ou non) et elle devra alors gérer plus finalement le comportement attendu par chaque licence Open Source dans ce contexte afin de continuer à bénéficier des droits.
Enfin, l'un des autres effets de bord qu'entraîne cette grande liberté est, pour continuer à maîtriser le système d'information au sein de l'établissement, l'organisation d'une veille relative aux différents logiciels utilisés (notamment en termes de sécurité et de fonctionnalités) et le besoin de rationaliser ces usages pour éviter une trop grande dispersion en raison de versions utilisées qui rendrait la maintenance très difficile (ces différentes activités de veille, maintenance, etc. sont très souvent déléguées dans le cadre de grandes institutions ou grands groupes). Le rôle de la DSI en devient d'autant plus central.
Enfin, dès lors que l'usage du logiciel « sort » de l'organisation et que le logiciel, modifié ou non, est distribué à des tiers (voire simplement que des tiers interagissent avec ce logiciel), alors les licences Open Source imposent un comportement précis (chaque licence imposant ses propres règles : transmission du code source, mentions de paternité, différenciation des modifications, etc.)¹⁶. Dans une telle hypothèse, qui concerne plus la R&D que la DSI (mais les deux départements doivent ici travailler de concert), il devient nécessaire de procéder à un audit dédié listant les composants Open Source utilisés, s'appuyant sur l'architecture du logiciel et la typologie des relations existantes entre chaque composant. Un tel travail pourra se prolonger par un examen de conformité et risques relatifs à l'utilisation de ces éléments, et permet à l'organisation de tirer les contraintes associées aux licences ainsi que les actions nécessaires pour s'y conformer.
Conclusion – Automatiser l'audit de licences
Finalement, que l'on soit en présence de licences Open Source/libres ou commerciales, la connaissance des contrats est indispensable. L'audit constitue une étape nécessaire à l'identification des risques encourus par l'entreprise, que ceux-ci soient présents dès l'utilisation du logiciel (pour les licences commerciales) ou bien qu'ils apparaissent au moment de la distribution (pour les licences Open Source).
L'audit des licences va permettre à l'entreprise d'acquérir une compréhension profonde des éléments contractuels. Grâce à cela, elle sera à même d'identifier les problèmes relatifs à la gestion des droits d'auteur (détection des installations sauvages de logiciels sur les postes de travail et utilisation de logiciels au-delà du périmètre de la licence) et procéder à la régularisation de sa situation auprès de l'éditeur sans se voir astreinte à lui régler une somme astronomique au titre de la régularisation.
C'est en s'astreignant à une gestion rigoureuse de leur parc logiciel que les entreprises seront le plus à même de parer tout litige afférent à leurs licences. Non à l'audit subit, oui à l'audit proactif !
Benjamin Jean (CEO) & Caroline Pépin (Juriste)
1 Ainsi, dans le cadre de la décision du TGI de Paris du 6 novembre 2014, l’AFPA reprochait l'usage des audits par Oracle « en les détournant de leur objectif, afin de faire pression sur l’AFPA pour la dissuader de faire appel à un concurrent au moment des périodes de renouvellement contractuel, ce afin de restreindre la concurrence sur le marché des solutions SGF et sur le marché connexe des SGBDR, ces pratiques ayant pour objet ou pour effet de restreindre la concurrence au sens des dispositions des articles L.420-2 du Code de commerce (…). »
2 Tels que le Software Asset Management, ou encore OCS Inventory NG.
3 Voir le rapport intitulé 2013-14 Key trends in software pricing and licensing survey : software license audits : costs & risks to enterprises, Flexera Software. A titre d'exemple, en 2012, Oracle a réclamé 1,5 millions d'euros à l'office régional bruxellois de l'emploi (Actiris) ; 13,5 millions d'euros à l'AFPA (déboutée par le TGI de Paris le 6 novembre dernier, en cours d'appel).
4 Programmes visant à contrôler le respect des conditions de leurs produits et à identifier les utilisations susceptibles de générer des redevances complémentaires.
5 Article L335-3 du Code de la propriété intellectuelle.
6 Ce d'autant plus que s'il existe des outils de gestion de licence tel que le Software Asset Management, leur compréhension n'est pas aisée, d'où la nécessité de recourir à un acteur indépendant possédant les compétences requises.
7 Normes ISO 19 770 (exemple).
9 Inventaire qui devra être tenu à jour par la suite afin d'anticiper d'éventuelles régularisations.
10 La lecture des licences doit permettre d'identifier les logiciels concernés et les droits de propriété intellectuelle ainsi que les droits d'utilisation associés.
11 Bonnes pratiques pouvant être basées à partir de ITIL (Information Technology Infrastructure Library), référentiel de "bonnes pratiques", voir ici.
12 Cigref réseau des grandes entreprises, Maturité et gouvernance de l'Open Source- la vision des grandes entreprises, mars 2011, voir ici.
13 Pour sa part, la Free Software Foundation (FSF) se fonde sur quatre critères (ou libertés fondamentales) pour reconnaître la qualité de libre à un logiciel. Voir ici.
14 Cela dit, la négociation avec les éditeurs commerciaux est généralement très mince aussi pour d'autres contraintes, généralement commerciales voire administrative.
15 Ces exceptions font néanmoins figurent d'exception et il ne reste plus à notre connaissance de juristes compétents qui mettraient en doute la validité des licences Open Source dans leur globalité.
16 Il y a aussi certains risques propres aux libertés que confèrent ces licences : en offrant des autorisations très larges sur le composant (permettant notamment la modification et la création de solutions composites), elles génèrent des situations où la combinaison de créations réuni une multitude de titulaires de droits. Certaines licences dites « copyleft », qui imposent le maintien de la licence lors de la diffusion du composant initial ou de ses versions dérivées, peuvent engendrer des situations d'incompatibilités empêchant toute distribution sans violer au moins l'une des licences.