Wikipédia en route vers la licence Creative Commons By-Sa

Drunkprincess - CC byIl y a à peine un mois la Free Software Foundation sortait la version 1.3 de sa licence de documentation libre la GNU Free Documentation License (ou GNU FDL).

Ceci peut apparaître totalement anodin, d’autant qu’il ne s’agit d’une d’une version intermédiaire avant la 2.0, mais c’est en fait un évènement à marquer d’une pierre blanche dans la petite histoire de la « culture libre ».

Cette nouvelle version a en effet été principalement motivée pour répondre au souhait de la Wikimedia Foundation de pouvoir changer la licence du contenu de ses projets, la fameuse encyclopédie libre Wikipédia en tête.

À sa création en 2001 Wikipédia a certainement adopté la meilleure des licences libres existantes, à savoir justement la GNU Free Documentation License. Or cette licence a été principalement créée pour la documentation de logiciels libres et posséde certaines contraintes qui peuvent compliquer la vie des utilisateurs de l’encyclopédie. Ainsi un enseignant qui souhaite distribuer l’imprimé d’un article de Wikipédia à ses élèves doit nécessairement y adjoindre l’intégralité de la licence (à savoir plusieurs pages) quand bien même l’article considéré ne remplit pas une page. Dans la pratique notre enseignant ne le fait généralement pas et se retrouve donc à ne pas respecter les termes de la licence.

De plus sont arrivées dans l’intervalle les licences Creative Commons avec le succès que l’on sait. Plus souples, mieux adaptées aux contenus culturels (textes, multimédias…) et possédant une traduction juridique officielle dans de nombreux pays, elles ont été massivement adoptées par les auteurs de l’ère numérique. Et d’ailleurs la grande majorité des images, sons et vidéos qui apparaissent aujourd’hui dans Wikipédia se trouvent être placés sous licence Creative Commons (et plus précisément les plus libres de la gamme, à savoir la By et By-Sa).

On peut affirmer sans risque de se tromper que si Wikipédia avait vu le jour en 2008, elle aurait choisi la licence Creative Commons By-Sa[1].

Le problème c’est qu’elle n’a jamais pu envisager cela parce que les deux licences étaient incompatibles. C’est justement cette incompatibilité que vient de lever la Free Software Foundation dans la nouvelle version de sa licence GNU FDL modifiée quasiment sur mesure pour que Wikipédia puisse passer sous Creative Commons By-Sa.

Dans la mesure où Free Software Foundation ne souhaite pas voir toutes les ressources sous GNU FDL suivre le même chemin, la clause est restreinte aux wikis créés avant le premier novembre 2008 et s’arrêtera après le 1er août 2009. Autrement dit la Wikimedia Foundation a quelques mois pour se décider mais il serait étonnant qu’elle ne profite pas d’une opportunité qu’elle a elle-même ardemment désirée.

Et pour ajouter plus de poids encore à cette information rien de telle que la traduction de l’annonce de Larry Lessig sur son blog où il témoigne aussi bien de son enthousiasme que de sa reconnaissance envers Richard Stallman[2].

Nouvelle de la plus haute importance émanant de la Free Software Foundation

Enormously important news from the Free Software Foundation

Lawrence Lessig – le 3 novembre 2008
(Traduction Framalang : Olivier)

La Free Software Foundation a publié la nouvelle version 1.3 de sa GNU Free Document License. La section 11 de cette licence permet (principalement) maintenant à certains wikis d’être publiés sous licence Creative Commons Paternité-Partage des Conditions Initiales à l’Identique (By-Sa v3.0) à condition que le changement de licence soit effectué avant le 1er août 2009. Ceci implique donc que la communauté Wikipédia a le choix de modifier sa licence au profit d’une licence Creative Commons (voir la FAQ pour cette amendement).

C’est un changement d’une importance majeure pour la communauté de la culture libre, difficile de le nier. Un défaut élémentaire du mouvement de la culture libre actuel est que la licence qui protège son projet le plus important, Wikipédia, le rend incompatible avec une qmajorité d’autres contenus du mouvement de la culture libre. Une solution pour y remédier serait évidemment de tout mettre sous Free Document License (FDL). Mais cette licence a été créée à l’origine pour les manuels et pour certaines raisons techniques elle était peu (voire parfois pas du tout) adaptée à d’autres types importants de contenu.

