1. Contrefaçon : l’autre visage du conflit Blue Mind vs. Linagora

Depuis 2012, un contentieux oppose Blue Mind à Linagora, deux éditeurs de solutions collaboratives open source.

Linagora a initié deux procédures parallèles :

– Une devant le Tribunal de Commerce (le « TC ») (rebaptisé Tribunal des activités économique) pour violation de la garantie d’éviction, à la clause de non-concurrence et au devoir de loyauté entre actionnaires.

– Une seconde devant le Tribunal de Grande Instance (désormais le Tribunal Judiciaire) pour violation du droit d’auteur et contrefaçon de logiciels

Dans les deux premiers épisodes, nous avons exploré le volet corporate : d’abord le pacte d’actionnaires, puis la garantie légale d’éviction.

Dans ce troisième épisode, la bataille porte sur le code source du logiciel.

Rappel du contexte :

Vous savez déjà tout sur les faits grâce aux deux précédents épisodes mais, à la manière d’une saison 3 de games of Thrones, nous vous redonnons les détails à garder en tête.

En 2007, Linagora rachète Aliasource, éditrice d’un logiciel de messagerie collaborative intitulé OBM. Ce logiciel est expressément listé parmi les éléments rachetés par Linagora.

Un ingénieur informatique – appelons le Raoul -, poursuit son activité chez Linagora du fait du rachat. En 2009, après le rachat et alors qu’il est salarié de Linagora, il publie le module O-PUSH depuis son site personnel sous licence open source.

En 2010, il quitte Linagora. Il rejoint brièvement une autre structure puis rejoint Blue Mind deux ans plus tard.

Or Blue Mind commercialise à son tour une solution open-source intégrant deux modules intitulés BM-CORE et EAS, que Linagora estime être des copies des modules OMB-SYNC et O-PUSH.

En 2010, un jugement est rendu par le TGI de Bordeaux.

Mais s’il y a bien une chose sur laquelle les parties étaient d’accord, c’est que le jugement de première instance du TGI de Bordeaux ne convenait pas. Blue Mind et Linagora ont toutes les deux fait appel du jugement.

C’est donc la Cour d’appel de Bordeaux qui a eu la tâche de les départager dans un arrêt dense et technique du 27 janvier dernier.

Le cœur du litige : deux modules

Tout l’enjeu du litige est de déterminer si les deux modules open-source intégrés au logiciel OBM constituent de la contrefaçon vis-à-vis de la solution de Linagora.

En d’autres termes, les modules open source d’OBM copient-ils, illégalement, la technologie de Linagora ?

Les circonstances sont différentes :

• Le module O-PUSH : il a été développé par Raoul, l’ancien salarié de Linagora, devenu salarié de Blue Mind
• Le module OBM-SYNC : pour ce module, il n’y a pas de débat sur la titularité, les parties sont d’accord sur le fait qu’il appartient à Linagora. Ce module a été publié sous licence open source par Linagora, ce qui permettait à Blue Mind de l’utiliser légalement, mais à condition d’en respecter les termes.

Concernant le module O-PUSH :

Premier point du débat : la titularité.

Qui est propriétaire : Linagora ou Raoul le salarié ?

En effet, clou du spectacle, le salarié est intervenu pour faire valoir ses droits.

Selon lui, il est l’unique propriétaire de ce module qu’il a développé sur son temps libre pour un besoin personnel.

Linagora considère qu’elle est propriétaire pour plusieurs raisons :

• Le module a été développé par le salarié dans le cadre de ses fonctions, il y a donc un transfert automatique des droits selon l’article L113-9 du CPI
• Le contrat de travail du salarié prévoyait une clause de transferts de tous les éléments de propriété intellectuelle créés par le salarié pendant sa mission au profit de Linagora.

Mais la Cour d’appel retient les points suivants :

• Le module O-PUSH a été publié la première fois par le salarié sur son site personnel. Il est donc présumé titulaire de l’œuvre, sauf démonstration contraire par Linagora.
• Le contrat de travail de Raoul, repris par Linagora au moment du rachat, limite la cession des droits aux éléments créés par Raoul « dans l’exercice de ses fonctions ». Elle considère qu’il faudrait donc démontrer que O-PUSH a été créé sur le temps de travail, avec les moyens mis à disposition par Linagora, et sous les ordres de Linagora.

Or, aucune preuve ne montre que O-PUSH a été développé dans ces conditions.

