Bear passe désormais à une licence source disponible
(herman.bearblog.dev)- Le projet Bear passe de la licence MIT à l’Elastic License
- L’ancienne licence MIT autorisait l’utilisation libre du code et les forks, mais la nouvelle licence les restreint dans le cadre de la fourniture d’un service hébergé
- Plusieurs projets open source suivent également cette tendance en adoptant des changements de licence similaires pour empêcher la concurrence gratuite
- À l’ère de l’intelligence artificielle, copier du code et le transformer en service est devenu très facile
- L’ouverture du code est importante, mais la communauté d’utilisateurs et la volonté de maintenir le service dans la durée constituent le cœur de Bear
Contexte du passage de Bear à une licence source disponible
- Au départ, le projet Bear publiait son code sous licence MIT, avec pour objectif de permettre l’apprentissage et l’auditabilité, tout en offrant aux utilisateurs une garantie de confidentialité et de sécurité
- Mais avec le temps, des services concurrents basés sur le code du projet Bear ont commencé à apparaître
- Le logiciel avait été développé avec passion, mais voir le code facilement copié puis revenir sous forme de concurrence a provoqué un sentiment de perte ainsi qu’une inquiétude économique
- Malgré une conviction forte dans les valeurs de l’open source, la situation est devenue concrètement difficile
Décision de changement de licence
- À la suite d’un incident récent, la décision a été prise de passer de la licence MIT à l’Elastic License (une approche de type copyleft introduite par Elastic Search)
- L’Elastic License est similaire à la MIT, mais interdit de fournir le logiciel en tant que service hébergé ou managé
- Les clauses précises de la licence peuvent être consultées via ce lien GitHub
Tendances de l’écosystème open source
- D’après l’enquête menée, de nombreux projets open source ont, ces dernières années, adopté une tendance à la restriction de licence pour empêcher la « concurrence parasitaire »
- Exemples : Plausible, Fathom, Grafana, Snowplow, ScyllaDB, Sentry et d’autres projets ont pris des décisions similaires
L’ère de l’IA et l’intensification de la concurrence
- Avec l’apparition des outils de codage IA, il devient possible de copier rapidement un dépôt et de le transformer en service, par exemple avec des consignes comme : « fork ce dépôt, change le nom puis déploie-le sur EC2 »
- Cette évolution de l’environnement impose une charge et un risque encore plus grands aux auteurs d’origine
La valeur particulière de Bear
- La véritable valeur de la plateforme Bear ne réside pas simplement dans le code source lui-même, mais dans la communauté qui l’utilise et dans le sens des responsabilités à long terme de l’exploitant
- Même si certaines restrictions sont désormais introduites au niveau du code, l’équipe affirme sa volonté de maintenir activement la plateforme
3 commentaires
Il semble que la GPLv3 et l’AGPL ne soient pas utilisées conformément à l’intention de leurs auteurs.
Comme la plupart autorisent la double licence, j’ai trop souvent vu ces licences finir par servir de mécanisme pour imposer un usage commercial.
Dans ce sens, je pense qu’Apache et MIT sont parmi les rares licences open source qui fonctionnent encore selon leur intention initiale.
(Je ne pense pas pour autant qu’il existe une licence open source parfaitement irréprochable.)
Avis Hacker News
Si j’ai bien compris, le camp « Open Source » considère que si Amazon peut le proposer comme service AWS, alors ce n’est pas du véritable open source, et se montre très contrarié quand quelqu’un affirme le contraire.
J’aimerais que tout le monde reconnaisse un peu davantage ce phénomène de « concurrence parasitaire » dont parle l’auteur. Ce que fait Herman est bénéfique pour tous, donc j’aimerais qu’il existe un nouveau terme, plus chaleureux que « source-available » et qui rende mieux justice à un projet communautaire.
J’ajoute ce commentaire parce qu’il résume bien ma pensée :
La tendance naturelle du marché à aller vers des situations de winner-takes-all n’aide pas la mission du logiciel libre et open source (FOSS). Si on n’empêche pas les grandes entreprises de monétiser ainsi, cela finit au contraire par gravement nuire à la mission de l’open source. Et, dans le processus, cela piège les utilisateurs dans une combinaison de logiciels propriétaires de grandes entreprises et de FOSS
À l’origine, la position du camp open source passait par des licences comme GPL → GPLv3 → AGPL, qui soutenaient explicitement des mécanismes bloquant clairement ce type de problème
Le fait que des licences permissives comme MIT/BSD/Apache se soient largement imposées ressemble à une évolution délibérée, alignée sur les intérêts des entreprises, pour affaiblir l’idéologie du logiciel libre
La plupart des gens n’ont pas vraiment de problème avec les logiciels qui ne sont pas open source
Le problème, c’est que des projets comme Terraform ont gagné en popularité et se sont développés parce qu’ils étaient open source, puis leur mainteneur est passé à une licence fermée, supprimant ainsi la base même de leur succès
Et quand, en plus, les contributeurs ont signé une CLA (Contributor License Agreement) qui permet ensuite de relicencier librement leur code en licence fermée, c’est deux fois plus décevant
Si l’open source ne vous intéresse pas, il suffit de ne pas l’utiliser ; jusqu’ici, le terme avait un sens clair et cohérent
Chacun peut produire son logiciel librement et choisir ce qu’il utilise selon ses valeurs, il n’y a pas vraiment de problème à cela
Chacun peut utiliser la licence qu’il veut, mais il faut se demander pourquoi la plupart des développeurs open source choisissent des licences permissives comme MIT
En pratique, il existe déjà beaucoup de bons logiciels open source, donc le choix est large ; si vous ajoutez des restrictions de licence, les gens prendront simplement une autre alternative
C’est pourquoi les licences de type GPL rendent plus difficile l’adoption massive d’un projet. Bien sûr, Linux ou WordPress sont des exceptions très réussies, mais ce n’est pas la norme
Il est déjà difficile de monétiser avec une licence permissive comme MIT, mais s’il n’y a même plus d’utilisateurs, c’est encore pire
On peut débattre de savoir si c’est bien ou mal, mais dans les faits, tout le monde semble agir de manière rationnelle. Fondamentalement, le logiciel n’est pas si rare que ça
L’AGPL n’a-t-elle pas justement été créée pour ce genre de cas ?
L’AGPL est une licence open source reconnue par l’OSI qui impose des restrictions quand le logiciel est fourni comme service réseau
Je me demande si le mainteneur a regardé Fair Source fair.io
Je pense que Fair Source est supérieur à « source-available », notamment parce qu’il propose une trajectoire vers un open source complet via le DOSP(opensource.org/dosp), ce qui est bénéfique pour les utilisateurs gratuits comme payants, et particulièrement adapté à une plateforme de blog comme Bear
La Fair Source License FCL(fcl.dev) est aussi proche dans son esprit de la Bear Blog License et correspond bien au manifeste Bear(herman.bearblog.dev/manifesto/)
Même si Bear PTY LTD disparaissait, on pourrait structurer les choses pour que Bear lui-même continue d’exister (ce que le DOSP peut définir)
J’ai d’ailleurs participé à la rédaction de Fair Source
Malgré tout, l’expression « fair source » sonne plutôt bien
Est-ce qu’il suffit qu’un logiciel devienne open source avec le temps, comme avec Apache ou MIT, pour qu’il soit considéré comme fair source, ou y a-t-il des critères plus complexes ?
Certains ont simplement été un peu naïfs. Si on choisit la licence MIT, alors n’importe qui est libre d’utiliser mon code comme il veut. Puis, quand on veut gagner de l’argent plus tard, on bascule vers une licence exotique pour corriger le tir
Au final, les options sont MIT/BSD, GPL, LGPL, AGPL, et toutes les autres licences ne font que créer des problèmes de compatibilité inutiles
Je suis d’accord avec ce point de vue. Quand on veut vraiment une publication du code « sans condition », on choisit MIT
Ici, j’ai l’impression que ce n’était pas un choix aussi clair, mais plutôt une volonté un peu floue de jouer à la fois au « gentil » et à l’« entrepreneur »
La MPL (Mozilla Public License) me semble aussi être une licence assez utile et sous-estimée
Elle est nettement moins virale que la famille GPL, tout en imposant plus de contraintes que MIT/BSD (les modifications doivent être publiées à la distribution)
MIT et BSD n’apportent pas de garantie sur les droits de brevet, ce qui est une bonne raison de préférer l’Apache License
Guy (le créateur) semble simplement avoir voulu construire son projet et donner accès au code source
Je ne pense pas qu’il y ait eu un objectif stratégique particulier derrière
Les utilisateurs qui pensent qu’un projet open source restera open source pour toujours sont eux aussi naïfs
Les auteurs ont le droit de changer la licence, et être surpris par cela, tout comme croire qu’il est facile de bâtir un business sur l’open source, relève au fond de la même naïveté
Si l’objectif est de bloquer totalement l’usage concurrentiel, c’est en général comme cela qu’on s’y prend. Et il est aussi juste de ne plus utiliser le terme open source
Mais dans la plupart des cas, je pense que l’AGPL est une meilleure alternative. Avec l’AGPL, les grandes entreprises ne peuvent souvent pas utiliser le code à cause de leurs règles internes, ce qui bloque de fait l’entrée des gros acteurs
C’est trahir le sens même de l’open source
« Ouvrir en MIT puis découvrir que quelqu’un gagne de l’argent en utilisant mon code dans son business sans que je l’aie anticipé, ça me dépasse »
Pourquoi cela se répète-t-il sans cesse ? Pourquoi autant de développeurs ne voient-ils pas cette conséquence pourtant évidente ?
La licence MIT était un choix par défaut très accessible sur GitHub : on crée un nouveau projet, on choisit l’option dans une liste déroulante, et c’est parti
Quand un projet est nouveau et qu’on ne sait pas encore comment il va évoluer, il est difficile d’imaginer qu’il deviendra un jour suffisamment important pour qu’on doive se soucier de sa licence
La licence MIT permet dès le départ au projet d’être relicencié plus tard
Le mainteneur de Bear a d’abord choisi une licence permissive, puis, quand le contexte a changé, il est passé à une licence plus stricte
Cela me paraît tout à fait rationnel
Je pense que c’est parce que, il y a 15 à 20 ans, le camp BSD a gagné la guerre culturelle de l’open source
Je me demande à quoi ressemblerait l’écosystème actuel si le camp des licences GNU l’avait emporté
J’ai soutenu Bear parce qu’il était open source, mais si ce n’est plus le cas, je n’ai plus de raison de le soutenir et j’ai résilié mon abonnement
J’aimerais vraiment qu’il revienne sous AGPL
Bear est libre d’utiliser la licence qu’il souhaite, et moi je suis libre de décider si je veux l’utiliser ou non
L’objectif d’une licence open source est fondamentalement le partage, pas le gain financier
Je comprends parfaitement qu’on choisisse de ne soutenir que des projets open source
Quand arrive le moment de générer des revenus, une licence open source peut ne plus être adaptée
Certains développeurs se trompent en pensant que l’open source protégera leurs revenus, et certains utilisateurs se trompent en imaginant qu’un projet restera open source pour toujours
Des modèles comme source-available ou shipped-with-source restent une forme de licence propriétaire, ils n’ont pas besoin d’être qualifiés d’open source
« Les utilisateurs ne peuvent pas héberger ou fournir le logiciel comme service managé s’il offre les fonctionnalités principales du logiciel »
Je ne suis pas juriste, mais je me demande si cette restriction empêche aussi d’installer Bear soi-même et de l’exploiter en interne ou à titre personnel
Si c’est effectivement interdit, je ne vois pas pourquoi il était sous licence MIT au départ
Texte de la Bear Blog License
En revanche, il n’est pas permis de le proposer comme service à d’autres personnes ou entreprises
Référence : Elastic License FAQ
Je comprends la déception, mais la nouvelle licence est un peu floue
Quand elle dit « pas de fourniture de fonctionnalités via un service hébergé/managé », est-ce que cela vise aussi un fournisseur VPS classique où l’on installe le logiciel via un gestionnaire de paquets ?
Et qu’en est-il des scripts d’installation en 1 clic : est-ce que c’est permis tant qu’on ne présente pas cela comme un service ?
J’ai l’impression d’une sorte de théâtre où un tiers peut fournir le script d’installation, et où tout devient acceptable tant qu’on ne le mentionne pas explicitement au moment de vendre le service
Autrement dit, il est interdit de fournir le logiciel à d’autres sous forme de service (gratuit ou payant), mais l’utiliser uniquement pour soi reste permis
Le point essentiel est qu’il faut considérer que la création de comptes pour des tiers est interdite
Fournir un hébergement clé en main est aussi interdit, mais le problème n’est pas tant l’hébergeur que le fait de vendre des comptes utilisateurs sur cette instance hébergée
Le libellé vise à empêcher de grandes entreprises comme Amazon de fournir une instance de base de données à des tiers puis de simplement distribuer des comptes dessus
En revanche, une simple installation sur une VM via un gestionnaire de paquets reste acceptable
Cela dit, ce genre de licence est extrêmement confus et manque de clarté
Si l’intention est de ne pas rester open source tout en voulant que beaucoup de gens utilisent le logiciel, mais sans accepter qu’il soit hébergé par des tiers, alors il n’y a pas forcément besoin de partager le code : on peut tout aussi bien laisser « All rights reserved »
Je comprends la motivation et l’intention de partager le code source, mais si la crainte portait sur la concurrence, je me demande pourquoi ne pas avoir envisagé l’AGPL plutôt que MIT
Avec l’AGPL, quelqu’un d’autre ne pourrait-il pas quand même revendre le code tel quel, sans le modifier, dans un contexte commercial ?
L’AGPL n’impose que la publication du code source des modifications
Ici, le problème semble être surtout le cas où quelqu’un reprend Bearblog presque tel quel, ou avec juste un changement de nom, pour le commercialiser
Il est probable qu’au départ il ne voyait pas la concurrence comme un problème, puis qu’avec le temps cela en est devenu un
Personnellement, je pense que cette approche (code source disponible + restriction sur l’hébergement, etc.) est le meilleur modèle de licence
Elle me permet d’inspecter et modifier le code selon mes besoins, tout en laissant au projet et à son mainteneur la possibilité de préserver leur propre base sans subir une concurrence excessive
Si on commence ainsi dès le départ, on évite les changements brusques plus tard, les polémiques qui en découlent et les forks qui finissent par dépasser l’original
Je ne pense pas que Bear soit un projet d’une ampleur telle que cela déclenche un énorme choc
J’utilise aussi parfois mataroa.blog avec plaisir, et j’espère que le mainteneur de Bear continuera à trouver de la satisfaction dans son projet
En réalité, pour un projet open source, l’intérêt et les contributions des utilisateurs sont presque les seules ressources disponibles.
À moins qu’il ne soit déjà complètement installé, si n’importe qui — surtout une grande entreprise — le fork et monopolise l’attention, on finit simplement par travailler pour le bénéfice des autres.
À l’origine, ces licences étaient destinées à la liberté des utilisateurs, pas à celle des développeurs.
Saviez-vous que
winget, le gestionnaire de paquets en ligne de commande de Windows, a lui aussi été lancé par Microsoft après avoir forké tel quel le projet de quelqu’un d’autre en ne changeant que le nom ?Il existe aussi un billet écrit par l’auteur du projet original, appget.
The Day AppGet Died.
Si vous ne voulez pas simplement faire quelque chose au seul profit des autres (en particulier des grandes entreprises ou de ceux qui excellent dans le viral) et que vous accordez de la valeur à votre temps, vous devriez reconsidérer l’adoption d’une licence open source.
Même dans le cadre du bénévolat, il y a une grande différence entre être respecté pour sa contribution et être complètement ignoré.
Regardez des alternatives comme celles mentionnées dans les commentaires sur Hacker News.