Editeurs open source : modèle à double licence contre simple licence, lequel privilégier ?
Double licence : quel est l’apport réel de ce modèle d’un point de vue communautaire ? C’est la question que se pose Jonathan Le Lous dans son article Editeur open source: le modèle américain. Un article qui vient à point, car cela fait quelque temps que je ne sais plus trop quoi penser de ce modèle qui repose deux caractéristiques principales :
– Un logiciel en version communautaire considéré comme « dégradé », dans le sens où sa version n’offre aucune garantie aux utilisateurs et ne bénéficie d’aucun support de la part de l’éditeur voir dans une situation extrême il est nettement moins fonctionnel.
– Un logiciel en version privative, propriétaire qui se déploie, via des licences, et bénéficie de support au même titre qu’un logiciel classique.
Ce modèle américain est aussi analysé sous l’angle juridique par le « Dual licensing », le principe est le suivant: Vous mettez une version du logiciel en GPL dans le but de favoriser la diffusion de celui-ci et vous proposer un version classique, en terme de droit d’auteur, pour laquelle vous proposer un droit de licence d’utilisateur final.
Voilà donc pour moi l’occasion de tenter de mettre mes idées au clair sur le sujet.
Du côté de l’éditeur
Jonathan le dit dans son article c’est un modèle qui présente des avantages pour l’éditeur :
- Technique avec l’apport potentiel d’une communauté de contributeurs extérieurs,
- Commercial en bénéficiant d’une forme de publicité gratuite grâce à la possibilité offerte d’utiliser ou de tester une version du logiciel sans coût de licence.
C’est un modèle qui à mon sens a souvent été choisi, car il fait parti des stratégies de conquête d’un marché sur lequel existe déjà une concurrence bien installée. Il est rare que les éditeurs de niche adoptent ce modèle. En effet, dans ce cas, la peur d’être copié est un frein à l’adoption du modèle open source.
Si l’on observe les quelques exemples donnés par Jonathan : Red Hat, Zimbra, Alfresco, MySQL, ils sont chacun arrivés sur des marchés matures, avec une offre déjà existante et au parc de clients important. Respectivement : les systèmes d’exploitation pour serveur d’entreprise, le groupware, la gestion de contenu, les bases de données.
L’absence de coût de licence constitue un avantage commercial indéniable pour « casser » le marché. Les éditeurs propriétaires ont bien saisis la tendance, car ils proposent de plus en plus souvent une version gratuite de leur logiciel, mais bridée ou appauvrie en fonctionnalité.
A partir de là on peut se demander si l’avantage commercial n’est pas la première voir la seule motivation de ces éditeurs. Il faut alors observer leur comportement vis-à-vis de la constitution d’une communauté autour de leur logiciel. De ce point de vu là la tentation de freiner l’entrée de contributeurs pour garder le contrôle total des évolutions du logiciel est grande. Une dérive qui peut mener ces éditeurs à un comportement quasi fermé vis-à-vis de l’extérieur. C’est ce que l’on qualifie de fauxpen source. Et là l’apport pour la communauté open source est quasiment nul.
Pourquoi la communauté est-elle importante pour l’entreprise utilisatrice ?
Rappelons-nous qu’un des avantages des logiciels open source est d’apporter une plus grande pérennité aux logiciels grâce à une communauté active et participant au développement du coeur du logiciel et pas seulement de modules périphériques. Or l’absence de communauté revient à se retrouver avec l’équivalent d’un logiciel propriétaire dont la survie sera conditionnée par le rachat de celui-ci en cas de faillite.
L’autre inconvénient et on peut le voir avec le rachat de Sun par ORACLE, est l’incertitude que cela peut créer lors d’un rachat par un concurrent. L’absorption pouvant aboutir soit à la disparition progressive du logiciel soit à la limitation de son développement technique et fonctionnel. Dans les deux cas, cela ne sera pas en faveur de l’utilisateur final.
Doit-on en conclure que ce modèle est à éviter, car souvent associé à un faible développement communautaire et donc à la perte d’un avantage significatif pour l’utilisateur ? On arrivera toujours à trouver des contre-exemples et cela mériterait une étude approfondie des pratiques de chacun des éditeurs.
La pratique de la licence simple, gage de pérennité ?
C’est un modèle qui rend plus difficile l’objectif de rentabilité recherché par tout éditeur de logiciel. En adoptant ce modèle, il se coupe d’une source de revenus que sont les licences. Ce qui explique que bien souvent ils connaissent une évolution plus lente que leur concurrent à double licence.
Mais ce sont des éditeurs qui ont souvent une approche plus communautaire du développement avec une ouverture à des contributeurs externes qui participent également au développement du coeur du logiciel. C’est une façon de compenser ces revenus qui peuvent faire défaut en tentant de maximiser cet avantage de l’éditeur.
Concernant ces bonnes pratiques, Vincent Massol a mis en ligne une présentation (nécessite Flash) expliquant l’approche adoptée autour du développement du logiciel XWiki. Il est intéressant d’y apprendre qu’il y a 15 committers (pour moi cela signifie qu’ils peuvent transmettre des modifications sur le serveur central du projet) dans la communauté pour 12 employés par Xwiki SAS l’éditeur. Bien sût il faut relativiser et prendre aussi en compte le temps passé par ces comitters externes pour le comparer au 12 de l’éditeur qui travaillent probablement à plein temps sur le projet.
Pour finir, il va sans dire que le modèle à simple licence ne crée pas d’utilisateurs à deux vitesses. Tout le monde a accès aux mêmes fonctionnalités ce qui ne peut qu’élargir la base des contributeurs possible sur l’ensemble des fonctionnalités du logiciel. En tant qu’utilisateur, j’ai donc tout intérêt à privilégier ce type d’éditeur.
Encore une fois, je suis conscient qu’il existe des contre-exemples à chacun des cas que j’ai indiqués ici. Cependant, les éditeurs qui privilégient le développement d’une vraie communauté contribuent à la pérennité du logiciel qu’ils éditent et donc en tant qu’utilisateur, j’ai intérêt à les privilégier. C’est un point clé à étudier lorsque l’on doit choisir entre plusieurs solutions open source. Ce n’est pour l’instant qu’une impression générale qui reste à confirmer, mais je pense que ce sont les éditeurs pratiquant la simple licence qui sont le plus souvent dans ce cas.
Bonjour,
Merci Philippe d’apporter ces éléments de réponses à cette différence en terme de contributions et de modèle.
A bientôt,
Jonathan
> « voir dans une situation extrême il est nettement moins fonctionnel »
À strictement parler, le dual-licensing consiste à diffuser un même produit logiciel sous deux licences différentes. Si on retire des fonctions, ce n’est plus le même produit et ce n’est plus du dual-licensing.
> « ne bénéficie d’aucun support de la part de l’éditeur »
Pas forcément, Nokia vend du support pour les versions GPL et LGPL de Qt par exemple[1].
Pour l’absence de communauté, je suis d’accord dans le cas du dual-licensing proprio/GPL : mécaniquement les ajouts à la version GPL ne s’ajoutent pas à la version proprio (sauf à faire don du code à l’éditeur, mais pourquoi lui faire ce cadeau ?), et donc à moins de forker, cela empêche les contributions, et donc l’apparition d’une communauté.
Si on veut voir apparaitre une communauté, soit on diffuse sous GPL uniquement, mais il est impossible de réutiliser pour faire du propriétaire (pas forcément un mal, mais tout dépend de ce que l’on veut), soit on diffuse sous BSD ou LGPL, mais réutiliser pour faire du propriétaire ne présente aucun cout supplémentaire…
[1] http://qt.nokia.com/products/licensing où on peut lire « Not included but available separately for purchase »
Bonjour,
Pour comparer les deux modèles de lience, je pense qu’il faut revenir aux fondamentaux : nous voulons des logiciels présents, donc qui ont trouvé des contributeurs, pérennes, et libres d’évoluer si quelqu’un veut s’en charger.
La situation me semble plus complexe que le propos de l’article, car :
– un logiciel qui ne trouve pas de communauté de bénévoles à un moment donné, n’est pas forcément un logiciel sans intérêt, et il peut choisir la licence double pour permettre par exemple dans l’avenir, si l’entreprise commerciale s’arrête après quelques années de succés, de pouvoir encore faire évoluer le logiciel grâce à une nouvelle communauté qui reprendra la version GPL,
– les ajouts à la version GPL peuvent faire l’objet de don du copyright à l’éditeur initial, voire d’achat par cet éditeur, si le développeur de ces ajouts a pris conscience que la force principale de développement du logiciel est chez son éditeur, et que celui-ci a besoin de se financer pour être au service d’un produit toujours meilleur, offert à tous ceux qui ne veulent pas le payer. Ainsi, il y a échange libre et constructif de dons entre les deux ‘mondes’.
En résumé, c’est surtout une affaire de prise de conscience, chez chaque acteur, de la logique et des forces en présence qui permettront d’obtenir un grand logiciel libre, le plus vite possible. Cela demande au développeur bénévole de savoir changer son regard sur l’aspect constructif de certaines entreprises commerciales.
A l’inverse, lorsque la communauté de développeurs peut être assez forte pour assumer tous les développements nécessaires, le modèle de double licence me semble effectivement peu approprié. Dans l’idéal, toutes choses égales par ailleurs, une forte communauté apporte une plus grande garantie de pérennité.
@Patrick : il faudrait effectivement analyser toutes les situations possibles et elles sont effectivement nombreuses
Bonjour
Vos analyses sont très correct. Personnellement je pense que les licences doubles sont l’avenir car au-delà de tout ils augmentent la confiance entre l’utilisateur et l’éditeur.
Cependant je pense qu’il est plus complexe de proposer une licence double pour les logiciels dit ‘frontend’ ou IHM (Interface Homme Machin). Tout repose sur l’absence de fonctionnalités dans la version gratuite pour créer la vente.
Ce n’est pas la même chose pour les logiciels dit ‘backend’ qui sont plus complexes et moins accessibles et nécessites en général une IHM. Là la licence double prend tout son sens car le logiciel fourni au public aurait là même qualité que celui fourni à l’intégrateur ou à l’utilisateur.
A méditer …
@Michael licence double ne veut pas forcément dire que le version payant inclue une IHM complète. Je dirais qu’il s’agit plus d’un approche open core. une version « light » open source et une version commerciale avec toutes les fonctionnalités qui rendent le logiciel utilisable. Un article plus récent sur le sujet