Passer au contenu principal

Voilà, vous avez un nouveau projet, et l’avez commencé. Maintenant vous vous posez la question de la licence : un truc libre ou un truc proprio ? Il s’agit d’un dilemme auquel nous tentons de répondre ici.

Libre != gratuit

Alors autant le dire tout de suite : libre ne veut pas dire gratuit. Un exemple très simple : RedHat Enterprise Linux (RHEL) est libre, mais la marque RedHat ne l’est pas. Il se trouve que RHEL est payant, notamment pour obtenir tous les correctifs du système ce qui est critique en entreprise. Par contre CentOS est binairement compatible avec RHEL, ce n’est en fait que ce dernier dans lequel toutes les marques et icônes RedHat ont été enlevées.

Plus généralement, si vous faites du libre vous ne pourrez pas contrôler ce que fait le client de votre code. C’est une bonne et une mauvaise chose : pour le client c’est un gage de pérennité, ce qui peut être un très bon argument de vente, par contre si vous comptiez facturer un client une telle somme pour une installation sur un tel nombre de machines c’est raté.

Bref le business autour des logiciels libres se fait plus généralement sur les contrats de support. Un exemple très simple est JBoss : le logiciel est libre, mais l’entreprise vend la documentation et les formations relatives à son produit.

Par contre autant être honnête : vous aurez du mal à gagner beaucoup d’argent en faisant du logiciel libre, du moins directement. RedHat est à l’heure actuelle la seule entreprise vraiment rentable qui produit du logiciel libre.

Le libre : release early, release often

On l’a vu dans notre article sur la démarche devops, il est important de pouvoir faire de nouvelles versions fréquemment pour avoir un maximum de retour sur ce qu’on développe. A ce niveau le libre est clairement avantagé. En effet votre projet intéressera rapidement quelques dizaines voire centaines de personnes à travers le monde qui pourront tester votre projet, faire des remarques et autres suggestions pour vous aider à l’améliorer.

D’autre part en procédant de la sorte vous pourrez stimuler de l’intérêt autour de votre projet, ce qui peut vous permettre d’attirer encore plus de monde et ainsi de suite. C’est d’ailleurs comme ça que Linux a pu devenir ce qu’il est devenu, et qu’il évolue maintenant très rapidement, bien plus que Windows.

Sur le plan financier autant être honnête : le code que vous écrivez dans le cadre de votre projet ne vous rapportera souvent pas grand chose. Par contre il peut augmenter fortement votre visibilité ou celle de votre organisation sur le marché du travail, jusqu’à attirer les grands. Pour info JBoss a été racheté un milliard de dollars par RedHat. Par ailleurs avec un projet libre vous pouvez avoir des dizaines de développeurs bénévoles qui travaillent sur votre projet, et ce sans nécessiter d’apport financier.

Le propriétaire : attention à la qualité de vos releases

Dans le cadre du logiciel propriétaire, vous ou votre organisation prenez l’intégralité des développements à votre charge, puis commercialisez un produit fini. Autant être honnête, c’est le meilleur moyen de faire rapidement de l’argent. Par contre, pour être rentable… c’est une autre histoire.

D’autre part non seulement il sera plus difficile de tester à grande échelle votre application avant release, mais en prime si vous faites une version pourrie de votre logiciel cela peut lui être fatal. On pourra notamment se souvenir de dBase, à la fin des années 80. Bref ça peut rapporter gros mais à moins d’être en situation de quasi-monopole sur vos produits vous aurez difficilement le droit à l’erreur. Tout le monde ne s’appelle pas Microsoft.

Vous devrez également vous préoccuper de la protection contre le piratage (ça existe aussi avec le libre, mais c’est moins fréquent), et avoir un service juridique à disposition pour la rédactions des différents contrats de licence.

Dernier point : les révélations d’Edward Snowden ont jeté un voile de méfiance sur l’informatique en général, et le fait de ne pas pouvoir accéder au code de votre application pourra poser problème à certains clients, ce qui est normal.

