Re: [HS] Microsoft s'ouvre t-elle à l'opensource ?

[FGK <f6k@opmbx.org>]

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 <f6k@opmbx.org> -*%:- http://f6k.github.io -:%*-