Oracle – Rimini Street : ce qui se joue après 11 ans de litige

Que signifie « code source » ? C’est l’une des nombreuses questions auxquelles la justice américaine doit encore répondre dans le conflit entre Oracle et Rimini Street.

Voilà plus de dix ans que les deux entreprises s’écharpent devant les tribunaux. Oracle avait déposé la première plainte en janvier 2010. Dans les grandes lignes, il accusait Rimini Street de pratiques illégales à travers ses prestations de maintenance pour les logiciels PeopleSoft, J.D. Edwards et Siebel. On parle là de concurrence déloyale, de ruptures de contrats, de vol massif de ressources ou encore d’infraction au copyright.

L’affaire a rebondi plusieurs fois en cour d’appel. Avec des issues plus ou moins favorables à l’une ou l’autre partie. Parmi elles, une injonction décrétée à l’encontre de Rimini Street. Malgré les tentatives répétées de ce dernier pour la faire annuler, elle conserve aujourd’hui l’essentiel de sa substance. Son rôle : poser un cadre aux prestations de maintenance. L’extrait ci-dessous en illustre la principale disposition : ne pas reproduire les logiciels Oracle ou leur documentation, ni en créer des dérivés. Sauf à travailler pour un client donné qui dispose des licences adéquates… et à se conformer aux conditions spécifiques de chaque logiciel.

« Process 2.0 » : Rimini Street vraiment clean ?

La justice avait esquissé cette injonction dès 2014, à l’heure de rendre ses premières conclusions. Pour éviter cette issue, Rimini Street avait revu ses processus de développement. Notamment pour PeopleSoft, cœur de l’affaire. En particulier en arrêtant, prétend-il, de mettre, sur ses propres serveurs, des copies des logiciels de clients. Il avait ensuite déposé plainte auprès de la même juridiction qu’Oracle quatre ans plus tôt. En l’occurrence, la cour de district du Nevada. Objectif : obtenir la validation de ce « Process 2.0 », entre autres méthodes.

En l’état, on n’a toujours pas de réponse définitive à ce sujet. En tout cas sur l’affaire principale, dans le cadre de laquelle Oracle avait invité le tribunal à trancher. Celui-ci s’y est refusé, préférant en décider dans l’autre dossier – celui ouvert en 2014 et pour lequel aucune date n’est encore fixée pour la prochaine audience. Il s’est effectivement déjà prononcé sur certains aspects. C’était l’an dernier. Son constat : Rimini Street a commis plusieurs infractions de copyright, sur PeopleSoft HRMS et sur l’outil de développement PeopleTools.

Comment se traduisent ces infractions ? Principalement de deux manières :

• Prototypage d’une mise à jour de PeopleSoft sur l’environnement de dev d’un client (en l’occurrence, Campbell Soup), pour finalement la fournir à un autre client (Toll Brothers) directement en production
• Dans le même esprit, mais avec création d’un dérivé, la fourniture d’une mise à jour de PeopleTools Application Designer à plusieurs clients après développement sur l’environnement d’un autre client (la ville d’Eugene, dans l’Oregon)

Deux dossiers pour le prix d’un

Les éléments soulevés dans ce dossier secondaire se sont « mécaniquement » retrouvés dans l’affaire principale. Rimini a tenté de convaincre la justice de ne pas raisonner ainsi ; et de privilégier un examen séparé de ses « anciens » et de ses « nouveaux » processus. Les uns dans le cadre du litige d’origine ; les autres, dans le second. Une demande rejetée la semaine passée.

Oracle aussi a été débouté sur certains points. En particulier, la pratique dite « dev/retrofit ». C’est-à-dire, le prototypage d’un update chez quelques clients, puis son déploiement massif. Pour la cour de district du Nevada, il en va du « bon sens » : les équipes de Rimini Street gagnent forcément en rapidité d’exécution à mesure qu’elles acquièrent de l’expérience. Dans le même esprit, on ne considérera pas, explique le tribunal, que tout update d’un logiciel Oracle est un dérivé.

Les cas d’Eugene et de Campbell Soup sont, en revanche, problématiques. La justice estime qu’il y a faute. L’audience devra permettre de déterminer s’il y a lieu de sanctionner Rimini Street pour outrage (non-respect de l’injonction). Pour sa défense, ce dernier fait valoir que les deux cas pointés du doigt remontent à 2014 et 2015… et sont donc antérieurs à l’injonction.

La question du code source

Certains éléments nécessiteront une audition des preuves. C’est le cas concernant la présence, sur les systèmes de Rimini Street, de code issu notamment de PeopleSoft. Mais aussi de J.D. Edwards. Là se pose la question de savoir ce qu’est le « code source ». Oracle considère que le terme englobe à la fois le code ouvert et le code propriétaire… auquel se limite la perception de Rimini Street.

Une partie des griefs de la plainte d’origine ne sont plus d’actualité. Parmi eux, la violation de lois américaines sur la sécurité des systèmes d’information. Condamné en première instance, Rimini Street était parvenu à inverser la tendance. On lui reprochait d’utiliser les identifiants de clients Oracle pour télécharger massivement des ressources. Non seulement au-delà des limites des licences, mais aussi au risque de causer des interruptions de service pour les autres clients de « Big Red ».

Les deux adversaires se retrouveront à la barre le 20 septembre 2021. En attendant, ils rivalisent de communication. Rimini Street évoque, eu égard au dernier jugement, des décisions « en sa faveur sur des points clés ». Du côté d’Oracle, on annonce une « défaite sans équivoque » de Rimini Street, qui a « violé l’injonction ».

Illustration principale © Activedia – Visualhunt