Le blog de Lizzie Crowdagger

Dans le billet précédent, j’ai essayé d’expliquer comment partager et modifier une œuvre sous licence libre Creative Commons. Ici, je voudrais aborder un autre point : comment contribuer à une œuvre libre existante pour proposes ses modifications à l’auteur ou l’autrice, avec l’exemple en particulier de Github.

Par exemple, les fichiers sources, au format Markdown, d’un certain nombre de mes textes sont disponibles sur Github, ce qui facilite la possibilité d’y apporter une contribution ou de proposer une version dérivée. Sauf que, si vous n’êtes pas développeu·r·se informatique, il y a des chances que vous ne trouviez pas cela très simple d’accès et que votre réaction soit quelque chose comme « oh la, c’est quoi encore ce truc de geek ?! ». Pourtant, il est possible d’utiliser Github pour apporter une contribution sans avoir à taper de commandes ésotériques.

Je prends ici l’exemple de mes textes, mais il est évident que ce sera peu ou prou la même chose si vous désirez apporter des modifications à d’autres textes libres hébergés sur Github, y compris s’il s’agit de la description ou de la documentation de votre logiciel libre préféré.

À des fins didactiques (et parce que ça m’amusait), ce billet contient un certain nombre de screenshots (moches). Ils ne sont pas forcément très lisibles tels qu’affichés dans le corps du texte, mais vous pouvez cliquer dessus pour les agrandir.

Étape préalable : vous créer un compte sur Github

Avant toute chose, si vous voulez contribuer à un projet hébergé sur Github, il vous faudra vous créer un compte. Bon, ce n’est pas très compliqué : ça demande juste de choisir un identifiant, de rentrer une adresse mail et de mettre un mot de passe. La procédure habituelle, certes rébarbative mais pas outrageusement ardue.

Github est axé pour les développeurs et développeuses informatique, et cela peut être intimidant si vous n’y connaissez rien. Cela dit, rassurez-vous : vous pouvez vous contenter d’ignorer les messages du type « Built for developpers », car il est aussi possible d’utiliser un certain nombre de fonctionnalités sans avoir à écrire la moindre ligne de code ni taper la moindre commande.

Signaler un souci, émettre une suggestion, etc.

La première possibilité est de faire remonter un souci (coquilles, mauvaise mise en page, répétitions à un endroit), etc. Pour cela, il est facile d’ajouter une issue sur Github :

Il suffit ensuite de décrire le problème, en donnant un titre et un commentaire. Bien sûr, plus c’est détaillé, mieux c’est :

Sujet : Fautes

Ouais y’a des fautes

n’est pas très utile, alors que

Sujet : Fautes dans Pas tout à fait des hommes

J’ai repéré quelques fautes dans Pas tout à fait des hommes :

- chapitre 3: “Il l’a mordu” -> “Il l’a mordue”

- chapitre 7: “Elle a attrapé son son épée” -> “son” en double

l’est beaucoup plus.

Bien sûr, il est possible de laisser des commentaires pour autre chose que des fautes, que ce soit pour faire remarquer qu’un passage n’est pas très compréhensible, signaler un problème de lecture sur telle liseuse, ou encore demander de nouvelles « fonctionnalités » (dans le cas d’un texte de fiction, le terme peut paraître étrange, mais on peut envisager des choses comme « je trouverais ça cool que les fichiers soient disponibles au format MOBI »).

Évidemment, pour tout ça, il n’est pas nécessaire en soi de passer par Github : dans mon cas, vous pouvez aussi m’envoyer un mail, par exemple (lizzie at crowdagger point fr). L’intérêt est surtout :

• pour les projets (plutôt logiciels) qui ont beaucoup de rapports de bug à traiter ;
• pour les projets un peu plus collaboratifs : ça permet aux contributeurs et contributrices de voir ce qu’il y a à faire, et de proposer des changements ;
• à titre personnel, ça me sert plutôt de « TODO list », pour noter les choses qu’il faudrait que je fasse un jour.

Proposer des changements directement sur Github

Github propose également une interface en ligne pour modifier des fichiers. C’est d’autant plus facile avec des fichiers Markdown, car c’est ce qu’utilise Github pour sa documentation.

