Pour le logiciel libre, la liberté a un prix et un modèle économique
Le logiciel libre n’est pas qu’une question de licences, comme titrait dans un article Frank Karlitschek, fondateur de NextCloud. C’est aussi une question de pouvoir de contrôle, ou de liberté, selon le point de vue. Encore faut-il disposer des ressources et un modèle adapté, pour exercer ce pouvoir. Ainsi, l’association Framasoft a récemment arrêté certains de ses services libres visant à la « degooglisation » d’Internet. Car elle ne pouvait soutenir toutes les charges d’exploitation avec son modèle. Elle incite d’autres acteurs à se mobiliser. Cet article revient dans ce contexte sur l’enjeu des questions de contrôle et de ressources, pour les entreprises qui choisissent l’open source.
Un logiciel libre ne veut pas dire gratuit, ni même libre de droits.
C’est une ambiguïté de traduction du terme « free software ».
Dans le mouvement du logiciel libre, le secret de fabrique d’un logiciel est honni. Car il est considéré comme un frein au partage du savoir. Il s’agit de promouvoir la libre circulation du code source afin que chaque utilisateur puisse avoir la liberté d’étudier la structure de ce code, de l’exécuter pour en comprendre le fonctionnement, éventuellement de l’adapter et de le partager, pour pouvoir le modifier et l’améliorer. L’idée est d’en faire un bien commun améliorable par tous.
Richard Stallman à LibrePlanet 2019
En créant une licence, la GNU General Public Licence, Richard Stallman a donné un cadre juridique à cette liberté. Le tout pour en interdire la spoliation ou la restriction. Il fallait « rendre le programme libre et s’assurer qu’il le reste ». La licence GPL « emprunte à la logique du droit d’auteur en stipulant les conditions d’exercice de ce droit sous la forme de quatre libertés accordées à l’utilisateur du logiciel : utiliser le programme, en étudier le code source, le modifier et distribuer des copies de la version originale ou modifiée ».
La licence GPL n’impose pas la gratuité du logiciel et indique même explicitement qu’un travail sous GPL peut être vendu. Mais son approche est contraignante dans la redistribution. La notion de « copyleft », qui fait miroir à celle de « copyright » pour garantir les libertés des utilisateurs, y est très forte. Elle impose que la licence s’étende également à la distribution d’une création à laquelle est intégrée l’œuvre.
Des licences plus ou moins permissives
Tout logiciel incluant dans ses programmes un code sous licence GPL est considéré comme une modification de ce code. Par conséquent, il doit être redistribué sous licence GPL, sous peine de poursuites judiciaires éventuelles. Dans un contexte de création de solutions logicielles en entreprise, un code utilisé sous licence GPL en tant que brique logicielle dans un programme plus vaste, imposerait à l’ensemble de la construction d’être redistribué à tous.
Le caractère contaminant de la licence GPL peut devenir un frein à l’usage. Certaines entreprises n’ont nul désir de rendre visible la façon dont elles adaptent des solutions génériques à leurs spécificités. C’est ouvrir aux concurrents potentiels une partie de leur caractère différenciant, en quelque sorte.
C’est pourquoi de nombreuses autres licences du libre ont été créées. Elles ont des droits de distribution plus permissifs au sens en particulier de cohabitation avec des briques propriétaires.
Une attention toute particulière doit être portée cependant aux licences de type «copyleft». Surtout quand on réutilise plusieurs logiciels libres en briques logicielles de construction d’une solution plus globale. Deux licences différentes avec copyleft sont généralement incompatibles. Autrement dit, il est illégal de fusionner du code utilisant l’une de ces licences avec du code utilisant l’autre.
Il est donc prudent de bien analyser, quand on construit un système d’information ou une solution logicielle sur un assemblage de logiciels libres, la compatibilité des licences dans cette composition.
logiciel libre ou open source : méthode ou philosophie?
Après le mouvement du libre, un autre mouvement est apparu, celui de l’open source. Avec l’idée de faire travailler en communauté une force de développement de milliers de codeurs et testeurs. L’objectif étant d’améliorer la qualité des socles de produits logiciels. Pour cela, il faut partager le code, le rendre disponible. Le mouvement open source part donc du libre avec ce socle commun de liberté d’accès au code source pour pouvoir l’exécuter, le modifier, le copier, le partager. Néanmoins, selon Richard Stallman, quand le libre porte un projet de société, l’open source est davantage une méthodologie de développement.
Un projet open source nécessite plusieurs développeurs et beaucoup d’utilisateurs pour constituer une base de contributeurs solide et pérenne. C’est un point non négligeable dans l’approche d’une PME. Utiliser un code open source qui n’est pas supporté par une fondation ou une communauté robuste, en tout cas un pôle de contributeurs actifs, fait peser la menace de ne plus le voir évoluer à moment ou à un autre. Autrement dit, garder ses « bugs », ne plus étendre sa couverture fonctionnelle et présenter le flanc à la découverte et l’exploitation de failles de sécurité.
Les nécessités de la maintenance et l’évolution du code
Reprendre à son compte le code lui-même pour le faire évoluer n’est pas envisageable dans tous les cas de figure. Ce n’est pas une option pérenne pour une PME qui n’est pas dans l’industrie du logiciel. Il est peu probable qu’elle souhaite employer une personne à plein temps pour maintenir le code. Elle aura donc très souvent recours à une société tierce partie pour la maintenance et l’évolution d’une solution fondée sur un logiciel open source.
Qui peut imaginer un pont inaltérable? Voire n’importe quelle construction humaine qui n’aurait jamais besoin d’être réparé ou rénové ou amélioré, éventuellement remplacé ?
Une solution logicielle n’échappe pas au besoin de maintenance. Elle a été conçue et développée à un moment donné pour répondre à des besoins, en fournissant les fonctions d’usage requises. Mais, d’une part, la conception n’est jamais exempte d’erreur d’approche ou de compréhension des besoins réels et des contextes d’utilisation. En outre, les besoins peuvent changer sous l’effet d’une transformation de l’environnement économique ou de nouveaux facteurs d’influence sociologiques, politiques, écologiques, technologiques ou législatifs. Donc il faut faire évoluer la solution.
Que le code source soit en libre accès ne signifie pas que tout un chacun ait les capacités à le modifier pour le corriger ou le faire évoluer. Cela nécessite des connaissances approfondies dans le langage utilisé, dans les technologies de base de données utilisées (PostgreSQL, MySQL…), etc. Sans parler des puissances machines et des architectures nécessaires (y compris en matière de sécurité) pour certains cas d’usage.
Connaître le langage d’un code, ce n’est pas le comprendre automatiquement
Pierre de Rosette – Source Wikimedia commons – licence CC-By-Sa-3.0
Connaître le langage ne suffit pas non plus à comprendre instantanément comment la solution fonctionne. Lire le français ne vous donne pas de facto la connaissance ou la compréhension de toute la littérature française… Pour pouvoir modifier un code, il faut prendre le temps de l’étudier.
C’est pourquoi certaines sociétés de services du monde du logiciel libre (SSLL) spécialisent leurs offres sur l’expertise de quelques solutions open source choisies. Leurs développeurs deviennent d’ailleurs eux-mêmes souvent des contributeurs de ces solutions. Car cela crédibilise leur rôle d’experts. Quant au support, c’est typiquement un des services annexes sur lesquels les éditeurs de logiciel libre fondent leurs revenus.
Dans tous les cas, le choix d’une solution en licence libre impose de prévoir les compétences et le temps pour les services nécessaires à son déploiement opérationnel et son usage à long terme au sein de l’organisation. Si les ressources ne sont pas disponibles en interne, il faudra recourir à des services externes. Qu’il s’agisse du temps d’une ressource interne ou d’une prestation en régie ou en forfait, cela se traduit par des coûts, mais aussi par la mise en place d’une politique adaptée.
En premier lieu, cette politique doit formaliser le processus pour sélectionner et approuver les composants open source. En précisant la liste des licences open source que la société accepte. Par ailleurs, elle doit formaliser les responsabilités par rapport au suivi du code open source utilisé. Cela en matière de gestion des configurations (quelles versions sont utilisées et où ?), mais aussi de gestion des vulnérabilités connues et de mises à jour nécessaires.
Les évolutions sont indispensables, mais attention aux montées de version
Le prix de la liberté, c’est la vigilance éternelle.
Thomas Jefferson.
Afin de prévoir correctement les aspects de maintenance et de support, choisir une solution logicielle open source suppose de vérifier qu’elle est bien supportée par une communauté active, en plus d’avoir vérifié la licence. Car pour rappel, une licence GPL vous conduira pour toute évolution du code à devoir la mettre sous licence GPL. Autrement dit, la partager et diffuser librement. Ensuite, le logiciel sera d’autant plus robuste qu’il aura eu de multiples contributeurs pour le tester et relever ses failles.
L’activité d’une communauté open source se mesure à sa réactivité. Pour résoudre les problèmes, remédier aux vulnérabilités et modifier puis diffuser le code revu en conséquence. De nombreux projets connus en open source ont choisi d’ailleurs d’opter pour une approche RERO (Release Early, Release Often) avec des montées de version très fréquentes, plusieurs fois par an, pour donner suite au retour d’utilisateurs et de contributeurs. Les nouvelles versions corrigent des vulnérabilités et proposent de nouvelles fonctionnalités.
Cela n’est pas sans inconvénient toutefois pour une entreprise qui a installé la solution open source dans une version précédente et l’utilise au quotidien. Pour profiter de ces mises à jour, il va falloir réaliser des opérations d’installation et de migration. L’effet en sera forcément perturbateur pour les activités. Cela peut aussi conduire à des régressions : fonctionnalités ou interfaces qui ne marchent plus dans la nouvelle version. Certains logiciels open source proposent dès lors des versions LTS (Long-Term Support) qui sont maintenues pour au moins deux ans, avec des mises à jour légères uniquement pour des raisons de sécurité. Dans ce cas, ne pas les installer serait plus risqué que le contraire, tandis qu’il ne peut y avoir de régressions de fonctionnalités.
La liberté, en matière de logiciels, est rarement gratuite
Si le logiciel libre laisse la liberté à l’utilisateur d’exploiter le code source, de le modifier, de l’améliorer, de le diffuser, il demande aussi de disposer des compétences et des ressources pour le faire.
La liberté est au prix de cette capacité. Cette grille de lecture permet de mieux comprendre le succès économique de RedHat, racheté par IBM, qui propose des distributions Linux avec des assemblages contrôlés de briques open source aux entreprises et des services d’assistance. Cela explique également le changement de modèle d’Odoo qui s’est dirigé vers un modèle « open core », pour proposer de l’hébergement et donc un ERP dans le cloud.
Certains pourraient voir le SaaS en réponse idéale pour qu’une PME n’ait plus à se soucier de la maintenance. Là encore, ce serait une conclusion aussi hâtive que de décréter que l’open source réduit de facto les coûts de possession. Certes, en SaaS, la maintenance et le support deviennent moins coûteux pour l’éditeur (une seule version) et invisible pour le client consommateur.
Dans le cas d’une offre SaaS (Software as a Service), il n’y a pas de contrat de maintenance avec prestations. Car il s’agit d’un service fourni sur abonnement. On ne possède pas un bien qu’il faudrait maintenir, on ne fait que louer à l’usage un bien logiciel. Charge au fournisseur de s’assurer de la mise à jour continue de ce bien et de s’occuper des infrastructures nécessaires à son bon fonctionnement.
La liberté, c’est aussi une question de ressources
Quand vous prenez un taxi, vous n’achetez pas la voiture ni ne vous souciez de son assurance, des réparations, contrôles et maintenance à faire. Vous louez les services d’un chauffeur qui utilise une voiture, pour un besoin de déplacement. Le SaaS ainsi ressemble plus au fait de prendre un taxi que de louer une voiture. Car vous ne pouvez pas faire ce que vous voulez du véhicule. C’est satisfaisant quand vos besoins sont standards. Cela peut être gênant quand vous voulez aller plus loin, hors des sentiers battus, en gardant le contrôle des évolutions.
C’est là aussi où se joue la liberté potentielle offerte par l’open source. Celle qui autorise d’intervenir directement sur les directions fonctionnelles prises. Mais encore faut-il comprendre que ça ne peut pas être gratuit. Ni sans avoir à mobiliser des ressources de façon pérenne.
[…] Pour le logiciel libre, la liberté a un prix et un modèle économique (semsimo.com) […]