Évolutions de la gouvernance des projets libres

Le mouvement du logiciel libre a commencé à se structurer au milieu des années quatre-vingt et on pourrait croire qu’après trente-cinq ans d’évolution, il a trouvé un mode de fonctionnement optimal qui n’est plus remis en question de nos jours. Pourtant, il n’en est rien, bien au contraire. L’organisation des projets libres continue à évoluer, remettant en question les modèles établis, à la recherche d’une efficacité toujours accrue. Cela se perçoit notamment au travers de quatre évolutions :

• une gestion allégée des contributions sur le plan juridique avec l’adoption croissante du Developer Certificate of Origin (DCO) en lieu et place des accords de contribution plus formels (ICLA/CCLA) ou du transfert des droits patrimoniaux (copyright assignment) ;

• une popularité croissante des licences permissives au détriment des licences diffusives, notamment celles très exigeantes promues par la Free Software Foundation (GNU GPL, GNU LGPL) ;

• un recul des modèles de gouvernance historiques (méritocratie et dictateur bienveillant à vie) au profit d’un modèle démocratique instaurant une plus grande fluidité temporelle des pouvoirs ;

• l’émergence de nouvelles fondations incarnant ces changements et, par conséquent, une perte d’influence des acteurs historiques tels que la Free Software Foundation (FSF) ou la fondation Apache.

Ceux qui continuent à opposer libre et open source y verront sans doute une victoire du second sur le premier et s’en désoleront (à moins qu’ils ne préfèrent hurler à la fabulation), mais mon implication personnelle et professionnelle dans le logiciel libre et mes vingt-deux années d’expérience dans ce milieu, qui me font alterner les positions d’utilisateur, de contributeur, d’accompagnant, d’observateur et de promoteur du logiciel libre me convainquent que ces évolutions répondent tout autant aux visées des entreprises qu’aux souhaits de la génération montante de libristes, comme je vais tenter de vous le démontrer.

Adoption croissante du Developer Certificate of Origin

La plupart des projets libres comptent très peu, voire pas, de contributeurs et leurs auteurs ne perdent pas leur précieuse énergie à en structurer le fonctionnement et à les sécuriser sur le plan juridique. Beaucoup n’ont même pas cette problématique à l’esprit. Toute contribution est un cadeau que l’auteur s’empresse d’accepter et d’intégrer sans se poser plus de questions. Mais dès que le projet gagne en maturité et en envergure, il devient important de le sécuriser sur le plan juridique pour que les efforts de tous ne soient pas réduits à néant par un procès ou même une simple menace de procès. Se pose alors – un peu tardivement – la question de la titularité des droits patrimoniaux et de la légalité des contributions. Qui détient les droits patrimoniaux sur le code ? Les contributeurs étaient-ils réellement en mesure de contribuer ?

Un premier mode de gestion des contributions est la cession des droits patrimoniaux (copyright assignment) à l’entité portant le projet. Mais une telle exigence braque bien naturellement les contributeurs potentiels. Quels desseins inavouables poursuit une entité instaurant un mode de collaboration aussi déséquilibré et à son avantage ? Pourquoi un contributeur accepterait-il de renoncer à ses droits patrimoniaux sans contre-partie ? Il faut vraiment avoir l’aura de la FSF et incarner l’essence du libre pour rencontrer le succès malgré cette stratégie (et encore, certains restent rétifs à toute cession de droit, même au profit de la FSF). De ce fait, peu d’entités ont tenté cette stratégie en dehors de la FSF, et celles qui l’avaient fait l’ont pour la plupart abandonnée par la suite.

Du coup, suivant la voie tracée par la fondation Apache, la plupart des projets structurés ont préféré à la cession des droits patrimoniaux un accord formel de contribution (Contributor License Agreement – CLA), souvent décliné en accord à destination du contributeur (Individual Contributor License Agreement – ICLA) et en accord à destination de son employeur (Corporate Contributor License Agreement – CCLA). L’ICLA stipule que le contributeur conserve ses droits patrimoniaux sur sa contribution, mais en le signant, le contributeur assure le projet qu’il est l’auteur de la contribution, qu’il accepte que celle-ci soit incorporée au projet et diffusée sous sa licence, et que les ressources tierces sur lesquelles elle s’appuie éventuellement ont été publiées par leurs ayants droit respectifs sous une licence compatible avec celle du projet. Via le CCLA, l’employeur du contributeur acte qu’il a connaissance de la contribution et qu’il l’autorise.

