Séminaire "Construire son projet sur du libre : quelles précautions prendre ?"

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 30/04/09
  • Correction mineure : 11/05/10
Mots-clés

Séminaire "Construire son projet sur du libre : quelles précautions prendre ?"

  • Type de ressource : compte-rendu, événement
  • Date de publication du document ou de l'événement : 4 février 2009
  • Auteur(s) ou responsable(s) : le Cabinet Alain Bensoussan Avocats a organisé ce séminaire (petit déjeuner-débat), ce compte-rendu a été rédigé par Teresa Gomez-Diaz

Introduction

Voici quelques notes sur le petit-déjeuner - débat du 4 février 2009 "Construire son projet sur du libre : quelles précautions prendre ?", organisé par le cabinet d'avocats Alain Bensoussan (Paris).
Ces notes peuvent être inexactes, incomplètes et refléter les centres d'intérêt d'une informaticienne du CNRS. Aucune erreur dans ce texte peut être atribuée aux conférenciers ou au cabinet d'avocats Alain Bensoussan.
Tout au long de ce texte, je note par LL les logiciel(s) libre(s) ou le software open source.
La journée : Salle de réunions pleine à craquer, autour de 110 participants. Public assez orienté entreprise/PME, avec quelques assistants qui connaissent bien le domaine LL. La réunion commence vers 9H15, finit vers 12H30 après beaucoup de questions et une longue discussion.
Cette fiche est un complément pour la Fiche Plume FAQ : licence & copyright pour les développements de logiciels libres de laboratoires de recherche.

Trois présentations

  • Construire son projet sur du libre : quelles précautions prendre ? par Maître Laurence Tellier-Loniewski (département Propriété intellectuelle), http://www.alain-bensoussan.com/
  • Créer et implémenter une politique d'utilisation des logiciels libres dans l'entreprise : maîtriser les risques sur la propriété intellectuelle des actifs logiciels, par Jean-Pierre Bigot (ESALAB), http://www.esalab.com/
  • Utiliser l'Open-Source pour accélérer les développements, par Hervé Guyomard (Black Duck Software), http://www.blackducksoftware.com/

Construire son projet sur du libre : quelles précautions prendre ?

Plan :

  • le concept juridique
  • risques liés à l'utilisation
  • risques liés à la redistribution
  • démarche de sécurisation

0 - Introduction

  • les LL ont une attraction croissante (robustesse croissante)
  • les LL permettent d'acquérir une indépendance technologique
  • le modèle du LL est un modèle juridique complexe (propriété intellectuelle)
  • premières jurisprudences en France, ce qui permet de clarifier le cadre juridique

1 - Concept juridique

1.1 Il n'a pas de définition légale de LL, et libre ne veut pas dire "libre de droits" puisque tous les logiciels sont protégés par le droit d'auteur. On mentionne les 4 libertés FSF (Free Software Fondation), et on insiste sur ce qui est ou pas un LL (selon FSF). On mentionne des licences libres, CeCILL.
1.2 Licences
Libre mais pas sans risque :

  • interprétation stricte des droits consentis : ce qui n'est pas consenti est interdit
  • les libertés sont celles accordées par le titulaire des droits patrimoniaux (utilisation, copie, ...)
  • pas de respect d'une licence implique contrefaçon
  • absence de garantie technique
  • absence de garantie juridique
  • contreparties
  • risques de contamination

