On Tue, Nov 18, 2014 at 10:27:39AM +0100, D. Barbier wrote: > 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 ;-)
Héhé, ok je vois tout à fait ce que tu veux dire. Et même, en écrivant mon message précédent, j'ai pensé que cette remarque viendrait sur la table. "Si on demande aux juristes, ils vont certainement pas refuser du boulot" ;D Effectivement la réponse sera certainement oui, mais pas forcément pour cette raison. "Lawyers are humans too" ;P Bon, blague à part, je reviens sur cette remarque juste en-dessous. > [...] >> 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. > > Ok, je vois ce que tu veux dire, et retiens tes critiques à l'encontre du > CLA de .NET. Pas seulement à l'égard de .NET Fondation, mais à toute structure qui "impose" un contrat à l'autre partie sans que celle-ci ait les moyens de négocier. Ça va pour les projets des communautés Libre et Open Source notamment qui exprime en non-dit à leur _propre_ communauté : "si vous voulez le faire/continuer alors signer ça, c'est un contrat type, non négociable". Si on leur répond que le contrat ne convient pas et qu'on voudrait négocier, il leur est répondu : "on ne va pas vous faire votre version à vous ; vous êtes pas obligé de contribuer, on ne vous force pas" puis retour à la première réponse. La seule manière de contrer ça étant un battage médiatique d'un grand nombre à base de "je m'en vais claquer la porte" (cf. Canonical). On retrouve la même chose ailleurs. Vous n'êtes pas obligé d'aller chez Google, vous n'êtes pas obligé d'aller sur FB, etc. Et mieux encore, vous n'êtes pas obligé de souscrire une assurance chez nous ; vous n'êtes pas obligé de venir dans notre banque, etc. Non c'est sûr, mais la loi m'impose d'avoir une assurance pour ma voiture et survivre sans compte bancaire de nos jours est loin d'être simple. A-t-on vraiment le choix ? Bon cela ouvre un autre débat, mais la critique est là effectivement, dans le fait de se faire imposer un CLA du jour au lendemain sans que l'on puisse avoir son mot à dire. C'est pour cela que je trouve l'approche d'Arduino saine. Ce qu'il s'est passé pour Canonical est un peu moins sain à mon sens, puisqu'il a fallu des claquements de porte, des billets incendiaires, des menaces en tout genre pour faire respecter finalement un tant soit peu la volonté de la communauté... > Mais tu oublies néanmoins un paramètre important, qui est le ressenti > de la communauté. Je ne peux que te rejoindre là-dessus. Où est la relation de confiance dorénavant ? Surtout dans le cas d'un CLA imposé ? En plus quand on ne connait pas tous les effets de ce CLA ? > 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'est pas impossible > que le résultat aurait été différent s'il n'avait été là. Parfaitement. > 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 Merci pour le lien ! Je ne connaissais pas, je le sauvegarde, c'est très intéressant. À propos de ce texte, plusieurs remarques. Tout d'abord, il exprime le fait qu'on ne peut pas être sûr que les clauses des CLAs soient effectivement valides en soi, notamment en terme d'assurance pour le contributeur. C'est effectivement vrai, et cela a déjà été soulevé dans ce fil. La seule manière de les mettre à l'épreuve, c'est d'avoir un litige qui soit résolu devant un juge. N'empêche que ça n'est pas pour ça qu'on ne peut pas essayer de faire quelque chose qui tienne la route. Ensuite, il ne traite _que_ des brevets en élaguant les problématiques du développeur/contibuteur pourtant introduite dans les premiers paragraphes qui retirerait son travail six mois plus tard et deux jours avant la publication de la nouvelle version du projet (voir mon exemple récurrent). À propos des brevets, il propose de remplacer la fonction du CLA en tant que mécanisme juridique pour se prémunir de cette problématique par un autre mécanisme juridique ayant la même fonction (notamment il parle du Developer Certificate of Origin (DCO)). Il critique le CLA en insistant sur le fait que la responsabilité en cas de violation de brevet soit bien rejeté sur le contributeur (je ne vais pas critiquer la légitimité ou non de ce processus, ça n'est pas la question ici). Mais la solution qu'il propose (les solutions mêmes) ont la même fonction. S'assurer que le développeur confirme que le travail soumis n'est pas breveté ; et si c'était le cas, dû à l'acceptation du DCO par exemple, le développeur en tient la responsabilité. Par voie de conséquence, si un brevet était violé dans un projet, pas besoin que le projet se retourne contre l'un de ses contributeurs afin de faire jouer la responsabilité --- qui serait du plus mauvais effet, il va sans dire --- puisque celle-ci étant déjà établie sur le contributeur. Je n'ai pas encore eu le temps de me pencher sérieusement sur tout cela, je n'ai donc pas d'avis sur la question si ce n'est que : remplacer un mécanisme juridique par un autre mais meilleur ? Pourquoi pas, car comme l'indique la Règle n° 16 d'Acquisition Ferengi : « Un accord est un accord... qu'un plus profitable remplace ». Au-delà de ça, pourquoi cherche-t-il un /autre/ moyen de résoudre ce problème ? Cette proposition sert surtout à éviter d'une part le comportement "Don't Read & Click" tout en évitant aussi à mon sens, et là je te rejoins dans ton exemple à propos de debian, le côté anxiogène de la CLA. N'empêche que la protection, notamment au regard des brevets, existent toujours. Continuons sur le thème "se passer des CLAs". Quid dès lors de la problématique du développeur qui retirerait son travail à un moment critique ? C'est une question importante pour les projets ; nous en avons eu déjà plusieurs exemples. Il était proposé (je crois par la FSF, mais c'est le fouilli dans mes bookmarks, je n'arrive plus à mettre la main dessus) d'inclure en préambule de chaque commit quelques lignes disant en substance "j'autorise [NOM DE LA FONDATION] à utiliser ce travail pour [NOM DU PROJET] en accord avec les termes de la [NOM DU CLA]." Le but étant de rendre le commit disponible et totalement utilisable par le mainteneur sans possibilité de recours du développeur. En lisant cela j'ai eu une idée. Je n'ai pas fait de recherche mais je suis certain que d'autres ont déjà eu cette idée. Pourquoi ne pas mettre une ou quelques lignes disant : "Je, [NOM], met à disposition ce commit sous Licence GPLv3" (dans le cas de la FSF). Dès lors le commit serait clairement libre dès la soumission et donc serait, librement, utilisable par le projet sans retirer les droits de l'auteur (puisque sous GPLv3). On pourrait imaginer que le contributeur ajoute une ligne comme celle-ci à chaque fois et en adéquation avec la licence du projet auquel il contribue. Aussi, et face à cette problématique, on remplace le mécanisme juridique de la CLA par un autre mécanisme juridique ayant les mêmes effets. Il y a d'autres questions soulevées dans les relations contributeurs/projets, notamment en terme de protection du code soumis (ainsi que l'explique trop brièvement Eben Moglen[1]) et pour chacune on pourrait imaginer un mécanisme spécifique. Pourquoi alors un très grand nombre de gros projets, sur toute la gamme du Libre et de l'Open Source, de l'entreprise aux communautés de volontaires, choisissent de passer par un CLA plutôt que par plusieurs petites procédures distinctes ? Je ne suis dans les petits papiers de personne, donc je n'ai pas de réponse formelle. Par contre, rien n'empêche de faire des hypothèses. La mienne est : "parce que c'est plus simple". La relation dont il est question ici pose un certain nombre de question, on va donc résoudre toutes ces questions au même endroit, dans un contrat négocié entre le contributeur et le mainteneur (idéalement), que l'on va nommer CLA. 1. http://www.gnu.org/licenses/why-assign.html 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. > 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. Évidemment qu'un juriste sera favorable à ce type de cadre ; surtout parce que ça permet de régler à l'avance de possibles problèmes à venir (et qui sont arrivé à d'autres). Et il est toujours plus sain de discuter de ce genre de chose quand tout va bien, la tête froide, plutôt que quand tout va mal et que tout le monde est bien énervé. Laisse moi prendre un exemple. Il est parfaitement possible de vivre avec son amoureux·se, avoir des enfants, un chien et un jardin, le tout en concubinage -- c'est-à-dire sans contrat formellement écrit. J'ai des exemples dans mon entourage, qui vivent dans cette situation depuis des années, et ça se passe très bien. Pourquoi tant de gens alors établissent un contrat de mariage civil ? (« parce que ça permet de réduire les impôts ? », entend-je au fond de la salle ? Quel est ce troll ? je prend les noms attention !) Au-delà de la tradition, je dirais : parce que ça répond à la question "et si ?", au fameux "au cas où". Surtout en ce qui concerne l'avenir des enfants. Voir un couple sur un nuage, des coeurs dans les yeux aborder les questions relatives à la gestion de leur patrimoine et au devenir des enfants qui ne sont encore qu'un projet est quelque chose de particulier. Oui, les jolies coeurs sont là sur un parterre de rose. Et pourtant, derrière des sourires parfois un peu crispé, il y a le côté "ok, en cas de problème, on sait ce qu'il va arriver". D'un autre côté, il y a le revers de la médaille. J'ai un prof qui a coutume de faire une blague quand il parle du contrat de mariage : « À quoi sert le mariage ? À compliquer les ruptures ». F- -- -:%*- FGK <[email protected]> -*%:- 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 [email protected] En cas de soucis, contactez EN ANGLAIS [email protected] Archive: https://lists.debian.org/20141118230137.GA6348@shyla
