On Mon, Nov 17, 2014 at 10:11:44PM +0000, D. Barbier wrote: > Le 17 novembre 2014 20:22, FGK a écrit : > [...]
> > 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 pas dit que > > le contributeur conserve ses droits sur son code tandis qu'ils les > > accordent bien à Google. > > Si si, au 1er paragraphe. Haha, ah merci. J'avais lu tout ça plus qu'en diagonale au final... Dans ce cas, je rangerais les CLAs d'Apache, Google, Canonical et FSF dans le même sac (avec peut-être des variations au sein de ce sac, à voir) ; et mettrais celle de .NET Fondation à part. > Mais ce texte vient en préambule, je suis étonné que ça ait une quelconque > valeur. Dans un contrat tout ce qui est écrit à une valeur. Tu peux mettre des touts petits caractères en bas de la page, dire que c'est un préambule, une adjonction, qu'importe, ça fait partie du contrat, donc c'est opposable. > 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 droits > permet de se protéger. Là tu soulèves un lièvre. Le but des CLAs dans le monde du logiciel libre et open source est clairement de protéger le projet, mais avec quelques variations. Si on reprend à nouveau l'exemple de "Jambunathan K" (décidemment j'aime vraiment cet exemple) qui souhaite retirer tout son travail juste avant la publication, mais après que tout le travail d'intégration a été fait, la CLA ne va pas dans son sens. L'idée de la FSF ici est de dire : ok, vous avez envoyer une contribution au projet dans le but qu'elle soit rendue publique et libre/open source. Maintenant, juridiquement, le code vous appartenant totalement jusqu'à publication vous pouvez en demander le retrait. Sauf que voyez-vous, cher contributeur adoré, ça nous fouterait dans une panade pas possible, non seulement nous mais aussi tous les autres contributeurs. Donc on vous demande de signer ça de sorte que votre code soit libre et utilisable par nous dès que vous le soumettez. On ne vous demande pas d'abandonner vos droits mais simplement de nous permettre de l'utiliser pour le projet. Il n'y a donc pas, techniquement, d'abandon de droits. Seulement de donner des droits à quelqu'un d'autre. La formulation à ce propos de Canonical est tout à fait intéressante je trouve. Si on reprend le point 2.1 (a) il est dit que vous gardez vos droits comme si vous n'aviez jamais signer cet accord. Donc oui, je pense qu'il est très clair effectivement que le but des CLAs n'est pas tant de protéger le contributeur individuel mais bien le projet. Mais il était peut-être nécessaire de rassurer le contributeur d'emblée en lui expliquant qu'il n'a rien à craindre. Après, on peut considérer aussi que le contributeur sachant exactement ce qu'il advient de sa contribution, ça le protège aussi. Ensuite, les CLAs, dans l'absolu, je trouve ça légitime d'une certaine façon. Je m'explique. Normalement le contributeur veut que son code soit intégré au projet sous sa licence. Aucun besoin de CLA (comme ça a été le cas durant de nombreuses années). Mais comme il est arrivé des cas particuliers, il a fallut trouver une manière de combler cette insécurité pour le projet et aussi pour les autres contributeurs. Si une personne soumet une fonction importante, que tout le monde se met à travailler sur cette base et que cette personne, six mois plus tard, juste avant la publication, décide (et peut) retirer son travail au dernier moment, ça va causer du tord à beaucoup de monde. Donc en pratique ça n'est pas forcément que pour protéger le travail et les intérêts du projet mais aussi de tous les autres contributeurs. Pour le dire autrement, rendre le code libre (dans les meilleures CLAs) et réutilisable dès la soumission, avant la publication officielle, c'est faire primer l'intérêt général sur l'intérêt particulier. Évidemment, il faut bien lire le contrat et le comprendre (surtout dans ses effets) et voir si, en tant que contributeur, le compromis demandé par le projet est acceptable ou non. Mais, ça, c'est l'affaire de chacun. > > Conséquence, le code appartient à .NET Fondation et plus au contributeur > > Je ne suis pas d'accord, mais bon Étant donné que la CLA de .NET Fondation ne prévoit à aucun moment que le contributeur garde l'un quelconque de ses droits tandis qu'il les transfère à la Fondation, c'est pourtant la conclusion qui me paraît logique. > , 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 comprends pas > les implications de cette section, et n'aurais aucune envie de signer ce > CLA. Idem pour celui de Canonical, au passage (section 6.1). Oui effectivement ces sections peuvent être problématiques, surtout en pratique. Il est d'usage d'expliciter dans certains contrats le tribunal compétent, histoire d'éviter des problèmes de territorialité, et quand ça n'est pas spécifiquement prévu par la loi (ou qu'elle laisse le choix). Dans les cas qui nous occupent nous avons en plus des contrats à visée internationale. Donc il est précisé quelle loi est applicable en cas de litige, à savoir celle de l'État de Washington dans le cas de .NET Fondation et celle de l'Angleterre pour Canonical (ce dernier prévoyant au passage d'exclure les règles de convention des Nations Unies ; sans arrières pensées, je me demande vraiment pourquoi). Je n'ai que des connaissances vagues en droit international privé, j'évite donc de rentrer clairement dans le sujet. Ceci dit, effectivement, il y a de fortes chances pour qu'un étranger (au sens non citoyen du pays où se trouve l'entité émettrice du contrat) doivent effectivement se plier aux règles de droit du pays en question en cas de litige. A forciori s'il a reconnu dans le contrat qu'il s'y soumettrai. En pratique je ne sais pas si ça tient ; instinctivement je pense que oui, mais il faudrait vérifier. (en relisant je me permet d'ajouter : en fait je suis sûr que la réponse n'est qu'à trois ou quatre clics de souris, mais là j'ai la flemme :P). > Ah zut, je l'ai signé ;-) Héhé :D > 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/9dirF2aXhAE Je n'avais pas encore entendu parler du CLA d'Arduino, merci de le mettre en avant. Elles sont peut-être réticentes mais elles se rendent compte petit à petit qu'elles n'ont pas le choix en réalité. Dans un monde "idéal" (quoique ?) il n'y a pas besoin d'écrire quoique ce soit. La règle et la coutume (au sens juridique du terme) étant comprise et suivie par tout le monde. Si quelqu'un y contrevenait un peu, il suffirait de le reprendre et tout irait bien (ce qui a été le cas pendant longtemps ; si on lit esr, il nous explique que l'"esprit hacker" remonte aux années 1950). Et puis un beau jour, voilà qu'un problème de photocopieuse met en avant une situation grave encore jamais arrivée jusqu'ici. Quand on relit l'histoire, on se rend compte que Stallman n'avait évidemment pas de plan à l'avance. Il a juste été confronté à une situation qui a remis en question tout son univers et, pour éviter qu'elle se reproduise, a mis par écrit les idéaux qui règnaient au sein, notamment, de son labo. C'était selon lui la meilleure chose à faire. Nous vivons dans un monde où le Droit est avant tout écrit, sa réaction n'a donc rien d'étonnant. Avec le temps, chaque communauté de la même façon a mis par écrit sa vision (quelle soit philosophique ou économique) pour la protéger et afin que chacun sache à quoi s'en tenir. 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 vision du mainteneur, à voir). Je n'ai par exemple jamais contribué au kernel Linux mais Linus a exprimé à plusieurs reprises qu'à partir d'une certaine date, impossible de rejouter et surtout de retirer du code, et pour pouvoir 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 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 contribution en la mettant par écrit. Le truc c'est que les contributeurs n'ont pas forcément la même vision que le(s) mainteneur(s). Du coup, ce qui 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 train de régider un contrat qui conviendrait à tout le monde, en prenant en compte les commentaires 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'autre à 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. F- -- -:%*- FGK <f...@opmbx.org> -*%:- http://f6k.github.io -:%*- -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20141118002750.GG2435@shyla