2 - Risques liés à l'utilisation

  • techniques (logiciel à prendre dans l'état)
  • juridiques (exclusion de garanties, obligations)

(M. Tellier-Loniewski a lu des parties du texte d'une des licences CeCILL)
Note (TGD) : ces risques sont aussi présents dans des logiciels propriétaires. Extrait d'une licence propriétaire que j'ai lue : ... X reserves the option to discontinue, in whole or in part, and at any time, offering Software Maintenance Service and/or technical support for any Program or Platform ....

3 - Risques liés à la redistribution

  • techniques
  • juridiques

(M. Tellier-Loniewski a lu des parties du texte d'une des licences CeCILL)
3.1 Licences "copyleftées"
copyleft = néologisme qui s'oppose à copyright = exclusion de monopole d'exploitation
C'est-à-dire, obligation de distribution des modifications d'un code avec la même licence que celle du code d'origine.
On parle de plusieurs types de licences et de leur compatibilité.
Note : Aucune licence ne peut s'opposer aux droits d'auteur.

4 - Premières jurisprudences en France

4.1 Premières applications jurisprudentielles sur la violation GPL en France :

Note 1 : il s'agit d'un problème juridique et technique : être capable de bien déterminer (et pouvoir montrer) la dépendance/indépendance du nouveau code par rapport au code LL d'origine (définition précise en termes d'espace d'adressage).
Note 2 (TGD) : cela explique bien les difficultés associées aux licences LL, il y a quelques jurisprudences mais pas de définition juridique, pas de décision juridique.

5 - Démarche de sécurisation

  • définir une politique lisible
  • mettre en place les démarches nécessaires pour soutenir la politique définie
  • étudier la contractualisation avec des prestataires, avec mention LL dans le contrat, exiger ou interdire l'utilisation des LL, demander (par ex.) la diffusion des nouveaux produits en tant que LL
  • faire des contrôles : des audits juridiques et techniques, attention aux salariés qui utilisent des logiciels sans faire attention aux licences, faire apparaître des clauses relatives à ce point dans les contrats de travail

Créer et implémenter une politique d'utilisation des logiciels libres dans l'entreprise : maîtriser les risques sur la propriété intellectuelle des actifs logiciels

Présentation qui définit principalement le processus d'implémentation d'une politique LL (orientée entreprise) :

  • Evaluer : exigences en matière des risques des LL utilisés
  • Elaborer une politique : préconiser les règles, les outils de traçabilité, organiser l'identification, la validation et le contrôle des LL utilisés, organiser les règles de contribution aux communautés LL
  • Auditer l'existant, implémenter des outils : procéder à un inventaire de LL et la conformité de leur usage aux obligations des licences, mettre en place des outils de traçabilité
  • Informer, sensibiliser et former : faire accepter les règles de la mise en œuvre comme enjeu et pas comme contrainte
  • Suivre la conformité et les bénéfices de la politique : mettre en œuvre les tableaux de bord "reporting" et "alerte"

Note : il a été mentionné

  • on ne peut pas déposer un logiciel ou un brevet si on n'est pas propriétaire de l'objet
  • attention à la traçabilité de tout code utilisé

Utiliser l'Open-Source pour accélérer les développements. Présentation des solutions proposées par l'entreprise Black Duck Software à des problèmes liés aux LL

Cas CISCO

Cascade dans l'utilisation d'un code en origine LL : CISCO - LinkSys - Broadcom - CyberTAN

  • CyberTAN utilise un code GPL pour adapter une distribution de linux pour Broadcom
  • Broadcom embarque le code GPL dans un chipset
  • LinkSys adopte technologie Broadcom dans un routeur
  • CISCO achete LinkSys et utilise le code GPL dans des routeurs sans diffuser le code source
    FSF accuse CISCO de violation de la licence GPL, et CISCO publie le code du routeur.

Black Duck

La solution proposée par Black Duck :

  • recensement des licences existantes (autour de 1200 licences repertoriées dans leurs bases de données)
  • logiciel Protex pour la gestion de la conformité
  • audit : confronter un code source à cette base de données pour déterminer de possibles conflits de licences

Questions

J'en ai noté quelques unes, elles ne sont pas présentées dans l'ordre. Il y a eu une longue discussion et des questions sont revenues régulièrement comme les brevets associés aux LL, le concept d'utilisation interne, de distribution, FreeBox... Sur certaines, je donne mon opinion ...

  • La première : sur les brevets et les logiciels.
  • Question sur les brevets et la diffusion de logiciel associé en LL (on ne peut pas éviter la libre diffusion du LL). Ce point n'est pas encore clair pour moi.
  • Les modalités de distribution des LL (il existe les licences qui imposent l'ouverture du nouveau code).
  • Le cas de la FreeBox a été longuement discuté.
  • Des participants ont parlé des dangers de la GPL, un assistant a répondu sur ce point que la fiabilité du noyau de Linux est un des résultats positifs de ce modèle de développement.
  • Qui est le propriétaire des droits dans le cadre des collaborations ?
  • Distinction de l'utilisation en interne des LL : le problème est la définition d'usage interne, par exemple dans le cadre des entreprises filiales. La solution : bien rédiger les contrats qui définissent les collaborations entre les entreprises.
  • La signification du mot distribution est différente en anglais et en français, quand il est utilisé dans un contrat (tout comme la traduction de "free" en français).
  • Qu'arrive-t-il si l'on utilise un logiciel commercial qui devient libre après (ou le contraire) ? La solution est l'utilisation des doubles licences.
  • Une question très concrète sur la licence d'un site web développé pour un client : est-ce une utilisation interne ? Le problème de licence ne se pose pas, bien rédiger le contrat.
  • La licence libre n'a pas de limite territoriale (alors qu'on peut dire qu'un contrat a validité en France), c'est la réponse à une question compliquée sur l'exportation du code vers un autre pays. Sur ce point on a mentionné qu'il y a des pays avec des logiciels interdits et que Ubuntu peut lancer des messages d'alerte s'il détecte l'installation d'un de ces logiciels (mais ne peut pas empêcher l'installation).
  • Question sur l'utilisation des logiciels diffusés sans licence : effectivement tout droit qui n'est pas explicitement octroyé est interdit, donc l'utilisation est interdite.

Quelques idées que j'ai retenues

  • Il est intéressant d'avoir la vision juridique.
  • Le droit international n'existe pas (uniquement droit anglosaxon, européen, ...)
  • Aucune licence ne peut s'opposer aux droits d'auteur (ceux-ci prévalent sur les droits accordés/interdits par les licences)
  • Le droit d'auteur est indépendant du type de distribution et inaliénable : il doit être respecté quel que soit le type de distribution (par exemple, chipset FreeBox).
  • Les cas d'étude : TGI Paris Educaffix/CNRS, FreeBox, Cisco ...
  • Ce qui sera décidé pour la FreeBox aura une grande importance pour les logiciels embarqués des futurs téléphones, c'est un gros enjeu économique.
  • En France on peut rédiger et utiliser des contrats qui ne sont pas rédigés en français. Il faut faire attention aux documents traduits (il y a des termes comme "free", "distribution" qui posent des problèmes de traduction).
  • Le problème juridique sur un conflit de licence revient à montrer l'indépendance du code produit avec le code LL d'origine.
    Il y a une définition très technique de ce qui est un module interne/externe par rapport à l'espace d'adressage.
  • Ce qui n'a pas été dit suffisamment dit (à mon avis) : l'utilisation des LL est un choix.
  • Le cadre juridique des LL continue à ne pas être clairement établi.
  • Les contrats inclueront de plus en plus des points sur l'utilisation et la diffusion des LL, contrats entre entreprises et contrats avec les salariés.
  • On ne peut pas déposer un logiciel, un brevet si on n'est pas propriétaire de l'objet (immatériel parfois).
  • Les brevets peuvent être utiles pour protéger des fonctionnalités liées à un logiciel et contenir des clauses sur la diffusion libre de ces logiciels (voir, par exemple, Propriété Intellectuelle et Logiciels par l'Association Française Des Editeurs de Logiciels, question 14, page 16).

Commentaires

Logiciels libres et Freebox : vers la fin d’un conflit ?

Free annonce (août 2011), par le biais d’une nouvelle version de ses CGV, la mise en place d’un site web consacré aux logiciels open source utilisés dans ses boîtiers Freebox.

Voir : http://www.freenews.fr/spip.php?article10578