Il est fréquent que les éditeurs d’applications connectées à une base de données concluent avec l’éditeur du SGBD un contrat de partenariat leur permettant de vendre des licences du SGBD spécifiques à leur application.
Par exemple, l’éditeur d’un ERP adossé au SGBD Oracle va conclure un contrat de partenariat avec Oracle lui permettant de vendre à ses clients, en même temps que les licences de son ERP, les licences Oracle nécessaires, qui ne pourront être utilisées que pour les besoins de cet ERP, à l’exclusion de toute autre utilisation.
L’éditeur de l’application (parfois appelé « ISV » – Independent Vendor Software), l’éditeur du SGBD et l’utilisateur tirent tous trois avantage de ce partenariat :
- Pour l’éditeur du SGBD, c’est un moyen d’agréger autour de lui un réseau d’ISV partenaires développant des applications sous son SGBD, donc d’étendre la diffusion et la notoriété de ce SGBD.
- Pour l’éditeur de l’application, c’est un moyen de fidéliser (pour ne pas dire de verrouiller) le client, puisque celui-ci serait contraint de racheter des licences du SGBD s’il décidait ultérieurement de changer d’application.
- Pour le client final, l’intérêt est que ces licences « bridées » (parfois appelées « licences runtime », même si les deux notions sont en réalité distinctes) sont généralement vendues à un prix inférieur à celui qu’il devrait payer pour acquérir une licence classique (non « application specific ») directement auprès de l’éditeur du SGBD.
Le client doit néanmoins être conscient des risques et limites de ce système… et l’expérience montre qu’il l’est rarement.
Tout d’abord, il doit savoir que, par définition, ces licences « application specific » (appelées par exemple « ASFU » chez Oracle ou « ASL » chez IBM) ne pourront pas être utilisées autrement qu’en combinaison avec l’application concernée. Ces licences SGBD ne pourront donc pas être réaffectées, au sein de l’entreprise à d’autres applications. En cas de problème majeur avec l’application (par exemple en cas d’échec du projet d’implémentation de l’ERP ou du progiciel de Supply Chain Management), il sera difficile pour le client d’obtenir le remboursement des licences du SGBD… dont il ne pourra pourtant rien faire puisque ces licences sont strictement liées à l’application en cause.
Par ailleurs, la licence du SGBD est souvent plus restrictive que la licence de l’application, mais paradoxalement, le client ne connaît pas toujours les termes de cette licence…
Juridiquement, le schéma est en effet le suivant : le contrat de partenariat conclu entre l’éditeur du SGBD et l’éditeur de l’application impose à ce dernier de conclure avec ses clients un « contrat de licence d’utilisateur final » (CLUF), lors de chaque vente de licence du SGBD.
Le contrat de partenariat définit généralement les clauses que l’éditeur de l’application doit impérativement faire figurer dans le CLUF.
Or, première difficulté, le partenaire n’est pas toujours conscient de ce schéma juridique et a tendance à considérer que la licence est concédée directement par l’éditeur du SGBD (et que la maintenance y afférente est fournie directement par ce dernier… qui n’a pourtant aucun lien contractuel direct avec le client).
De ce fait, deuxième difficulté, l’éditeur-partenaire ne respecte pas toujours son obligation de faire signer un CLUF par le client. Parfois, il ne dispose même pas d’un CLUF standard ou, lorsqu’il a pris soin d’établir un CLUF, celui-ci n’est pas conforme aux exigences imposées par le contrat de partenariat de l’éditeur du SGBD.
Et par conséquent, troisième difficulté, le client n’est que rarement pleinement informé des droits d’utilisation qu’il détient réellement sur le SGBD.
Pour prendre un exemple concret, dans son contrat de partenariat (accessible en ligne sur son site), Oracle impose à ses partenaires distribuant des licences ASFU (« Application Specific Full Use ») de faire figurer dans le CLUF des clauses :
(1) limitant l’utilisation du SGBD à la personne morale ayant signé le CLUF ;
(2) limitant l’utilisation du SGBD à l’application et à l’activité interne propre de l’utilisateur final.
Typiquement ces deux contraintes (qui ne seront pas portées à la connaissance du client si l’éditeur-partenaire n’a pas établi de CLUF ou si son CLUF n’est pas conforme aux exigences du contrat de distribution de licences ASFU) seront en contradiction avec le contrat de licence d’application de l’éditeur-partenaire si cette licence est concédée (comme le client le demande souvent) à l’ensemble des filiales du groupe, pour les besoins de chacune.
Dans cette hypothèse fréquente, le client se trouvera sans le savoir en contrefaçon des droits de propriété intellectuelle de l’éditeur du SGBD et en cas d’audit de conformité, la régularisation pourra s’avérer douloureuse.
(*) Alexis est avocat au barreau de Paris, spécialisé dans le droit des contrats informatiques. Plus d’information sur le site www.baumann-avocats.com.