Cette modification devrait maintenant permettre l’interopérabilité des projets de culture libre, tout comme la prédominance de la GNU GPL permet l’interopérabilité entre les projets de logiciels libres. Cette modification abat des obstacles inutiles et contre-productifs à la diffusion et au développement de la culture libre.

Richard Stallman y est pour beaucoup dans ce changement. Nombreux étaient en effet ceux qui pensaient qu’il n’autoriserait jamais le changement de licence d’un Wikipédia devenu par sa licence FSF l’exemple emblématique de son mouvement pour les libertés. Car c’est de cela qu’il est question, tout comme le système d’exploitation GNU/Linux qui a été rendu possible par son mouvement, Wikipedia a été rendu possible par la liberté qu’offre la FDL. Qu’un homme moins noble que Richard Stallman trouve toute sorte d’excuses pour faire opposition à ce changement serait compréhensible.

Mais voici les mots de Richard, en 2002 et dans un autre contexte : « Si nous ne voulons pas vivre dans la jungle, nous devons changer notre manière de faire. Nous devons commencer par faire comprendre à tout le monde qu’un bon citoyen est une personne qui coopère quand cela s’avère nécessaire… ».

Vous pouvez ajouter « bon citoyen » à la liste des grandes qualités de ce père de la liberté moderne.

Notes

[1] On notera que Framasoft s’est aussi retrouvé avec ce dilemme quand sont apparues les licences Creative Commons, dilemme que nous avons résolu par le « tour de passe-passe » consistant à adopter au choix les deux licences en question pour notre contenu. Ce qui donne depuis 2004 : « Sauf mention contraire, le site est placé sous double licence Creative Commons By-Sa et GNU Free Documentation License ».

[2] Crédit photo : Drunkprincess (Creative Commons By)




Un logiciel libre peut-il se passer d’un dictateur bienveillant à vie ?

Hoyasmeg - CC byLe développement d’un logiciel libre est paradoxal. En théorie, et c’est même ce qui le fonde, il est ouvert à tout le monde mais en pratique son efficacité tire très souvent profit d’une structure qui voit une personne, presque toujours le créateur initial, se dégager de la multitude pour exercer, ce que l’on qualifie faut de mieux, une « dictature bienveillante ».

La « dictature »[1] c’est le fait de choisir seul la ligne directrice du projet en assumant les décisions (prises en concertation mais généralement sans réel processus démocratique). La « bienveillance », c’est la capacité du « dictateur » à écouter et l’attitude par laquelle il manifeste la considération qu’il éprouve envers les contributeurs.

C’est le sujet de la traduction du jour qui penche très clairement en faveur de cette étrange méritocratie qui va à l’encontre d’une organisation plus collective que l’auteur nomme ici « comité ». Avec, quoiqu’il arrive, une question en suspens : et si le « dictateur à vie » venait à ne plus pouvoir travailler sur son projet, ce dernier saurait-il véritablement lui survivre ?

NB : Il est à noter que si l’on accepte de voir le réseau Framasoft dans son ensemble comme une sorte de « gros logiciel libre en développement » alors nous n’échappons pas au débat. Le rôle de dictateur bienveillant, si dictature il y a, étant alors joué conjointement par Pierre-Yves Gosset et moi-même.

Les dictateurs dans les logiciels libres et open source

Dictators in free and open source software

Tony Mobily – 22 juillet 2008 – Free Software Magazine
(Traduction Framalang : Olivier et Penguin )

Certaines personnes remettent en cause l’idée que la plupart (voire la totalité) des projets de logiciels libres ne peuvent pas se passer d’un dictateur bienveillant, c’est à dire une personne qui a le dernier mot sur toutes les décisions prises. Ils pointent facilement les « erreurs » passées de Linus Torvalds (notez les guillemets) : l’utilisation de BitKeeper pour gérer le noyau, l’interdiction de greffons, etc. En tant que développeur logiciel, je pense qu’un dictateur est absolument nécessaire dans un projet de logiciel libre. Voici pourquoi.

Respect gagné par le DBAV

