f6k ~ Les fonctions cachées de .NET Fondation

Rédigé le 14 novembre 2014 • Première publication le 22 novembre 2014, republié le 01 décembre 2014.

Remarque : cet article a été initialement publié le 22 novembre 2014 sur le Blog-Libre (http://blog-libre.org). Ayant malheureusement fermé le 01 décembre 2014 (voir aussi l’annonce de Christophe sur Diaspora*), je republie l’article ici. Seuls les commentaires ont été perdus ; ils comportaient pourtant des questions intéressantes dont certaines peuvent être retrouvées ici. Ce blog collaboratif avait été initié par Cyrille Borne et l’équipe était composée, entre autres, de Christophe Gallaire, de Cep, de Damien ou encore de Cascador. Ils m’avaient fait la joie d’accueillir en invité cet article sur leur blog. N’ayant jamais eu l’occasion de le faire publiquement avant, je tiens à les remercier ici de leur confiance. Je voudrais aussi les remercier pour le travail effectué durant ces nombreuses années en espérant qu’ils retrouvent tous un projet aussi porteur, chaleureux et amical. Comme le dit Frédéric Béziès, cette lecture quotidienne va manquer…

Cette semaine, une nouvelle peu commune a fait quelques bruits dans la communauté libre et open source. Il s’agit de l’annonce faite par Immo Landwerth quant à la libération de .NET Core. Cette annonce était attendue depuis le début de l’année alors que Microsoft lançait publiquement ladite fondation afin de chapeauter tous les projets open source made in Redmond, Washington, USA. Beaucoup d’enthousiasme donc dans le billet de M. Landwerth mais aussi dans la communauté.

Nous allons d’abord revenir un peu sur la licence du projet de .NET Fondation avant de nous pencher sur la force reconnue de la communauté libre et open source que sont les contributions, particulièrement en détaillant la relation entre un contributeur et un mainteneur de projet. Nous verrons alors par quel mécanisme juridique .NET Fondation transforme cette relation pour s’approprier le travail des développeurs et cela dès les premiers temps de leur participation aux projets.

Aux frontières de l’open source

Ainsi que le rappelle gashe dans un journal sur linuxfr le code est disponible sur la plate-forme github où une lecture attentive nous apprend qu’il est diffusé sous licence MIT. Nom de licence trompeuse comme chacun le sait puisque le MIT utilise bien d’autres licences. Il s’agit en fait de la licence Expat, très permissive — faut-il le rappeler — puisque n’empêchant pas de rendre à nouveau le code propriétaire, ni n’empêchant la mise en place de brevets. Nous sommes ici aux frontières de l’open source. En regardant un peu plus loin on remarque la présence d’un autre fichier intitulé PATENT.TXT. Sa lecture en est très intéressante. Ça n’est pas en soi un document juridique opposable, mais simplement une promesse. De quoi ? Que Microsoft ne poursuivra personne pour violation de brevets si on utilise d’une quelconque manière son code. En échange, il est implicitement demandé à celui qui utilise le code de ne pas poursuivre Microsoft pour violation de brevets. Pourquoi faire une « promesse » pareille qui semble sortir avec un sourire entendu mais carnassier ? Il faut lire entre les lignes. Parce que Microsoft a ouvert le code sur un licence open source (aussi laxiste soit-elle) il ne peut pas formellement en interdire toute utilisation qui ne lui conviendrait pas — entendre qui lui ferait du tord ou de la concurrence. Mais, cependant, il montre les dents et prévient.

D’un autre côté, rien n’empêche .NET Fondation et ses partenaires de tirer parti des contributions publiées et intégrées au projet afin de déposer de nouveaux brevets et de diffuser du logiciel fermé loin des idées des développeurs du libre et open source — qu’elles soient d’ailleurs philosophiques et/ou pratiques. Mais ceci est une chose connue et tout à fait acceptée par les développeurs qui choississent de contribuer à ce type de projet. Les développeurs ont donc conscience des enjeux et contribuent en connaissance de cause, il n’y a donc rien à dire à ce sujet. En réalité avec .NET Fondation la vérité est ailleurs, j’y arrive tout de suite.

Un projet open source donc ? Certes, mais du bout des doigts, les services juridiques étant prêts en cas de besoin si quelque chose n’allait pas dans le sens voulu. Pourquoi dès lors, en étant aussi frileux, se lancer dans une aventure comme celle-ci ? Parce que le monde de l’open source évidemment dispose d’une grande ressource : sa communauté et, surtout, les contributions de la communauté. Ce ne sont pas les premiers à aller dans ce sens pour ces raisons, ni ne seront les derniers. Mais là encore Microsoft refuse de se laisser prendre au jeu et il s’en donne les moyens.

Une relation de confiance

Qui dit projet libre ou open source dit contributions de la communauté. C’est une chose très importante dans ce type de projet, cela en est même la pierre angulaire. Je pense pouvoir dire que, d’un point de vue juridique, la contribution à un projet libre ou open source, bien que contractuelle, se construit avant tout sur une relation de confiance entre le mainteneur du projet et le contributeur. Pour schématiser, admettons un développeur soumettant du code au responsable d’un projet lambda open source. Le but avoué du développeur en question est que son code soit accepté et intégré au projet. C’est-à-dire qu’il sait que le code qu’il soumet sera diffusé sous cette licence ouverte ; le développeur sait que, à terme, il va perdre une partie de ses droits sur son code. Mais il le fait en toute connaissance de cause puisqu’il souhaite justement que son code devienne libre ou open source en intégrant le projet. Ceci étant dit, chose très importante, juridiquement tout le temps que le mainteneur n’a pas accepté l’intégration du code au projet, le développeur garde la paternité et la propriété pleine et entière de son code. Autrement dit, si le mainteneur refuse l’intégration du code au projet lambda, il n’a cependant pas le droit de le réutiliser comme bon lui semble pour un autre projet sans l’autorisation du développeur. Ainsi, si celui qui rédige du code apprenait que sa contribution, refusée pour le projet auquel il l’a soumis, a été réutilisée par le mainteneur dans un autre projet, par exemple, à source fermée, il y a de grandes chances que le développeur ne soit pas très content. Et il serait dans son bon droit de poursuivre le mainteneur pour violation de son droit d’auteur. Je n’ai pas d’exemple sous la main d’un conflit juridique de cette nature exacte, mais il est clair que les développeurs de logiciel libre ou open source n’aiment pas voir leur code changer impunément de licence sans leur accord, ou pire encore propriétarisé. On pourra se rappeler par exemple de la fameuse affaire Freebox où Harald Welte (iptables) bien vite rejoint par Rob Landley et Erik Andersen (BusyBox) avec le soutien bienveillant de la Free Software Foundation ont menacé la société Iliad/Free alors que celle-ci utilisait leur code sans respecter la licence.

Cette relation de confiance entre le contributeur et le mainteneur, forgée au cours du temps, tacite et normale — attendue même pourrait-on dire — dans le monde du libre ou de l’open source, n’existe pas quand on se penche sur .NET Fondation. En effet, la situation est toute différente, la Fondation y opèrant un changement profond. D’une part, la relation est purement contractuelle et cela de façon très claire. Par ailleurs, mieux encore, la réalité juridique du code est même contraire à ce que décrit ci-dessus.

Le contrat entre le contributeur et .NET Fondation

Dans son billet d’annonce M. Landwerth explique que, évidemment, les pull requests — mécanisme de contribution de github — seront acceptés pourvu qu’ils respectent certains critères notamment concernant la feuille de route du projet ainsi que la qualité du code. Plus loin d’ajouter que, avant l’incorporation du code au projet, il sera nécessaire pour le développeur de signer un Contrat de Licence du Contributeur — Contributor License Agreement (CLA). Bien que toujours en chantier, M. Landwerth indique que cette formalité ressemblera probablement à ce qui existe déjà pour le projet Azure. Comment fonctionne la procédure pour Azure ? Très simplement. Le développeur se rend sur la page d’Azure concernant le CLA où il lui est demandé de se connecter sur son compte github. Ceci étant fait, l’application Azure Contribution License Agreement demande la permission d’accéder au compte, notamment à l’email. Viens ensuite la signature numérique du CLA.

Une fois n’étant pas coutume, lisons attentivement le Contributor License Agreement de .NET Fondation. On y trouve bien sûr les définitions concernant certains termes importants du contrat ainsi que les juridictions compétentes en cas de conflit. Outre cela, deux choses sont à bien noter. Tout d’abord, le développeur reconnaît qu’il a signé le contrat avant toute soumission de code (point 2. du CLA), c’est important pour la suite. De plus celui-ci affirme que le code qu’il va soumettre est une production originale (point 3. du CLA) et non issue d’un autre projet ou d’une tierce personne. Si le développeur venait à vouloir soumettre un code non original, cela se ferait alors de manière séparée au projet, c’est-à-dire selon une autre procédure et en dehors des termes de notre CLA. Pourquoi le contractant doit reconnaître ces deux points ? Car c’est la condition nécessaire à ce qui va suivre. En effet, le développeur accorde finalement à .NET Fondation ainsi qu’à ses partenaires tous les droits concernant son code et cela dès la soumission de celui-ci (point 4. du CLA). Ainsi, et pour le dire autrement, le développeur reconnaît qu’à partir du moment où il soumet son travail au projet, celui-ci devient la propriété pleine et entière de la fondation .NET et de ses partenaires, que le code soit accepté pour intégration ou non.

De manière plus pratique, on comprend tout de suite ce qu’il peut se passer. Premier cas de figure, le contributeur soumet son code qui devient la propriété de .NET Fondation. Cette dernière décide souverainement de l’intégrer au projet. Le code est alors diffusé sous la licence MIT ainsi qu’escompté par le contributeur. Second cas de figure, le contributeur soumet son code qui devient la propriété de .NET Fondation. Cette dernière décide souverainement de ne pas l’intégrer au projet. Mais rien n’indique au contributeur que le code ne sera pas effectivement réutilisé ailleurs. Au contraire, puisque le code ne lui appartient plus. .NET Fondation peut tout à fait décider de le modifier pour l’intégrer à un autre projet sous une autre licence, voir, pourquoi pas, de réutiliser le code, la fonction, l’idée même, pour un autre projet à source fermée. Mieux encore, elle peut parfaitement en déposer un brevet à son nom ou celui de ses partenaires au regard du point 4.2. du CLA. Le code, simplement soumis et non intégré, lui appartenant, on peut imaginer toutes les cas de figure ; juridiquement la fondation .NET sera dans son bon droit. Il est évident que nous avons donc ici une situation parfaitement contraire à ce qu’exige la coutume dans les communautés du libre et de l’open source.

[Insérez ici un titre de conclusion]

Que peut-on penser de tout cela ? Tout ceci est encore bien jeune, la question reste donc en suspens et chacun, en connaissance de cause, peut se forger sa propre opinion.

D’un point de vue personnel, je suis tout à fait sceptique quant aux buts poursuivis par .NET Fondation, loin d’être sûr que cette institution souhaite effectivement aller dans le sens de l’open source et du libre, mais, au vue de ce qui a été dégagé ici, chercherait peut-être plutôt à tirer profit de sa communauté en se préservant au maximum des échanges que cela implique par des mécanismes juridiques tout à fait intéressants.

Ceci étant dit, et comme exprimé par ailleurs, je ne jette pas la pierre sur qui que ce soit, ni sur le projet. De quel droit, qui serais-je pour faire cela ? Il est seulement important de remarquer et de faire remarquer que nous avons ici avec .NET Fondation un comportement tout à fait anormal en comparaison de ce qui se fait habituellement dans la communauté libre et open source. Tant du point de vue de la libération du code ; mais aussi du point de vue de ce qui est demandé, en non-dits, quant à l’utilisation du code ; et surtout au vue la relation entre le contributeur et cette structure. Il est important que le développeur sache ce qu’il advient d’un point de vue juridique à son code dès qu’il se met en tête de vouloir participer au développement des projets de .NET Fondation. Les développeurs, contributeurs et autres utilisateurs peuvent tout à fait souscrire à tous les contrats qu’ils veulent, mais pourvu que ce soit fait en connaissance de cause.