Le plus compliqué est sans doute de repérer à quel fichier Markdown correspond à le passage vous êtes en train de lire, et cela peut demander de fouiller un peu dans les répertoires. Notamment sur des dépôts comme le mien où tout n’est pas forcément toujours très bien rangé (et encore, vous n’avez pas vu mon appart’).

Par exemple, admettons que je veuille modifier Réagir sans violence pour changer la mise en page des dialogues. Le plus compliqué est sans doute de deviner qu’il s’agit du fichier hell_butches/sigkill.md (reagir_sans_violence.md serait sans doute plus logique, certes, mais voilà).

Une fois que je suis sur la bonne page, Github propose un bouton pour éditer le document :

Une fois que j’ai cliqué dessus, il est possible d’éditer le texte, au format Markdown.

Une note sur le format Markdown

Le format Markdown est juste du texte, avec quelques éléments en plus pour dire qu’il s’agit d’un titre, d’un lien, ou pour mettre en italique. Concrètement, pour des romans, il y a essentiellement deux éléments pour la mise en page, les titres et les italiques :

• ce *mot* est en italiques, ce *groupe de mots* aussi affichera « ce mot est en italiques, ce groupe de mots aussi ».
• pour les titres, on « souligne » le titre de chapitre en mettant des ==== à la ligne suivante :

Titre de chapitre
=============

(Si vous voulez en savoir un peu plus, vous pouvez regarder le tutoriel Markdown in 60 seconds.)

Github utilise beaucoup Markdown, et il est donc possible de prévisualiser les modifications pour voir si le résultat correspond bien à vos attentes.

Cette fonctionnalité montre également les changements que vous avez apportés au fichier :

Soumettre les modifications

Une fois satisfaite des modifications, je peux les soumettre à l’autrice^[1] en remplissant le mini-formulaire en bas de la page :

Il ne me reste plus alors qu’à vérifier vite fait les modifications apportées, et je peux créer une pull request (en gros une proposition de modification toute automatisée, qui peut être acceptée d’un clic) qui sera envoyée à l’autrice.

Encore une dernière étape pour valider le texte du commentaire, et voilà, la contribution est envoyée, et l’autrice n’a plus qu’à la valider !^[2]

À quel moment devient-on co-auteur (co-autrice) ?

On a jusque là uniquement parlé de l’aspect technique de la contribution. Il me semble pourtant que les aspects juridiques sont importants, et méritent d’être abordés. Et notamment la question : à partir de quel moment avez-vous un statut de « co-auteur » sur le texte final (à supposer, évidemment, que la contribution soit acceptée) ?

Je ne suis pas juriste, mais si je comprends bien les choses, le critère est qu’il y ait un aspect « créatif » à la contribution. Par exemple, corriger des fautes d’orthographe ne rentre pas dans cette catégorie, pas plus que mon exemple précédent sur la mise en page des dialogue. En revanche, à partir du moment où il y a, par exemple, rédaction d’un paragraphe supplémentaire, il y a dans ce cas une contribution « créative », et vous devenez, dans ce cas, co-autrice ou co-auteur du texte final.

Même si ce n’est pas toujours formalisé explicitement, il est en général admis qu’à partir du moment ou vous envoyez une contribution à un projet libre, vous acceptez que votre contribution soit également distribuée sous les conditions de la (ou des) licences du projet (en l’occurrence pour mes textes libres, Creative Commons Attribution - Partage dans les Mêmes Conditions 4.0 International).

À partir de ce moment là, vous êtes donc sur un pied d’égalité avec l’autrice de l’œuvre original : vous pouvez, comme elle, distribuer l’œuvre de votre côté (y compris, selon les licences, de manière payante). S’il s’agit (comme c’est le cas ici) d’une licence dite copyleft, vous n’êtes pas libre, en revanche, de distribuer l’œuvre de manière privatrice, mais l’autrice de l’œuvre originale ne peut pas le faire non plus (à moins évidemment de retirer votre contribution et de revenir à une œuvre dont elle est l’unique autrice).

Par exemple, à l’heure actuelle, je peux aller voir un éditeur, lui montrer Pas tout à fait des hommes, lui proposer de faire ensemble quelques modifications à l’œuvre et de diffuser cette version avec un contrat d’exclusivité^[3]. Si vous contribuez à ce livre en réécrivant des passages, en ajoutant des scènes, etc., je n’aurais plus le droit de le faire (du moins sans votre accord).

Ça peut paraître un peu du pinaillage juridique, mais je pense que c’est important, car c’est ce qui met un garde-fou important (même s’il reste relatif) à l’exploitation du travail gratuit des contributeurs et contributrices.

Parfois, certains projets demandent, avant d’envoyer une contribution, de signer par ailleurs une cession de droits envers l’auteur original (ou une entreprise ou une association), ce qui lui permet ainsi une plus grande flexibilité pour pouvoir changer de licence pour le projet. Je ne suis pas très fan de ce genre de procédé^[4], qui casse l’égalité entre les contribut·eur·rice·s, et fait, je trouve un peu rentrer la contribution dans le domaine du travail gratuit plus que de la collaboration.

Quand contribuer, et quand créer une œuvre dérivée ?

Cette question n’est pas forcément spécifique aux textes, mais peut aussi s’appliquer aux programmes : à quel moment faut-il plutôt essayer de contribuer à l’œuvre originale, et à quel moment vaut-il mieux créer une œuvre dérivée (ou un fork dans le monde du logiciel) ?

Évidemment, ça dépend un peu de chaque personne, mais j’aurais tendance à dire :

• Pour des modifications mineures, dont on sait clairement qu’il y a des chances qu’elles soient acceptées (correction de fautes d’orthographe, bugfixes), il paraît plus constructif de contribuer à l’œuvre originale ; à vrai dire, si quelqu’un publiait une version modifiée d’un de mes textes libres en disant « celle-là est mieux, j’ai corrigé plein de fautes » et en me laissant galérer à essayer de trouver ce qu’il a corrigé, je l’aurais un peu mauvaise (sauf bien sûr s’il m’a envoyé les modifications mais qu’il s’agit d’un vieux texte sur lequel je n’ai plus envie d’accorder la moindre énergie).
• Pour des modifications d’importance, dont on n’est pas certain que l’autrice va vouloir les intégrer (réécriture d’une partie de l’histoire, ajouts de paragraphes, ajout ou modification de fonctionnalités pour un logiciel), on peut toujours les soumettre, mais tout en ayant en tête qu’elles seront peut-être rejetées parce qu’il est possible qu’elle soient incompatibles avec une certaine vision du projet.
• Parfois, un effet, il y a en effet des visions divergentes d’une même œuvre ou d’un même logiciel. C’est l’intérêt du libre de pouvoir permettre qu’elles coexistent, plutôt que de donner tout le pouvoir à la personne qui détient les droits originaux. Dans ce cas, il est logique de créer une œuvre dérivée plutôt que d’essayer à tout prix de concilier deux visions inconciliables (pour reprendre mon exemple du début : histoire lesbienne ou histoire gay, ou encore : logiciel qui fait plein de chose ou logiciel qui se spécialise sur quelque chose de précis et ne cherche pas à gérer le reste).

Conclusion

J’espère aussi vous avoir un peu convaincu·e que contribuer à un projet libre n’est pas aussi compliqué que cela peut le sembler. J’ai personnellement mis longtemps avant d’oser envoyer des pull requests sur Github, mais avec l’interface Web, cela peut se faire de manière plutôt simple lorsqu’il s’agit de corriger des fautes, des liens cassés ou de reformuler une phrase pas très compréhensible, et cela ne requiert en fait aucune compétence en informatique.

---

---

Si vous aimez ce que j’écris, vous pouvez me soutenir en vous abonnant (à partir d’1€ par mois) sur Tipeee, et vous recevrez en contrepartie accès à des textes inédits. Abonnez-vous sur :

Pour être tenu·e au courant de mes dernières parutions, vous pouvez vous inscrire à ma liste de diffusion (faible trafic, pas plus d’un message par mois) :