1- Quel est l’historique du litige ?
En 2007, Linagora, une entreprise spécialisée dans les logiciels open source, acquiert la société Aliasource (anciennement Aliascom), éditrice de la messagerie open source Obm, fondée par Pierre Baudracco et Pierre Carlier. Après la cession, l’ex-fondateur de la société Aliasource, Pierre Baudracco crée en 2010 la société Bluemind, proposant une nouvelle solution de messagerie éponyme.
Linagora accuse alors Bluemind de réutiliser illicitement des codes sources d’OBM et de détourner sa clientèle.
2- Qu’est-ce que l’open source sur le plan juridique ?
Un logiciel open source est un logiciel dont le code source est rendu accessible à tous, avec la possibilité de l’utiliser, le modifier et le redistribuer, sous réserve du respect d’une licence spécifique. Contrairement aux logiciels propriétaires, l’open source repose sur un modèle de collaboration, souvent communautaire, mais cela n’exclut pas une protection juridique du contenu
Les principales licences open source (GPL, MIT, Apache, BSD…) encadrent précisément :
- les droits d’utilisation ;
- les obligations de redistribution ;
- la propriété du code initial et dérivé.
- la mention des auteurs.
Ainsi, la liberté d’usage est conditionnée au respect des termes de la licence. Enfreindre ces conditions peut entraîner une action en contrefaçon, au même titre qu’une violation de logiciel propriétaire.
3- L’originalité au cœur des débats.
Deux modules de la solution Blue Mind sont au cœur du litige, à savoir « Bm Core » et « Eas », lesquels peuvent être utilisés gratuitement sous réserve de l’acceptation des conditions d’utilisation stipulées par le contrat de licence GPL (General Public License). Les différents rapports d’expertises font ressortir que ces deux modules sont en fait des copies serviles des deux modules « Obm-Sync » et « O-Push » de la solution Obm de la société Linagora.
La société Linagora affirme donc que les modules, bien qu’open source, sont protégés par le droit d’auteur en raison de leur originalité, laquelle résulterait notamment de choix de conception et d’un effort de développement important (environ 80 000 lignes de code).
Cependant, les conclusions de l’expert judiciaire, tout comme le jugement de première instance, ont successivement retenu une absence d’originalité, estimant que les éléments techniques avancés (choix des technologies, architecture, base de données) concernaient davantage l’ensemble du logiciel Obm que les modules en cause spécifiquement.
A l’inverse, la cour d’appel retient que « l’effort de personnalisation est suffisamment caractérisé tout au long du développement du programme et permet de retenir l’originalité du module logiciel Obm-Sync, travail empreint de la personnalité de son auteur, portant la marque des salariés Linagora, de sorte que celle-ci bénéficie de la protection au titre des droits d’auteur sur ce module logiciel ».
En effet, à la lecture du jugement de première instance, l’on pouvait s’interroger sur la manière dont il était possible de reconnaître l’originalité d’une solution dans son ensemble, tout en refusant de reconnaître le travail conséquent réalisé sur l’une de ses parties, pourtant essentielle à l’échange d’informations avec un haut niveau de fiabilité et dans des conditions exigeantes en matière de temps de réponse.
4- L’absence problématique de mentions de paternité.
L’originalité des modules open source étant reconnue il ne restait plus qu’à la cour de constater l’existence d’actes contrefaisants, un préjudice ainsi qu’un lien de causalité.
Il s’avère que les deux modules « Obm-Sync » et « O-Push » de la solution Obm éditée par la société Linagora étaient mis à disposition sous la licence Gnu Affero Gpl V3 qui impose en sa section 5 de respecter les mentions de paternité (auteur, notices de copyright, etc.).
En effet, comme toute licence avec un copyleft fort, il est nécessaire de :
- Mentionner les modifications intervenues : en indiquant clairement que le programme a été modifié et mentionner la date des modifications.
- Mentionner la licence applicable : en signalant de manière visible que l’œuvre est distribuée sous la Gnu Agpl v3.
- Appliquer intégralement la licence : en plaçant l’ensemble du travail, y compris ses parties modifiées, sous la Gnu Agpl v3. En effet, en vertu de l’effet « contaminant » il n’est pas possible d’appliquer une autre licence, sauf autorisation par un autre accord distinct.
- Afficher les mentions de paternité : en prévoyant sur les interfaces interactives lesdites mentions appropriées, sauf si le programme original ne le faisait pas.
Dans le litige en question, les différentes expertises ont mis en évidence l’absence de mention explicite de la paternité de Linagora, bien que certains développeurs ayant contribué à la création des modules aient été nommément mentionnés. Toutefois, ces mentions ont été jugées insuffisantes au regard de l’implication significative de Linagora dans l’évolution des modules, notamment après le départ des développeurs initiaux.
A l’issue de ce litige, la société Bluemind a été condamné à :
- verser la somme de 196 000 euros (déjà perçue par Linagora en 2020 en vertu du jugement de première instance) ;
- afficher sur son site web pendant une période de trois mois une notice résumant les principaux éléments de l’arrêt ;
- payer pour la publication d’annonces légales dans trois journaux ou publication ;
- rembourser les frais de justice engagés par Linagora dans le cadre de cette procédure.
5- Quels réflexes à adopter face aux développements open source ?
Cette solution s’inscrit dans le prolongement de l’arrêt rendu par la Cour d’appel de Paris le 14 février 2024, dans un litige opposant la société Orange à la société Entr’Ouvert, dans lequel la cour a retenu l’existence d’actes de contrefaçon résultant de la violation des termes de la licence open source Gnu Gpl V2.
Toutes ces décisions soulignent l’importance du respect des licences open source et rappelle que leur violation peut entraîner des sanctions pour contrefaçon. Raison pour laquelle, lorsqu’on intègre ou développe des solutions open source, il est essentiel de respecter un certain nombre de bonnes pratiques :
- Identifier la licence de chaque brique logicielle utilisée (Mit, Gpl, Agpl, Apache, etc).
- Respecter les obligations de licence : mentions de paternité, redistribution du code, etc.
- Conserver les fichiers d’origine (License, Readme, Notice) dans le projet.
- Documenter l’origine et l’historique des composants open source intégrés.
- Former les équipes techniques aux risques juridiques liés aux licences open source.
