Responsabilité et Licences Libres
 

Like this? Share it with your network

Share

Responsabilité et Licences Libres

on

  • 376 views

Toutes les entreprises utilisent aujourd’hui au moins en partie des logiciels libres, notamment pour leurs avantages que sont la gratuité, la fiabilité et le code source ouvert. Mais du fait de ce ...

Toutes les entreprises utilisent aujourd’hui au moins en partie des logiciels libres, notamment pour leurs avantages que sont la gratuité, la fiabilité et le code source ouvert. Mais du fait de ce libre accès, de nombreux risques existent, et peuvent affecter toute une organisation. Quelles sont alors les responsabilités juridiques attribuées à l’utilisateur, au distributeur, au sous-traitant et à l’intégrateur ?

Statistics

Views

Total Views
376
Views on SlideShare
319
Embed Views
57

Actions

Likes
0
Downloads
11
Comments
0

2 Embeds 57

http://www.zdnet.fr 55
http://www.hyang.dev.zdnet.fr 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Responsabilité et Licences Libres Document Transcript

  • 1. responsabilité ET licences libres
  • 2. 2 Responsabilité et licences libres Ouvrage réalisé par l’Agence pour la Protection des Programmes sous la direction de Raphaël d'Assignies, Président et de Mélaine Lecardonnel, Responsable du service juridique.
  • 3. 3 introduction 09 DÉFINITION RAPIDE DES LICENCES LIBREs 15 ■■ La qualification de contrat d’adhésion ■■ La possibilité de redistribuer l’œuvre ■■ Le respect de la paternité de l’œuvre ■■ L’exclusion ou la limitation des garanties et de la responsabilité 1ère PARTIE Analyse juridique des licences libres : obligations et responsabilités 19 LES LICENCES LIBRES, SOURCES D’OBLIGATIONS 21 ■■ L’obligation d’information ■■ L’obligation de mise à disposition des codes sources LES LICENCES LIBRES, SOURCES DE RESPONSABILITÉ 27 ■■ Responsabilité de droit commun ■■ Responsabilité du fait des produits défectueux ■■ Garantie d’éviction ■■ Garantie des vices cachés SOMMAIRE
  • 4. 4 2ème PARTIE Analyse PRATIQUE DE LA RESPONSABILITÉ LORS DU RECOURS à DES LICENCES LIBRES 37 RESPONSABILITÉ EN CAS D’INCOMPATIBILITÉ ENTRE LES LICENCES LIBRES 39 ■■ Les responsabilités en jeu ■■ Quelques bonnes pratiques à mettre en place RESPONSABILITÉ EN CAS D’ABSENCE DE MISE à DISPOSITION DES SOURCES 45 ■■ étendue de l’obligation de mise à disposition des sources ■■ La mise à disposition des sources en pratique ■■ Les risques en cas de non-respect de l’obligation de mise à disposition des sources ■■ Quelques bonnes pratiques à mettre en place ■■ Pour aller plus loin RESPONSABILITÉ EN CAS DE DÉFAILLANCE DU LOGICIEL 58 ■■ Intégration d’un composant libre dans une solution plus complexe ■■ Le cas des sous-traitants ■■ Quelques bonnes pratiques à mettre en place DIFFICULTÉS LIÉES À LA MISE EN ŒUVRE PRATIQUE DE LA RESPONSABILITÉ 64 ■■ Téléchargement direct du composant libre ■■ Identification des utilisateurs ■■ Bonnes pratiques - fournisseurs ■■ Bonnes pratiques - utilisateurs
  • 5. 5 Quelle entreprise, quelle administration n'utilise pas aujourd'hui de logiciels libres ? Ils recèlent de nombreux avantages : généralement gratuits, ils sont souvent fiables et ouverts. Mais le recours à ces composants open source n'est pourtant pas sans risque du fait de la particularité de leurs licences. On oublie, par ailleurs, trop souvent que ces produits restent des programmes informatiques susceptibles de comporter des défaillances pouvant entraîner des dommages. Pour la première fois, une étude aborde, de manière globale, la question de la responsabilité liée aux logiciels libres que ce soit celle de l'utilisateur, du distributeur, du sous-traitant ou de l'intégrateur. Ce livre blanc s'intéresse aux implications juridiques du recours aux logiciels open source. Trop nombreux sont ceux qui ignorent encore les règles du jeu et s'exposent à des procédures judiciaires. Car la licence libre est avant tout un contrat dont il faut respecter les clauses. Quelques décisions de justice intervenues en France rappellent en effet que le risque est bien réel. AVANT-PROPOS
  • 6. 6 Cette étude expose ainsi les obligations spécifiques des licences open source dont le non-respect peut engager la responsabilité : l'absence de mise à disposition des codes sources, les problèmes de compatibilité entre licences libres mais aussi avec des logiciels propriétaires, le caractère « contaminant » de la licence GPL, etc. De façon plus originale, cet ouvrage aborde la question de la responsabilité de droit commun qui s'applique également aux logiciels libres : validité des clauses exonératoires ou limitatives de responsabilité, garantie d'éviction et des vices cachés, responsabilité du fait des produits défectueux, etc. Ce document ne se contente pas d'un exposé théorique sur les cas de responsabilité, il propose, témoignages à l'appui, quelques bonnes pratiques à mettre en place.
  • 7. 7 La France représente le premier marché européen pour le logiciel libre1 . L’engouement des sociétés françaises repose notamment sur les économies générées par le recours aux logiciels libres. En effet, on estime qu’unelignedecodepropriétairedébuguée,documentée et faisant l’objet d’une maintenance coûte entre 13 et 19 dollars2 . Or, dans la majorité des cas, les œuvres sous licence libre sont diffusées gratuitement3 . Mais cette gratuité n’est pas automatique4 et peut n’être qu’apparente5 . L’aspect financier n’est pas la seule raison du recours des entreprises aux logiciels libres. Elles comptent également sur la fiabilité supposée de ces produits. Leurs codes sources étant ouverts, la communauté des développeurs peut les tester et les débuguer. Il faut cependant nuancer cette affirmation. Elle est surtout vraie pourleslogicielslibreslespluspopulairesauseindelacommunauté du libre. Un logiciel inconnu ne bénéficie pas d’un tel suivi. En cas de bug, l’utilisateur se retrouvera seul face au code défectueux et devra soit engager des frais de développement pour sous-traiter le débogage à un tiers, soit affecter un ou plusieurs salariés à la résolution du problème, soit dégager de son propre temps pour effectuer cette tâche. INTRODUCTION
  • 8. 8 Le choix de distribuer des logiciels libres doit être réfléchi car il engage la responsabilité du fournisseur de la solution en cas de dysfonctionnement. Qui est responsable en cas de bug du logiciel libre entraînant un arrêt de l’activité de l’utilisateur pendant plusieurs jours ? La présence de composants libres se multiplie au sein de systèmes plus complexes comme des centres de commandes, des outils de production technique… En plus d’un arrêt de la productivité du client, ces défaillances peuvent causer des dommages matériels, voire humains. Les conséquences sont potentiellement très lourdes. L’identification du responsable sera donc un enjeu majeur. Afin de prévenir tout défaut de fonctionnement d’un logiciel libre, il est vivement conseillé de s’appuyer sur la communauté du libre à l’aide des forums dédiés par exemple. Il est également possible de souscrire des solutions d’assurance ou de maintenance. Les utilisateurs peuvent également voir leur responsabilité engagée en cas de redistribution du logiciel libre. Quels sont les risques judiciaires et financiers s’ils ne respectent pas les obligations liées à la redistribution d’un composant libre ? Le non-respect des licences libres constitue une atteinte aux droits des auteurs initiaux. Un logiciel libre est reconnu comme sûr et pérenne : d’une part, le fait que le code source soit accessible permet à l’ensemble de la communauté de déceler les failles de sécurité rapidement ; d’autre part, si par malheur la communauté d’un logiciel venait à disparaître, l’utilisateur aura toujours la possibilité de le faire évoluer pour ses propres besoins. Il faut néanmoins savoir faire les bons choix lorsqu’on utilise un logiciel libre. Il est préférable d’opter pour un logiciel soutenu par une communauté dynamique, capable de faire évoluer le produit. D’ailleurs, nous pouvons remarquer qu’un mauvais produit aura une communauté faible et disparaîtra rapidement, alors qu’un bon produit aura une communauté étendue et très dynamique. Pascal HATÉ, directeurassocié,Merethis(éditeuropensourcedelasuitedelogicielsdesupervisionCentreon)
  • 9. 9 Une œuvre diffusée sous licence libre ne tombe pas dans le domaine public. Elle est toujours protégée par le droit d’auteur si elle remplit les conditions posées par le code de la propriété intellectuelle. En choisissant d’accorder de larges autorisations aux utilisateurs, l’auteur n’a fait qu’user de ses prérogatives. L’emploi de l’adjectif «libre» entretient la confusion, qui est faite dans l’esprit d’un grand nombre d’utilisateurs, entre les œuvres diffusées sous licences libres et les œuvres libres de droits. Ainsi, tout non-respect des termes de la licence engage la responsabilité de l’utilisateur qui peut être assigné en justice par les auteurs du logiciel. C’est un risque qui doit être vraiment pris en compte par les entreprises. Ces dernières doivent donc s’assurer que les termes des licences des logiciels qu’elles vont utiliser sont compatibles avec l’exploitation qu’elles envisagent pour leur solution finale. De nombreuses assignations en justice ont eu lieu aux Etats-Unis, mais aussi en Allemagne par exemple, à l’égard de sociétés qui ne respectaient pas les conditions de diffusion imposées par les licences libres des composants intégrés à leur produit final. Généralement, des transactions ont lieu pour résoudre ces conflits. Cependant malgré l’absence de condamnation, la société utilisatrice a subi des dommages financiers (coût de la procédure, montant de la transaction, absence de commercialisation pendant un temps donné…) mais également des dommages en termes d’image. Il est donc important de savoir sur qui porte la responsabilité en cas de non-respect des termes de la licence, notamment lorsque la société a fait appel à un sous-traitant. Si son client se retourne contre lui, le sous-traitant bénéficie-t-il de moyens d’exonération ? De la même manière, l’intégration de plusieurs logiciels diffusés sous des licences libres incompatibles entre elles peut conduire à une impossibilité d’exploiter le produit final.
  • 10. 10 Cette situation peut notamment concerner une société ayant acquis le patrimoine immatériel d’une autre entreprise. Peut-elle voir sa responsabilité engagée si elle commercialise un des produits concernés ? Quels sont les moyens dont elle dispose pour éviter cette situation ? De même, une société ayant fait appel à un sous- traitant peut se retrouver dans le même genre de situation et ne pas pouvoir exploiter son produit. Quels risques encourt-elle si elle passe outre ? Peut-elle se retourner contre son sous-traitant si elle a délégué le développement ? De quels moyens ce dernier dispose-t-il pour s’exonérer de toute responsabilité ? Recourir à des composants diffusés sous licence libre nécessite une phase préalable de définition des besoins et de détermination descontraintesacceptablesdanslecadred’uneexploitationfuture: l’entreprise est-elle prête à diffuser les codes sources du composant, mais aussi des modifications qu’elle aura effectuées, voire de la solution informatique finale dans sa globalité ? Les obligations générées par les licences libres sont-elles compatibles avec le projet d’exploitation du produit fini ? De même, en cas de recours à plusieurs composants distribués sous différentes licences libres, il est indispensable de vérifier la compatibilité de ces licences entre elles afin de ne pas bloquer toute exploitation. Il est également important de s’assurer de la présence ou non de composants diffusés sous licence libre au sein d’un logiciel avant de le commercialiser. En cas de non-respect des termes de la licence, l’entreprise ne pourra pas invoquer le fait qu’elle n’était pas informée de l’intégration de ces composants pour s’exonérer de toute responsabilité si ce sont ses salariés qui en sont à l’origine.
  • 11. 11 Un travail de sensibilisation du personnel est donc nécessaire. La question de la responsabilité ne concerne pas seulement l’utilisateur des composants sous licence libre ou le sous-traitant qui les intègre. Les fournisseurs de logiciels libres sont également concernés. La validité des clauses exclusives de responsabilité présentes dans les licences libres est sujette à caution. Il n’est pas exclu que leur responsabilité soit engagée en cas de défaillance du composant qu’ils ont fourni. Il leur appartient alors de prouver que ce n’est pas leur composant qui est à l’origine du problème mais, soit les modifications apportées par l’utilisateur ou l’intégrateur, soit les développements auxquels a été intégré leur produit. Des solutions existent pour les aider à se protéger mais elles doivent êtrelerésultatd’unedémarchepréventivecommecelaseraexpliqué dans ce livre blanc. Le but de cet ouvrage est de sensibiliser les professionnels à la nécessité de prendre en compte l’incidence que peut avoir le recours aux licences open source sur leur éventuelle responsabilité vis-à-vis des auteurs initiaux mais aussi de leurs utilisateurs. De plus en plus de sociétés ont recours, consciemment ou inconsciemment6 , à des composants logiciels sous licence open source. Le fait d’intégrer des briques dites libres au sein de leur produit engendre des obligations et est susceptible de faire naître des responsabilités, d’autant plus que les produits au sein desquels sont implémentés ces composants logiciels sont de plus en plus spécifiques et pointus. Afin de profiter pleinement de l’opportunité que représente l’explosion du libre, il est impératif de prendre quelques précautions. C’est dans cet objectif que nous avons pensé ce livre blanc.
  • 12. 12 définition rapide des licences libres Avant d’aborder pleinement la question de la responsabilité, il est important de revenir sur la définition des logiciels libres. En effet, cette expression est souvent utilisée mais il n’est pas certain que tout le monde sache ce qu’elle recouvre. Un logiciel libre est un logiciel distribué à l’aide d’une licence dite libre. On s’accorde à dire qu’une licence revêt cette qualification dès lors qu’elle offre les quatre libertés mises en avant par la Free Software Foundation (FSF)7 : ■■ la liberté d’exécuter le programme, ■■ la liberté d’étudier le fonctionnement du programme, et de l’adapter, ■■ la liberté de redistribuer des copies, ■■ la liberté de distribuer des copies du programme modifié. Toutes les licences libres ont cinq points communs qui peuvent être mis en évidence :
  • 13. 13 La qualification de contrat d’adhésion Un contrat d’adhésion est un contrat dont les clauses ne peuvent pas être négociées par l’une des parties. Celle-ci n’a pour seule liberté que de les accepter ou de les refuser. C’est le cas des licences libres. En effet, lorsqu’un utilisateur veut modifier ou redistribuer une œuvre sous licence libre, il doit accepter les termes de cette licence. Il ne peut pas les négocier. S’ils ne lui conviennent pas, il ne peut que les refuser. Il ne pourra alors pas modifier ou distribuer l’œuvre en cause. Cette particularité définit les contrats d’adhésion : l’une des deux parties ne peut pas discuter les clauses qui lui sont soumises. Elle ne peut que les accepter ou les refuser dans leur globalité. Bien que cette qualification concerne principalement l’utilisateur, l’auteur se trouve souvent dans une situation similaire lorsqu’il a re- cours à des licences libres. En effet, s’il désire diffuser son œuvre dans ce cadre, sa liberté ne porte que sur le choix du contrat : GNU-GPL, Creatives Commons, Art Libre… Une fois celui-ci choisi, il ne pourra pas en modifier une clause8 . Il devra l’accepter dans son intégralité. S’il le désire, il peut rédiger sa propre licence libre. Dans ce cas, il sort de l’esprit commu- nautaire qui sous-tend le mouvement du libre et perd les garanties apportées par cette assimilation à un groupe bénéficiant d’une cer- taine notoriété et ayant fait preuve de sérieux. Les licences libres sont donc des contrats génériques qui s’imposent à la fois aux auteurs et aux utilisateurs. La possibilité de redistribuer l’œuvre Les licences libres n’imposent pas aux utilisateurs de redistribuer l’œuvre mais elles leur offrent toutes la possibilité de le faire. Cette faculté est encadrée par les termes de la licence qui peuvent impo- ser que toute redistribution se fasse sous les mêmes conditions que la distribution initiale. Cela signifie que l’utilisateur devra diffuser l’œuvre, modifiée ou non, en utilisant la même licence. C’est ce qu’on appelle le «copyleft».
  • 14. 14 On parle de «copyleft fort» lorsque la licence contamine toute création à laquelle le composant libre est intégré. La redistribu- tion de l’ensemble doit se faire sous cette licence. Il existe des licences ayant un «copyleft faible». Dans ce cas, la licence ne contamine pas le reste de la solution à laquelle est intégré le com- posant libre. Seul ce dernier doit continuer à être distribué sous cette licence. L’effet contaminant ne concerne que ses modifications. La licence doit également s’appliquer aux versions modifiées du composant. Enfin, certaines licences libres sont «sans copyleft». Cela signifie que l’utilisateur peut redistribuer le logiciel sous la licence qu’il désire (y compris une licence propriétaire). Le respect de la paternité de l’œuvre Lorsqu’il redistribue l’œuvre, l’utilisateur s’engage à ne pas effacer les mentions concernant l’auteur initial ainsi que les auteurs des modi- fications successives s’ils sont mentionnés dans la licence ou sur la création. Il doit également clairement identifier les éléments qu’il a transformés. Ces exigences sont une application du droit moral que détient tout auteur sur son œuvre. En effet l’article L.121-1 du code de la propriété intellectuelle accorde aux auteurs un droit de paternité qui ne peut pas être cédé et qui est transmis aux héritiers en cas de décès. L’absence d’exclusivité Une licence libre ne peut pas être exclusive sinon elle ne répond plus à l’objectif que tendent à atteindre les promoteurs du libre. Les œuvres distribuées de cette façon sont «offertes» à la communauté afin qu’elle se les accapare et les fasse vivre. Accorder une exclusivité sur une création empêcherait ce processus collectif de s’accomplir. D’ailleurs aucune licence libre ne contient de clause d’exclusivité et il n’est pas possible d’en insérer une, les termes de ces contrats ne se négociant pas. L’exclusion ou la limitation des garanties et de la responsabilité Chaque licence libre contient une clause de limitation de garantie et de responsabilité. Elle fait partie de ce que Benjamin Jean nomme le « socle minimal » de ces contrats9 .
  • 15. 15 1H.ALTERMAN,F.PERBOSTetA.WALTER,CompréhensionetreconnaissancedumodèleOpenSourceparlestribunauxfrançais, RevuedeJurisprudenceCommerciale,Janvier/Février2011,N°1,p.31. 2 BlackDuck,TheBusinessCaseforAutomatingOpenSourceCodeManagement,p.3. 3 Encesens,voirV.-L.BENABOUetJ.FARCHY,Lamiseàdispositionouvertedesœuvresdel’esprit,RapportduConseilSupérieur de la Propriété Littéraire et Artistique, juin 2007 [en ligne]. Disponible sur http://www.cspla.culture.gouv.fr/CONTENU/misea- diposouverterapp.pdf,p.5. 4 Contrairementàuneidéerépandue,ilestpossibledegénérerdesbénéficesavecdesproduitssouslicencelibre.Cettecroyance vientdufaitquedanslespaysanglophones,leslogicielslibressontappelés«freesoftware».Al’instardel’adjectiffrançaisquia été appliqué aux licences, le terme «free» a été utilisé pour qualifier les contrats qui accompagnent la diffusion de ces œuvres. Il setraduitpar«libre»maisaussipar«gratuit»,cequiapermisàl’idéeselonlaquelleunecréationsouslicencelibreestforcément gratuitedeperdurer.Maiscen’estpasdanscesensqu’ilfautcomprendrel’adjectif«free».Seulelaréférenceàlanotiondeliberté doitêtreretenue.C’estd’ailleurscequepréciselepréambuledelatroisièmeversiondelalicenceGNU-GPL:« Whenwespeakof freesoftware,wearereferringtofreedom,notprice». 5 La création ainsi mise à disposition peut être un produit d’appel vers d’autres produits ou services. Elle peut nécessiter un accompagnementtechniquepayant. 6Ilarrivequecertainssalariésintègrentdescomposantslogicielssouslicenceopensourcesanslementionner. 7 La Free Software Foundation a été fondée en 1985 par Richard Stallman. Elle se présente comme un organisme ayant pour mission de promouvoir à travers le monde la liberté des utilisateurs d’ordinateur et de défendre les droits des utilisateurs de logicielslibres.Pourdesinformationsplusdétaillées,voirwww.fsf.org. 8 La GNU General Public License commence ainsi : « Everyone is permitted to copy and distribute verbatim copies of this license document,butchangingisnotallowed». 9 B. JEAN¸ « Option Libre » : compatibilité entre contrats, Mémoire de Master II Recherche mention Droit des Créations Imma- térielles, Université de Montpellier I, 2006, p.18. Benjamin Jean est cofondateur et président de la société Inno³, qui propose notamment un accompagnement dans la mise en œuvre de politique Open Source, il est par ailleurs consultant pour le cabinet GillesVerckenetenseignelapropriétéintellectuelleàSciencesPo.
  • 16. 16 1ère PARTIE Analyse juridique des licences libres : obligations et responsabilités
  • 17. 17 Tout comme les contrats dits propriétaires, les licences libres engagent les parties qui contractent. Il en résulte une série d’obligations dont certaines sont spécifiques à ce type de contrat, comme l’obligation de mettre à disposition les codes sources. D’autres obligations sont en apparence communes aux contrats propriétaires et aux licences libres mais, en pratique, leur incidence varie selon la nature du contrat. C’est le cas de l’obligation d’information. L’OBLIGATION D’INFORMATION L’obligation d’information à laquelle est soumis le fournisseur d’un programme informatique est généralement détaillée en trois sous- obligations : ■■ une obligation de renseignement qui consiste à fournir au client les informations et les éléments nécessaires au bon fonctionnement du programme informatique  de manière compréhensible. Cela peut porter sur l’environnement bureautique nécessaire, sur les fonctionnalités, sur la notice d’utilisation, sur le délai de livraison de la dernière version ; LES LICENCES LIBRES, SOURCES D’OBLIGATIONS
  • 18. 18 ■■ une obligation de mise en garde qui vise à attirer l’attention du client sur les risques liés à l’utilisation ou à l’installationduprogramme.Eneffet,lamutationdel’ensemble des postes de travail d’un applicatif à un autre peut avoir des conséquences fâcheuses comme la perte de données. La mise en garde peut également porter sur la nécessité de former le personnel à ce nouvel applicatif ou sur l’incidence de celui-ci sur l’organisation du travail au sein de la société ; ■■ une obligation de conseil qui vise à s’assurer que le produit correspond bien aux besoins du client. Elle répond à l’obligation du client de collaborer avec le fournisseur dans la définition de ses besoins. L’objectif de l’obligation d’information est de rééquilibrer la relation entre le fournisseur professionnel et le client non rompu à l’informatique. Son intensité varie donc en fonction des aptitudes connues du client. Elle sera moins forte s’il s’agit d’une société dont l’activité est en relation avec l’informatique. En revanche, elle sera importante si le fournisseur se trouve face à un novice en matière informatique. Elle varie également selon la nature du programme informatique. Elle sera plus importante lorsque le client commandera un logiciel spécifique que lorsqu’il achètera un progiciel. En ce qui concerne l’objet de cette étude, l’obligation d’information peut être source de responsabilité lorsque le fournisseur devra livrer un logiciel spécifique au sein duquel il aura intégré des composants open source. D’un point de vue théorique, les conséquences de cette obligation sont relativement les mêmes que pour un logiciel propriétaire. Néanmoins, certaines licences insistent sur cette obligation. Ainsi, le préambule de la licence CeCILL dispose que « l’attention de l’utilisateur est attirée sur les risques associés au chargement, à l’utilisation, à la modification et/
  • 19. 19 ou au développement et à la reproduction du logiciel par l’utilisateur étant donné sa spécificité de logiciel libre, qui peut le rendre complexe à manipuleretquileréservedoncàdesdéveloppeursoudesprofessionnels avertis possédant des connaissances informatiques approfondies. Les utilisateurs sont donc invités à charger et tester l’adéquation du logiciel à leurs besoins dans des conditions permettant d’assurer la sécurité de leurs systèmes et/ou de leurs données et, plus généralement, à l’utiliser et l’exploiter dans les mêmes conditions de sécurité ». D’un point de vue pratique, cette obligation d’information est essentielle au sein des licences libres. Elle est d’ailleurs au cœur d’une des décisions des tribunaux français relatives aux logiciels libres. Il s’agit du jugement rendu le 28 mars 2007 par le TGI de Paris10 . En l’espèce, une société avait fait réaliser un logiciel destiné à une commercialisationsousunmodepropriétaire.Maislesdéveloppeurs avaient utilisé comme sous-bassement au programme un logiciel libre sous GNU-GPL. L’éditeur demandait la résolution du contrat aux torts exclusifs de l’équipe de développement car il ne pouvait pas commercialiser le programme final sans dévoiler le code source du logiciel libre a minima, voire sans dévoiler l’intégralité des sources en cas d’effet contaminant. Les juges n’ont pas accédé à cette demande et ont prononcélarésolutionauxtortspartagésdesdeuxparties.Ilsjustifient leur décision par le fait que l’éditeur avait été prévenu de la présence de ce logiciel libre. A contrario, on peut en déduire une obligation d’information qui pèse sur les développeurs. Ils doivent signaler à leurs clients qu’ils utilisent un tel programme. S’ils omettent cette démarche, ils engagent leur responsabilité et risquent une résolution du contrat de développement et de cession à leur tort exclusif ainsi qu’une condamnation à payer des dommages et intérêts. 10 TGI Paris, 28 mars 2007, Educaffix / Cnrs, Université Joseph Fourier et autres, Expertises des systèmes d’information n°315, juin2007.
  • 20. 20 L’OBLIGATION DE MISE à DISPOSITION DES CODES SOURCES La mise à disposition du code source est l’une des obligations contractuelles la plus importante des licences libres. Dès lors que l’utilisateur veut redistribuer sa création, il doit permettre à ses futurs utilisateurs d’accéder au code source. Ce faisant, il devient fournisseur. De la même manière, si l’utilisateur initial a intégré un composant open source ou a adapté un logiciel open source, il a dû avoir accès au code source. En matière de licence libre, la qualité de fournisseur et d’utilisateur peut facilement se cumuler. L’ensemble des licences libres contient cette obligation de mettre à disposition les codes sources. Par exemple, l’article 3.2 de la Mozilla Public License stipule que : «  Any Modification which You create or to which You contribute must be made available in Source Code form under the terms of this License either on the same media as an Executable version or via an accepted Electronic Distribution Mechanism to anyone to whom you made an Executable version available ; and if made available via Electronic Distribution Mechanism, must remain available for at least twelve (12) months after the date it initially became available, or at least six (6) months after a subsequent version of that particular Modification has been made available to such recipients. You are responsible for ensuring that the Source Code version remains available even if the Electronic Distribution Mechanism is maintained by a third party. » La notion de distribution est au cœur de l’obligation de mise à disposition des codes sources, notamment pour la licence GNU-GPL qui est la licence la plus utilisée. Il est donc important de la définir. Malheureusement, il n’existe aucune définition juridique de cette notion.
  • 21. 21 La licence CeCILL indique que le droit de distribution comporte : « Notamment le droit de diffuser, de transmettre et de communiquer le Logicielaupublicsurtoutsupportetpartoutmoyenainsiqueledroitde mettre sur le marché à titre onéreux ou gratuit, un ou des exemplaires du Logiciel par tout procédé ». Néanmoins il ne s’agit pas d’une réelle définition de la notion de distribution. On peut s’accorder sur le fait qu’il y a distribution dès lors qu’il y a communication à un public défini. L’affaire qui oppose Free à trois auteurs de logiciels diffusés sous licence GNU-GPL aurait pu nous apporter un éclairage supplémentaire sur la notion de distribution. En effet, les parties s’opposaient sur le fait de savoir s’il y avait distribution ou non et donc obligation de mise à disposition des codes sources. En l’espèce, au sein du modem fourni par Free à ses abonnés, la Freebox, des logiciels sous licences GNU-GPL sont intégrés. Trois développeurs de certains de ces modules ont assigné Free pour contrefaçon en invoquant le fait que l’opérateur internet ne respecteraitpaslalicenceGNU-GPL,etplusprécisément,l’obligation de mise à disposition des sources en cas de redistribution. Certains fournisseurs internet qui ont également intégré des composants libres au sein de leur modem remplissent cette condition11 . Le préambule de la version 2 de cette licence (version sous laquelle étaient diffusés les composants litigieux) stipule que : « For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. » Les auteurs des logiciels libres estimaient donc que Free devait proposer à ses abonnés une manière d’accéder aux codes sources. 11 Par exemple, les composants open source de la Neuf Box 4 sont disponibles à l’adresse : http://www.efixo.com/neufbox4/ freesoftware/.
  • 22. 22 En ne permettant pas cet accès, ils en concluaient que Free contrefaisait leurs logiciels. Ce que réfutait l’opérateur internet. Il estimait qu’il n’y avait pas de distribution car sa Freebox n’était pas vendue et qu’elle faisait partie intégrante de son réseau. Pour lui, ses utilisateurs n’avaient donc aucun droit à accéder aux sources. Une ordonnance du juge de la mise en état a été rendue le 26 mars 2010 afin que les auteurs des composants libres fournissent une traduction jurée de la licence GNU-GPL dans sa version 2. Rappelons que la FSF ne reconnaît aucune traduction et que seul le texte anglais lie les utilisateurs de cette licence. Cependant, comme le rappelle le juge de la mise en état, les juridictions ne peuvent examiner que des documents en langue française. Or le litige portait sur l’interprétation de la notion de distribution au sein du texte de la licence. Cette affaire aurait été l’occasion d’apporter une définition à cette notion. Mais une transaction au contenu confidentiel a eu lieu en 2011. Free met dorénavant à disposition les codes sources de sa Freebox12 et est ainsi revenu sur sa position alors qu’il la soutenait fermement depuis le début du litige. Le fait qu’une société aussi importante ait fini par transiger traduit bien les enjeux et les risques inhérents à toute condamnation en cas de non-respect de l’obligation de mise à disposition des sources. C’est la commercialisation même du produit qui peut être en danger. Cette affaire est spécifique à l’utilisation de licence en langue anglaise. Mais elle démontre que l’obligation contractuelle de mettre à disposition les codes sources du logiciel peut être à l'origine de responsabilité pour le fournisseur. 12 LescomposantsopensourcedelaFreeboxsontdisponiblesàl’adresse :http://floss.freebox.fr/.
  • 23. 23 RESPONSABILITÉ DE DROIT COMMUN PRINCIPE L’article 1382 du code civil pose un principe clair  : «  Tout fait quelconque de l’homme, qui cause à autrui un dommage, oblige celuiparlafauteduquelilestarrivéàleréparer. »Ainsi,siladéfaillance du composant sous licence libre que vous avez fourni provoque des dommages pour vos utilisateurs (arrêt de l’exploitation pendant quelques jours, impossibilité de livrer leurs propres clients dans les délais fixés contractuellement…), ces derniers peuvent se retourner contre vous. EXONERATION Comme nous l’avons vu précédemment13 , la majorité des licences libres possèdent des clauses limitant leur responsabilité14 ou les exonérant totalement15 . Ainsi l’article 16 de la licence GNU-GPL stipule que : LES LICENCES LIBRES, SOURCES DE RESPONSABILITÉ
  • 24. 24 « In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who modifies and/or conveys the program as permitted above, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the program (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the program to operate with any other programs), even if such holder or other party has been advised of the possibility of such damages »16 . Généralement les licences open source contiennent également des clauses limitant les garanties apportées par le fournisseur. Mais, bien que la présence de telles dispositions est commune à un grand nombre de licences libres, elle ne leur est pas spécifique. Il est possible de trouver des articles similaires au sein des licences propriétaires. En effet, le droit français admet les clauses limitatives de responsabilité sous certaines réserves. Nous nous attarderons sur trois d’entre elles. Premièrement, la clause ne doit pas porter sur une obligation essentielle du contrat. Cette solution est issue de la jurisprudence dite Chronopost selon laquelle une clause limitative de responsabilité qui contredit la portée de l’engagement pris doit être réputée non écrite. Enl’espèce,lasociétédelivraisonn’avaitpasrespecté,àdeuxreprises, les délais indiqués. Suite à l’assignation de son client, le transporteur invoquait une clause qui limitait l’indemnisation du retard au prix du transport dont le client s’était acquitté. Or, dans une décision du 22 octobre 199617 , les juges ont indiqué que la livraison des plis dans un délai donné était une obligation essentielle du contrat. Ainsi, toute clause qui limite la portée d’une telle obligation n’est pas valable en droit français.
  • 25. 25 Mais une clause limitative de responsabilité qui porte sur une obligation essentielle, sans pour autant la priver de tout son sens, reste valable. En effet, le 29 juin 201018 , la chambre commerciale de la Cour de cassation, après avoir rappelé que « seule est réputée non écrite la clause limitative de réparation qui contredit la portée de l’obligation essentielle souscrite par le débiteur  », a décidé que la clause limitant le montant de l’indemnisation en cas de manquement à ladite obligation à une somme non négligeable ne vidait pas de sa substance cette clause et devait donc être déclarée valable. Néanmoins, le risque existe qu’une clause limitative de responsabilité soit déclarée nulle et non écrite. Il convient donc de s’interroger sur l’obligation essentielle qui résulte d’un contrat de licence open source. Dans la décision sus-visée du 29 juin 2010, l’obligation de livrer une version précise du logiciel a été considérée comme une obligation essentielle du fournisseur. En l’espèce, le contrat prévoyait la livraison de la V12 en septembre 1999 (des solutions provisoires devant être fournies à l’utilisateur durant l’attente). Or cette version n’a jamais été livrée. Dans le cadre d’une licence open source, l’obligation de livraison des codes sources peut être considérée comme une obligation essentielle du contrat. Deuxièmement, les clauses limitatives de responsabilité ne peuventpasêtreinvoquéesencasdefautelourde. L’arrêtprécité du 29 juin 2010 précise que « la faute lourde ne peut résulter du seul manquement à une obligation contractuelle, fût-elle essentielle, mais doit se déduire de la gravité du comportement du débiteur ». Troisièmement, le législateur a veillé à protéger le consommateur lorsqu’il contracte avec un professionnel. L’article L.132-1 du code de la consommation dispose que « dans les contrats conclus entre professionnels et non-professionnels ou consommateurs, sont abusives les clauses qui ont pour objet ou pour effet de créer, au détriment du non-professionnel ou du consommateur, un déséquilibre significatif entre les droits et obligations des parties au contrat ».
  • 26. 26 Il en résulte que ces clauses seront réputées nulles et non écrites. Les contrats de licence de logiciels sont concernés par cette législation sur les clauses abusives. La Commission des clauses abusives a d’ailleurs rédigé une recommandation « relative aux contrats proposés par les éditeurs ou distributeurs de logiciels ou progiciels destinés à l’utilisation sur micro-ordinateurs »19 . Il est donc fort probable que certaines clauses qui exonèrent totalement un fournisseur professionnel de toute responsabilité puissent être qualifiées d’abusives si elles sont opposées à un utilisateur non-professionnel. Ces trois exemples démontrent que les clauses limitatives de responsabilitéprésentesdansleslicencesopensourcenegarantissent pas aux fournisseurs une absence totale de responsabilité. La possibilité d’invoquer de telles clauses est encadrée. Mais il est important de préciser que si ces dernières sont déclarées nulles et non écrites, cela n’entache pas la validité du contrat de licence. Enfin, il faut également souligner le fait que les rédacteurs des licences open source ont pris soin d’encadrer eux- mêmes l’utilisation des clauses limitatives de responsabilité en rappelant que leur champ d’application dépend de la loi des pays dans lesquels elles sont appliquées. Ainsi, la clause limitative de responsabilité de la licence GNU-GPL contient l’expression suivante : « unless required by applicable law or agreed to in writing ». Il en est de même pour la clause de garantie qui contient également les expressions suivantes : « to the extent permitted by applicable law » et « except when otherwise stated in writing ».
  • 27. 27 RESPONSABILITÉ DU FAIT DES PRODUITS DÉFECTUEUX Quoi ? Les articles 1386-1 à 1386-18 du code civil érigent un principe de responsabilité sans faute applicable aux producteurs européens. Lorsqu’un produit qui présente un défaut cause un dommage à un consommateur, la responsabilité du producteur peut être engagée. L’article 1386-2 limite le champ d’application de cette responsabilité à la réparation du dommage qui résulte soit d’une atteinte à la personne, soit d’une atteinte à un bien autre que le produit défectueux lui-même. Cependant, avec le développement de l’utilisation de logiciels libres au sein de systèmes plus complexes pouvant avoir un impact direct sur la sécurité des personnes, les hypothèses dans lesquelles cette responsabilité peut être invoquée sont susceptibles d’augmenter (centre de commande d’une centrale nucléaire, système de pilotage d’un avion, systèmes d’aides à la conduite embarqués au sein des automobiles…). Par ailleurs, l’article 1386-15 du code civil déclare nulle et non écrite toute clause écartant ou limitant la responsabilité du fait des produits défectueux. Qui ? Ce dernier peut être le producteur d’une matière première, le fabricant d’un produit fini ou d’une partie composante dès lors qu’il agit en tant que professionnel. L’article 1386-6 du code civil vise également «  toute personne agissantàtitreprofessionnel:(1°)quiseprésentecommeproducteur en apposant sur le produit son nom, sa marque ou un autre signe distinctif  ; ou (2°) qui importe un produit dans la Communauté européenne en vue d’une vente, d’une location, avec ou sans promesse de vente, ou de toute autre forme de distribution ».
  • 28. 28 Lesdéveloppeursetlesdistributeursdelogicielsontconcernés. D’ailleurs, lors d’une communication publiée au JOCE20 , il a été précisé que la directive s’appliquait aux logiciels. Mais, comme le rappelle, en 1998 Elisabeth Guigou, alors Garde des Sceaux, «  l’application de ce texte aux logiciels ne vise (…) que les situations où ceux-ci seraient à l’origine directe d’une atteinte à la sécurité des personnes ou des biens, hypothèses pour le moins résiduelles ». Comment s’exonérer de cette responsabilité ? L’article 1386-11 du code civil prévoit 6 causes d’exonération de responsabilité. Parmi celles-ci, il faut retenir le fait que « le défaut (soit) imputable à la conception du produit dans lequel cette partie a été incorporée ou aux instructions données par le producteur de ce produit » et le fait que « l’état des connaissances scientifiques et techniques, au moment où (le producteur) a mis le produit en circulation, n’(ait) pas permis de déceler l’existence du défaut ». Ces deux causes d’exonération doivent être prises en compte dans la gestion pratique du risque lié à une éventuelle mise en cause de sa responsabilité lorsqu’on opère le choix de diffuser son logiciel sous licence open source. Il convient également de noter que cette responsabilité ne s’applique pas lorsque le dommage a été causé à des biens qui ne sont pas utilisés par la victime principalement pour son usage ou sa consommation privée, dès lors que le contrat lie deux professionnels. GARANTIE D’ÉVICTION La garantie d’éviction assure au cessionnaire une jouissance paisible des droits qui lui ont été cédés. Lors d’une licence de droits d’auteur, cela signifie que le cédant déclare être titulaire des droits qu’il cède et garantit le ou les cessionnaires contre toute action en contrefaçon qui pourrait être intentée à son encontre. La Cour de cassation a
  • 29. 29 confirmé, dans un arrêt du 7 avril 1998, que cette garantie s’applique aux cessions de droits d’auteur21 . Les licences libres doivent donc la respecter et ne pas contenir de clauses contraires. Or certaines d’entre elles prévoient explicitement l’absence de garantie contre d’éventuelles actions en contrefaçon. Il en est ainsi pour la licence CeCILL qui indique, dans son article 9.4, que : «  le Concédant ne garantit pas, de manière expresse ou tacite, que le Logiciel ne porte pas atteinte à un quelconque droit de propriété intellectuelle d’un tiers (…). Ainsi, le Concédant exclut toute garantie au profit du Licencié contre les actions en contrefaçon qui pourraient être diligentées au titre de l’utilisation, de la modification, et de la redistribution du Logiciel… ». Bien qu’aucune décision de justice n’ait été rendue en France sur ce point, il est probable que les juges concluraient à la nullité de cette clause. Elle serait réputée non écrite, ce qui n’affecterait pas la validité du contrat lui-même. L’absence de garantie ne rend pas les licences libres illicites au regard du droit civil. A l’inverse, certaines licences libres prévoient explicitement l’existence de cette garantie. Ainsi, l’article 5(a) des licences Creative Commons dispose que : «  en mettant l’Œuvre à la disposition du public selon les termes de ce Contrat, l’Offrant déclare de bonne foi qu’à sa connaissance et dans les limites d’une enquête raisonnable : i. L’Offrant a obtenu tous les droits sur l’Œuvre nécessaires pour pouvoir autoriser l’exercice des droits accordés par le présent Contrat, et permettre la jouissance paisible et l’exercice licite de ces droits, ceci sans que l’Acceptant n’ait aucune obligation de verser de rémunération ou tout autre paiement ou droits, dans la limite des mécanismes de gestion collective obligatoire applicables décrits à l’article 4(e) ; ii. L’Œuvre n’est constitutive ni d’une violation des droits de tiers,
  • 30. 30 notamment du droit de la propriété littéraire et artistique, du droit des marques, du droit de l’information, du droit civil ou de tout autre droit, ni de diffamation, de violation de la vie privée ou de tout autre préjudice délictuel à l’égard de toute tierce partie. » Le respect de cette garantie suppose un travail de recherche de la part du fournisseur qui désire distribuer un logiciel ayant plusieurs composants open source. Il doit s’assurer que l’ensemble de ces derniers sont bien identifiés ainsi que les licences applicables. Il est ainsi en mesure de vérifier qu’il remplit l’ensemble des obligations que lui imposent ces contrats. En pratique, ce travail de recherche peut s’avérer fastidieux et complexe en raison de la multiplicité des contributeurs au sein de certains logiciels libres et du caractère temporaire des informations fournies lors de la contribution (adresse e-mail désactivée, coordonnées non mises à jour…). Rappelons que le non-respect des obligations, notamment de redistribution, inhérentes aux licences open source est constitutif d’une contrefaçon. Dès lors que le fournisseur qui intègre des composants libres dans son produit ne respecte pas ces obligations, il porte atteinte aux droits d’auteur du ou des titulaires de droits sur les composants et commet donc une contrefaçon. Il est donc susceptible d’être confronté à une demande en garantie d’un utilisateur. GARANTIE DES VICES CACHéS La garantie des vices cachés sera exclue de cette étude, son applicationauxlogicielsétantsourcedediscussionsjurisprudentielles et doctrinales. Il ressort de l’ensemble de ces débats que cette garantie s’applique lorsque le contrat porte sur le matériel informatique mais qu’elle est
  • 31. 31 exclue lorsque le contrat ne concerne qu’un logiciel. Elle ne peut être invoquée que lorsque le matériel est en cause. 13Voirsuprap.16 14Parexemple,art.8delalicenceCECILL :« 8.1Sousréservedesdispositionsdel’article8.2,leLicenciéalafaculté,sousréserve de prouver la faute du Concédant concerné, de solliciter la réparation du préjudice direct qu’il subirait du fait du Logiciel et dont ilapporteralapreuve. 8.2 La responsabilité du Concédant est limitée aux engagements pris en application du Contrat et ne saurait être engagée en raisonnotamment:(i)desdommagesdusàl’inexécution,totaleoupartielle,desesobligationsparleLicencié,(ii)desdommages directsouindirectsdécoulantdel’utilisationoudesperformancesduLogicielsubisparleLicenciéet(iii)plusgénéralementd’un quelconquedommageindirect.Enparticulier,lesPartiesconviennentexpressémentquetoutpréjudicefinancieroucommercial (parexemplepertededonnées,pertedebénéfices,perted’exploitation,pertedeclientèleoudecommandes,manqueàgagner, troublecommercialquelconque)outouteactiondirigéecontreleLicenciéparuntiers,constitueundommageindirectetn’ouvre pasdroitàréparationparleConcédant. » 15 Par exemple, art. 9 de la Mozilla Public License 1.1 (MPL-1.1) (disponible à l’adresse http://www.mozilla.org/MPL/MPL- 1.1.html) : « Under no circumstances and under no legal theory, whether tort (including negligence), contract, or otherwise, shall you, the initial developer, any other contributor, or any distributor of covered code, or any supplier of any of such parties, be liable to any person for any indirect, special, incidental, or consequential damages of any character including, without limi- tation,damagesforlossofgoodwill,workstoppage,computerfailureormalfunction,oranyandallothercommercialdamages or losses, even if such party shall have been informed of the possibility of such damages. This limitation of liability shall not apply to liability for death or personal injury resulting from such party’s negligence to the extent applicable law prohibits such limitation. Some jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so this exclusion andlimitationmaynotapplytoyou.»(enmajusculesetengrasdansletextedelalicence) 16Letexteestenmajusculeauseindelalicence.Ils’agitd’attirerl’attentiondel’utilisateursurcetteclauseetderespecterainsi les dispositions de l’Uniform Commercial Code dont le texte est disponible à l’adresse suivante : http://www.law.cornell.edu/ ucc/ucc.table.html. 17Cass.Com.,22octobre1996,Bull.Civ.N°261. 18Cass.Com.,29juin2010,Bull.Civ.N°115. 19Recommandationn°95-02relativeauxcontratsproposésparleséditeursoudistributeursdelogicielsouprogicielsdestinésà l’utilisationsurmicro-ordinateurs,disponibleàl’adressehttp://www.clauses-abusives.fr/recom/95r02.htm. 20JOCE,8mai1989,C144/42. 21Cass.1èreciv.,7avril1998,pourvoin°96-13292[enligne].Disponiblesurwww.legifrance.gouv.fr(consultéle15août2009) : « Attenduquelagarantied’évictionestduepartoutcédantd’undroitdepropriété,corporelouincorporel ».
  • 32. 32 2ème PARTIE Analyse PRATIQUE DE LA responsabilité lors du recours à des licences libres
  • 33. 33 Il existe une multitude de licences libres. Elles ont été rédigées par des organismes différents sans concertation. Il en résulte qu’elles ne sont pas toujours compatibles entre elles. Certaines sont soumises au droit américain, d’autres au droit français… Certaines sont propres aux logiciels et ont été étendues aux autres œuvres alors que d’autres ont une vocation plus générale… Cesproblèmesd’incompatibilitépeuventavoirdesrépercussionssur l’exploitation ultérieure d’un produit qui intégrerait des composants diffusés sous des licences libres différentes. Cette incompatibilité dépend du caractère contaminant ou non des licences utilisées. On peut les classer en trois catégories : ■■ Licence à copyleft fort  : la licence s’applique à toute redistribution de l’œuvre et s’étend également à la distribution d’une création à laquelle est intégrée l’œuvre. La licence GNU-GPL entre dans cette catégorie. RESPONSABILITÉ EN CAS D’INCOMPATIBILITÉ ENTRE LES LICENCES LIBRES
  • 34. 34 ■■ Licence à copyleft faible : la licence s’applique uniquement à la redistribution de l’œuvre initiale et ne s’étend pas aux créations auxquelles elle pourrait être intégrée. ■■ Licence sans copyleft : la redistribution de l’œuvre est libre et peut se faire sous une autre licence. Derrière cet effet «contaminant», se cache une sorte de compétition entre les différentes communautés de licences libres afin que leur texte devienne celui le plus utilisé, la référence. Mais cela peut conduire à des situations inextricables comme le montre le schéma et le tableau ci-dessous : copyleft fort copyleft faible sans copyleft copyleftfort Blocage sauf si l’une des licences contient une clause de compatibilité Blocage sauf si l’une des licences contient une clause de compatibilité Distribution possible P doit être distribué sous la licence B copyleftfaible Blocage sauf si l’une des licences contient une clause de compatibilité Distribution possible P peut être distribué sans que les licences A et B ne contaminent la partie hachurée et à condition que chaque module soit distribué sous sa propre licence Distribution possible P peut être distribué sans que la licence B ne contamine la partie hachurée et le module A et à condition que le module B soit distribué sous la licence B sanscopyleft Distribution possible P doit être distribué sous la licence A Distribution possible P peut être distribué sans que la licence A ne contamine la partie hachurée et le module B et à condition que le module A soit distribué sous la licence A Distribution possible aucune contamination MODULE A MODULE B PRODUIT P
  • 35. 35 Les deux cas de blocage sont les suivants : Les modules A et B sont distribués sous deux licences libres différentes ayant chacune un copyleft fort. La licence A a vocation à contaminer l’ensemble du produit P qui devrait être distribué sous cette licence. La licence B a également vocation à contaminer l’ensemble du produit P. Les deux licences entrent donc en compétition et aucune des deux ne peut primer sur l’autre. Il y a donc un conflit qui empêche la distribution de P. Il faut alors remplacer l’un des composants par un autre module compatible ou le réécrire. Un des modules est distribué sous une licence libre ayant un copyleft fort (A) et l’autre sous une licence libre ayant un copyleft faible  (B). La licence A a vocation à contaminer l’ensemble du produit P y compris le composant B. Or la licence de ce dernier impose qu’il continue à être distribué sous elle. Il y a donc un conflit qui empêche la distribution de P. Il faut alors remplacer le module B par un composant compatible avec la licence A ou le réécrire. Ces deux cas peuvent également être résolus par la présence au sein de l’une des deux licences d’une clause de compatibilité. En effet, certains auteurs de licence ont conscience des problèmes que peuvent engendrer l’absence d’interopérabilité entre les licences. Ils ont donc inclus dans leur texte une clause qui rend compatible leur licence avec d’autres. Ainsi, l’article 5.3.4 de la licence CECILL V2 prévoit une compatibilité expresse avec la licence GNU GPL : « Le Licencié peut inclure un code soumis aux dispositions d’une des versionsdelalicenceGNUGPLdansleLogicielmodifiéounonetdistribuer l’ensemblesouslesconditionsdelamêmeversiondelalicenceGNUGPL. Le Licencié peut inclure le Logiciel modifié ou non dans un code soumis aux dispositions d’une des versions de la licence GNU GPL et distribuer l’ensemble sous les conditions de la même version de la licence GNU GPL. »
  • 36. 36 LES RESPONSABILITÉS EN JEU RESPONSABILITÉ DU DISTRIBUTEUR DU PRODUIT Lorsqu’un produit comporte deux composants ayant des licences incompatibles, sa distribution n’est pas possible légalement. Mais un distributeur peut décider de passer outre. Il prend alors le risque que les auteurs du composant dont la licence ne sera pas respectée l’attaquent en justice et engagent sa responsabilité contractuelle. Les risques encourus sont le paiement de dommages-intérêts, l’arrêt de la distribution du produit, le paiement de nouveaux développements pour remplacer le composant litigieux… Cela peut vite atteindre des sommes importantes. Ces risques ne sont pas que des spéculations. Ils sont bien réels. En 2005, la société Fortinet a reçu une injonction de la cour de Munich lui ordonnant d’arrêter la commercialisation de son produit tant que les termes de la licence GNU-GPL n’étaient pas respectés. En l’espèce, le litige n’était pas dû à une incompatibilité entre deux licences libres mais au non-respect de la licence GNU-GPL : Il est conseillé de systématiquement demander à ses salariés de compléter une fiche signalétique dans laquelle les informations suivantes seraient listées : ■■ nom des composants libres utilisés, ■■ licences libres associées à ces composants, ■■ contraintes inhérentes à ces licences libres. Ces fiches ont vocation à être transmises aux juristes de l’entreprise utilisatrice de composants Open Source afin qu’ils puissent détecter d’éventuelles incompatibilités. Cela suppose que l’entreprise ait préalablement formé son juriste à l’utilisation des licences libres. Une fois informée des potentiels risques d’incompatibilité, la société doit prendre les mesures nécessaires pour permettre la bonne utilisation et/ou distribution des nouveaux logiciels produits. Pascal HATÉ, directeurassocié,Merethis(éditeuropensourcedelasuitedelogicielsdesupervisionCentreon)
  • 37. 37 la société ne redistribuait pas son produit sous cette licence. Mais les conséquences sont les mêmes : en cas de non-respect de la licence, les auteurs du composant libre sont fondés à demander l’arrêt de la distribution. RESPONSABILITÉ DU FOURNISSEUR DU PRODUIT Si le commanditaire d’un produit n’a pas été informé par son fournisseur de la présence de deux composants diffusés sous deux licences libres incompatibles, il peut se retourner contre ce dernier et engager sa responsabilité. QUELQUES BONNES PRATIQUES à METTRE EN PLACE 1. Informer les salariés et sous-traitants des risques d’incompatibilité entre licences afin qu’ils adaptent leur façon de travailler. 2. Créer un espace de travail commun entre les développeurs et les juristes au sein duquel les développeurs déclareraient les composants sous licence libre utilisés afin que les juristes s’assurent de la compatibilité des licences entre elles. Au préalable, le service juridique aura pu dresser un tableau de compatibilité. 3. Auditer les sources par une société tierce. Ce genre de structure possède une base de données très importante au niveau des codes sources sous licence libre. De plus, leurs équipes ont déjà analysé les principales licences et peuvent ainsi rapidement vous informer des risques d’incompatibilité.
  • 38. 38 Quoi ? Risque d’incompatibilité de licences conduisant à l’impossibilité de distribuer le produit final. Qui ? ■■ Responsabilité du distributeur du produit qui le commercialise en dépit du conflit interne entre les licences. ■■ Responsabilité du sous-traitant qui a intégré deux composants incompatibles. Quels risques en cas de non-respect ? ■■ Arrêt de la distribution ■■ Dommages et intérêts ■■ Déficit d’image en cas de poursuites Quelles précautions prendre ? ■■ Faire travailler conjointement les développeurs et les juristes. ■■ Faire auditer les codes sources.
  • 39. 39 RESPONSABILITÉ EN CAS D’ABSENCE DE MISE à DISPOSITION DES SOURCES Les licences libres se caractérisent par la liberté accordée aux utilisateurs de pouvoir modifier les codes sources des logiciels diffusés sous ce type de licence. Cela suppose qu’ils puissent y avoir accès. Une obligation de distribution des codes sources pèse donc sur tout fournisseur d’un logiciel sous licence libre. Ainsi, si vous choisissez de distribuer votre logiciel sous licence libre, vous devez impérativement fournir les sources de ce dernier. Cette obligation peut également peser sur les utilisateurs d’un logiciel distribué sous licence libre dès lors qu’ils redistribuent à leur tour le logiciel initial ou qu’ils distribuent le logiciel modifié. C’est une des conséquences de la notion de «copyleft» qui caractérise la plupart des licences libres. Cette expression, issue d’un jeu de mots avec le terme «copyright», renvoie au caractère contaminant de certaines licences libres  : la redistribution doit se faire dans les mêmes conditions que la distribution initiale, c’est-à-dire sous la même licence libre. L’amplitude de la contamination diffère selon la licence choisie : elle ne peut concerner que les développements initiaux tout comme elle peut s’appliquer à l’ensemble de l’œuvre au sein de laquelle a été intégré un composant libre22 . 22Pourunedéfinitionplusdétailléeducopyleft,voirsuprap.39
  • 40. 40 ÉTENDUE DE L’OBLIGATION DE MISE à DISPOSITION DES SOURCES L’étendue de l’obligation de mise à disposition des sources qui pèse sur l’utilisateur varie selon l’hypothèse dans laquelle il se trouve : 1ère hypothèse  : l’utilisateur veut redistribuer le logiciel tel quel. C’est la situation la plus simple. Il doit communiquer les codes sources initiaux ou les mettre à disposition dès lors qu’il redistribue le logiciel. 2ème hypothèse : l’utilisateur a modifié le logiciel initial et veut distribuer le logiciel modifié. Dans ce cas, l’obligation ne porte plus sur les codes sources tels qu’il les a reçus par le fournisseur. Elle porte sur les codes sources modifiés. Ainsi, il ne remplit pas son obligation s’il met à disposition les codes sources originaux. Il doit communiquer aux futurs utilisateurs les codes sources qui résultent de son travail d’adaptation. logiciel A sous licence libre Distribution du logiciel A Distribution du le logiciel A’ Pas d’obligation de distribution des codes sources du logiciel A’ Distribution des codes sources du logiciel A’ Pas d’obligation de distribution des codes sources du logiciel A Distribution des codes sources du logiciel A OUI OUI NON NON OUINON
  • 41. 41 Certaines licences encadrent strictement la distribution des codes sources modifiés. C’est le cas de la licence GNU-GPL. Son article 5 stipule que l’utilisateur qui veut distribuer le logiciel après y avoir apporté des modifications doit faire apparaître clairement le fait que les sources de ce dernier ont été modifiées ainsi que la date à laquelle ces changements ont eu lieu. Le but de telles dispositions est d’éviter que des erreurs ou des bugs ne soient pas attribués à la mauvaise personne. Il est également possible de se préserver contre de tels troubles en enregistrant les modifications effectuées auprès d’un tiers de confiance. 3ème hypothèse  : l’utilisateur a intégré un composant sous licence libre au sein d’une solution informatique qu’il veut distribuer. Cette hypothèse vise la situation dans laquelle le logiciel diffusé sous licence libre ne représente qu’un composant d’un ensemble plus complexe. Ce cas est fréquent. En effet, rares sont les logiciels créés ex nihilo. Par souci d’efficacité et de rapidité, les développeurs se tournent vers des composants open source pour les intégrer à leur propre développement. Ils doivent alors vérifier le caractère contaminant de la licence sous laquelle est diffusé ce composant. En effet, le copyleft peut être plus ou moins « fort » selon la licence. Aujourd’hui, tout le monde est d’accord sur le fait qu’il est contreproductif d’essayer de développer des programmes alors qu’il en existe déjà qui sont très largement testés et performants. Les développeurs se tournent naturellement vers ces solutions. Aujourd’hui, il faut être le premier à sortir un produit. Cela incite à utiliser des composants existants. Les logiciels comportent ainsi des composants open source, soumis à des licences plus ou moins contraignantes. Par exemple, les programmes de Microsoft reposent énormément sur des composants open source, sous des licences très permissives. Benjamin JEAN, docteurendroit,présidentdeInno3,Expertisesn°363,Novembre2011.
  • 42. 42 La Mozilla Public License (MLP) est un exemple de licence à « copyleft » faible. Bien qu’elle oblige la redistribution du logiciel et de ses modifications sous MLP (art. 3.1 et 3.2 d), elle autorise le développeur qui intègre ce dernier dans un ensemble à ne pas fournir le code source des parties qu’il a entièrement développées (art. 3.7). Seules les sources du logiciel initialement en MLP devront être publiques. A l’inverse, la licence GNU-GPL est l’exemple même du « copyleft » fort. Selon son article 2.b, la licence s’étend à l’ensemble du programme issu de l’intégration du logiciel libre. Par exemple, la NeufBox ayant des composants logiciels sous licence GNU-GPL, Neuf Cegetel avait, dès 2007, mis en ligne les codes sources de son modem sur un site dédié. Un pas supplémentaire vers une libération totale des sources a été franchi en 2010 avec la communication du code source de son firmware par SFR (ex-Neuf Cegetel) rendant ainsi possible pour les utilisateurs d’ajouter de nouvelles fonctions à la NeufBox. En choisissant d’intégrer des composants diffusés sous licence libre au sein de ses solutions, l’utilisateur doit avoir conscience que pèse sur lui une obligation de mise à disposition des sources. Elle peut être a minima et ne concerner que les sources de ce(s) composant(s). Mais elle peut également être extrêmement contraignante et porter sur l’ensemble des sources de la solution (y compris les développements réalisés par l’utilisateur). Au sein d’une société dont l’objectif est de commercialiser ladite solution, ce problème doit être soulevé dès le début du développement afin qu’une position claire soit définie sur l’étendue de l’obligation de mise à disposition que peut supporter la société sans que l’exploitation commerciale de sa solution soit compromise.
  • 43. 43 Les développeurs devront ensuite s’assurer, en partenariat avec le service juridique, de la compatibilité des licences sous lesquelles sont diffusés le ou les composants avec la politique de l’entreprise relative à la mise à disposition des sources. Parallèlement, un autre problème peut se poser lorsque plusieurs composants open source sont intégrés au sein d’une même solution. Ils peuvent ne pas être diffusés initialement sous la même licence. La question de leur compatibilité va alors devoir être envisagée et ses éventuelles conséquences sur la possibilité ou non de commercialiser la solution23 . 23Cepointesttraitédanslechapitreprécédent,voirsuprap.40 COPYLEFT FORT COPYLEFT FAIBLE Intégration d’un composant B sous licence libreau sein d’un programme C de la licence NONOUI Mise à disposition de l’intégralité des sources du programme C en cas de redistribution Mise à disposition des sources composant B en cas de distribution Mise à disposition des sources du composant B en cas de distribution composant sous licence libre
  • 44. 44 LA MISE à DISPOSITION DES SOURCES EN PRATIQUE La mise à disposition des sources peut se faire de différentes façons : ■■ Communication des sources sur un support en même temps que l’exécutable ■■ Communication des sources via un site internet clairement identifié et dont l’adresse est transmise aux utilisateurs lors de la livraison de la solution. C’est la solution choisie par exemple par SFR pour les codes sources de la NeufBox. ■■ Proposition écrite de fournir lesdits codes sources sur simple demande formulée à une adresse (mail ou postale) transmise aux utilisateurs lors de la livraison de la solution. LES RISQUES EN CAS DE NON-RESPECT DE L’OBLIGATION DE MISE à DISPOSITION DES SOURCES Le non-respect de l’obligation de mise à disposition des sources expose le fournisseur ou l’utilisateur à qui elle incombe à des risques de poursuites judiciaires. La FSF est particulièrement active sur ce point. Le faible nombre de décisions rendues en la matière en France ne doit pas conduire à penser que le risque est inexistant. Rappelons qu’une décision rendue par la cour d’appel de Paris le 16 septembre 2009 a reconnu la validité de la licence GNU-GPL en droit français24 . Ainsi, il n’est pas infondé de penser que plusieurs actions risquent prochainement de voir le jour en France. De nombreuses poursuites ont été entamées aux Etats-Unis. Les conséquences pour les entreprises concernées ont pu être assez importantesquecesoitentermesd’imagequ’entermesdepertesfinancières. 24 Courd’appeldeParis,10èmechambre,16septembre2009, Edu4/Afpa,ExpertisesN°341,Novembre2009
  • 45. 45 Par exemple des actions en justice ont été intentées à l’encontre d’une dizaine d’entreprises qui avaient intégré le logiciel BusyBox à leurs solutions sans respecter l’obligation de mise à disposition des sources. Après une tentative de conciliation à l’amiable, la Software Freedom Conservancy a assigné ces sociétés devant un tribunal new-yorkais. Ces assignations ont fait l’objet d’une large couverture médiatique,cequiapuavoirunimpactsurl’imagedecesentreprises auprès des consommateurs américains. Il est intéressant de noter qu’en France, Free a également été poursuivi par un des développeurs de ce même logiciel pour ne pas mettre à disposition les codes sources de sa Freebox. En l’espèce, les parties sont arrivées à un accord amiable et Free a mis en ligne les codes sources litigieux25 . Pour résumer, la diffusion d’un logiciel sous une licence libre est un acte d’exploitation de ses droits d’auteur par le titulaire des droits sur ce logiciel. Le non-respect des termes de la licence (comme le fait de ne pas mettre à disposition les codes sources en cas de redistribution) constitue donc une atteinte à ses droits d’auteur et peut conduire à une condamnation pour contrefaçon. Les conséquences d’une telle décision de justice porteront à la fois sur la renommée de la société mais également sur la pérennité de son activité selon les coûts engendrés lors de la procédure. Le fait que de puissantes sociétés comme Cisco ou Free aient préféré transiger après qu’une action a été engagée à leur encontre démontre que ces sociétés avaient beaucoup à perdre en allant jusqu’au procès. 25 Pourplusdeprécisions,voirsuprap.25
  • 46. 46 QUELQUES BONNES PRATIQUES à METTRE EN PLACE 1. Définir une politique claire quant à l’usage des licences libres au sein de l’entreprise et réfléchir aux obligations qui en découlent comme la mise à disposition des sources en cas de redistribution. Elle pourrait découler des réponses apportées aux questions suivantes : Accepte-t-on de diffuser nos développements sous licence libre ? Si oui, quels développements peuvent être concernés par une diffusion sous licence libre ? Les programmes que nous avons intégralement développés ? Les programmes initialement sous licence libre que nous avons modifiés ? Les programmes au sein desquels nous avons intégré des composants sous licence libre ? 2. Dresser une liste de licences libres compatibles avec les exigences mises en exergue dans la politique définie ci-dessus. Le critère déterminant en l’espèce est la présence ou non d’un copyleft et le caractère fort ou faible de ce dernier. Par exemple, voici une liste non exhaustive : Licence Copyleft texte de la licence GPL FORT http://www.gnu.org/copyleft/gpl.html LGPL FORT http://www.gnu.org/licenses/lgpl-3.0.html FDL FORT http://www.gnu.org/licenses/fdl-1.3.html MPL FAIBLE http://www.mozilla.org/MPL/MPL-1.1.html APACHE SANS http://www.apache.org/licenses/LICENSE-2.0 BSD SANS http://www.freebsd.org/copyright/license.html
  • 47. 47 3. Informer le personnel des risques liés à l’intégration ou à la modification de composants sous licences libres et diffuser soit une charte reprenant la politique définie par l’entreprise, soit une sorte de guide de bonnes pratiques. Par exemple, l’ADAE (l’Agence pour le développement de l’administration électronique) avait édité à l’usage des agents publics « un guide pratique d’usage des logiciels libres dans les administrations »26 . Lechoixdutypededocumentpeutemporterdesconséquences juridiques sur son caractère contraignant ou non. 26 http://www.adullact.org/IMG/pdf/GuideLLadministrations-V1.2.0.pdf Dès lors qu’une société choisit d’utiliser des composants et/ou d’assembler des composants Open Source, elle doit former ses juristes et ses experts internes à la bonne compréhension des cas d’utilisation et des possibilités offertes par les différents types de licences Open Source. Dans le cas où dans un premier temps, elle ne souhaiterait pas faire cet investissement, elle pourra faire appel à des sociétés spécialisées dans l’étude, le développement, l’intégration, et la gestion des composants Open Source. En effet, l’Open Source offre des libertés, mais demande également de respecter certains contraintes/devoirs. Par exemple, si une société utilise au sein d’un de ses produits un composant Open Source, dans certains cas, elle ne pourra pas fermer le code de son produit et le vendre sous une autre licence. Il faut donc bien étudier chaque cas d’utilisation pour limiter les risques. Dans un autre cas, si vous ajoutez de nouvelles fonctionnalités à certains composants d’une brique Open Source, il est de bon ton de reverser/proposer vos développements à la communauté. Elle pourra ensuite intégrer ou non vos développements à la branche principale du projet. Dans le cas où vos développements seraient intégrés, vous assurerez la pérennité de ces derniers au sein de la branche principale du projet Open Source. Dans le cas contraire, vous devrez maintenir vous-mêmes vos composants et les faire évoluer pour les maintenir compatibles avec les nouvelles versions du composant Open Source initialement utilisé.  Pascal HATÉ, directeurassocié,Merethis(éditeuropensourcedelasuitedelogicielsdesupervisionCentreon)
  • 48. 48 Plusieurs décisions de justice ont reconnu le caractère contraignant d’une charte sous certaines conditions et approuvé le licenciement d’un membre du personnel ayant agi en enfreignant ce texte27 . 4. Instaurer des outils et des espaces de travail pour une collaboration entre les services de développement et les services juridiques afin d’avoir une vision claire des licences utilisées et des obligations qui en découlent. Cela peut prendre la forme d’un système déclaratif dans lequel les développeurs devraient énumérer les logiciels libres qu’ils utilisent ainsi que la licence à laquelle ils sont soumis et remonter régulièrement cette liste aux juristes de l’entreprise. 5. Faire appel à une société tiers pour auditer les codes sources afin de déterminer les licences des composants open source si les mesures évoquées ci-dessus n’ont pas été mises en place. 27 Plusdeprécisions,danslerécapitulatifdesbonnespratiques.
  • 49. 49 Quoi ? Obligation de distribuer ou redistribuer les codes sources d’un logiciel sous licence libre. Qui ? ■■ Tout fournisseur d’un logiciel sous licence libre. ■■ Tout utilisateur d’un logiciel libre voulant le redistribuer à son tour. ■■ Tout utilisateur ayant modifié les codes sources du logiciel et voulant distribuer le logiciel modifié. Dans ce cas, l’obligation porte sur les codes sources modifiés. ■■ Tout utilisateur d’un logiciel libre l’ayant intégré au sein d’une solution informatique qu’il souhaite distribuer. Dans ce cas, il convient de vérifier le caractère contaminant ou non de la licence. Comment ? Les sources peuvent notamment être jointes avec l’exécutable ou être disponibles sur un site internet dont l’adresse est clairement identifiable par les utilisateurs. Quels risques en cas de non-respect ? ■■ Assignation en justice ■■ Condamnation ■■ Arrêt de l’exploitation ■■ Déficit d’images ■■ Perte de revenus Quelles précautions prendre ? ■■ Définir une politique claire quant à la mise à disposition des sources (étendue de cette mise à disposition : codes sources initiaux, codes sources modifiés, intégralité des codes sources) ■■ Matérialiser cette politique à l’aide d’une charte ■■ Etablir une liste des licences compatibles avec la politique mise en place ■■ Amener les développeurs et les juristes à travailler ensemble ■■ Auditer les sources des solutions avant leur mise sur le marché
  • 50. 50 Pour aller plus loin La dépendance fonctionnelle d’un programme à un logiciel libre Il ne faut pas confondre l’intégration d’un composant sous licence libre au sein d’un programme et la dépendance fonctionnelle de ce programme à un logiciel sous licence libre. Autant les conséquences juridiques de la première opération sont établies (notamment la mise à disposition plus ou moins étendue des codes sources), autant la deuxième hypothèse est sujette à plus d’interrogations. Le schéma ci-dessous donne un aperçu de la différence que l’on peut faire entre ces deux notions. Alors que dans le premier cas, le composant est imbriqué au sein du logiciel C, dans le second, il existe une indépendance matérielle entre les deux programmes. Le composant B n’est pas intégré au logiciel C mais lui permet de fonctionner. Il y a une communication entre les deux programmes mais ils restent totalement dissociables. Par exemple, le logiciel libre B peut être une passerelle permettant au logiciel C de communiquer avec une base de données. Dans cette hypothèse, il ne devrait pas y avoir d’effet contaminant a priori, chaque programme étant indépendant physiquement malgré une dépendance fonctionnelle. COMPOSANT B LOGICIEL C BASES DE DONNÉES D LOGICIEL LIBRE B LOGICIEL C
  • 51. 51 Néanmoins, le fait que le logiciel C sera distribué avec la base de données D et le logiciel libre B entraîne-t-il une contamination de C par la licence B ? La réponse est loin d’être évidente. En effet, l’indépendance matérielle des deux programmes peut conduire à penser à une absence d’effet contaminant. Mais certains éléments amènent à se montrer moins catégorique. En effet, il existe une dépendance fonctionnelle entre les deux logiciels. De plus, lors de la commercialisation du produit fini, le logiciel libre sera vendu en même temps et sur le même support que le développement original. Enfin, certaines licences ont un copyleft extrêmement fort qui pourrait s’étendre au développement réalisé. En effet, la FSF estime que la licence GNU-GPL interdit que des bibliothèques non GNU- GPL soient liées à un logiciel sous GNU-GPL28 . Ne pourrait-on pas alors estimer que tout programme lié à un logiciel sous GNU-GPL doit être soumis à cette licence ? Aucune réponse définitive n’est apportée à cette question. Mais il nous semble qu’un effet contaminant peut être mis en évidence en cas de copyleft fort. Selon la licence utilisée pour le composant B, il est possible que les codes sources du logiciel C doivent également être mis à disposition. 28 Y COOL et P. LAURENT, Repères pour comprendre le mouvement du logiciel libre, in Y COOL et al., Les logiciels libres face au droit,Bruylant,2005,coll.CahiersdeCentredeRecherchesInformatiqueetdroitn025,p.d,note7.
  • 52. 52 La philosophie des licences libres est de placer l’utilisateur au centre du système en lui accordant plus de libertés. Il ne serait donc pas cohérent d’invoquer la diffusion sous licence libre comme moyen d’exonération de toute responsabilité au prétexte que le code est ouvert et que l’utilisateur peut intervenir dessus. Ainsi, un fournisseur de logiciel libre peut voir sa responsabilité engagée par un utilisateur en cas de défaillance du programme. INTÉGRATION D’UN COMPOSANT LIBRE DANS UNE SOLUTION PLUS COMPLEXE Prenons l’exemple suivant : une société X développe un composant qu’elledécidedediffusersouslicencelibre.Cecomposantestensuite intégré par une société Y au sein d’un ensemble plus complexe. La défaillance de ce composant est alors à l’origine d’un arrêt du système occasionnant soit des pertes matérielles soit des pertes financières. RESPONSABILITÉ EN CAS DE DÉFAILLANCE DU LOGICIEL
  • 53. 53 Plusieurs hypothèses sont à envisager : 1ère hypothèse  La société Y n’a pas modifié le composant X avant de l’intégrer dans la solution informatique qu’elle va livrer à l’utilisateur final. Elle a également informé l’utilisateur final de la présence de ce composant sous licence libre. Dans ce cas, c’est le mécanisme habituel de la responsabilité civile qui s’applique. La société Y peut voir sa responsabilité engagée si elle n’a pas été en mesure de corriger dans un délai raisonnable le bug à l’origine de la défaillance. Elle pourra éventuellement se retourner contre la société X. composant X Intégration du composant X au sein 1èrehypothèse 2ème hypothèse OUI OUI NON Intégration du composant X’ au sein Information du client de la présence du composant X Information du client de la présence du composant X’ 3ème hypothèse 4ème hypothèse OUI NON NON
  • 54. 54 2ème hypothèse  La société Y n’a pas modifié le composant X avant de l’intégrer dans la solution informatique qu’elle va livrer à l’utilisateur final. Mais elle n’a pas informé l’utilisateur final de la présence de ce composant sous licence libre. Lasituationestlamêmequedanslapremièrehypothèse.Néanmoins, l’utilisateur final pourra également demander la résolution du contrat de développement et de cession aux torts exclusifs de la société Y car elle n’a pas respecté son obligation d’information. 3ème hypothèse  La société Y a modifié le composant X et a intégré un composant X’ au sein de la solution informatique livrée à l’utilisateur final. Ce dernier a été informé de la présence de ce composant libre. La société Y pourra voir sa responsabilité engagée si elle n’a pas été en mesure de corriger dans un délai raisonnable le bug à l’origine de la défaillance. Si elle veut se retourner contre la société X, elle devra prouver que ce ne sont pas les modifications qui sont à l’origine de la défaillance mais le développement initial. Les sociétés X et Y ont alors intérêt de pouvoir prouver l’étendue de leurs développements respectifs. Un enregistrement préalable des codes sources auprès d’un tiers de confiance aurait pu les aider dans leur défense. 4ème hypothèse  La société Y a modifié le composant X et a intégré un composant X’ au sein de la solution informatique livrée à l’utilisateur final. Ce dernier n’a pas été informé de la présence de ce composant libre. Nous sommes dans la même situation que la troisième hypothèse. Mais, la société Y n’ayant pas respecté son obligation d’information, pourra voir le contrat de cession et de développement résilié à ses torts exclusifs.
  • 55. 55 LE CAS DES SOUS-TRAITANTS Dans les hypothèses évoquées ci-dessus, nous supposions que la société Y savait que le logiciel X était diffusé sous licence libre. Mais elle peut également faire appel à un sous-traitant qui aurait intégré ce composant, modifié ou non, sans l’en informer. Dans ce cas, la société Y pourra se retourner contre son sous-traitant selon le principe de la responsabilité en cascade. RESPONSABILITÉ DU FAIT DES PRODUITS DÉFECTUEUX Pour que cette responsabilité puisse s’appliquer, il faut que la défaillancedulogiciellibreaitcausésoituneatteinteàunepersonne, soit une atteinte à un bien autre que le logiciel défectueux lui-même. Cette hypothèse est envisageable lorsque le logiciel libre est intégré dans un système plus complexe pouvant avoir un impact sur les biens ou les personnes. Parexemple,ladéfaillanced’unlogicielintégréauseind’uncentrede commande d’une usine peut engendrer des dommages matériels, voire des dommages humains. L’article 1386-11 du code civil prévoit la possibilité pour le fournisseur du logiciel litigieux de s’exonérer en démontrant que la défaillance est imputable à un dysfonctionnement du produit dans lequel le logiciel a été incorporé. Le recours à un tiers de confiance lors de la livraison du logiciel peut être un avantage dans ce cas. Enfigeantlescodessourcesremislorsdelatransaction,lefournisseur peut alors remettre à un expert ces éléments conservés par ce tiers de confiance afin de déterminer si c’est le logiciel ou le produit dans lequel il est intégré qui a causé le dysfonctionnement.
  • 56. 56 QUELQUES BONNES PRATIQUES à METTRE EN PLACE 1. Auditer les codes sources remis par les sous-traitants pour s’assurer de la présence ou non de composants sous licence libre. 2. Enregistrerauprèsd’untiersdeconfiancelesdéveloppements effectués par la société afin d’être en mesure de prouver que ce ne sont pas ces derniers qui sont à l’origine de la défaillance. 3. S’appuyer sur la communauté du libre pour suivre les évolutions et les corrections de bugs. L’un des avantages du recours aux logiciels libres est de bénéficier de l’expertise de la communauté du libre en étant notamment informé des éventuels bugs ou de la mise en ligne de patchs correctifs. 3. Proposer aux utilisateurs des solutions d’assurance. Il peut s’agir de contrats classiques d’assurance ou de contrats de maintenance (appelés également contrats d’assurance).
  • 57. 57 Quoi ? Responsabilité en cas de défaillance du logiciel libre : ■■ responsabilité contractuelle, ■■ responsabilité du fait des produits défectueux. Qui ? ■■ Tout fournisseur d’un logiciel sous licence libre. ■■ Tout utilisateur d’un logiciel libre voulant le redistribuer à son tour. ■■ Tout utilisateur ayant modifié les codes sources du logiciel et voulant distribuer le logiciel modifié. Dans ce cas, la responsabilité porte sur logiciel modifié. Quels risques ? ■■ Assignation en justice ■■ Condamnation ■■ Arrêt de l’exploitation ■■ Déficit d’images ■■ Perte de revenus Quelles précautions prendre ? ■■ Auditer les sources des solutions pour vérifier la présence de logiciels libres ■■ Matérialiser les sources remises au client avant qu’il les intègre dans un produit plus complexe en les enregistrant chez un tiers de confiance ■■ Effectuer une veille auprès de la communauté du libre pour être averti des éventuels bugs ou des correctifs existants. ■■ Recourir à des solutions d’assurance ou de maintenance pour pallier toute défaillance.
  • 58. 58 La mise en œuvre de la responsabilité pose des difficultés pratiques dans deux cas : ■■ Téléchargement du composant libre directement sur internet ■■ Identification des utilisateurs ne respectant pas les termes de la licence par les auteurs du logiciel libre. TéLéCHARGEMENT DIRECT DU COMPOSANT LIBRE Si le téléchargement a lieu sur le site de la société qui a développé le logiciel libre et que cette société bénéficie d’une certaine assise dans la communauté du libre, il n’y a pas vraiment de difficultés. La situation devient problématique lorsqu’il s’agit d’un composant libre téléchargé sur un forum, un blog ou un site lambda. Il faut alors se fier à un faisceau d’indices pour déterminer les personnes responsables  : mentions légales du site proposant le téléchargement, méta-données présentes dans le code source… Généralement, le code contient l’adresse électronique du développeur mais il n’y a aucune garantie sur la pérennité de celle-ci. DIFFICULTÉS LIÉES à LA MISE EN ŒUVRE PRATIQUE DE LA RESPONSABILITÉ
  • 59. 59 Les difficultés augmentent lorsque de multiples œuvres dérivées ont été créées à partir du logiciel diffusé sous licence libre. Il est difficile d’identifier la totalité des contributeurs. L’utilisateur de la licence concernant l’œuvre «A’» contracte-t-il avec l’auteur de l’œuvre «A», l’auteur de la modification «’» ou les deux auteurs ? Celasecompliqueencorepluslorsqu’ilyademultiplesmodifications comme le démontre le schéma suivant : Les garanties apportées par les licences libres sont-elles suffisantes pour que l’on puisse identifier aisément le titulaire des droits? Elles imposent toutes que soient mentionnés le nom de l’auteur premier et celui de ceux qui ont modifié le programme. Mais comment garantir la pérennité de ces informations ? Une adresse électronique peut être désactivée, une adresse postale peut ne pas être mise à jour suite à un ou des déménagements. IDENTIFICATION DES UTILISATEURS La complexité des licences libres se traduit également au niveau de la chaîne contractuelle qui en découle. Il n’y a aucun suivi. L’œuvre est mise à la disposition du public. L’auteur ne connaît pas les utilisateurs avec lesquels il a contracté. Il n’est pas non plus averti de toutes les modifications subies par sa création. Logiciel A Logiciel ELogiciel D Logiciel FLogiciel C Logiciel GLogiciel B Logiciel I Logiciel J Logiciel K Logiciel H
  • 60. 60 Cette chaîne complexe rend difficile l’exercice d’une action en contrefaçon en cas de non-respect de la licence. Une fois l’utilisateur identifié et le non-respect de la licence détecté, qui pourra agir ? Par exemple, l’auteur du logiciel D (schéma précédent) ne met pas à disposition les codes sources de son logiciel alors que la licence initiale a un copyleft fort. Qui peut engager sa responsabilité  ? L’auteur C alors qu’il n’a réalisé qu’une modification ? L’auteur A alors que l’auteur D est parti du logiciel C et non du logiciel A ? Les auteurs A, B et C ensemble ? Cette dernière solution apparaît comme la plus plausible, le logiciel D devant être qualifié soit d’œuvre de collaboration, soit d’œuvre composite. Une telle action sera donc difficile à mettre en place car des titulaires de droits qui ne se connaissent pas, qui ne sont peut-être pas de la même nationalité devront s’entendre pour agir en justice. Mais surtout, les personnes ayant modifié le logiciel A méritent-elles toutes la qualité d’auteur ? Le code de la propriété intellectuelle soumet cette qualité à la réalisation d’une œuvre originale. Or certaines modifications effectuées ne répondent pas à ce critère, même si celui-ci est quelque peu atténué en matière de logiciel(16). Il nous semble tout de même excessif de qualifier tous les «modificateurs» d’auteurs. Or leur nom est indiqué en tant que tel sur le programme. BONNES PRATIQUES FOURNISSEURS Déposer auprès d’un tiers de confiance les sources remises aux clients. L’une des caractéristiques des licences libres est de permettre à vos clients de modifier les sources de votre logiciel. Il est donc important pour vous d’être en mesure de prouver le contenu de ce que vous lui avez livré.
  • 61. 61 En effet, si le composant sous licence libre que vous lui avez fourni provoque un dysfonctionnement au sein de la solution et entraîne des dommages financiers ou matériels, votre client peut se retourner contre vous. Pour vous exonérer de toute responsabilité, vous devez prouver que ce sont les modifications qu’il a apportées à votre composant qui sont à l’origine de la défaillance. En enregistrant les sources livrées auprès d’un tiers de confiance, vous serez en mesure de les remettre à un expert judiciaire, en cas de litige. Celui-ci pourra donc vérifier si la défaillance provient de vos sources ou de la version modifiée par votre client. Trois cas de figures sont à prévoir : 1. Vous avez entièrement développé les sources que vous lui remettez et vous avez décidé de les diffuser sous licence libre. L’enregistrement vous permettra également de préconstituer la preuve de vos droits. En effet, un logiciel libre n’est pas libre Il existe deux principales familles de produits Open Source : les produits complètement et uniquement communautaires et les produits communautaires soutenus par des entreprises. » «  L’un des atouts majeurs de l’utilisation de composants Open Source soutenus par des sociétés est de permettre aux utilisateurs de joindre directement celles-ci pour pouvoir bénéficier d’un support de qualité et d’une réactivité identique à celle d’un éditeur classique. L’utilisateur pourra également bénéficier de prestations de services d’expertise ou de développements spécifiques pour de nouvelles fonctionnalités. Le modèle Open Source permet également aux utilisateurs de communiquer via les forums avec l’ensemble de la communauté. Celle-ci étant constituée de l’ensemble des utilisateurs et développeurs du produit, l’utilisateur peut alors très simplement trouver des personnes ayant les mêmes problématiques que lui et ainsi résoudre très rapidement son problème. Pascal HATÉ, directeurassocié,Merethis(éditeuropensourcedelasuitedelogicielsdesupervisionCentreon)
  • 62. 62 de droits. L’enregistrement auprès d’un tiers de confiance29 vous permet de dater vos développements et ainsi d’être en mesure de prouver l’étendue de vos droits. 2. Vous avez intégré des composants que vous n’avez pas développés mais dont vous avez acquis la titularité des droits. Vous avez choisi de diffuser votre produit sous licence libre. Comme précédemment, l’enregistrement auprès d’un tiers de confiance vous permettra de préconstituer la preuve de l’étendue de vos droits et de matérialiser vos développements. 3. Vous avez intégré des composants sous licence libre que vous n’avez pas développés et pour lesquels vous n’avez qu’un droit d’utilisation. Dans ce cas, l’enregistrement n’aura pas vocation à revendiquer des droits sur ces composants mais juste à matérialiser le contenu des développements remis à vos clients. L’enregistrement auprès d’un tiers de confiance vous protège contre toute appropriation frauduleuse de vos travaux et également contre toute tentative de vous attribuer des modifications à l’origine de dysfonctionnements plus ou moins graves. En effet, bien que certaines licences libres imposent d’indiquer son nom lors de la modification des sources, vous n’êtes pas à l’abri du fait que votre client ne respecte pas cette règle. Concrètement, lors de l’enregistrement de vos développements, le tiersdeconfiancevamettrelesupportnumériquesurlequelvousles aurez enregistrés sous scellés. Il va également émettre un document mentionnant notamment la date de cette mise sous scellés. Ce scellé ne pourra être ouvert que dans des cas limités et définis par le tiers de confiance. Toute ouverture en dehors de ces cas fait perdre toute force probante à votre enregistrement. Il pourra notamment être ouvert sur décision de justice par un expert mandaté par le tribunal pour déterminer l’origine de la défaillance litigieuse. 29 L’APP peut remplir ce rôle et vous propose plusieurs procédures : le référencement, le dépôt simple et le dépôt contrôlé. Pourplusd’information,www.app.asso.fr
  • 63. 63 S’appuyer sur la communauté du libre En décidant de diffuser vos développements sous licence libre ou d’intégrer des composants diffusés sous licence libre dans les solutions que vous livrez à vos clients, vous pouvez bénéficier de l’expertise des développeurs de la communauté du libre. Il est essentiel de saisir l’opportunité que vous donne ce mode de diffusion de pouvoir partager vos travaux et recueillir les corrections et améliorations proposées par d’autres développeurs. Concrètement, vous devez vous tenir au courant de l’actualité liée au logiciel utilisé en vous rendant sur le site dédié à ce programme mais également en participant aux forums spécifiques. Si vous avez choisi de diffuser votre programme sous licence libre, vous pourrez le faire connaître par ce biais et ainsi solliciter l’avis d’autres informaticiens. Vous bénéficierez ainsi de plusieurs expertises et pourrez proposer de cette manière à vos utilisateurs un composant corrigé et amélioré. Souscrire des contrats de maintenance Avec le développement des licences libres, plusieurs sociétés proposent des solutions, sous l’intitulé de contrats d’assurance mais qui s’apparententplusàdescontratsdemaintenance,pourlesintégrateurs de composants open source ou pour leurs utilisateurs. La majorité de ces services consiste en un travail de veille qui avertit le client de l’existence d’un patch correctif ou d’une mise à jour essentielle. D’autres solutions vont plus loin et mettent à disposition du client une équipe d’informaticiens pour réparer tout bug dans le composant libre. Certainessociétésconseillentmêmeleurclient,danslecadreducontrat d’assurance, en cas de changement de serveurs ou de systèmes…30 30 Pour plus d’information, voir L’open Source professionnalise sa responsabilité, in OVS, Octobre 2009, numéro 20, p.4, http://www.linagora.com/IMG/pdf/OVS.pdf
  • 64. 64 Veiller à remplir son obligation d’information En tant que fournisseur de solutions informatiques ou en tant que sous-traitant, vous avez une obligation d’information vis-à-vis de vos clients. Classiquement, elle se décompose en trois sous-obligations : ■■ une obligation de renseignement qui consiste à fournir au client les informations et les éléments nécessaires au bon fonctionnement du programme informatique de manière compréhensible. Cela peut porter sur l’environnement bureautique nécessaire, sur les fonctionnalités, sur la notice d’utilisation, sur le délai de livraison de la dernière version ; ■■ uneobligationdemiseengardequiviseàattirerl’attention du client sur les risques liés à l’utilisation ou à l’installation du programme. En effet, la mutation de l’ensemble des postes de travail d’un applicatif à un autre peut avoir des conséquences fâcheuses comme la perte de données. La mise en garde peut également porter sur la nécessité de former le personnel à ce nouvel applicatif ou sur l’incidence de celui-ci sur l’organisation du travail au sein de la société ; ■■ une obligation de conseil qui vise à s’assurer que le produit correspond bien aux besoins du client. Elle répond à l’obligation du client de collaborer avec le fournisseur dans la définition de ses besoins. En matière de logiciels libres, cette obligation d’information vous impose de prévenir vos clients de la présence de composants libres au sein de la solution que vous leur fournissez. Lenon-respectdecetteobligationpeutengagervotreresponsabilité comme l’a démontré le jugement rendu le 28 mars 2007 par le TGI de Paris. En l’espèce, le tribunal a refusé de prononcer la résolution du contrat aux torts exclusifs du fournisseur car celui-ci avait bien rempli son
  • 65. 65 obligation d’information en prévenant son client de la présence d’un composant sous licence libre. BONNES PRATIQUES UTILISATEURS Adopter une politique claire en matière de logiciels libres Le recours aux licences libres doit résulter d’une démarche réfléchie. Il est important de déterminer les raisons de ce choix et d’être conscient des conséquences que cela peut avoir sur votre politique commerciale. L’adoption d’une politique claire est donc nécessaire pour bénéficier de tous les avantages des licences libres de manière sereine. La liste de questions qui suit peut notamment vous aider dans l’élaboration de cette politique : Acceptons-nous de diffuser nos développements sous licence libre ? Si oui, quels développements peuvent être concernés par une diffusion sous licence libre  ? Les programmes que nous avons intégralement développés  ? Les programmes initialement sous licence libre que nous avons modifiés  ? Les programmes au sein desquels nous avons intégré des composants sous licence libre ? Quels sont les risques que des composants sous licence libre soient intégrés dans nos produits sans qu’on en soit préalablement averti ? Est-il opportun de demander à nos sous-traitants de respecter une charte en la matière ? Sinousintégronsdescomposantslibresdansnosproduits,préférons- nous mobiliser du personnel afin d’assurer leur maintenance et procéder à une veille sur les améliorations publiées au sein de la communauté du libre ? Ou préférons-nous souscrire à une solution d’assurance proposée par une société tierce ?
  • 66. 66 En cas de conflit de licence entre deux composants, quelle position adoptons-nous ? Réécrivons-nous les deux composants ? un seul ? Recherchons-nous d’autres composants ? Limitons-nous le recours aux logiciels libres aux seuls logiciels bénéficiant d’une certaine assise au sein de la communauté libre ou acceptons-nous de prendre le risque d’utiliser un logiciel libre ne bénéficiant pas d’une telle popularité et donc d’une telle expertise ? Il peut être opportun de dresser une liste des licences libres les plus connues compatibles avec certaines des réponses apportées au questionnaire ci-dessus ou d’établir un tableau avec les principales caractéristiques des licences (caractère fort, faible ou inexistant du copyleft, compatibilité entre elles, obligations spécifiques…). Les industriels n’ont d’autre choix que d’apprendre à utiliser [le logiciel libre] dans le respect des licences et dans les limites autorisées par leur politique industrielle et celles de leurs clients. Cet apprentissage doit s’inscrire dans la durée par la mise en place d’une gouvernance du logiciel libre au sein de l’entreprise et par la constitution d’un comité de pilotage s’assurant de la mise en œuvre et du respect de cette gouvernance sur le long terme. Cette gouvernance décidera notamment : ■■ de la création (collecte et/ou rédaction) du fonds documentaire de référence ; ■■ du plan de formation et de sensibilisation de l’ensemble des collaborateurs concernés (formations spécialisées en fonction des catégories professionnelles et des besoins) ; ■■ des règles d’usage du logiciel libre (quand, quoi, comment ?) et les bonnes pratiques ; ■■ des règles de sélection des composants libres, ces derniers étant en priorité puisés dans un catalogue de composants qualifiés constitué au fil de l’eau par l’entreprise ; ■■ des processus de qualification de nouveaux composants quand ceux disponibles dans le catalogue s’avèrent inadaptés ou non optimaux ; ■■ des modalités de vérification du respect des règles et des licences (mise en œuvre des outils de Black Duck Software, Palamida, Protecode, OpenLogic ou Antelink ou de logiciels libres tels que Fossology) ; ■■ des règles de contribution à des projets libres et de publication d’outils sous licence libre ; ■■ des fonctions impliquées dans le processus et de leur mission, ainsi que de la nomination de référents locaux et à l’échelle de l’entreprise. Sébastien Dinot, vice-présidentdel’April
  • 67. 67 En tout état de cause, avant de se lancer dans l’aventure du libre, une société devra prendre le temps d’établir une véritable politique en la matière. Informer et sensibiliser les salariés et les partenaires Une fois votre politique à l’égard des logiciels libres adoptée, vous devez informer les personnes en charge de vos développements de celle-ci et leur expliquer les raisons de cette politique. Cette information peut prendre la forme d’un guide de bonnes pratiquescommel’avaitfaitl’ADAE(l’Agencepourledéveloppement de l’administration électronique) pour les agents publics31 ou d’une charte. Le choix du type de document peut emporter des conséquences juridiques sur son caractère contraignant ou non. Ainsi, plusieurs décisions de la Cour de cassation ont approuvé le licenciement d’un salarié pour non-respect de la charte informatique de l’entreprise32 . Vous pouvez également demander à vos sous-traitants de s’engager à respecter le document que vous aurez établi quant à l’usage des licences libres. 31 Guidepratiqued’usagedeslogicielslibresdanslesadministrations : http://www.adullact.org/IMG/pdf/GuideLLadministrations-V1.2.0.pdf 32 Cass.Soc.5juillet2011,pourvoiN°10-14685 ;Cass.Soc.15décembre2010, http://www.legalis.net/spip.php?page=jurisprudence-decision&id_article=3060. Je conseille aux entreprises d’instaurer une obligation à tous les programmeurs de déclarer les logiciels libres qu’ils utilisent. Cela ne peut fonctionner que sur un mode déclaratif car on ne peut pas contrôler un développeur. Le problème doit être pris à la base : il faut prévoir des formations, de l’information et une obligation de déclaration. Isabelle Renard, Avocat,ExpertisesN°362,Octobre2011
  • 68. 68 Mettre en place un système de travail collaboratif La majorité des professionnels du droit ayant déjà travaillé sur le sujet des licences libres s’accordent sur l’importance de mettre en place un système de travail collaboratif entre les juristes et les informaticiens. Les premiers devront étudier les licences en jeu, déterminer la faisabilité des obligations qu’elles imposent et solutionner les problèmes de compatibilité qui peuvent survenir. Quant aux seconds, ils auront la charge d’expliquer le logiciel, d’indiquer les composants sous licence libre utilisés, le nom de la ou des licences utilisées, les éventuelles interactions entre les différents composants pour que les juristes puissent déterminer s’il y a ou non contamination. Ce système peut revêtir différentes formes : des réunions de travail en amont et en aval du développement, un document déclaratif à remplir au fur et à mesure du développement et à transmettre au service juridique… Le but de ce système est d’assurer une traçabilité des composants libres : savoir sur quel site il a été téléchargé, sous quelle licence il est diffusé,dansquellepartieducodeilestintégré,quellefonctionnalité il remplit. Auditer les codes sources Lorsque vous commandez une solution informatique spécifique, ou que vous sous-traitez certains développements, il est conseillé de vous assurer du contenu des sources qui sont livrées. En effet, si des composants libres y sont intégrés, vous devenez débiteurs d’obligations contractuelles dès lors que vous décidez de distribuer cette solution. Il est possible de déléguer du personnel pour effectuer cet audit.
  • 69. 69 Cependant, ce process est long, coûteux et soumis aux erreurs internes. En effet, il s’agit d’une recherche manuelle à partir de mots-clés. Une fois les codes sources libres détectés, il faut identifier la licence et vérifier ensuite la compatibilité de l’ensemble des licences entre elles… La détection des codes sous licence libre suppose que les méta-données soient correctement renseignées, ce qui n’est pas toujours le cas. Or les entreprises ne possèdent pas un catalogue de l’ensemble des codes sources diffusés sous licence libre. C’est pourquoi les services proposés par les sociétés d’audit de codes sources peuvent se révéler utiles. Ces dernières vous proposent d’analyser les codes sources que vous leur remettez afin de dresser la liste des composants libres présents dans votre produit, des licences utilisées et d’attirer votre attention sur les éventuelles incompatibilités et interactions de ces licences. Elles utilisent pour cela des outils spécialisés et disposent de bases de données très étendues permettant de détecter un nombre important de codes sources sous licence libre, même si les méta- données sont mal renseignées. Le résultat de l’audit que vous remettent ces sociétés n’est pas une simple compilation des logiciels et des licences libres présentes. Il attire votre attention sur les spécificités de certaines licences libres oudecertainslogicielslibres(notammentsurlaprésenced’éléments de cryptologie) pouvant empêcher l’exploitation du produit final ou, du moins, la soumettre à certaines restrictions. Les sociétés d’audit de codes sources décèlent également les incompatibilités entre les différentes licences libres. Déposer auprès d’un tiers de confiance les modifications que vous avez effectuées En acquérant un logiciel libre, vous pouvez le modifier et l’intégrer à une solution plus complexe. Un certain nombre de licences vous
  • 70. 70 oblige à vous identifier en tant qu’auteur des modifications. Il est intéressant de doubler cette précaution par un enregistrement auprès d’un tiers de confiance. Vous serez ainsi en mesure de prouver que les modifications que vous avez apportées ne sont pas à l’origine d’un dysfonctionnement ou qu’elles n’ont eu aucune incidence sur un éventuel bug. Concrètement, lors de l’enregistrement de vos développements, le tiersdeconfiancevamettrelesupportnumériquesurlequelvousles aurez enregistrés sous scellés. Il va également émettre un document mentionnant notamment la date de cette mise sous scellés. Ce scellé ne pourra être ouvert que dans des cas limités et définis par le tiers de confiance. Toute ouverture en dehors de ces cas fait perdre toute force probante à votre enregistrement. Il pourra notamment être ouvert sur décision de justice par un expert mandaté par le tribunal pour déterminer l’origine de la défaillance litigieuse. Remerciements Pour avoir accepté de partager leur expérience de profes- sionnels quant à l’utilisation de logiciels sous licence libre, Sébastien  Dinot, vice-président de l’April, Pascal Hate, directeur associé, Merethis (éditeur open source de la suite de logiciels de supervision Centreon), Benjamin Jean, docteur en droit, président de Inno3, Maître Isabelle Renard, avocate. Sivoussouhaitezobtenirdeplusamplesrenseignements sur les licences libres vous pouvez contacter le service juridique de l’APP par téléphone au 01.40.35.03.03 ou par email (legal@app.asso.fr).