La Cour ajoute que le module O-PUSH n’a pas été spécifiquement visé dans l’acte de cession lorsque Linagora a racheté Aliasource (La boulette…, mieux vaut bien relire l’acte de cession (le SPA) quand le logiciel est l’asset principal).

Dans son rapport, l’expert relève qu’il est étrange que la société Linagora ait laissé Raoul publier le logiciel sur son site personnel alors que ce n’était pas dans son intérêt mais il relève que puisque c’était un logiciel open source, la société a dû considérer qu’elle pourrait de toute façon y avoir accès.

L’expert conclura : « on ne peut pas nier le fait que les managers de Linagora ont accepté que M. [M] soit auteur avec la licence qu’il a affecté à O-PUSH’. »

Conclusion : la titularité revient au salarié, pas à Linagora.

Blue Mind n’a donc pas commis d’acte de contrefaçon puisque ce n’est pas Linagora qui est propriétaire.

Pour le second module : OBM-SYNC :

La question était différente.

Ici, pas de débat sur la propriété : OBM-SYNC appartient à Linagora.

Mais Blue Mind conteste l’originalité du module – un prérequis pour toute protection par le droit d’auteur.

Petite pause définition : L’originalité, c’est ce qui permet à une création d’être protégée : en droit d’auteur, une œuvre est originale si elle reflète des choix personnels et créatifs de son auteur, et non de simples contraintes techniques ou des automatismes.

Le premier tribunal avait suivi Blue Mind. Mais la Cour d’appel retient l’inverse.

Le logiciel est original.

Il est donc protégeable.

Mais il reste une question centrale : y-a t’il contrefaçon, alors même que le code est publié sous licence open source ? Car open source ne veut pas dire “gratuit et sans condition” : si les règles fixées par la licence ne sont pas respectées, son utilisation peut devenir illégale.

Pour garder une taille raisonnable sur cet épisode, on s’arrête là. Mais si votre curiosité est piquée et que vous voulez savoir :

– Comment Linagora a réussi à faire reconnaitre l’originalité du logiciel ?

– Comment Linagora a réussi à faire condamner Blue Mind à publier l’encart ci-dessous sur son site internet ?

Alors cliquez sur le bouton ci-dessous pour recevoir ce décryptage complémentaire.

Recevoir le décryptage

2. Le Temps technique : pourquoi la garantie légale d’éviction a été mise en échec

L’article L.113-9 du Code de la propriété intellectuelle prévoit que :

« Sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l’exercice de leurs fonctions ou d’après les instructions de leur employeur sont dévolus à l’employeur. »

Autrement dit :

• Le transfert automatique s’applique uniquement si le logiciel est créé dans l’exercice des fonctions du salarié ou sur instruction de l’employeur.
• Si le salarié développe un logiciel en dehors de ses fonctions, sur son temps libre, sans lien avec l’entreprise, il reste titulaire des droits.

L’histoire du jour, rappelle que les juges prennent en compte les critères suivants pour apprécier si le transfert automatique des droits au profit de l’employeur a eu lieu :

• travail réalisé sur le temps de travail,
• avec les moyens fournis par l’entreprise,
• sous les ordres de l’employeur,
• dans le cadre des missions prévues par le contrat.

Plus le nombre de critère réuni est important, plus il y a de chance que le juge retienne le transfert automatique.

D’où l’importance de :

1. conserver des preuves montrant que le logiciel a bien été conçu par le salarié dans le cadre de ses fonctions,
2. rédiger une clause de cession contractuelle, pour sécuriser la titularité au-delà du seul L.113-9, et ce d’autant plus si le développeur ne se contente pas de coder mais également de designer des interfaces qui sont susceptibles d’être protégées par le droit d’auteur. Dans ce cas, on n’oublie pas de réitérer la cession des droits, puisqu’il n’est pas possible de céder des œuvres qui ne sont pas encore créées.
3. réaliser un audit juridique rigoureux, mené par des avocats maîtrisant à la fois les enjeux corporate / M&A et les spécificités des actifs tech : la titularité du code source, les clauses RGPD, les dépendances open source ou encore les contrats freelances doivent être analysés à la lumière du droit et des usages du secteur.
   C’est souvent à ce stade que se joue la valorisation — ou la fragilisation — d’un deal.

Vous ne pourrez pas dire que vous ne le saviez pas.