Encore une société opensource qui veux se prémunir contre les sociétés qui gagnent de l’argent en tirant parti de leur softs, mais sans contributions en retour:
2 « J'aime »
De ce que j’ai compris, ça ne change rien pour ceux qui utilisent la CLI terraform, mais plutôt les revendeurs de solutions qui ressemblent au terraform cloud. C’est bien ça ?
Oui, dans la pratique, ce que tu décris semble être juste.
Le point qui me fait poser des question c’est la possibilité du changement de licence à l’initiative de la société attaché au soft.
Je ne souhaite pas aborder le sujet relatif aux “méchants” géants du cloud qui utilisent de l’open-source sans y contribuer. C’est largement débattu ailleurs.
Ce qui m’interroge, c’est que va-t-il se passer lorsque les dirigeants de la société (actuels ou futur) vont décider qu’il y a un manque à gagner parce que beaucoup trop de sociétés utilisent l’open-source sans prendre de licence cloud ou de contrat de maintenance ?
Vont-ils a nouveau changer la licence pour dire que tous ceux qui font du business doivent payer ? (un peu comme docker-desktop, même si ce soft n’a jamais été open-source, avant, il était gratuit).
Les softs open-source sous GPL ne peuvent pas changer de licence sans l’accord exhaustif de tous les contributeurs, ici il semble que l’on puisse changer de licence à l’initiative de la société attaché au soft.
Personnellement, et dans la mesure du possible, chaque fois que je décide d’intégrer un soft dans mon infra, j’essaye de corriger un bug ou faire une évolution mineure utile pour voir comment se comporte la communauté et voir si mon nom apparait dans la liste des “commiteurs”. De cette manière, j’ai des droits sur le code contribué, et cela me garanti une certaine pérennité.
A cette occasion, j’ai découvert des boites qui lors de chaque pull-request (github) demandent à l’auteur de valider une formulaire qui annonce abandoner tous les droits sur le code produit (je suis incapable de me rappeler le nom de la boutique). Dans ce cas, le contrat est clair, tu enrichi la code base d’un produit qui peut devenir payant a tout moment.
1 « J'aime »
Et hop, la valse des fork commence:
Salut,
Perso je ne comprends pas trop où est le problème ? Dans quel monde les CGU ne risquent pas de changer ?
L’avantage des licences libres c’est qu’elles permettent de forker un logiciel lorsqu’on désire le modifier ou de continuer à le maintenir de façon indépendante, ce qui peut être notamment le cas si le logiciel change de licence.
Perso, je pense que la communauté devrait surtout mettre au point un format ouvert pour les providers ou fichier state des outils comme Terraform, ce qui permettrait d’avoir une vraie interchangeabilité entre différents outils .
Je ne sais pas si on peut utiliser le terme CGU pour évoquer la licence du code d’un soft. Même si cette licence fixe les condition d’utilisation, je doute que ce soit une CGU.
Le problème n’est pas le changement de licence en soi, mais le constat que l’éditeur puisse la changer à sa seule volonté. Cela ne pose pas de problème avec des licences commerciales, mais ici il s’agit d’une licence open source.
Sous GPL, la licence du soft peut être changée si et uniquement si tous les contributeurs, à l’unamité sont d’accord. Ainsi si tu base ta stratégie sur ce soft, tu devient contributeur et tu as une garantie de pérénnité.
Si tu constate que “l’éditeur” peut modifier sa licence en ne se souciant pas de l’avis des contributeurs, tu perd toute la pérénnité sur laquelle tu comptais.
Lorsque tu adopte un soft comme TF tu fait confiance au soft et a l’équipe de maintenance. Si tu forke, tu ne sais plus si tu peux avoir confiance dans une nouvelle équipe.
Par ailleurs, dans la cas ou il n’y a pas de fork, tu te retrouve a devoir maintenir ta propre version du soft, ce qui ne faisait pas forcement parti de la stratégie, ni des moyens engagés de ta société.
Finalement, les fork tombent souvent à l’eau. Il est rare de trouver un fork qui fonctionne bien et qui est aussi bien maintenu que ce que tu avais connu par le passé. Parmi les exemple qui ont fonctionné, on trouve Mariadb et nextcloud, mais les deux soft sont forkés par les auteurs d’origine. Je ne connais pas de cas d’un soft forké par une tierce équipe et qui a bien fonctionné (il y en a sûrement).
Donc, la crainte pour la pérénnité est la suivante :
- Des milliers de sociétés basent leur déploiement sur TF.
- La société qui porte TF change d’actionariat
- Les nouveaux actionnaires trouvent anormal qu’il y ait des milliers d’utilisateurs open-source qui ne rapporte pas d’argent
- La licence est à nouveau changée pour devenir fermée restreinte et payante.
- Tu te retrouve coincé
Avec une licence GPL, ceci ne peux pas arriver directement, car la licence est vérouillée. Si la société décide d’une licence GPL et souhaite changer d’avis, elle doit:
- soit avoir l’accord de la communauté
- soit réécrire la base de code sous une autre licence et changer le nom du produit.
Oui mais qui aime travailler gratuitement ? Surtout quand des gens se font de l’argent avec le fruit de ton travail ?
Le succès d’un fork est corrélé à la base de contributeurs, plus y’a des contributeurs engagés plus un fork peut fonctionner. Si tout le monde se contente de se reposer sur l’éditeur alors là oui un fork est difficile.
Personnellement, je regarde toujours avec attention le type de licence utilisé par les projets open source car cela a une importance lorsque les entreprises désirent modifier la licence. Et je m’intéresse beaucoup à leur modèle économique car s’il est fiable il y a moins de risque de changement de stratégie.
Dans le cas de Terraform, je ne m’inquiète pas trop, si leur licence est trop restrictive alors le fork se fera surement car la base d’utilisateurs et de contributeurs est importante. Je pense notamment à Microsoft qui semble promouvoir pas mal l’outil pour la IaC sur Azure contrairement à AWS par exemple qui offre ses propres outils.
En dernier point, j’ajouterai que même lorsqu’un projet open source n’est pas issu d’une entreprise, il y a un risque d’abandon par son créateur, c’est même je trouve plus souvent le cas qui se produit.
Le business plan est probablement le suivant:
- On met le produit open source pour qu’il soit largement adopté
- On lève des fonds et on fait plein de marketing/communication pour s’assurer que le produit soit largement adopté
- On se rentabilise avec les services tiers et le support.
Ça change quoi à ce qui est prévu dans le BP ci-dessus que d’autres se fassent de l’argent ?
D’ailleurs la raison officielle c’est que “ceux qui se font de l’argent” ne contribuent pas au produit (HashiCorp adopts Business Source License).
However, there are other vendors who take advantage of pure OSS models, and the community work on OSS projects, for their own commercial goals, without providing material contributions back.
Finalement, l’histoire de la contribution n’est peut-être n’est-ce pas la vrai raison car la nouvelle licence impacte clairement ceux qui leur font concurrence avec leur propre produit (https://github.com/hashicorp/terraform/blame/main/LICENSE)
You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp’s products.
Quoi qu’il en soit, ce n’est pas ce sujet qui me fait réagir, mais le fait que l’éditeur puisse changer de licence et trahir tout ceux qui ont basé leur stratégie IT et leur investissement dans la solution sur la licence précédente. Tout le monde est maintenant en droit de se demander quel sera le prochain changement de licence et qui va-t-il impacter ?
Vu la démonstration que la licence peut être modifié au bon vouloir de Hashicorp et malgré les 1700 contributeurs au projet, que va-t-il se passer lorsque les investisseurs vont vouloir récupérer leur bénéfices ? Je doute que baser son IT sur cette solution soit une bonne idée.
Que dire des 1700 contributeurs qui ont fourni du code et des correctifs à un soft en pensant qu’il est publié sous une certaine licence et qui, du jour au lendemain, voient la licence changer ? Eux ont réellement bossé gratuitement pour une société qui leur a menti.
Par ailleurs, je ne comprends pas que l’on puisse changer de licence sans avoir l’aval des contributeurs qui ont fourni du code. Avec la GPL ce n’est possible.
Le succès du fork dépends énormément de l’argent mis dans le marketing. Il est très rare de voir un soft opensource (y compris un fork) aussi génial soit-il sortir du lot si il n’y a pas de l’argent injecté dans le marketing. Le soft opensource fait dans son garage et qui rencontre le succès est aujourd’hui un mythe.
Je suis bien d’accord. De mon coté j’essaye de trouver un bug à corriger ou une feature pour avoir au moins une contribution et voir comment cela se passe.
Sait tu si la MPL autorise un changement de licence sans l’accord des contributeurs ?
En effet, le changement de licence en l’état ne semble pas suffisamment restrictif pour faire fuir les contributeurs. Par ailleurs, c’est une licence pour embetter le “grand méchant” et beaucoup risque d’ voir du bien. Seulement, le code produit depuis 3 semaine est soumis a cette nouvelle licence, et si dans 3 ans la licence devient plus restrictive, le fork sera très dur car la dernière version sous licence interessante a forker datera de 3 ans en arrière.
On verra …
En effet, c’est très difficile de faire de l’open source. Beaucoup pensent qu’il suffit de publier du code sur github et de mettre une licence opensource. C’est faux, il faut investir du temps pour répondre aux question, aux contributeur, faire les merges, … Et ce temps doit être financé:
- soit par la publicité que cela apporte à la société,
- soit par des contributeur qui soulage une entreprise de la maintenance d’un de ces produit.
- soit par une vente de services.
A cette occasion, j’ai découvert des boites qui lors de chaque pull-request (github) demandent à l’auteur de valider une formulaire qui annonce abandoner tous les droits sur le code produit
Je suis pas sûr que cela ne s’applique pas aussi pour d’autres licences OSS. J’ai contribué il y a longtemps à docker-py en Apache v2 est j’ai dû valider le type de formulaire que tu mentionnes.
Pour moi ce type de formulaire est justement présent pour que la société ait la propriété exclusive du code. De cette manière elle peut changer de licence et aussi éviter des procès potentiels sur les droits d’auteurs.
Je ne suis pas sur que ce soit pour du droit d’auteur. Je participe régulièrement à HAProxy, j’ai beaucoup de code fait personnellement, et la règle consiste a mettre sont nom en copyright du fichier de code si la contribution est significative. Il n’y a aucune notion d’abandon de droits. Je reste l’auteur de ce que j’ai fait, et cela garanti que le soft reste open-source car je doit donner mon accord pour changer la licence.
Pour moi, la seule raison raison valable de vouloir obtenir la propriété de tout le code contribué est comme tu le souligne d’avoir la liberté de changer de licence, mais pour des raisons de protection procédurière. Je ne vois pas de cas ou cela peut se produire, cela dit les citoyens US ont peut être plus d’imagination qu’un français sur ces sujets.
En revanche, la raison que je vois est de pouvoir changer passer vers une licence commerciale si le projet à un certains succès.
Quoi qu’il en soit, cette pratique ne me rassure pas pour la pérénnité de l’usage d’un soft.
Absolument car HAProxy respecte la GPL et la philosophie de la licence.
Je pense que globalement si tu choisis la GPL, c’est que tu souhaites que le logiciel reste FLOSS.
Tu dois te souvenir de l’affaire avec SCO / Linux. Tu peux te faire poursuivre par une boite qui revendique la propriété sur du code. Donc un contributeur/socièté qui n’aurait pas abandonné son droit d’auteur peut se lancer dans ce type d’action.
Oui changer ou avoir une version propriétaire en parallèle. C’etait le cas avec Docker par exemple ou la solution Docker Datacenter, si je me souviens bien, etait propriètaire.
Quoi qu’il en soit, cette pratique ne me rassure pas pour la pérénnité de l’usage d’un soft.
Je suis d’accord avec toi. C’est un signe que le logiciel peut devenir propriètaire assez rapidement.
1 « J'aime »