Le couple ICLA/CCLA, épaulé par un Software Grant pour les contributions mineures et ponctuelles, est considéré comme le meilleur compromis entre garanties apportées au projet et effort demandé aux contributeurs. Mais il n’est pas pour autant exempt de défaut. Pour commencer, cette approche n’est pas si équilibrée qu’il y parait de prime abord puisque la plupart des CLA contiennent une clause ouvrant la voie à un éventuel changement de licence, que le contributeur accepte par avance. Si l’objectif affiché de la manœuvre est de faciliter l’adoption d’une version ultérieure de la licence, ou d’une licence plus robuste, mais restant dans l’esprit de la licence initiale, dans le cas où cette dernière révèlerait une faille, la rédaction évasive de la clause ouvre parfois la porte à tous les changements, y compris la fermeture du code. Cela ne peut que braquer des contributeurs. Autre reproche que l’on fait à ces accords formels, le CCLA ne vaut que tant que le contributeur ne change pas d’employeur. L’expérience montre que les contributeurs omettent souvent de signaler un tel changement et que, de leur côté, les projets s’en inquiètent rarement. Pour remédier à ce problème, la durée de validité des CLA est parfois limitée et ceux-ci doivent être renouvelés tous les deux ou trois ans. Mais cette précaution ne fait qu’accroitre l’autre défaut des CLA : leur lourdeur administrative pour toutes les parties. Cette lourdeur rebute des contributeurs qui refusent de « perdre leur temps » en tracasseries administratives ou dont la hiérarchie ne sait pas traiter cette demande et se perd en consultations internes, créant une mauvaise expérience pour tout le monde. Elle met aussi mal à l’aise et ennuie les mainteneurs. J’ai ainsi constaté dans plusieurs projets un relâchement au fil du temps dans la gestion des CLA (notamment au détour du renouvèlement des équipes) et des contributions se retrouvent parfois intégrées sans que le moindre accord n’ait été demandé alors que la gouvernance du projet l’exige.

C’est pour évacuer cette lourdeur dans le cadre du développement du noyau Linux que la fondation Linux a imaginé en 2004 une autre façon, bien plus expéditive, de gérer les contributions sur le plan juridique. Cette approche est connue sous le nom de Developer Certificate of Origin (DCO). Le DCO est un texte par lequel le contributeur certifie peu ou prou les mêmes choses que dans le CLA, mais sous une forme volontairement beaucoup plus concise et qui lui laisse toute la responsabilité de la contribution (notamment vis-à-vis de son employeur, puisque dans le DCO, le contributeur certifie de manière très évasive qu’il a le droit de faire cette contribution). La procédure est encore allégée par le mode de transmission du DCO. Le contributeur n’a aucun document à signer ou à envoyer. Par convention, il indique qu’il contribue au projet selon les termes du DCO en ajoutant le champ « Signed-off-by » à la fin du message de commit, suivi de son nom et de son adresse email. Le gestionnaire de version git le fait même pour lui pour peu qu’il ajoute l’option -s à la commande git commit. L’avantage de cette approche technique est que l’accord est renouvelé à chaque contribution de manière triviale.

Cette légèreté séduit. Le DCO est plébiscité par les projets récents et on voit des projets plus anciens abandonner les CLA au profit du DCO. C’est par exemple le cas de Gitlab et cela est même en passe de devenir la règle chez Red Hat (cf. la section 7.1.2 du Open source participation guidelines).

L’objectif sous-jacent est clair : supprimer autant que faire se peut les freins à la contribution et à la fluidité des développements.

Recul des licences libres diffusives

Au fil des études statistiques publiées ces dix dernières années, j’ai noté un recul progressif des licences diffusives, à commencer par la licence GNU GPL. Au début, je n’ai vu dans ce recul annoncé qu’un biais imputable à la source des données : la plateforme Github. J’avais en effet noté que :

• Les projets historiques et structurants disposant déjà de leur propre infrastructure, ils étaient sous-représentés sur Github par rapport aux projets plus jeunes, friands des plateformes mutualisées gratuites. Beaucoup de ces jeunes projets avaient adopté une licence permissive, mais ils n’étaient pas représentatifs, en ampleur et en criticité, de ce qu’était alors un système libre.

• Ce déséquilibre était accentué par le fait que Github favorisait la contribution par fork et pull request. Or, les forks étaient comptés comme autant de projets distincts dans les bases de connaissance des entreprises d’audit telles que Black Duck Software¹ et Palamida², qui étaient bien souvent à l’origine de ces études. La sur-représentation des licences permissives dans les données s’en trouvait démultipliée³.

Je reste convaincu de la réalité de ce biais. Mais au fil du temps, j’ai réalisé que ces jeunes projets gagnaient en maturité et en audience, supplantaient des outils plus anciens ou étaient en passe de le faire, et que de nouveaux composants venaient compléter la panoplie d’outils que j’utilisais dans mes activités ou que je découvrais lors de mes audits. La majorité de ces projets émergents ont opté pour une licence permissive (MIT, BSD ou Apache), ce qui fait qu’en proportion et en criticité, le recul des licences diffusives est aujourd’hui bien réel.

