David Delassus a écrit 761 commentaires

il faut le faire accepter à tous les contributeurs avant, les recontacter et leur faire accepter, sinon enlever / réécrire leurs contributions en cas de refus…

Oui, et cela sera le cas peu importe la licence, GPL, ou MIT, ou proprio.

Quand je dis que la gouvernance n'a rien à voir, je parle de la définition d'opensource. Lua est un projet opensource, la gouvernance n'est pas ouverte.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Mon intuition de béotien est que la MIT et les BSD sont concises car elles donnes des permissions sur un produit soumis aux droits d'auteurs (elles partent de "aucun droit" et en ajoutent), la ou la GPL par du domaine publique et ajoute des restrictions (pas de redistribution proprio, contamination, …).

En gros :

• MIT = Droits d'auteurs + Permission 1 + Permission 2 + Permission 3
• GPL = Domaine Public + Restriction 1 + Restriction 2 + …

Les restrictions sont plus compliquées à préciser dans un texte légal, pour éviter les "loopholes" (trous de boucle en français ?)

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

À moins de faire signer des CLA qui permettent cela.

Ce que tout les projets requiert quand ils deviennent suffisamment gros.

Mais si tu n'acceptes aucune contribution externe, est-ce de l'open-source dans un sens utile du mot ?

Le code est disponible et livré sous une licence libre. Il est par définition open-source.

La gouvernance du projet n'a rien à voir là dedans.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

C'est la que les projets mettent en place un "Contributor License Agreement" qui désigne une entité comme étant propriétaire du code, cela peut être une personne physique, ou une personne morale (association, entreprise, fondation, …).

Si ils ne le font pas, il faut effectivement l'accord de tout un chacun pour changer la licence.

EDIT: En fait, c'est plus une question de gouvernance du projet ça. Cela ne change pas le fait que la licence peut changer, même si c'était du GPL.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

si la version future est basée sur la version actuelle, le copyleft s'applique, non ?

Non car l'auteur a tout les droits sur le code.

Pour moi, la GPL est une garantie envers les utilisateurs que le code restera libre.

La GPL garantie que les autres contributeurs ne peuvent pas privatiser le code dont tu es l'auteur.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Un produit sous GPL, ça peut virer au proprio tout autant qu'un produit sous MIT.

La licence ne s'applique qu'au code existant, pas au code futur.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Linux 6.9

Un jour, j'apprendrais à écrire.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Non, évidement.

Donc, les AWS/GCP/Azure pourront toujours continuer à proposer des services licencié GPL, ce qui ne plaira toujours pas à éditeurs de ces logiciels car cela concurrencera leurs propres offres SaaS, ce qui ne les empêchera pas de changer de licence pour les versions futures.

La GPL aide en faisant en sorte qu'un éditeur comme Redis ne peut plus du jour au lendemain prendre tout le monde de vitesse avec une licence propriétaire.

Et comment elle empêche l'auteur du code de sortir les futures versions sous une licence non libre ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

La joie de la langue française ou "sans doute" peut s'interpréter comme voulant dire "probablement" :D

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Les 2 licences cités sont :

• RSALv2 (Redis Source Available License)
• SSPLv1 (Server Side Public License)

Personne n'a dit que la GPL n'était pas libre à ce que je sache.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Kubernetes, c'est le mauvais exemple.

C'est un logiciel tout droit sorti des laboratoires de Google, issue des 20 ans de travaux sur Borg. Google a transféré la gouvernance de Kubernetes à la CNCF (Cloud Native Computing Foundation) dont Google est l'un des membres fondateurs.

Quand on a les moyens financier des GAFAM, c'est tout de suite plus facile de faire de l'OpenSource. C'est pas pour rien que les plus gros contributeurs OpenSource sont des entreprises d'ailleurs.

N'oublions pas que:

• React et GraphQL, ça vient de chez Facebook
• Amazon paye des ingénieurs pour contribuer sur des projets OpenSource clés pour eux (comme MariaDB, PostgreSQL justement, …)
• Google est l'auteur de Kubernetes, Go, Carbon, BigTable qui a donné naissance à CassandraDB, …

Et on ne va pas oublier Intel et RedHat qui sont parmi les plus gros contributeurs au noyau Linux.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Imaginons que Redis fusse sous GPL.

Est-ce que fournir une plateforme qui te permet de te créer un serveur dans le "cloud" (aka: chez quelqu'un d'autre) avec un Redis installé dedans est contaminé par la GPL ?

Car c'est bien là le soi-disant problème : les clouds providers. Ils construisent leurs offres en se basant sur des briques libres (leur droit).

Ces mêmes auteurs ont une offre SaaS pour leurs briques libres :

• https://redis.com/cloud/overview/
• https://www.elastic.co/fr/cloud
• https://www.mongodb.com/atlas/database
• …

Du coup, les Google/Amazon/Microsoft/… font directement concurrence à ces offres SaaS. Et ça ne plait pas aux auteurs qui essayent de faire tourner un business (la concurrence, ça fait jamais plaisir).

Sauf que le service fournit par ces "cloud providers" n'est pas le même. Quand je vais chez GCP/AWS/Azure, c'est pas pour avoir "un Redis SaaS". C'est pour avoir une infrastructure complète : VMs, Container Registry, CI/CD pipelines, monitoring, secret management, IAM, …

Dans cette infrastructure, j'y déploie ensuite mes dépendances : base de données, caches, reverse proxies, …

Les cloud providers me fournissent ces dépendances complètement intégrées à leur infrastructure, sans que j'ai besoin d'aller faire le apt install moi même.

Ok, disons qu'ils n'ont plus le droit de le faire, et que je ne veuille pas "self-host" (aka: faire le apt install moi même). Je vais donc chez les SaaS de ces auteurs "libristes", et maintenant je dois payer de la bande passante entrante et sortante de mon infrastructure, ce qui est bien connu comme étant potentiellement l'une des plus grosses dépenses dans le cloud.

Quelle solution ces auteurs proposent ils pour cela ? D'ailleurs. Ou hébergent ils leurs instances clouds si ce n'est chez Google/Amazon/Microsoft/… ?

---

On est en 2024, les infrastructures hébergées et gérées dans le Cloud, c'est monnaie courante. Le vendor-lock, on s'y résous à contre coeur car c'est plus simple comme ça (il faut avouer que Kubernetes a un peu aider a faciliter la portabilité d'un cloud provider à l'autre, si on reste dans les cas simples).

Avoir un seul contrat avec un seul provider au lieu de 10 contrats (1 par provider pour chacune de nos dépendances), c'est plus facile.

Du coup, comment la GPL aide ici ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Le dire au préalable sauvera le potentiel contributeur de la frustration d'investir du temps, de l'énergie dans un patch qui ne sera pas accepté, voir ignoré. Cela évitera aussi une mauvaise réputation du style "les développeurs s'en foutent des utilisateurs, ils ignorent même les tickets et pull requests".

Dire à l'avance "on n'accepte pas les contributions" c'est communiquer clairement que la gouvernence du projet se fait en interne avec des personnes séléctionnées au compte goutte.

C'est de la communication, rien de plus. Communiquer ses choix de gouvernence, que tu sois d'accord avec ou non, c'est sain.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

T'inquiètes, c'était juste un petit troll gratuit comme on les aime en ce Trolldi 22 mars :)

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Perso, si personne d'autre n'a ramené de tire bouchon, j'accueille cette personne avec le sourire.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

the development of the project is not open source

Grosse différence.

je trouve ça dommage, puisque c’est se priver de nombreuses contributions externes potentielles

Peut être qu'ils ne font pas de l'open source pour avoir des contributions externes. Peut être qu'ils n'ont pas les resources, le temps, l'énergie, l'envie, de traiter avec des inconnus qui ne partagent pas forcément la même vision de l'avenir du projet.

Je comprends parfaitement l'envie de se fermer aux contributions externes.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

J'avais rapidement l'impression de faire du lisp

Mais, c'est bien le Lisp pourtant !

https://xkcd.com/297/

---

PS: Oui Ysabeau, j'ai le droit de hotlink cette image, le site de xkcd fournit même le lien pour le faire.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Cela me fait penser à la gouvernance du projet Lua :

On vous file les sources lors d'une release, mais tout le reste, ça se passe en privé, entre nous.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

CONTRIBUTING.md pre PR

Note: by contributing code to the Redis project in any form, including sending a pull request via GitHub, a code fragment or patch via private email or public discussion groups, you agree to release your code under the terms of the Redis license that you can find in the COPYING file included in the Redis source distribution.

---

Note: En contribuant du code au projet Redis sous n'importe quelle forme, incluant l'envoi d'une Pull Request via Github, un fragment de code ou un patch via email privé ou groupes de discussion publics, vous acceptez de diffuser votre code sous les termes de la licence Redis que vous pouvez trouver dans le fichier COPYING inclus dans les sources du projet Redis.

La licence c'était donc du BSD-3 : COPYING pre PR

Qui autorise donc la redistribution du code sous une autre licence.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

import typing

try:
    from yaml import CSafeLoader as SafeLoader

    if typing.TYPE_CHECKING:
        from yaml import SafeLoader as _SafeLoader
        SafeLoader = typing.cast(type[_SafeLoader], SafeLoader)

except ImportError:
    from yaml import SafeLoader

Le if typing.TYPE_CHECKING n'est entré que lors du (roulement de tambours) type-checking par mypy.

C'est aussi utile pour les imports circulaires (quand on a des classes définies dans plusieurs modules qui se référencent mutuellement via les annotations).

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Complètement d'accord.

Plus je l'utilise, plus je suis contre.

Il faut noter que mypy est un très mauvais outil, il abandonne très vite lorsqu'il s'agit d'inférer des types complexes. Pyright (qui est développé en typescript et inclus de base avec VS Code) est mieux, mais on a toujours pas un type-checker qui soit solide.

Le système de type que Python propose est de plus peu expressif et ne fonctionne tout simplement pas dans des cas pourtant simple, par exemple :

type Request = Union[
  tuple[Literal["action_a"], PayloadA],
  tuple[Literal["action_b"], PayloadB],
]

match request:
    case ("action_a", payload_a):
        pass

    case ("action_b", payload_b):
        pass

Dans cet exemple, mypy ne sait pas inférer le type de payload_a ou payload_b.

Et il sera impossible d'exprimer un type Response dont les variants dépendent du variant de Request :

type Response = Union[
    ResponseA,
    ResponseB,
]

Comment exprimer que quand j'ai une PayloadA je reçois une ResponseA ? En Python c'est pas possible.

De plus, Python est un langage qui est de nature purement dynamique. Aucun type-checker ne pourra vérifier la magie noire que l'on peut faire avec de la magie noire à base de subclasshook. Et pourtant ce sont des choses bien utiles parfois lorsqu'il est question de génération de code au runtime.

Au final, je deviens de l'avis suivant :

Si tu veux un système de type, tu veux un autre langage, alors utilise un autre langage.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

18/20, on a le droit de faire des arrondis quand même ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Il n'y a qu'a voir pourquoi Linus Torwald, la maison Blanche, Google (Qui avait développé son concurrent Go) ne jurent maintenant que par Rust.

Linus Torvalds qui persiste et signe quand il dit que le noyau Linux restera écrit en C, et que le C reste le meilleur langage pour du développement d'OS ne jure que par Rust ? T'as des sources ?

Les politiciens de la maison blanche, on s'en cogne un peu.

Google ne jure pas que par Rust, ils continuent de maintenir Go et ils ont même démarré Carbon en plus.

[phrase retirée par la modération]

NdM: commentaire édité par la modération

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Si la HashMap avec l'algorithme de hashage par défaut de Rust est très lente ça ne durera pas.

Bah si, ça durera. Car c'est l'idée même de cette fonction de hashage, être cryptographiquement solide, cela veut donc dire exécution en temps constant (pour ne pas leak des infos sur la données en fonction du temps d'exécution). Elle ne sera donc jamais pus performante qu'un dict Python, car la team de Rust préfère fournir quelque chose de sécurisé par défaut.

La performance ça ne fait pas tout. Surtout quand tu es dans du IO bound et non du CPU bound (aka: tu passes plus de temps à attendre une réponse de la base de données qu'à faire des calculs).

C'est d'ailleurs pourquoi Java, Python, et Go sont très présents.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

S'arrêter proprement c'est relâcher les resources que l'on a acquise (file descriptor, socket, …) avant l'arrêt effectif. Ou plus communément appelé : "graceful shutdown".

Si ton serveur derrière le socket s'attend à ce que tu lui envoie goodbye avant de fermer le socket, c'est pas l'OS qui va le faire pour toi.

Par contre en Rust pour générer un pannic! il faut normalement faire un ".unwrap()" ou quelque chose de cet ordre.

Oue, il faudrait avoir fait un peu de Rust en fait avant de parler de Rust.

La fonction .unwrap() existe pour les types Result<T, E> et Option<T>. Elle génère effectivement un panic! si le Result<T, E> contient Err(E), ou si le Option<T> contient None.

De la même manière, Result<T, E> a une fonction .unwrap_err() qui génère un panic! si le Result<T, E> contient Ok(T).

C'est pas inné au langage, c'est un design d'API. Un autre design c'est que toutes les allocations faites par la stdlib génèrent un panic! si l'allocation échoue, à savoir notamment :

• Box::new(...)
• Vec::push(...)
• etc…

Note qu'il existe aussi Box::try_new(...) qui au lieu de générer un panic! va retourner un Result<T, E> avec Ok(Box<T>) ou Err(OutOfMemory). Et bien sûr, équivalent pour toutes fonctions allouant de la mémoire.

Mais tout ça, c'est au delà de ce que je disais, à savoir :

Il n'y a aucune différence entre panic! et :

void *p = malloc(size);
if (p == NULL) {
  abort(...);
}

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg