On Wed, Nov 19, 2014 at 12:44:16AM +0000, D. Barbier wrote: > 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 pratique 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.
Est-ce que je peux rajouter le mot "bonne" entre une et raison dans ta phrase ? Je n'ai pas vécu cette période, l'arrivée des licences libre puis open source chez les développeursmais est une bonne analogie selon moi. Puisque c'est bien documenté, on peut l'utiliser comme exemple. Suite à l'affaire de la photocopieuse de Stallman, son action a été vue au début comme du "préchi-précha" philosophico-juridique par une bonne partie des communautés impliquées. Le fait de mettre par écrit les règles qui règnaient n'apparaissaient pas comme quelque chose de "naturel". Certains ont peut-être dû s'y mettre par mimétisme, comme tu le fais remarqué. Mai son message a fini par être entendu et compris quant à la nécessité de protéger par un écrit le code diffusé, quitte à ce que ça soit un peu tourné en dérision en demandant simplement de se faire payer une bière. N'empêche que le texte est là et est claire sur les intentions du développeur quant à son code. Aujourd'hui, bon nombre de développeurs de toute sorte mettent une licence quand ils diffusent du code qui se veut être libre ou open source --- même quand il s'agit d'un simple petit script bash. C'est devenu un comportement normal. Cela ne veut pas dire qu'il n'y a plus cette relation de confiance entre le développeur et les utilisateurs. Les critiques à propos du développeur qui chercherait à se prémunir uniquement des mauvaises intentions de ses utilisateurs ne sont presque plus mises en avant. Mais les développeurs savent que justement pour se pémunir de mauvaises conduites (ou de conduites contraires à leur vision), mettre un licence est un début de garantie. Oh, le bout de papier n'empêche certainement pas un individu de mettre dans des sources fermés le code réputé libre, mais au moins ça permet d'avoir quelque chose d'opposable et de faire pression sur celui qui ne respecterait pas la licence. Il y a eu de nombreux exemples dans l'actualité. C'est peut-être donc bien par mimétisme. Mais le fait est que quelque chose d'extérieur à la communauté est venu changer la donne (je pense aux brevets notamment) et qu'il a fallu s'en protéger, sans parler des nouvelles conduites au sein de communautés elles-mêmes. C'est là où je dis que les projets se sont rendus compte qu'ils avaient besoin de protection, non seulement pour se protéger eux-mêmes de l'extérieur des mauvaises intentions, mais aussi pour protéger leurs contributeurs de l'extérieur (dans le cas des CLAs repectant les principes du libre et de l'open source bien sûr). >>> 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éveloppeur 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 quelque chose par >> écrit définissant clairement les relations et les effets à venir de sa >> contribution. Et ça coince encore plus quand le contrat est imposé par le >> projet, c'est certain. Et sans parler de l'impression que ça renvoie dans >> la relation de confiance qui existe depuis 35 ans. > [...] > > Que ça soit imposé ou non, la relation est forcément asymé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 différence. Effectivement ça fait une grande différence. > Dans un mail précédent, tu as écrit : > ] 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. > 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éaction > épidermique de certains contributeurs. Et c'est parfaitement compréhensible. Je pense que les inquiétudes des mainteneurs des grands projets étaient/sont légitimes. Le problème c'est que, dans la résolution de ce problème, ils se sont fortement éloignés de l'esprit du libre et de l'open source qui est censé régner. Bien sûr que ce sont eux qui font les choix in fine. Mais même Linus, réputé pour ne pas passer par quatre chemins et qui n'hésite pas à dire merde, prend le temps d'expliquer certains de ses choix cruciaux et attend de voir ce que les kernel hackers ont à dire. Avec ce qui s'est passé/se passe autour des CLAs, il faudrait écrire une suite à « La Cathédrale et le Bazar » : « La revanche de La Cathédrale ». Le grand guru vient apporter la bonne parole, énonçant un fait accompli, sans grandes discussions préalables, en s'attendant à ce que tout le monde suive benoîtement. On se croirait à un meeting d'Apple. « Ne vous inquiétez pas, ceci est une révolution, c'est bon pour vous, signez ici ». Qu'est-ce qui aurait pu être fait ? Commencer par dire à la communauté les problèmes rencontrés, qui sont de vrais problèmes, et chercher à trouver des solutions avec la communauté ; faire des propositions, expliquer, voir ce que les développeurs avaient à dire sur ce sujet, voir ce que les associations avaient à dire sur le sujet, etc. Et surtout que cela soit fait en prenant le temps. Mais il a fallu que ça soit fait unilatéralement le plus généralement, carrément dans l'urgence pour certains, face à la peur des brevets ou parce que les partenaires économiques exigeaient une solution immédiate. Tu as raison évidemment quand tu dis qu'il manque des informations pour l'une des parties. Maintenant les CLAs sont là, c'est un fait. Ils répondent à un vrai besoin et la tendance n'a pas l'air de vouloir se renverser. Aussi, les projets proposant (imposant ?) une CLA devrait en rédiger une version human-readable à l'instar de ce que fait Creative Commons. Si besoin des juristes, autres que ceux faisant partie du projet évidemment mais prochent des communautés, seraient les bienvenus pour expliquer le contenu de ces contrats --- notamment ceux faisant partie des associations comme APRIL ou LQDN par exemple. À une époque où les projets n'auraient eu besoin que de "sensibiliser" leur contributeur, à cause de la manière choisie pour mettre en avant cet outil qu'est le contrat, on se retrouve maintenant à devoir appliquer des pansements qui fonctionnent que modéremment, le mal étant déjà fait. 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/20141119034943.GB6348@shyla
