Licences et modèle économique – Interview de Benjamin Jean (inno³)

Benjamin Jean est un juriste spécialisé dans les modèles ouverts. Président de la société inno³, il est aussi maître de conférences à Sciences Po, et très actif dans les communautés libres et open source. Il nous donne ici son point de vue sur le lien entre le type de licence et le type de modèle économique. Cette interview a été publié dans le livre Open Models, les business models de l’économie ouverte.

Les licences ouvertes (open source, open data, etc.) sont très nombreuses, mais elles diffèrent suivant les secteurs ou les contextes où elles sont utilisées. Comment s’y retrouver ?

Les licences libres sont apparues au milieu des années 1980, lorsque le droit d’auteur a été adapté et étendu aux logiciels. L’usage d’une licence libre caractérise donc une certaine façon pour l’auteur d’exploiter ses droits. Elles portent essentiellement sur le droit d’auteur, mais elles se sont adaptées aux évolutions des différents droits de propriété intellectuelle.

Il y a aujourd’hui plus de 70 licences labellisées open source par l’open source initiative.

En pratique, on peut en dénombrer plusieurs centaines. En effet, toutes ne sont pas certifiées. Par ailleurs les auteurs des licences peuvent les faire évoluer (plusieurs versions coexistent alors) et les utilisateurs choisissent parfois de les adapter à leurs besoins.

À cet égard, les deux premiers gros projets externes (Linux et Perl) qui ont utilisé la GNU GPL (General Public Licence) rédigée par la Free Software Foundation, l’ont fait en la modifiant. Il y avait certainement une idée de réappropriation, mais surtout la preuve d’une grande pluralité et d’une hétérogénéité au sein de l’écosystème naissant.

Dans les licences dites open source, on distingue deux classes : les licences copyleft et les licences “permissives”.

Le rythme de création des licences s’est accéléré à partir de 1998, quand Mozilla a rédigé sa propre licence pour ouvrir son code. À partir de ce moment, la sphère industrielle a pris conscience de l’intérêt de l’open source. Malheureusement, la Mozilla public licence (MPL) a amorcé une vague de prolifération des licences car elle était rédigée de telle sorte qu’on ne pouvait pas la prendre en l’état. De grosses sociétés comme IBM, SUN ou Alcatel ont rédigé alors leur propre licence libre en s’appuyant sur la MPL.

Maintenant, la multiplication des textes est déconseillée dans la sphère communautaire, compte tenu des situations d’incompatibilité que cette prolifération génère (la combinaison de plusieurs composants devenant impossible à cause de leur licence respective). IBM a été le premier à abandonner ses anciennes licences au profit de licences communes et interopérables.

Qu’est-ce qui fait le succès de telle ou telle licence libre ?

Le succès d’une licence est rattaché à ses qualités intrinsèques, mais aussi à de multiples facteurs externes (ses “supporters” industriels ou communautaires, sa langue, les projets leaders, etc.). À cet égard, dans le secteur des biens culturels, lorsque les licences Creative Commons sont apparues en 2001, elles n’étaient pas les premières à s’intéresser aux créations numériques. Ce sont les efforts de communication et de vulgarisation qui ont fait que les utilisateurs les ont adoptées et que c’est devenu un standard (au détriment de la plupart des licences préexistantes qui ont disparu).

Dans les licences dites open source, on distingue deux classes : les licences copyleft et les licences “permissives”. Au sein d’une licence copyleft, les contributions et modifications doivent être reversées sous la même licence. Les licences permissives, comme les licences BSD ou Apache par exemple, autorisent en revanche la diffusion de la création finale ou des contributions sous n’importe quelle autre licence tant que sont conservées certaines obligations généralement peu contraignantes (garder a minima le texte de la licence et indiquer le nom de l’auteur).

Les entreprises marchandes “classiques” sont de plus en plus nombreuses à utiliser des licences libres pour diffuser leur production. Quelles sont leurs motivations ?

Dans certains cas, elles sont contraintes de le faire car elles utilisent des briques ou des développements qui sont réalisés sous des licences qui imposent ce modèle de diffusion (les licences copyleft déjà évoquées).

Dans d’autres cas, elles le font pour des raisons de pragmatisme et d’efficacité. L’équation est simple : elles ont intérêt à s’appuyer sur quelque chose de préexistant et utilisé par une large communauté. Face à cela, elles ne prennent pas un grand risque car la valeur du produit final provient d’autres facteurs (savoir-faire, connaissances, combinaison, mais aussi la marque de l’entreprise ou les services qu’elle entend associer).

Les licences sont des outils pour obtenir un résultat.