La première raison est aussi certainement la plus importante : le respect. Le dictateur bienveillant à vie (on le nommera DBAV à partir de maintenant) doit prendre des décisions, et même beaucoup de décisions, et en même temps il doit conserver le respect de ses pairs. Les décisions ne sont pas toujours populaires, et elles ne sont pas non plus toujours justes (particulièrement aux yeux des autres). Cependant, le DBAV doit faire preuve de charisme, aussi bien sur le plan technique que relationnel, pour conserver le respect du reste de l’équipe. Personne ne songerait jamais à initier un fork de Linux, car peu de développeurs abandonneraient Linus au profit de la personne à l’origine de la fourche. C’est vrai pour la plupart des projets et c’est pourquoi les forks sont rares. Il faut reconnaître cependant qu’il arrive que le DBAV réussisse à se mettre toute l’équipe de développement à dos, et que quelqu’un finisse par créer une fork en entraînant la majeure partie des développeurs avec lui. Un nouveau projet avec un nouveau nom se crée en s’appuyant sur le code source existant et l’ancien projet disparaît après quelques temps. C’est une bonne chose : le DBAV est en place tant que le peuple le souhaite. C’est une dictature, mais une dictature étrange puisqu’à tout moment les citoyens peuvent s’en aller créer un nouvel état ou en rejoindre un autre.

Connaissance

Le DBAV connaît le projet de A à Z. Il ou elle est à même de savoir si une décision détruira les fondations du projet, et saura également résoudre un problème en conservant la solidité de la structure. Drigg (un projet populaire que je maintiens) m’en apporte la preuve presque chaque semaine : je me rends compte que ma très bonne connaissance du projet le protège des mauvais patchs (NdT : correctifs) et des mauvaises demandes de fonctionnalités. Un DBAV est crucial et il ou elle doit être la personne qui prend les décisions. Dans un logiciel commercial, un manager moyen (qui ne sait pas coder) arrivera parfois à imposer une fonctionnalité ou une modification qui détruira inévitablement la structure du logiciel. Cela m’est aussi arrivé et je pense que c’est arrivé à presque toutes les personnes travaillant sur des logiciels clients propriétaires.

Rapidité

Tout se passe souvent très vite dans le développement de logiciels libres. Parfois les décisions sur la conception et la technique doivent être prises presque dans l’instant. Même si le DBAV peut demander leur avis aux autres membres, c’est à lui ou à elle que revient la décision finale. Il existe une expression anglaise qui dit « A Camel is a horse designed by committee » (NdT : « Un chameau est un cheval créé par un comité » pour dire que les décisions prises collectivement ne sont jamais optimales), je la trouve légèrement exagérée, tout dépend évidemment du comité en question, mais c’est en général vrai et c’est bien dommage. Des décisions doivent être prises, et parfois quand on suit la liste de discussion d’un projet, on souhaiterait vraiment que quelqu’un mette fin aux argumentations qui parfois s’éternisent et dise « ok, ça suffit, on va faire les choses comme ça ».

Charge de travail

Soumettre des idées pour de nouvelles fonctionnalités est un droit fondamental (par contre les exiger ne l’est pas). Les membres de l’équipe peuvent débattre de ces demandes de fonctionnalités et de leur implémentation. Cependant, le code fait la loi. Si un utilisateur propose quelque chose qui trouve écho chez une développeur, les discussions peuvent tirer en longueur, mais à un moment « quelque chose doit être codé si vous voulez qu’il se passe quelque chose ». En proposant un patch un membre de l’équipe gagnera du respect et de la crédibilité, à condition bien entendu que le correctif ne détruise pas la structure du projet. Cela signifie donc que les membres qui veulent contribuer prendront en charge ce qui leur tient vraiment à cœur et ils devront coder ces éléments de manière à ce que le DBAV ne les rejettent pas. Cela est bénéfique à la fois pour le code et pour la motivation des gens. Le code créé par les autres membres de l’équipe doit être bon. Ce qui nous amène au point suivant…

Envoyer de bons correctifs

Si un développeur sait que son patch sera inspecté par une personne ayant une connaissance poussée du projet, et que cette personne cherchera la petite bête, il mettra plus d’application dans l’élaboration de son correctif. Si ce n’est pas un DBAV mais un comité démocratique qui décide du sort des contributions, alors souvent de mauvais correctifs seront intégrés au code, des correctifs qui seront susceptibles de mettre à mal la structure du projet ou qui auront des effets secondaires obscures et difficiles à corriger. Ceci peut aussi se produire si le DBAV se comporte comme un père de famille confiant et aimant plutôt que comme un vrai DBAV. Oui, il m’est déjà arrivé d’accepter des correctifs trop rapidement, et je me suis retrouvé dans cette situation.

Maintenir la politique à l’écart du projet

Créer un comité c’est ouvrir la porte à la politique. L’équation suivante est souvent vraie : « Politique + Projet technique = Catastrophe ». Si un comité prend toutes les décisions, une partie des membres du comité pourrait finir par s’allier afin de faire passer des décisions pour des raisons autres que techniques (comprendre ici : renvoyer l’ascenseur, demander une faveur, etc.). Le DBAV peut aussi prendre des décisions politiques, mais ce ne seront toujours que les décisions politiques d’une personne, le DBAV lui-même, qui saura qu’une mauvaise décision sur le plan technique sera très préjudiciable au développement du projet.

Pour conclure…

Je ne suis pas spécialement fan des comités. Je pense qu’une méritocratie avec un DBAV fonctionne beaucoup mieux et réalise les choses beaucoup plus rapidement. Durant ma courte expérience de chef de projet de logiciel libre (presque un an), j’ai fait face, à une échelle plus modeste bien sûr, aux mêmes problèmes que rencontrent tous les jours beaucoup de développeurs de logiciels libres. Si vous n’êtes pas d’accord avec mes idées, vous pouvez créer un fork à partir d’un projet et mettre sa gestion dans les mains d’un comité. Mais vous avez de bonne chance d’accoucher d’un chameau plutôt que d’un cheval.

Vous êtes libre de me prouver que j’ai tort.

Notes

[1] Crédit photo : Hoyasmeg (Creative Commons By)




Framasoft créateur d’emploi (pour le moment unique et précaire)

pierre-yves-gosset_framasoft_fete-humanite-2008.jpg

Nous l’avons déjà annoncé (épisode 1, 2 et 3), nous allons incessamment sous peu entamer une ambitieuse campagne de soutien dont l’objectif est de poursuivre l’aventure du logiciel libre au sein du réseau Framasoft (qui ne veut pas mourir). Cet objectif passe selon nous par la présence de permanents qui pourraient pleinement se consacrer à la maintenance, au suivi et à l’organisation de l’énergie qui y circule.

Cette histoire de permanents je puis vous assurer que ce n’est pas du luxe parce qu’un jour qui sait je vous raconterai ma vie et les difficultés de trouver du temps à consacrer à Framasoft coincé entre vie professionnelle et vie privée (et heureusement que mes compagnes n’interviennent pas dans les commentaires pour dire ce qu’elles en pensent sachant que ce pluriel est déjà significatif !). Mais refermons bien vite cette parenthèse…

L’objectif étant fixé, peut-être ignorez-vous que l’association qui épaule le réseau possède déjà un permanent ? Il s’agit de Pierre-Yves Gosset, ci-dessus sur la photo, dont le salariat a débuté au mois d’avril dernier. Hormis le projet Framakey dont il est le principal animateur, son travail n’est pas forcément visible mais il est absolument indispensable car en bon multitâche il s’occupe ainsi de l’administration et de la gestion des sites, de l’animation des équipes (comme celle de l’annuaire), de la communication avec l’extérieur ou encore de la représentation de Framasoft sur le terrain. Si le réseau Framasoft garde la tête hors de l’eau en ce moment, il le doit clairement à cette nouvelle donne.

Comment cette création d’emploi a-t-elle été rendue possible ? C’est là que ça coince un peu parce que son financement provient pour une très large part de la publicité cumulée que nous avons décidé d’afficher en août 2007 sur le site principal du réseau. Une telle décision a été un crève-cœur et nous avons alors fort logiquement essuyé quelques critiques de visiteurs déçus de voir ainsi « leur » Framasoft quelque peu « défiguré » mais elle nous aura justement permis de pouvoir démarrer la chose et par là-même de continuer à exister.

Un mal pour un bien en quelque sorte, mais ce n’est pas satisfaisant. D’abord parce que les revenus engendrés par ces annonces, bien que non négligeables, ne permettent pas d’atteindre le budget nécessaire (en l’état le salariat de Pierre-Yves s’achèvera avant l’été prochain). Mais cela pose également des problèmes déontologiques car nous ne contrôlons pas les liens affichés qui peuvent parfois carrément vanter les mérites de logiciels propriétaires concurrents !

Nous aurons bien le temps d’en reparler. Soyons optimiste et regardons le verre à moitié plein : certes précaires et restreints pour le moment à la simple unité, nous sommes créateurs d’emplois ! Ayant été directement à l’origine de Framasoft qui aura commencé il y a sept ans comme un modeste petit site personnel, c’est, ne nous le cachons pas, une sacrée fierté.

Rendez-vous très bientôt pour faire en sorte de consolider ensemble cette fragile situation en admettant bien sûr que vous le voulez bien et que vous estimez que nous le valons bien 😉