Bien sûr, le noyau Linux, Emacs, GCC, GNU Make et la plupart des projets publiés sous licence GNU GPL ne vont pas l’abandonner et nous verrons toujours de nouveaux projets adopter cette licence. Mais je connais aujourd’hui beaucoup plus d’utilisateurs d’Atom et de VSCode que d’Emacs⁴. Clang taille de son côté des croupières à GCC, Ninja à GNU Make… Les projets sous licence libre permissive semblent attirer plus facilement les contributeurs et se révèlent plus dynamiques.

Certes, ce changement est, plus que les autres, favorable aux entreprises qui ont tout intérêt à promouvoir les licences permissives. Beaucoup finissent même par les adopter pour leurs propres logiciels, alors que la licence GNU GPL leur semblait autrefois bien mieux protéger leur investissement. Mais croire que ce glissement est le seul fait d’entreprises machiavéliques serait une erreur. En effet, les développeurs qui créent les logiciels publiés par les entreprises sont aussi ceux qui créent des logiciels libres sur leur temps libre. La plupart d’entre eux ont une aversion pour la chose juridique et ils réalisent que, dans un cas comme dans l’autre, les licences permissives leur causent bien moins de tracas que les licences diffusives. Beaucoup finissent donc par privilégier une licence permissive pour leurs propres logiciels. Ils comprennent dans les grandes lignes que « tout est plus simple » avec une telle licence, surtout si elle est très courte (et tant pis si cette concision la rend approximative et sujet à interprétation).

Comme pour la gestion des contributions, l’objectif latent est d’abaisser le niveau de contrainte et de complexité pour se concentrer sur l’essentiel (le code) et gagner en efficacité.

Poussée démocratique dans les gouvernances

La gouvernance fait connaitre à toute personne s’intéressant au projet ses conditions de collaboration et d’engagement. Elle établit donc le contrat social, la constitution du projet, à laquelle tous les participants peuvent se référer pour connaitre le processus de prise de décision ou pour vérifier le bon fonctionnement de la communauté et, si nécessaire, dénoncer une dérive. On peut inclure dans la gouvernance la licence, le mode de gestion des contributions, le code de conduite… Chaque projet structuré élabore sa propre gouvernance, qui se distingue parfois des autres sur des points de détail tel que le vocabulaire (par exemple, là où beaucoup définissent le rôle de committer, d’autres préfèrent pour le même rôle le terme maintainer, plus inclusif). Mais au final, pendant longtemps, la plupart de ces gouvernances ont relevé de l’un ou l’autre des deux modèles dominants : le dictateur bienveillant à vie (Benevolent Dictator for Life – BDFL) et la méritocratie.

Si des projets remarquables et d’envergure ont – ou ont longtemps eu – un dictateur bienveilllant à vie (le noyau Linux, Python, Vim, Blender, OpenBSD, etc.), ce modèle est notoirement clivant dans la mesure où il concentre tous les pouvoirs dans une seule personne, sans établir le moindre contre-pouvoir, ni permettre la destitution du dictateur. C’est la définition même du dictateur me direz-vous, sauf que nous sommes ici dans le cadre d’un projet libre dit collaboratif, on pourrait donc s’attendre à mieux. Du coup, un désaccord profond entre le BDFL et les autres mainteneurs ne peut se solder que par un fork ravageur. Pour l’éviter, le BDLF doit faire preuve de charisme, d’écoute et de discernement. Une somme de qualités rare.

Au regard du BDFL, la méritocratie semble donc bien vertueuse avec sa distribution du pouvoir entre les contributeurs les plus méritants et sa prédilection pour la discussion ouverte, devant conduire à un consensus mou ou, à défaut, à un vote formel. Les décisions sont ainsi mieux comprises et acceptées. La méritocratie rend les forks moins nécessaires et plus rares ; elle semble être un mode de collaboration apaisé.

Pourtant, la méritocratie résiste mal à l’usure des années. En effet, à moins que le contributeur ne se rende coupable d’actes, de propos ou d’attitudes toxiques, qui entachent son aura, son mérite et son rôle ne sont jamais reconsidérés, même quand son activité et sa pertinence déclinent, car tout le monde sait ce que le projet lui doit. Les contributeurs historiques restent donc plus influents que les contributeurs récents, même lorsqu’ils se retrouvent tous au même niveau de décision et lorsque les nouveaux sont plus essentiels pour le présent et le futur du projet que les anciens. Ce faisant, des voix s’élèvent désormais contre le modèle méritocratique, perçu comme un système oligarchique ou de castes, rendant très difficile l’accès effectif des nouveaux contributeurs aux instances de décision. Certains lui reprochent même de reproduire à l’échelle du projet les inégalités sociétales et les biais qui vont de pair.