Dans tous les cas, elles sont plus dans une logique d’analyse de type opportunité / risque que dans une analyse basée sur des convictions idéologiques. Les licences sont des outils pour obtenir un résultat. Notons néanmoins que de telles démarches d’ouverture peuvent emporter des conséquences bien au-delà de la seule R&D, initiant un changement de culture en généralisant la collaboration, tant vis-à-vis de ses partenaires que de ses propres salariés.

Quel est le lien entre les licences et le modèle économique ?

Il y a de nombreux liens. La première justification est directement intrinsèque de la propriété intellectuelle, principal objet de ces licences : au carrefour du droit et de l’économie, la propriété intellectuelle est l’un des actifs les plus importants de notre économie – j’y ajouterais le capital humain -. Sans surprise, la gestion de cette propriété intellectuelle au travers des licences libres et open source aura des conséquences majeures pour les organisations qui font le pas.

Les licences déterminent ce que chaque contributeur peut faire de la création commune. Elles créent ainsi un cadre qui assure la pérennité et la collaboration (par les droits qui sont ménagés).

Ensuite, la licence fournit un cadre qui explicite les droits et les devoirs des parties prenantes dans le cas d’une collaboration ponctuelle ou récurrente. Les licences déterminent ce que chaque contributeur peut faire de la création commune. Elles créent ainsi un cadre qui assure la pérennité et la collaboration (par les droits qui sont ménagés).

Ainsi, la licence expose les droits qui sont partagés  – par principe, tout ce qui n’est pas expressément partagé et conservé – et les conditions associées à leur usage. Certains modèles économiques sont impossibles en l’absence de certains droits. Seuls les titulaires de droits initiaux peuvent définir leur stratégie commerciale avec un minimum de contraintes, mais même ces derniers sont aujourd’hui obligés de penser en termes de chaîne de création et de production (la licence utilisée sur leur composant impactera la réutilisation de ce dernier). Par exemple, la société RedHat ne peut faire de dual licensing (c’est-à-dire proposer alternativement une licence commerciale) car les licences des composants qu’elle utilise imposent la diffusion en open source. A contrario, certaines organisations sélectionnent strictement les composants permettant de s’assurer une telle liberté.

On peut dire que les licences suivent le modèle économique autant qu’elles le déterminent. C’est pour cela que certains projets démarrent sous licence commerciale et se développent sous licence libre (et réciproquement).

Quelles sont les pratiques possibles au sein des projets contributifs comme les hackatons ? Et qu’en est-il des projets collectifs menés au sein des fab labs ?

J’accompagne depuis quelque temps les réflexions menées sur le sujet par le NUMA, un espace parisien dédié au numérique. L’objectif est ici de définir un cadre juridique qui rassure chaque partie prenante quant à l’exploitation qui sera faite des résultats, à l’issue d’un événement. Cela passe par la rédaction de certaines conventions entre les multiples acteurs.

Plus récemment, nous avons eu l’occasion de travailler conjointement avec les membres de l’Équipe qui souhaitaient organiser un hackaton. Cela nous a permis de définir quelques règles jugées “équilibrées” par les participants et les organisateurs : si certains continuaient leur projet ils devaient le faire de préférence avec les organisateurs. La convention stipulait également qu’à partir du deuxième jour, quand les projets commençaient à se concrétiser, les équipes devaient se réunir pour choisir une licence libre à appliquer sur leur création.

L’idée n’était pas de les destituer de leurs droits mais, au contraire, de les informer et notamment de leur expliquer que, par défaut, le statut de la cocréation est le plus compliqué des statuts existant en droit car la création plurale devient une copropriété commune à tous les contributeurs : rien ne peut être fait sans que tous les autres ne soient d’accord. Réunir tous les coauteurs et convenir d’un cadre commun d’exploitation est très compliqué a posteriori, si ce n’est impossible.

Des efforts sont à faire pour aider à optimiser la compréhension et l’acceptation de chacun. Mais il y a de toute façon une grande part de confiance. Cette remarque permet d’ouvrir aussi la discussion : s’il s’agit de leur objectif premier (instaurer une confiance pour favoriser la contribution), les licences fonctionnent elles-mêmes très souvent sur le principe de la confiance. C’est la raison pour laquelle le choix de la licence doit être réfléchi (l’usage d’une licence exotique éveillera la suspicion) et aussi ce qui explique que les potentiels contributeurs auront beaucoup plus confiance dans une licence rédigée par la FSF (Free Software Foundation) que dans une licence rédigée par une société qui édite par ailleurs des logiciels commerciaux concurrents aux principaux projets open source (Microsoft notamment, mais cela concerne bien d’autres sociétés).

Propos recueillis par Karine Durand-Garçon

Partager

Karine Durand-Garçon

À propos de Karine Durand-Garçon

Open Minded, curious & innovative Senior IT Manager.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *