C'est important, afin de ne pas laisser "les journaleux" faire des
déclarations tonitruantes à effets d'annonces "achetez mon jo urnal",
du genre : "Microsoft migre vers les Logiciels Libres et l'Opensource",
sous entendu "la paix est signée entre les deux communautés" .
Comme cela s'était passé il y a quelques années avec l'a ccord
entre Linux-Suse et Microsoft, le Figaro titrait :
"La paix enfin signée entre Microsoft et Linux"
(Benh voyons... !)
C'est important, afin de ne pas laisser "les journaleux" faire des
déclarations tonitruantes à effets d'annonces "achetez mon jo urnal",
du genre : "Microsoft migre vers les Logiciels Libres et l'Opensource",
sous entendu "la paix est signée entre les deux communautés" .
Comme cela s'était passé il y a quelques années avec l'a ccord
entre Linux-Suse et Microsoft, le Figaro titrait :
"La paix enfin signée entre Microsoft et Linux"
(Benh voyons... !)
C'est important, afin de ne pas laisser "les journaleux" faire des
déclarations tonitruantes à effets d'annonces "achetez mon jo urnal",
du genre : "Microsoft migre vers les Logiciels Libres et l'Opensource",
sous entendu "la paix est signée entre les deux communautés" .
Comme cela s'était passé il y a quelques années avec l'a ccord
entre Linux-Suse et Microsoft, le Figaro titrait :
"La paix enfin signée entre Microsoft et Linux"
(Benh voyons... !)
Par exemple, en ce qui concerne la voie de conséquence : ça n 'est pas parce
que .NET Fondation va inclure le code dans son projet sous la licence M IT
(Expat) en laissant le nom du contributeur que celui-ci a un droit de r egard
sur le code publié. Il ne pourrait donc pas en demander le retrait pour une
raison x ou y en se prévalant d'en être l'auteur initial. La licence MIT
(Expat) permet normalement de rendre du code non libre, de le retirer, par
exemple. En gros, le contributeur se refuserait à dire devant un j uge : c'est
mon code, il est publié sous mon nom par .NET Fondation (quoique c ela reste Ã
voir s'ils vont intégrer le nom des contributeurs), la licence Exp at me permet
de retirer mon code et de le rendre non-libre, alors faîtes-le. Da ns ce cas,
la fondation opposerait au contributeur la clause 4.3 du contrat qu'il a
signé. Ãa va de paire aussi avec l'estoppel en substance est un principe
indiquant que "nul ne peut se contredire au détriment d'autrui". O n pourrait
prendre un exemple comme cela pour chaque cas. Et surtout notons le "ou
autre", qui laisse une ouverture totale.
Par exemple, en ce qui concerne la voie de conséquence : ça n 'est pas parce
que .NET Fondation va inclure le code dans son projet sous la licence M IT
(Expat) en laissant le nom du contributeur que celui-ci a un droit de r egard
sur le code publié. Il ne pourrait donc pas en demander le retrait pour une
raison x ou y en se prévalant d'en être l'auteur initial. La licence MIT
(Expat) permet normalement de rendre du code non libre, de le retirer, par
exemple. En gros, le contributeur se refuserait à dire devant un j uge : c'est
mon code, il est publié sous mon nom par .NET Fondation (quoique c ela reste Ã
voir s'ils vont intégrer le nom des contributeurs), la licence Exp at me permet
de retirer mon code et de le rendre non-libre, alors faîtes-le. Da ns ce cas,
la fondation opposerait au contributeur la clause 4.3 du contrat qu'il a
signé. Ãa va de paire aussi avec l'estoppel en substance est un principe
indiquant que "nul ne peut se contredire au détriment d'autrui". O n pourrait
prendre un exemple comme cela pour chaque cas. Et surtout notons le "ou
autre", qui laisse une ouverture totale.
Par exemple, en ce qui concerne la voie de conséquence : ça n 'est pas parce
que .NET Fondation va inclure le code dans son projet sous la licence M IT
(Expat) en laissant le nom du contributeur que celui-ci a un droit de r egard
sur le code publié. Il ne pourrait donc pas en demander le retrait pour une
raison x ou y en se prévalant d'en être l'auteur initial. La licence MIT
(Expat) permet normalement de rendre du code non libre, de le retirer, par
exemple. En gros, le contributeur se refuserait à dire devant un j uge : c'est
mon code, il est publié sous mon nom par .NET Fondation (quoique c ela reste Ã
voir s'ils vont intégrer le nom des contributeurs), la licence Exp at me permet
de retirer mon code et de le rendre non-libre, alors faîtes-le. Da ns ce cas,
la fondation opposerait au contributeur la clause 4.3 du contrat qu'il a
signé. Ãa va de paire aussi avec l'estoppel en substance est un principe
indiquant que "nul ne peut se contredire au détriment d'autrui". O n pourrait
prendre un exemple comme cela pour chaque cas. Et surtout notons le "ou
autre", qui laisse une ouverture totale.
On Mon, Nov 17, 2014 at 05:38:52PM +0100, wro te:
> C'est important, afin de ne pas laisser "les journaleux" faire des
> déclarations tonitruantes à effets d'annonces "achetez mon jo urnal",
> du genre : "Microsoft migre vers les Logiciels Libres et l'Opensource",
> sous entendu "la paix est signée entre les deux communautés".
> Comme cela s'était passé il y a quelques années avec l'a ccord
> entre Linux-Suse et Microsoft, le Figaro titrait :
> "La paix enfin signée entre Microsoft et Linux"
> (Benh voyons... !)
Boh, je suis pas sûr que les contributeurs du libre et de l'open sou rce
soient forcément dupes quant aux annonces de Microsoft. Ne serait-ce que
pour d'autres entreprises, il y a eu un grand changement si on pense par
exemple à Google. On peut faire toutes les critiques que l'on veut, les
communautés sont réactives. Même à propos de logiciel fer-de-lance Mozilla,
il y a pas mal d'accusations (je pense à l'annonce récente "vou s êtes
libres" où il y a eu pas mal de lulz en mettant en avant les relatio ns avec
Google). Idem, mais à l'inverse, pour des services comme github, ser vice
fermé mais utilisant des logiciels libres. Les communautés gard ent un sens
critique. Je ne sais plus où j'ai lu que github hébergeait bien plus de
code libre que gitlab qui lui a pas mal de logiciel à source fermà ©e (je
n'ai jamais vérifié l'information, je ne sais pas si c'est vrai ).
Par contre, effectivement, en ce qui concerne les annonces grand public,
là ...
On Mon, Nov 17, 2014 at 05:38:52PM +0100, andre_debian@numericable.fr wro te:
> C'est important, afin de ne pas laisser "les journaleux" faire des
> déclarations tonitruantes à effets d'annonces "achetez mon jo urnal",
> du genre : "Microsoft migre vers les Logiciels Libres et l'Opensource",
> sous entendu "la paix est signée entre les deux communautés".
> Comme cela s'était passé il y a quelques années avec l'a ccord
> entre Linux-Suse et Microsoft, le Figaro titrait :
> "La paix enfin signée entre Microsoft et Linux"
> (Benh voyons... !)
Boh, je suis pas sûr que les contributeurs du libre et de l'open sou rce
soient forcément dupes quant aux annonces de Microsoft. Ne serait-ce que
pour d'autres entreprises, il y a eu un grand changement si on pense par
exemple à Google. On peut faire toutes les critiques que l'on veut, les
communautés sont réactives. Même à propos de logiciel fer-de-lance Mozilla,
il y a pas mal d'accusations (je pense à l'annonce récente "vou s êtes
libres" où il y a eu pas mal de lulz en mettant en avant les relatio ns avec
Google). Idem, mais à l'inverse, pour des services comme github, ser vice
fermé mais utilisant des logiciels libres. Les communautés gard ent un sens
critique. Je ne sais plus où j'ai lu que github hébergeait bien plus de
code libre que gitlab qui lui a pas mal de logiciel à source fermà ©e (je
n'ai jamais vérifié l'information, je ne sais pas si c'est vrai ).
Par contre, effectivement, en ce qui concerne les annonces grand public,
là ...
On Mon, Nov 17, 2014 at 05:38:52PM +0100, wro te:
> C'est important, afin de ne pas laisser "les journaleux" faire des
> déclarations tonitruantes à effets d'annonces "achetez mon jo urnal",
> du genre : "Microsoft migre vers les Logiciels Libres et l'Opensource",
> sous entendu "la paix est signée entre les deux communautés".
> Comme cela s'était passé il y a quelques années avec l'a ccord
> entre Linux-Suse et Microsoft, le Figaro titrait :
> "La paix enfin signée entre Microsoft et Linux"
> (Benh voyons... !)
Boh, je suis pas sûr que les contributeurs du libre et de l'open sou rce
soient forcément dupes quant aux annonces de Microsoft. Ne serait-ce que
pour d'autres entreprises, il y a eu un grand changement si on pense par
exemple à Google. On peut faire toutes les critiques que l'on veut, les
communautés sont réactives. Même à propos de logiciel fer-de-lance Mozilla,
il y a pas mal d'accusations (je pense à l'annonce récente "vou s êtes
libres" où il y a eu pas mal de lulz en mettant en avant les relatio ns avec
Google). Idem, mais à l'inverse, pour des services comme github, ser vice
fermé mais utilisant des logiciels libres. Les communautés gard ent un sens
critique. Je ne sais plus où j'ai lu que github hébergeait bien plus de
code libre que gitlab qui lui a pas mal de logiciel à source fermà ©e (je
n'ai jamais vérifié l'information, je ne sais pas si c'est vrai ).
Par contre, effectivement, en ce qui concerne les annonces grand public,
là ...
En ce qui concerne le CLA de Google par contre, a priori je te rejoindrai .
Mais je ne l'ai lu qu'en diagonale. à première vue, il n'est pa s dit que le
contributeur conserve ses droits sur son code tandis qu'ils les accordent bien
à Google.
Pour finir avec ce message déjà trop long, je me permet de fair e une remarque
concernant ton intervention "ce sont des CLAs, ils ne différent en r ien". Je
préfère voir cela comme une question : "ce sont tous des CLAs, en quoi
diffèrent-ils ?"
Conséquence, le code appartient à .NET Fondation et plus au con tributeur
En ce qui concerne le CLA de Google par contre, a priori je te rejoindrai .
Mais je ne l'ai lu qu'en diagonale. à première vue, il n'est pa s dit que le
contributeur conserve ses droits sur son code tandis qu'ils les accordent bien
à Google.
Pour finir avec ce message déjà trop long, je me permet de fair e une remarque
concernant ton intervention "ce sont des CLAs, ils ne différent en r ien". Je
préfère voir cela comme une question : "ce sont tous des CLAs, en quoi
diffèrent-ils ?"
Conséquence, le code appartient à .NET Fondation et plus au con tributeur
En ce qui concerne le CLA de Google par contre, a priori je te rejoindrai .
Mais je ne l'ai lu qu'en diagonale. à première vue, il n'est pa s dit que le
contributeur conserve ses droits sur son code tandis qu'ils les accordent bien
à Google.
Pour finir avec ce message déjà trop long, je me permet de fair e une remarque
concernant ton intervention "ce sont des CLAs, ils ne différent en r ien". Je
préfère voir cela comme une question : "ce sont tous des CLAs, en quoi
diffèrent-ils ?"
Conséquence, le code appartient à .NET Fondation et plus au con tributeur
Le 17 novembre 2014 20:22, FGK a écrit :
[...]
> En ce qui concerne le CLA de Google par contre, a priori je te rejoin drai.
> Mais je ne l'ai lu qu'en diagonale. à première vue, il n'es t pas dit que
> le contributeur conserve ses droits sur son code tandis qu'ils les
> accordent bien à Google.
Si si, au 1er paragraphe.
Mais ce texte vient en préambule, je suis étonné que à §a ait une quelconque
valeur.
C'est aussi marqué (pour Google et Apache) que le CLA protège le
contributeur ; or je ne vois pas en quoi abandonner une partie de ses d roits
permet de se protéger.
> Conséquence, le code appartient à .NET Fondation et plus au contributeur
Je ne suis pas d'accord, mais bon
, en le relisant, la section 8 me semble hautement problématique, je n'ai
donc pas envie de le défendre. En tant que non-juriste, je ne com prends pas
les implications de cette section, et n'aurais aucune envie de signer c e
CLA. Idem pour celui de Canonical, au passage (section 6.1).
Ah zut, je l'ai signé ;-)
D'accord pour dire que tous les CLA ne se valent pas ; ceux d'Apache et de
Google me semblent les moins mauvais, ils sont courts et sont
compréhensibles par des non-initiés.Mais les communautés sont toujours
réticentes à s'engager dans cette voie, Arduino est en train de l'apprendre
à ses dépens par exemple
https://groups.google.com/a/arduino.cc/forum/#!topic/developers/9dirF2a XhAE
Le 17 novembre 2014 20:22, FGK a écrit :
[...]
> En ce qui concerne le CLA de Google par contre, a priori je te rejoin drai.
> Mais je ne l'ai lu qu'en diagonale. à première vue, il n'es t pas dit que
> le contributeur conserve ses droits sur son code tandis qu'ils les
> accordent bien à Google.
Si si, au 1er paragraphe.
Mais ce texte vient en préambule, je suis étonné que à §a ait une quelconque
valeur.
C'est aussi marqué (pour Google et Apache) que le CLA protège le
contributeur ; or je ne vois pas en quoi abandonner une partie de ses d roits
permet de se protéger.
> Conséquence, le code appartient à .NET Fondation et plus au contributeur
Je ne suis pas d'accord, mais bon
, en le relisant, la section 8 me semble hautement problématique, je n'ai
donc pas envie de le défendre. En tant que non-juriste, je ne com prends pas
les implications de cette section, et n'aurais aucune envie de signer c e
CLA. Idem pour celui de Canonical, au passage (section 6.1).
Ah zut, je l'ai signé ;-)
D'accord pour dire que tous les CLA ne se valent pas ; ceux d'Apache et de
Google me semblent les moins mauvais, ils sont courts et sont
compréhensibles par des non-initiés.Mais les communautés sont toujours
réticentes à s'engager dans cette voie, Arduino est en train de l'apprendre
à ses dépens par exemple
https://groups.google.com/a/arduino.cc/forum/#!topic/developers/9dirF2a XhAE
Le 17 novembre 2014 20:22, FGK a écrit :
[...]
> En ce qui concerne le CLA de Google par contre, a priori je te rejoin drai.
> Mais je ne l'ai lu qu'en diagonale. à première vue, il n'es t pas dit que
> le contributeur conserve ses droits sur son code tandis qu'ils les
> accordent bien à Google.
Si si, au 1er paragraphe.
Mais ce texte vient en préambule, je suis étonné que à §a ait une quelconque
valeur.
C'est aussi marqué (pour Google et Apache) que le CLA protège le
contributeur ; or je ne vois pas en quoi abandonner une partie de ses d roits
permet de se protéger.
> Conséquence, le code appartient à .NET Fondation et plus au contributeur
Je ne suis pas d'accord, mais bon
, en le relisant, la section 8 me semble hautement problématique, je n'ai
donc pas envie de le défendre. En tant que non-juriste, je ne com prends pas
les implications de cette section, et n'aurais aucune envie de signer c e
CLA. Idem pour celui de Canonical, au passage (section 6.1).
Ah zut, je l'ai signé ;-)
D'accord pour dire que tous les CLA ne se valent pas ; ceux d'Apache et de
Google me semblent les moins mauvais, ils sont courts et sont
compréhensibles par des non-initiés.Mais les communautés sont toujours
réticentes à s'engager dans cette voie, Arduino est en train de l'apprendre
à ses dépens par exemple
https://groups.google.com/a/arduino.cc/forum/#!topic/developers/9dirF2a XhAE
[Les communautés] sont peut-être réticentes mais elles se rendent compte petit à petit
qu'elles n'ont pas le choix en réalité.
De la même manière, les contributions sont régies par des règles, à l'origine
non écrites certes mais pourtant strictes, et qui correspondent à la vision de
la communauté autour du projet (ou peut-être plus à la vis ion du mainteneur, Ã
voir). Je n'ai par exemple jamais contribué au kernel Linux mais Lin us a
exprimé à plusieurs reprises qu'à partir d'une certaine da te, impossible de
rejouter et surtout de retirer du code, et pour pouvoir retirer du code a vant
la date d'ailleurs, il faut avoir une sacré bonne raison. Il n'y a p as de CLA
formel à ce propos, mais tous les contributeurs connaissent cette r ègle
"coutumière". On s'imagine que tout va bien, qu'il n'y a pas besoin de signer
quoique ce soit. La plupart du temps c'est vrai. Seulement des problà ¨mes,
parfois graves (restons relatifs tout de même), sont apparus, comme pour la
photocopieuse, et il a fallu "protéger" une certaine vision de la co ntribution
en la mettant par écrit. Le truc c'est que les contributeurs n'ont p as
forcément la même vision que le(s) mainteneur(s). Du coup, ce q ui se passe
pour Arduino est une bonne chose à mon sens. à l'opposé de ce que fait .NET
Fondation, ou ce qu'à fait Canonical à l'origine, ils sont en t rain de régider
un contrat qui conviendrait à tout le monde, en prenant en compte le s
commentaires de la communauté, qui respecte la philosophie du projet Arduino
et qui permettra d'éviter des problèmes futurs. On ne demande j amais rien
d'autre à un contrat : une rencontre de deux volontés servant l es intérêts de
l'une et l'autre partie dans un espace de compromis.
[Les communautés] sont peut-être réticentes mais elles se rendent compte petit à petit
qu'elles n'ont pas le choix en réalité.
De la même manière, les contributions sont régies par des règles, à l'origine
non écrites certes mais pourtant strictes, et qui correspondent à la vision de
la communauté autour du projet (ou peut-être plus à la vis ion du mainteneur, Ã
voir). Je n'ai par exemple jamais contribué au kernel Linux mais Lin us a
exprimé à plusieurs reprises qu'à partir d'une certaine da te, impossible de
rejouter et surtout de retirer du code, et pour pouvoir retirer du code a vant
la date d'ailleurs, il faut avoir une sacré bonne raison. Il n'y a p as de CLA
formel à ce propos, mais tous les contributeurs connaissent cette r ègle
"coutumière". On s'imagine que tout va bien, qu'il n'y a pas besoin de signer
quoique ce soit. La plupart du temps c'est vrai. Seulement des problà ¨mes,
parfois graves (restons relatifs tout de même), sont apparus, comme pour la
photocopieuse, et il a fallu "protéger" une certaine vision de la co ntribution
en la mettant par écrit. Le truc c'est que les contributeurs n'ont p as
forcément la même vision que le(s) mainteneur(s). Du coup, ce q ui se passe
pour Arduino est une bonne chose à mon sens. à l'opposé de ce que fait .NET
Fondation, ou ce qu'à fait Canonical à l'origine, ils sont en t rain de régider
un contrat qui conviendrait à tout le monde, en prenant en compte le s
commentaires de la communauté, qui respecte la philosophie du projet Arduino
et qui permettra d'éviter des problèmes futurs. On ne demande j amais rien
d'autre à un contrat : une rencontre de deux volontés servant l es intérêts de
l'une et l'autre partie dans un espace de compromis.
[Les communautés] sont peut-être réticentes mais elles se rendent compte petit à petit
qu'elles n'ont pas le choix en réalité.
De la même manière, les contributions sont régies par des règles, à l'origine
non écrites certes mais pourtant strictes, et qui correspondent à la vision de
la communauté autour du projet (ou peut-être plus à la vis ion du mainteneur, Ã
voir). Je n'ai par exemple jamais contribué au kernel Linux mais Lin us a
exprimé à plusieurs reprises qu'à partir d'une certaine da te, impossible de
rejouter et surtout de retirer du code, et pour pouvoir retirer du code a vant
la date d'ailleurs, il faut avoir une sacré bonne raison. Il n'y a p as de CLA
formel à ce propos, mais tous les contributeurs connaissent cette r ègle
"coutumière". On s'imagine que tout va bien, qu'il n'y a pas besoin de signer
quoique ce soit. La plupart du temps c'est vrai. Seulement des problà ¨mes,
parfois graves (restons relatifs tout de même), sont apparus, comme pour la
photocopieuse, et il a fallu "protéger" une certaine vision de la co ntribution
en la mettant par écrit. Le truc c'est que les contributeurs n'ont p as
forcément la même vision que le(s) mainteneur(s). Du coup, ce q ui se passe
pour Arduino est une bonne chose à mon sens. à l'opposé de ce que fait .NET
Fondation, ou ce qu'à fait Canonical à l'origine, ils sont en t rain de régider
un contrat qui conviendrait à tout le monde, en prenant en compte le s
commentaires de la communauté, qui respecte la philosophie du projet Arduino
et qui permettra d'éviter des problèmes futurs. On ne demande j amais rien
d'autre à un contrat : une rencontre de deux volontés servant l es intérêts de
l'une et l'autre partie dans un espace de compromis.
Le 18 novembre 2014 01:27, FGK a écrit :
[...][Les communautés] sont peut-être réticentes mais elles se rendent compte
petit à petit qu'elles n'ont pas le choix en réalité.
Heu, non. On se dit juste que si une boite demande à un juriste s' il faut
mettre en place une procédure afin de se protéger, sa ré ponse sera forcément
oui ;-)
[...]De la même manière, les contributions sont régies par d es règles, Ã
l'origine non écrites certes mais pourtant strictes, et qui corre spondent Ã
la vision de la communauté autour du projet (ou peut-être pl us à la vision
du mainteneur, à voir). Je n'ai par exemple jamais contribué au kernel
Linux mais Linus a exprimé à plusieurs reprises qu'à pa rtir d'une certaine
date, impossible de rejouter et surtout de retirer du code, et pour po uvoir
retirer du code avant la date d'ailleurs, il faut avoir une sacré bonne
raison. Il n'y a pas de CLA formel à ce propos, mais tous les con tributeurs
connaissent cette règle "coutumière". On s'imagine que tout va bien, qu'il
n'y a pas besoin de signer quoique ce soit. La plupart du temps c'est
vrai. Seulement des problèmes, parfois graves (restons relatifs t out de
même), sont apparus, comme pour la photocopieuse, et il a fallu " protéger"
une certaine vision de la contribution en la mettant par écrit. L e truc
c'est que les contributeurs n'ont pas forcément la même visi on que le(s)
mainteneur(s). Du coup, ce qui se passe pour Arduino est une bonne cho se Ã
mon sens. à l'opposé de ce que fait .NET Fondation, ou ce qu 'à fait
Canonical à l'origine, ils sont en train de régider un contr at qui
conviendrait à tout le monde, en prenant en compte les commentair es de la
communauté, qui respecte la philosophie du projet Arduino et qui permettra
d'éviter des problèmes futurs. On ne demande jamais rien d'a utre à un
contrat : une rencontre de deux volontés servant les intérà ªts de l'une et
l'autre partie dans un espace de compromis.
Ok, je vois ce que tu veux dire, et retiens tes critiques à l'enco ntre du
CLA de .NET.
Mais tu oublies néanmoins un paramètre important, qui est le ressenti
de la communauté.
Par exemple, dans le choix des init fait par Debian, le fait qu'Upstart
nécessitait un CLA a eu un impact très négatif et il n'e st pas impossible
que le résultat aurait été différent s'il n'avait à ©té là .
Pour un juriste, le CLA est une bonne chose. Pour un développeur,
c'est une plaie. Le chef de projet doit faire la balance entre les
deux. Bradley Kuhn l'écrit bien mieux que moi
http://www.ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html
Pour un juriste, le CLA est une bonne chose. Pour un développeur, c'est une
plaie.
Le 18 novembre 2014 01:27, FGK a écrit :
[...]
[Les communautés] sont peut-être réticentes mais elles se rendent compte
petit à petit qu'elles n'ont pas le choix en réalité.
Heu, non. On se dit juste que si une boite demande à un juriste s' il faut
mettre en place une procédure afin de se protéger, sa ré ponse sera forcément
oui ;-)
[...]
De la même manière, les contributions sont régies par d es règles, Ã
l'origine non écrites certes mais pourtant strictes, et qui corre spondent Ã
la vision de la communauté autour du projet (ou peut-être pl us à la vision
du mainteneur, à voir). Je n'ai par exemple jamais contribué au kernel
Linux mais Linus a exprimé à plusieurs reprises qu'à pa rtir d'une certaine
date, impossible de rejouter et surtout de retirer du code, et pour po uvoir
retirer du code avant la date d'ailleurs, il faut avoir une sacré bonne
raison. Il n'y a pas de CLA formel à ce propos, mais tous les con tributeurs
connaissent cette règle "coutumière". On s'imagine que tout va bien, qu'il
n'y a pas besoin de signer quoique ce soit. La plupart du temps c'est
vrai. Seulement des problèmes, parfois graves (restons relatifs t out de
même), sont apparus, comme pour la photocopieuse, et il a fallu " protéger"
une certaine vision de la contribution en la mettant par écrit. L e truc
c'est que les contributeurs n'ont pas forcément la même visi on que le(s)
mainteneur(s). Du coup, ce qui se passe pour Arduino est une bonne cho se Ã
mon sens. à l'opposé de ce que fait .NET Fondation, ou ce qu 'à fait
Canonical à l'origine, ils sont en train de régider un contr at qui
conviendrait à tout le monde, en prenant en compte les commentair es de la
communauté, qui respecte la philosophie du projet Arduino et qui permettra
d'éviter des problèmes futurs. On ne demande jamais rien d'a utre à un
contrat : une rencontre de deux volontés servant les intérà ªts de l'une et
l'autre partie dans un espace de compromis.
Ok, je vois ce que tu veux dire, et retiens tes critiques à l'enco ntre du
CLA de .NET.
Mais tu oublies néanmoins un paramètre important, qui est le ressenti
de la communauté.
Par exemple, dans le choix des init fait par Debian, le fait qu'Upstart
nécessitait un CLA a eu un impact très négatif et il n'e st pas impossible
que le résultat aurait été différent s'il n'avait à ©té là .
Pour un juriste, le CLA est une bonne chose. Pour un développeur,
c'est une plaie. Le chef de projet doit faire la balance entre les
deux. Bradley Kuhn l'écrit bien mieux que moi
http://www.ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html
Pour un juriste, le CLA est une bonne chose. Pour un développeur, c'est une
plaie.
Le 18 novembre 2014 01:27, FGK a écrit :
[...][Les communautés] sont peut-être réticentes mais elles se rendent compte
petit à petit qu'elles n'ont pas le choix en réalité.
Heu, non. On se dit juste que si une boite demande à un juriste s' il faut
mettre en place une procédure afin de se protéger, sa ré ponse sera forcément
oui ;-)
[...]De la même manière, les contributions sont régies par d es règles, Ã
l'origine non écrites certes mais pourtant strictes, et qui corre spondent Ã
la vision de la communauté autour du projet (ou peut-être pl us à la vision
du mainteneur, à voir). Je n'ai par exemple jamais contribué au kernel
Linux mais Linus a exprimé à plusieurs reprises qu'à pa rtir d'une certaine
date, impossible de rejouter et surtout de retirer du code, et pour po uvoir
retirer du code avant la date d'ailleurs, il faut avoir une sacré bonne
raison. Il n'y a pas de CLA formel à ce propos, mais tous les con tributeurs
connaissent cette règle "coutumière". On s'imagine que tout va bien, qu'il
n'y a pas besoin de signer quoique ce soit. La plupart du temps c'est
vrai. Seulement des problèmes, parfois graves (restons relatifs t out de
même), sont apparus, comme pour la photocopieuse, et il a fallu " protéger"
une certaine vision de la contribution en la mettant par écrit. L e truc
c'est que les contributeurs n'ont pas forcément la même visi on que le(s)
mainteneur(s). Du coup, ce qui se passe pour Arduino est une bonne cho se Ã
mon sens. à l'opposé de ce que fait .NET Fondation, ou ce qu 'à fait
Canonical à l'origine, ils sont en train de régider un contr at qui
conviendrait à tout le monde, en prenant en compte les commentair es de la
communauté, qui respecte la philosophie du projet Arduino et qui permettra
d'éviter des problèmes futurs. On ne demande jamais rien d'a utre à un
contrat : une rencontre de deux volontés servant les intérà ªts de l'une et
l'autre partie dans un espace de compromis.
Ok, je vois ce que tu veux dire, et retiens tes critiques à l'enco ntre du
CLA de .NET.
Mais tu oublies néanmoins un paramètre important, qui est le ressenti
de la communauté.
Par exemple, dans le choix des init fait par Debian, le fait qu'Upstart
nécessitait un CLA a eu un impact très négatif et il n'e st pas impossible
que le résultat aurait été différent s'il n'avait à ©té là .
Pour un juriste, le CLA est une bonne chose. Pour un développeur,
c'est une plaie. Le chef de projet doit faire la balance entre les
deux. Bradley Kuhn l'écrit bien mieux que moi
http://www.ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html
Pour un juriste, le CLA est une bonne chose. Pour un développeur, c'est une
plaie.
Pour finir, je reviens ici sur ta remarque. La question n'était donc pas de
savoir si le projet avait besoin de protection. Le projet s'est rendu com pte
qu'il avait besoin de protection et a cherché une solution pratique et
accessible à tous ses problèmes.
Pour un juriste, le CLA est une bonne chose. Pour un développeur, c 'est une
plaie.
Idéalement le CLA est une protection, un cadre juridique clair entre le
développeur et le projet. Le problème est que le développe ur en question ne se
rend pas forcément compte, soit parce que ça ne l'intéress e pas, soit parce
qu'il ne comprend pas tout, de l'intérêt d'avoir quelque chose par écrit
définissant clairement les relations et les effets à venir de s a contribution.
Et ça coince encore plus quand le contrat est imposé par le pro jet, c'est
certain. Et sans parler de l'impression que ça renvoie dans la relat ion de
confiance qui existe depuis 35 ans.
Pour finir, je reviens ici sur ta remarque. La question n'était donc pas de
savoir si le projet avait besoin de protection. Le projet s'est rendu com pte
qu'il avait besoin de protection et a cherché une solution pratique et
accessible à tous ses problèmes.
Pour un juriste, le CLA est une bonne chose. Pour un développeur, c 'est une
plaie.
Idéalement le CLA est une protection, un cadre juridique clair entre le
développeur et le projet. Le problème est que le développe ur en question ne se
rend pas forcément compte, soit parce que ça ne l'intéress e pas, soit parce
qu'il ne comprend pas tout, de l'intérêt d'avoir quelque chose par écrit
définissant clairement les relations et les effets à venir de s a contribution.
Et ça coince encore plus quand le contrat est imposé par le pro jet, c'est
certain. Et sans parler de l'impression que ça renvoie dans la relat ion de
confiance qui existe depuis 35 ans.
Pour finir, je reviens ici sur ta remarque. La question n'était donc pas de
savoir si le projet avait besoin de protection. Le projet s'est rendu com pte
qu'il avait besoin de protection et a cherché une solution pratique et
accessible à tous ses problèmes.
Pour un juriste, le CLA est une bonne chose. Pour un développeur, c 'est une
plaie.
Idéalement le CLA est une protection, un cadre juridique clair entre le
développeur et le projet. Le problème est que le développe ur en question ne se
rend pas forcément compte, soit parce que ça ne l'intéress e pas, soit parce
qu'il ne comprend pas tout, de l'intérêt d'avoir quelque chose par écrit
définissant clairement les relations et les effets à venir de s a contribution.
Et ça coince encore plus quand le contrat est imposé par le pro jet, c'est
certain. Et sans parler de l'impression que ça renvoie dans la relat ion de
confiance qui existe depuis 35 ans.
Le 18 novembre 2014 23:01, FGK a écrit :
[...]
> Pour finir, je reviens ici sur ta remarque. La question n'était donc pas de
> savoir si le projet avait besoin de protection. Le projet s'est rendu compte
> qu'il avait besoin de protection et a cherché une solution prati que et
> accessible à tous ses problèmes.
Heuuuu, non, des fois c'est juste par mimétisme. Si les autres le
font, c'est qu'il doit y avoir une raison.
Pour un juriste, le CLA est une bonne chose. Pour un développeur , c'est une
plaie.
Idéalement le CLA est une protection, un cadre juridique clair en tre le
développeur et le projet. Le problème est que le dévelo ppeur en question ne
se rend pas forcément compte, soit parce que ça ne l'inté resse pas, soit
parce qu'il ne comprend pas tout, de l'intérêt d'avoir quelq ue chose par
écrit définissant clairement les relations et les effets à venir de sa
contribution. Et ça coince encore plus quand le contrat est impo sé par le
projet, c'est certain. Et sans parler de l'impression que ça renv oie dans
la relation de confiance qui existe depuis 35 ans.
[...]
Que ça soit imposé ou non, la relation est forcément asy métrique :
celui qui propose le CLA est passé par un juriste, alors que le
contributeur n'aura pas ce soutien. Et ça fait une énorme dif férence.
Dans un mail précédent, tu as écrit :
] On ne demande jamais rien d'autre à un contrat : une rencontre d e deux
] volontés servant les intérêts de l'une et l'autre part ie dans un espace de
] compromis.
Dans la mesure où les deux parties n'ont pas accès aux mê mes
informations, ça augure mal d'un compromis et explique la réa ction
épidermique de certains contributeurs.
Le 18 novembre 2014 23:01, FGK a écrit :
[...]
> Pour finir, je reviens ici sur ta remarque. La question n'était donc pas de
> savoir si le projet avait besoin de protection. Le projet s'est rendu compte
> qu'il avait besoin de protection et a cherché une solution prati que et
> accessible à tous ses problèmes.
Heuuuu, non, des fois c'est juste par mimétisme. Si les autres le
font, c'est qu'il doit y avoir une raison.
Pour un juriste, le CLA est une bonne chose. Pour un développeur , c'est une
plaie.
Idéalement le CLA est une protection, un cadre juridique clair en tre le
développeur et le projet. Le problème est que le dévelo ppeur en question ne
se rend pas forcément compte, soit parce que ça ne l'inté resse pas, soit
parce qu'il ne comprend pas tout, de l'intérêt d'avoir quelq ue chose par
écrit définissant clairement les relations et les effets à venir de sa
contribution. Et ça coince encore plus quand le contrat est impo sé par le
projet, c'est certain. Et sans parler de l'impression que ça renv oie dans
la relation de confiance qui existe depuis 35 ans.
[...]
Que ça soit imposé ou non, la relation est forcément asy métrique :
celui qui propose le CLA est passé par un juriste, alors que le
contributeur n'aura pas ce soutien. Et ça fait une énorme dif férence.
Dans un mail précédent, tu as écrit :
] On ne demande jamais rien d'autre à un contrat : une rencontre d e deux
] volontés servant les intérêts de l'une et l'autre part ie dans un espace de
] compromis.
Dans la mesure où les deux parties n'ont pas accès aux mê mes
informations, ça augure mal d'un compromis et explique la réa ction
épidermique de certains contributeurs.
Le 18 novembre 2014 23:01, FGK a écrit :
[...]
> Pour finir, je reviens ici sur ta remarque. La question n'était donc pas de
> savoir si le projet avait besoin de protection. Le projet s'est rendu compte
> qu'il avait besoin de protection et a cherché une solution prati que et
> accessible à tous ses problèmes.
Heuuuu, non, des fois c'est juste par mimétisme. Si les autres le
font, c'est qu'il doit y avoir une raison.
Pour un juriste, le CLA est une bonne chose. Pour un développeur , c'est une
plaie.
Idéalement le CLA est une protection, un cadre juridique clair en tre le
développeur et le projet. Le problème est que le dévelo ppeur en question ne
se rend pas forcément compte, soit parce que ça ne l'inté resse pas, soit
parce qu'il ne comprend pas tout, de l'intérêt d'avoir quelq ue chose par
écrit définissant clairement les relations et les effets à venir de sa
contribution. Et ça coince encore plus quand le contrat est impo sé par le
projet, c'est certain. Et sans parler de l'impression que ça renv oie dans
la relation de confiance qui existe depuis 35 ans.
[...]
Que ça soit imposé ou non, la relation est forcément asy métrique :
celui qui propose le CLA est passé par un juriste, alors que le
contributeur n'aura pas ce soutien. Et ça fait une énorme dif férence.
Dans un mail précédent, tu as écrit :
] On ne demande jamais rien d'autre à un contrat : une rencontre d e deux
] volontés servant les intérêts de l'une et l'autre part ie dans un espace de
] compromis.
Dans la mesure où les deux parties n'ont pas accès aux mê mes
informations, ça augure mal d'un compromis et explique la réa ction
épidermique de certains contributeurs.