En réaction, un modèle de gouvernance plus démocratique, que Github nomme modèle de « contribution libérale » dans son Guide Open Source, gagne des adeptes, notamment au sein de la jeune génération de libristes. Il instaure une plus grande fluidité temporelle des pouvoirs via des élections et des mandats à durée limitée, et une implication accrue de la communauté dans les décisions, selon le principe « une personne, une voix ». Les projets OpenStack, Prometheus, BQplot ou Python (projet gouverné selon le modèle du BDFL jusqu’à ce que Guido van Rossum renonce à ce titre en 2018) ont adopté ce modèle démocratique.

Cette évolution me semble elle aussi relever d’une quête d’efficacité. Sans ménagement pour les gloires passées, elle vise à donner le pouvoir à « ceux qui font », plus qu’à « ceux qui ont fait ». Pour le coup, je vois plus dans cette aspiration impudente la fougue de la jeunesse que le calcul d’entreprises qui préfèrent certainement l’oligarchie instaurée par la méritocratie.

Émergence de nouvelles fondations

L’écosystème du logiciel libre se peuple d’un nombre croissant de fondations. Les plus anciennes (FSF, Apache, OSI) embrassent le libre dans sa globalité. Elles l’ont conceptualisé et ont joué un rôle essentiel dans la structuration du mouvement, mais sans réellement s’intéresser à ses acteurs. Une seconde génération de fondations est donc apparue, plus focalisée sur les aspects économiques et juridiques qui préoccupent les entreprises (Linux Foundation, Eclipse, OW2…). En échange d’une cotisation parfois couteuse, ces fondations orientées « business » offrent des services (support juridique, communication) à leurs membres. Les communautés ne trouvant leur compte ni dans les premières, ni dans les secondes, une troisième vague a émergé, faisant apparaitre des acteurs thématiques, centrés sur la technique, mais avec une approche communautaire (i.e. accordant plus d’importance aux projets et à leur synergie qu’au service rendu aux membres). Si ces fondations thématiques sont souvent portées par un acteur industriel majeur du secteur, quelques unes sont le fruit d’une initiative communautaire. Leur simple existence et le succès que rencontrent certaines d’entre elles dénotent une volonté de leur communauté de fédérer et de coordonner les efforts, de mutualiser les ressources dans un domaine particulier, tout en échappant à l’emprise pas toujours heureuse des fondations historiques.

La fondation NumFOCUS, qui vise à promouvoir la recherche ouverte et l’informatique scientifique, incarne bien cette troisième génération. Elle met en avant les projets et, comme d’autres, peut les prendre sous son aile. Mais elle se distingue par le soutien financier direct ou indirect qu’elle peut leur apporter et par sa volonté de rendre les communautés plus engagées, ouvertes et inclusives, qui se traduit par un programme éducatif et par des attentes fortes envers les projets qui souhaitent la rejoindre. Elle exige qu’ils aient une gouvernance ouverte et publique (avec une prédilection pour l’approche démocratique, qu’elle n’impose cependant pas), un code de conduite favorisant la diversité et un caractère réellement communautaire. NumFOCUS fait ainsi clairement passer les communautés avant les projets, même si l’épanouissement des premières sert in fine à assurer le développement et la bonne marche des seconds. Avec une telle approche, il n’est pas étonnant que, malgré son jeune âge, de nombreux projets se rangent sous l’étendard de la fondation NumFOCUS, et pas des moindres (ITK, SciPy, NumPy, Matplotlib, Pandas, Jupyter…).

Là encore, le pragmatisme et la recherche d’efficacité me semblent évidents, et procèdent d’un intérêt partagé des entreprises, du monde de la recherche et des particuliers engagés dans le libre.

En conclusion…

Ces évolutions de l’écosystème révèlent une vitalité du libre plus forte que jamais. Au travers de gouvernances mieux pensées et d’efforts plus structurés, les communautés et les projets trouvent des optimums « locaux » qui assurent leur bonne marche et les rendent plus efficaces et attractifs. À l’instar du code source tant chéri par les libristes, quand un mode de fonctionnement ne fournit pas un résultat pleinement satisfaisant, on le remet en cause et on tente une nouvelle approche, remédiant aux problèmes identifiés.

Quand on baigne comme moi depuis longtemps dans le libre, on a parfois l’impression de tout savoir ou presque de lui et de son fonctionnement. Vanité ! L’animal est polymorphe et en mutation constante, il faut l’avoir à l’œil si on ne veut pas se laisser surprendre.