La fondation LLVM change la licence de LLVM pour la passer à une licence Apache 2 + LLVM exception. Pour cela, ils ont besoin de l'accord de tous les développeurs qui ont contribué. Ils en sont à 94% du code avec la nouvelle licence. Plus de détails dans le lien.
Posté par Zenitram (site web personnel) .
Évalué à 3.
Dernière modification le 21 novembre 2021 à 16:25.
Dans l'image des acceptations manquantes il y a des gros rectangles, ça n'est pas une seule ligne de code…
Il reste 6% à gérer, ce n'est pas rien. A un moment ils pourront se demander de regarder si c'est copyrightables et si oui se taper à ré-écrire (ce n'est pas marrant comme taf), mais la ils ne semblent pas en être encore à cette étape.
Posté par _kaos_ .
Évalué à 2.
Dernière modification le 22 novembre 2021 à 07:09.
Il est possible que l'auteur de ce commit ne se soit pas limité à ce seul commit (pure hypothèse).
Et quand bien même, la réponse est oui, car cet ajout, dans l'ensemble global, est la contribution. Ce n'est pas simplement le break (qui en soit n'appartient à personne, probablement : c'est tout au mieux un mot clef utilisé dans différents langages ; un concept, donc).
Il est possible que l'auteur de ce commit ne se soit pas limité à ce seul commit (pure hypothèse).
Quand tu regardes la liste (Google Documents), tout en bas tu as une tripoté de personnes qui n’ont fait qu’un seul commit et n’ont changé qu’une seule ligne de code. J’en ai pris un au hasard et je suis tombé sur l’ajout d’un break, mais je suppose que pour les autres c’est pareil.
D’où ma question, ajouter un break ne transforme probablement pas une fonction en une œuvre originale, donc l’auteur ou l’autrice n’a probablement aucun droit sur le code, donc LLVM n’a probablement pas besoin de lui demandé son accord pour changer sa licence.
Zenitram répond (à sa manière alambiqué) qu’il n’en sont pas encore à l’étape de prendre une décision sur ces petites modifications et sous entend qu’ils pourraient effectivement ne pas demander l’accord de leurs auteurs ou autrices.
C'est tout sauf cosmétique, et c'est potentiellement dur à détecter au vu du break juste au dessus. Perso, je ne jugerai pas un apport sur le nombre de lignes/caractères ajoutés/modifiés… Ça demande de comprendre tout le code autour, aussi. Je me garderai bien de juger.
Ensuite, je ne suis pas certain que tout le monde puisse commiter comme bon lui semble dans llvm. Ça peut aussi être un commit pour avoir son nom dans la liste des contributeurs (ça fait bien sur le CV). Ou encore une volonté de faire valoir ses droits, de manière plus ou moins nuisible.
Posté par _kaos_ .
Évalué à 2.
Dernière modification le 22 novembre 2021 à 23:06.
C’est pour ça que je pose une question…
Et c'est bien le sens de ma réponse : strictement parlant, oui, il faut l'accord de tous. Et tu auras autant de réponses que d'interprétation des licences, voir plus.
Aller au delà, c'est prendre position sur la valeur de la contribution, et n'étant pas juriste, je souligne juste que se borner aux règles établies évite tout problème.
Tu pars au début du principe que c'est juste un commit d'une ligne constitué d'un mot clef, alors bon, hein, on peut bien s’asseoir dessus… je t'ai (volontairement) poussé à l'admettre : ce n'est peut-être pas simplement cosmétique. Ça pose des problèmes : où est la limite si l'on fait des distinctions de valeur ? Qui juge la valeur au final ? Quelle serait la licence de ce même ajout si c'était un robot qui l'avait introduit automatiquement, par apprentissage à partir d'autres exemples de code ? (je charrie un peu, là…)
C'est un cas assez limite, certes, mais c'est ouvrir la voie à d'autres petits arrangements. Puis d'autres, parce qu'en fait, le précédent n'arrangeait pas tant que ça, et ainsi de suite. Ça crée un précédent, dit autrement :) Et le projet LLVM a pas mal de visibilité, ce qui est "assez" gênant, pour des défenseurs d'une application stricte du droit. Le problème sera donc non pas de convaincre uniquement tous les détenteurs de droits de changer de licence, mais aussi d'ignorer la licence d'autres contributeurs, au risque de voir les voir demander un retrait de leur contribution au projet, si celui-ci suit cette voie non stricte (bin oui, s'ils n'adhèrent plus aux valeurs, ça peut changer leur vision des choses et l'accord) ;)
Comme je l'indiquais plus haut, cette pratique d'un petit commit est plus ou moins un moyen de verrouiller un outil à une licence, pour le meilleur ou le pire. Même si ce n'est probablement pas totalement vrai, je pense que c'est très compliqué dès le premier petit commit minime de changer une licence. Du coup, ce ne sont plus seulement les gros blocs qui vont poser problème, mais chaque petit détail également, à traiter plus ou moins individuellement.
Pour faire un autre parallèle plus gros, c'est comme si l'avis des personnes qui corrigent des fautes d'orthographe dans la documentation ne comptait pas. C'est déjà pas facile d'avoir de la documentation, si en plus leur boulot est écarté car non utile fonctionnellement, bon courage pour recruter de futurs contributeurs…
C'est avant tout un problème éthique, donc. Avec son paquet de complexité associé :) Il n'y a pas de bonne et unique réponse à ta question, à mon avis.
Non cosmétique, mais les idées ne sont pas copyrightable, et ça me semble plus une idée que d'une réflexion sur comment tourner un algo, ce qui serait plus copyrightable.
Je ne suis pas juriste, je précise! Mais perso j'ai pour habitude de demander un CLA sauf pour quand c'est ce genre de "bug fix", je prend le "risque" pour si un jour je change (encore) de licence.
Les CLA ne sont pas toujours appréciés (ils permettent des trucs moins sympas comme une version non libre par l'ayant droit, compensable par la création d'une entité non commerciale gérée par la communauté et en charge de ces droits, ou par la disponibilité en licence permissive qui laisse peu de place à la valorisation d'avoir plus de droits que les autres) mais ça évite ce genre de galères… A méditer quand vous commencez un projet, un CLA peut d'un côté vous faire perdre des contributeurs mais d'un autre côté vous éviter des ennuies quand pour une raison X ou Y vous avez besoin de passer à une autre licence.
Bon courage, car entre les entités (entreprises ou personnes) qui en ont rien à faire et les celles qui n'existent plus…
Je me demande s'il n'y aurait pas un genre de CLA qui ferait moins peur, du style « j'autorise X à changer la licence de ma contribution, si j'ai (ou les ayants droits ont) été contacté et qu'on n'a pas donné de nouvelles / on ne s'est pas opposés dans les 6 mois, ou qu'on n'est plus joignables » (en légalement plus robuste).
Je me suis déjà posé la question de faire l'inverse : contribuer sous une licence très permissive. Comme ça quand ils mergent, ils passent la contribution à la licence qu'ils veulent mais le patch en lui même peut changer de licence au besoin.
D'ailleurs ça aurait comme avantage de donner le droit à tout le monde et pas seulement aux mainteneurs.
Posté par raphj .
Évalué à 2.
Dernière modification le 24 novembre 2021 à 08:44.
Pour moi, si le principe est appliqué à toutes les contributions, ça tue effectivement l'utilité / l'intérêt des licences copyleft (pour les projets en copyleft), parce que ça veut dire que potentiellement la grosse majorité du code du projet et sous cette licence très permissive. Pour les projets sous licence copyfree je suppose qu'il y aurait des effets similaires.
Cela dit, si c'est un choix que tu fais toi en tant que contributeur individuel de placer ta contribution sous une licence très permissive, c'est tout à ton honneur je suppose !
# Résumé
Posté par vitanix . Évalué à 2.
La fondation LLVM change la licence de LLVM pour la passer à une licence Apache 2 + LLVM exception. Pour cela, ils ont besoin de l'accord de tous les développeurs qui ont contribué. Ils en sont à 94% du code avec la nouvelle licence. Plus de détails dans le lien.
[^] # Re: Résumé
Posté par Anonyme . Évalué à 1. Dernière modification le 21 novembre 2021 à 15:13.
Ezt-ce qu'ils ont vraiment besoin de l'accord de tout le monde ?
Je veux dire, dans la liste j'ai vu un commit qui ajoute un
breakdans une boucle.[^] # Re: Résumé
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 21 novembre 2021 à 16:25.
Dans l'image des acceptations manquantes il y a des gros rectangles, ça n'est pas une seule ligne de code…
Il reste 6% à gérer, ce n'est pas rien. A un moment ils pourront se demander de regarder si c'est copyrightables et si oui se taper à ré-écrire (ce n'est pas marrant comme taf), mais la ils ne semblent pas en être encore à cette étape.
[^] # Re: Résumé
Posté par _kaos_ . Évalué à 2. Dernière modification le 22 novembre 2021 à 07:09.
Il est possible que l'auteur de ce commit ne se soit pas limité à ce seul commit (pure hypothèse).
Et quand bien même, la réponse est oui, car cet ajout, dans l'ensemble global, est la contribution. Ce n'est pas simplement le break (qui en soit n'appartient à personne, probablement : c'est tout au mieux un mot clef utilisé dans différents langages ; un concept, donc).
Matricule 23415
[^] # Re: Résumé
Posté par Anonyme . Évalué à 2.
Quand tu regardes la liste (Google Documents), tout en bas tu as une tripoté de personnes qui n’ont fait qu’un seul commit et n’ont changé qu’une seule ligne de code. J’en ai pris un au hasard et je suis tombé sur l’ajout d’un break, mais je suppose que pour les autres c’est pareil.
D’où ma question, ajouter un break ne transforme probablement pas une fonction en une œuvre originale, donc l’auteur ou l’autrice n’a probablement aucun droit sur le code, donc LLVM n’a probablement pas besoin de lui demandé son accord pour changer sa licence.
Zenitram répond (à sa manière alambiqué) qu’il n’en sont pas encore à l’étape de prendre une décision sur ces petites modifications et sous entend qu’ils pourraient effectivement ne pas demander l’accord de leurs auteurs ou autrices.
[^] # Re: Résumé
Posté par _kaos_ . Évalué à 4.
On parle bien de celui-là ?
C'est tout sauf cosmétique, et c'est potentiellement dur à détecter au vu du break juste au dessus. Perso, je ne jugerai pas un apport sur le nombre de lignes/caractères ajoutés/modifiés… Ça demande de comprendre tout le code autour, aussi. Je me garderai bien de juger.
Ensuite, je ne suis pas certain que tout le monde puisse commiter comme bon lui semble dans llvm. Ça peut aussi être un commit pour avoir son nom dans la liste des contributeurs (ça fait bien sur le CV). Ou encore une volonté de faire valoir ses droits, de manière plus ou moins nuisible.
Matricule 23415
[^] # Re: Résumé
Posté par Anonyme . Évalué à 2.
J’ai jamais dit que c’était cosmétique…
C’est pour ça que je pose une question…
[^] # Re: Résumé
Posté par _kaos_ . Évalué à 2. Dernière modification le 22 novembre 2021 à 23:06.
Et c'est bien le sens de ma réponse : strictement parlant, oui, il faut l'accord de tous. Et tu auras autant de réponses que d'interprétation des licences, voir plus.
Aller au delà, c'est prendre position sur la valeur de la contribution, et n'étant pas juriste, je souligne juste que se borner aux règles établies évite tout problème.
Tu pars au début du principe que c'est juste un commit d'une ligne constitué d'un mot clef, alors bon, hein, on peut bien s’asseoir dessus… je t'ai (volontairement) poussé à l'admettre : ce n'est peut-être pas simplement cosmétique. Ça pose des problèmes : où est la limite si l'on fait des distinctions de valeur ? Qui juge la valeur au final ? Quelle serait la licence de ce même ajout si c'était un robot qui l'avait introduit automatiquement, par apprentissage à partir d'autres exemples de code ? (je charrie un peu, là…)
C'est un cas assez limite, certes, mais c'est ouvrir la voie à d'autres petits arrangements. Puis d'autres, parce qu'en fait, le précédent n'arrangeait pas tant que ça, et ainsi de suite. Ça crée un précédent, dit autrement :) Et le projet LLVM a pas mal de visibilité, ce qui est "assez" gênant, pour des défenseurs d'une application stricte du droit. Le problème sera donc non pas de convaincre uniquement tous les détenteurs de droits de changer de licence, mais aussi d'ignorer la licence d'autres contributeurs, au risque de voir les voir demander un retrait de leur contribution au projet, si celui-ci suit cette voie non stricte (bin oui, s'ils n'adhèrent plus aux valeurs, ça peut changer leur vision des choses et l'accord) ;)
Comme je l'indiquais plus haut, cette pratique d'un petit commit est plus ou moins un moyen de verrouiller un outil à une licence, pour le meilleur ou le pire. Même si ce n'est probablement pas totalement vrai, je pense que c'est très compliqué dès le premier petit commit minime de changer une licence. Du coup, ce ne sont plus seulement les gros blocs qui vont poser problème, mais chaque petit détail également, à traiter plus ou moins individuellement.
Pour faire un autre parallèle plus gros, c'est comme si l'avis des personnes qui corrigent des fautes d'orthographe dans la documentation ne comptait pas. C'est déjà pas facile d'avoir de la documentation, si en plus leur boulot est écarté car non utile fonctionnellement, bon courage pour recruter de futurs contributeurs…
C'est avant tout un problème éthique, donc. Avec son paquet de complexité associé :) Il n'y a pas de bonne et unique réponse à ta question, à mon avis.
Matricule 23415
[^] # Re: Résumé
Posté par Zenitram (site web personnel) . Évalué à 2.
Non cosmétique, mais les idées ne sont pas copyrightable, et ça me semble plus une idée que d'une réflexion sur comment tourner un algo, ce qui serait plus copyrightable.
Je ne suis pas juriste, je précise! Mais perso j'ai pour habitude de demander un CLA sauf pour quand c'est ce genre de "bug fix", je prend le "risque" pour si un jour je change (encore) de licence.
# Moralité
Posté par Zenitram (site web personnel) . Évalué à 4.
Les CLA ne sont pas toujours appréciés (ils permettent des trucs moins sympas comme une version non libre par l'ayant droit, compensable par la création d'une entité non commerciale gérée par la communauté et en charge de ces droits, ou par la disponibilité en licence permissive qui laisse peu de place à la valorisation d'avoir plus de droits que les autres) mais ça évite ce genre de galères… A méditer quand vous commencez un projet, un CLA peut d'un côté vous faire perdre des contributeurs mais d'un autre côté vous éviter des ennuies quand pour une raison X ou Y vous avez besoin de passer à une autre licence.
Bon courage, car entre les entités (entreprises ou personnes) qui en ont rien à faire et les celles qui n'existent plus…
[^] # Re: Moralité
Posté par raphj . Évalué à 6.
Je me demande s'il n'y aurait pas un genre de CLA qui ferait moins peur, du style « j'autorise X à changer la licence de ma contribution, si j'ai (ou les ayants droits ont) été contacté et qu'on n'a pas donné de nouvelles / on ne s'est pas opposés dans les 6 mois, ou qu'on n'est plus joignables » (en légalement plus robuste).
[^] # Re: Moralité
Posté par barmic 🦦 . Évalué à 3.
Je me suis déjà posé la question de faire l'inverse : contribuer sous une licence très permissive. Comme ça quand ils mergent, ils passent la contribution à la licence qu'ils veulent mais le patch en lui même peut changer de licence au besoin.
D'ailleurs ça aurait comme avantage de donner le droit à tout le monde et pas seulement aux mainteneurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Moralité
Posté par raphj . Évalué à 2. Dernière modification le 24 novembre 2021 à 08:44.
Pour moi, si le principe est appliqué à toutes les contributions, ça tue effectivement l'utilité / l'intérêt des licences copyleft (pour les projets en copyleft), parce que ça veut dire que potentiellement la grosse majorité du code du projet et sous cette licence très permissive. Pour les projets sous licence copyfree je suppose qu'il y aurait des effets similaires.
Cela dit, si c'est un choix que tu fais toi en tant que contributeur individuel de placer ta contribution sous une licence très permissive, c'est tout à ton honneur je suppose !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.