Il faut penser l'open source autrement

On le sait, l'open source est une affaire de communauté. Pourtant, le consensus sur les usages reste difficile. C’est la question que posent à nouveau les récents conflits entre Elastic et AWS, débattue depuis de nombreuses années et toujours pas résolue. Dans ce dernier épisode de la guerre des logiciels open source, Elastic a accusé AWS d'avoir « un comportement incompatible avec les normes et les valeurs sur lesquelles repose l'écosystème des logiciels libres ». AWS a répondu que c’était Elastic qui violait les normes et les valeurs de l'open source, justifiant ainsi son fork d’Elasticsearch et de Kibana. Le fournisseur affirme qu’avec la bifurcation de ces logiciels libres, il veut « encourager des pratiques saines et durables en matière d'open source, y compris la mise en place d'une gouvernance de projet partagée avec une communauté de contributeurs ». Personnellement, je ne pense pas que ce conflit relève d’une question de licence. Enfin, c’est le cas, mais ce n'est qu'un symptôme, et pas la cause. Le cœur du problème est de savoir qui profite des logiciels open source. De nouvelles licences et une autre manière de décrire ces licences pourraient permettre de résoudre en partie ce problème. (Suis-je sur le point de suggérer une « source partagée » ? Oui, mais lisez la suite).

Revenons aux faits

Tout d'abord, comme le savent la plupart des lecteurs, je rappelle que je travaille pour AWS. Ensuite, je rappelle aussi que je suis impliqué dans l'open source depuis bien plus longtemps (près de 20 ans de plus) que je ne travaille pour AWS. Mon identité dans le domaine de l'open source passe avant tout. En écrivant ceci, j'écris en tant que Matt, le gars de l'open source qui travaille aujourd'hui pour AWS mais qui a défendu l'open source depuis son premier emploi chez Lineo, le vendeur d’un Linux embarqué. C’était en 2000. (Oui, je suis vieux !)

Cela étant dit, permettez-moi de partager quelques vérités objectives :

- Il est très difficile de créer des logiciels open source de qualité pour les nombreux utilisateurs très en demande de ce genre de solutions ;

- Il est probablement plus difficile encore de gagner de l'argent avec ces formidables logiciels open source ;

- Ce n'est pas parce que vous développez un bon logiciel que vous avez le droit d'en tirer profit, et le fait que votre code soit open source signifie que vous accordez à d’autres les mêmes chances pour essayer d’en tirer profit ;

- Enfin, certaines entreprises ont été plus rapides que d'autres à comprendre l’intérêt de la monétisation de l'open source.

Ces dernières décennies, l’industrie du logiciel libre a expérimenté différents modèles de commercialisation de l'open source, comme la vente de support (mauvaise idée !) et le noyau ouvert (qui pose d’autres problèmes). Mais le modèle le plus propre, et celui qui s'est avéré le plus efficace pour mettre au même niveau les intérêts des clients et des fournisseurs, est celui des services gérés dans le cloud, comme je l'ai déjà pu l’écrire auparavant. Cependant, le problème c’est que, historiquement, les individus et les entreprises qui arrivent à développer de bons logiciels n'ont pas toujours été les mieux placés pour rendre leur code opérationnel. Un point soulevé il y a quelque temps par le développeur canadien Tim Bray. Comme il l'a déclaré, « les qualités qui font que les gens sont capables de créer des logiciels de grande valeur à partir de rien ne garantissent pas nécessairement que leurs logiciels seront aussi performants en production ». Et réciproquement. Les clients ont adopté les services cloud managés pour utiliser leur logiciel open source préféré à moindre coût. Mais de façon générale, l'argent n’est pas remonté vers la source du code, pour les motifs 2 et 4 exprimés ci-dessus.

C'est un problème, mais il est difficile de savoir qui blâmer. Certains pointent du doigt les entreprises cloud, mais leurs critiques reviennent un peu à dire qu’il faudrait « arrêter de donner aux clients ce qu'ils veulent ». Et pour ceux qui affirment que les entreprises cloud ne contribuent pas proportionnellement à la valeur qu'elles reçoivent, il est bon de rappeler que, d’une part, en général, de telles contributions de code ne sont pas les bienvenues et d’autre part, que ce n’est pas ce que les développeurs de logiciels libres attendent vraiment. Mais alors, que veulent-ils ? Ils veulent un blocage de la monétisation du code open source qu'ils écrivent, même si ce code n’est pas encore aussi bon que celui de leurs concurrents pour répondre aux besoins des clients.

Ce qui nous amène à considérer le point de vue de ceux qui critiquent ces développeurs open source. « Le fait que vous ne sachiez pas transformer un bon logiciel en produit commercial est votre problème », estiment ceux qui les critiquent. Ce qui revient un peu à blâmer la victime. Mais il y a du vrai dans cette affirmation selon laquelle ces développeurs semblent vouloir les avantages de la distribution de l'open source (la communauté !) et les avantages de la monétisation des logiciels propriétaires (eux-mêmes !). Quoi qu'il en soit, cette affirmation ne tient pas compte du fait que le développeur de logiciels libres peut avoir besoin de plus de temps pour atteindre le niveau opérationnel nécessaire, et de plus en plus attendu par les clients.

L’option de la source partagée

Pour gagner du temps, des entreprises comme MongoDB et, aujourd’hui, Elastic, se sont tournées vers des licences du genre Server Side Public License (SSPL). Non, ce ne sont pas des licences open source. Mais ce ne sont pas non plus des licences propriétaires, du moins pas au sens classique de ces licences. C’est un moyen terme entre les deux, et cette approche quasi-open source peut éventuellement convenir à de nombreux objectifs, comme le montre le succès de MongoDB. Pendant au moins deux décennies, nous avons essayé de trouver un terme pour ce juste milieu. Je ne pense pas qu’il faudrait désigner ces licences par le terme générique « open source », car elles ne le sont pas. L'open source a un sens spécifique, développé (et défendu) depuis plus de deux décennies. Mais nous ne devrions pas non plus diaboliser ces licences. Elles résultent des efforts entrepris par les développeurs pour profiter financièrement du code qu'ils ont écrit, et il n'y a rien de mal à cela.

Alors pourquoi ne pas partager les sources ?

Il est certain que le terme de « source partagée » a une histoire chargée : Microsoft l’a utilisé pour essayer d'imiter l'open source sans pour autant l'adopter. Mais en dehors de cette tentative d’usurpation, le terme est suffisamment accessible et précis pour décrire ce que ces entreprises veulent faire : partager la source avec d'autres tout en limitant (généralement, mais pas toujours) l’usage de cette source pour développer des produits compétitifs. Alors, pourquoi ne pas utiliser le terme « source partagée » pour désigner une catégorie de licence qui ne serait ni open source ni propriétaire, et qui donnerait aux utilisateurs potentiels une idée sur les droits et restrictions qu'ils devront respecter pour utiliser la licence ? Matt Seitz explique comme le système pourrait fonctionner : « Cela me rappelle les débats que l‘on pouvait avoir sur le « logiciel gratuit » (copyleft) et l'« open source ». Les licences, comme la couleur, ont un spectre. Nous pouvons les classer par grandes catégories (rouge, vert), puis ajouter des adjectifs (rouge rubis) ou créer des termes spécialisés (cramoisi) ».

La licence Server Side Public License (SSPL) pourrait être considérée comme une « source partagée, mais pas pour les fournisseurs de cloud ». Oui, il y a des nuances au-delà de cela, mais c'est une désignation abrégée qui pourrait faciliter la compréhension de ce qui se passe. Avons-nous besoin de cette catégorie ? Je pense que oui. Nous pouvons débattre pour savoir qui est responsable des guerres de monétisation du logiciel libre, mais le fait qu'il y ait une guerre et qu'elle ait duré si longtemps montre qu'il y a un vrai problème à résoudre. Difficile de dire si les développeurs adopteront les licences en sources partagées. Est-ce que MongoDB rencontrerait le même succès aujourd’hui avec une licence SSPL si le projet n’avait pas évolué au cours de toutes ces années en tant que projet open source ? Peut-être, ou peut-être pas. Mais je crois que c'est aux développeurs d'en décider. Permettez-leur de choisir des licences claires et précises parmi plusieurs catégories de licences, selon des tarifs et des restrictions faciles à comprendre, et voyons ce qui se passe.