Vous développez une application à destination d’un marché de niche

Dans le cas où votre application est destinée à un marché de niche l’argument de la pérennité offert par le libre est très puissant. Malheureusement le fait que tout le monde ait accès au code peut être un très bon moyen pour vos concurrents de récupérer celui-ci, donc à vous de choisir une licence virale comme la GPL pour au besoin avoir un recours juridique si un concurrent ne mettait pas à disposition les sources modifiées. A ce sujet d’ailleurs il est bon de rappeler que la redistribution des sources n’est obligatoire que si vous diffusez une version modifiée de l’application à l’extérieur.

D’autre part le fait que le client sache qu’en cas de souci il peut passer à la concurrence peut être dans les faits positif pour votre organisation car le fait qu’il reste chez vous montrera que vous avez sa confiance, ce qui peut être un argument de vente pour d’autres clients.

Mais il faut reconnaître que dans le cas d’un marché de niche, vu qu’il y a par définition peu de clients et peu d’acteurs, le fait que l’application soit libre ou pas ne changera pas grand chose. Ce qui compte est davantage l’expertise métier que vous pourrez ajouter.

Vous développez une application « mainstream », comme un traitement de texte

Dans le cas d’une application « mainstream » comme un traitement de texte, à moins d’avoir de grosses ressources financières à disposition il est pratiquement suicidaire de vouloir lancer une application propriétaire. Il suffit de regarder Opera qui persiste dans son modèle propriétaire en ayant un mal fou à gagner des parts de marché et à diffuser son produit. D’ailleurs c’est en partie pour cette raison que les dernières versions d’Opera sont basées sur Chromium, justement parce que ça revient à moins cher de ne pas avoir à maintenir de moteur de rendu.

Vous développez un jeu vidéo

Dans un jeu vidéo il y a du code, mais l’essentiel du travail se trouve au niveau artistique, à savoir les graphismes, les musiques et le reste. Et là autant le dire tout de suite les jeux libres n’arrivent pas à la cheville des jeux propriétaires. Alors ce que font certains est d’avoir le code du moteur libre mais pas les données. C’est d’ailleurs ce que fait idSoftware quand ils libèrent le code de leurs jeux : vous ne pourrez pas jouer à Doom 3 légalement si vous n’avez pas acheté une licence pour les données du jeu. Ne me faites toutefois pas dire ce que je n’ai pas dit : il existe de très bon jeux libres comme OpenTTD, mais il faut avouer que ceux-ci sont très peu nombreux.

Bref s’il y a bien un domaine dans lequel les licences propriétaires ont de beaux jours devant elles, c’est bien le jeu vidéo.

En bref

Le choix d’une licence libre ou propriétaire dépend avant tout de la manière dont vous percevez les choses. A titre personnel j’aurais tendance à privilégier les licences libres, mais bon c’est aussi parce que j’utilise GNU/Linux sur mon ordinateur personnel notamment en raison des licences libres et des valeurs qu’il véhicule. Et au passage j’apporte ma maigre contribution en testant notamment certaines applications et en remontant des bugs si besoin. Une des seules applications que j’ai faites sur mon temps libre, un jeu de Puissance 4 est d’ailleurs sous licence GPL. Et il s’agit d’un projet migré depuis Google Code, ce dernier ayant fermé.

Maintenant si vous vous lancez dans une application concurrente d’un produit disponible de longue date en version propriétaire payante, l’argument du libre sera un point qui pourra jouer en votre faveur, et ce d’autant plus si à côté vous fournissez des prestations de support sur votre solution.

Dernier point non négligeable pour certains : l’éthique. Développez une solution propriétaire revient quelque part à tenir vos clients captifs de manière pas forcément loyale. Voir l’article de Roberto di Cosmo sur le sujet. Personnellement ça me gêne, mais c’est à chacun de voir.

Cet article vous a plu ? Vous aimerez sûrement aussi :

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter Son LinkedIn

Laisser un commentaire