MutterWare #2: aller (encore) plus loin dans son utilisation du mail

[Note : Je vais cesser d’écrire en français sur ce blog. Désormais, ce que j’écris en français est publié sur mon blog personnel, y compris lorsque cela est lié à la FSFE.]

Mardi soir, Nicolas organisait le 2e MutterWare. Mais qu’est-ce que c’est que ça ?

Le MutterWare est une réunion d’utilisateurs de Mutt qui veulent partager leurs bonnes pratiques et quelques astuces bien utiles. Les non-utilisateurs de mutt curieux sont bienvenus, surtout s’ils sont légèrement blasés de leur client email ☺

Le nom est inspiré directement du TupperVIM organisé chez Mozilla, à Paris.

Pour cette deuxième édition, nous avons cette fois été invités à admirer les bureaux somptueux de Mozilla boulevard Montmartre. Voir la photo prise par Yoann :

Encore une fois, ce MutterWare était un bon mélange entre utilisateurs (très) expérimentés, et non-utilisateurs de Mutt curieux de voir comment fonctionne le machin et prêts à ouvrir leur terminal pour commencer à configurer la bête !

Quelques informations ont été ajoutées au wiki : https://wiki.fsfe.org/groups/Paris/Mutterware.

Pour ma part, j’insisterai sur cette très bonne page qui permet de démarrer sur Mutt. C’est en anglais mais c’est bien écrit. Cette page a cependant deux défauts à mon avis : elle se concentre sur l’usage à partir d’un serveur mail chez Google (or Gmail a des tas de particularités pas très orthodoxes) et elle se limite à un seul compte. Or je ne sais pas pour vous mais moi, j’ai deux comptes : l’un est plus, « personnel ».

Enfin, la cerise sur le gâteau, c’est Emmanuel qui l’a apportée en me montrant l’outil t-prot, qui permet de nous débarrasser de toutes ces petites choses qui peuvent être désagréables dans le mail : les gens qui font des citations trop longues, les gens qui font du top-posting ou encore les gens ont des signatures de 3 kilomètres. T-prot a aussi des fonctions particulières pour Mutt, comme par exemple l’argument --pgp-move qui déplace les informations relatives aux signatures openPGP d’un email vers le bas, et non vers le haut comme c’est le cas par défaut, ce qui permet d’avoir accès plus directement au contenu du mail, sans avoir à scroller ! Plus d’infos sur la config T-prote d’Emmanuel sur le wiki.

Du coup, j’ai touché pas mal à ma config (dispo sur https://github.com/hugoroy/.mutt). Tout est désormais plus sobre depuis que j’ai modifié les barres de statuts, retiré la barre d’aide, et remplacé quelques codes couleurs. Lire ses mails sur Mutt est encore plus plaisant qu’avant ☺

À bientôt pour la 3e édition ! N’hésitez pas à vous inscrire sur la liste fsfe Paris https://lists.fsfe.org/mailman/listinfo/paris ou à nous rejoindre sur irc #fellows-paris.

A (small) lesson about patent FUD.

Steve Jobs, the MPEG LA and HTML5’s <video>.

On March 7, Google announced they reached an Agreement with MPEG-LA around patents that “may” cover the open video codec VP8.

Thanks to this agreement, the most serious concerns that people had about using VP8 and webM for their videos on the web are gone. (Well, almost, because Nokia(/Microsoft) claims to have patents infringed by VP8 still).

Monty from Xiph.Org, developer of free software and open video codecs like Theora is very happy about this announcement. Indeed, it shows that MPEG-LA has lost. They did not have anything serious to bring VP8 down.

Oh. Oh my. After a decade of the MPEG LA saying they were coming to destroy the FOSS codec movement, with none other than the late Steve Jobs himself chiming in, today the Licensing Authority announced what we already knew.

They got nothing.

But what should remain from this? I think there are some lessons to learn here for Free Software. Sure, MPEG-LA has lost. But who won? Not us, and surely not the Web.

The question is: how’s that possible that a group of patent holders who had nothing serious to stop adoption of webM and other open codecs like Theora managed to impose on us their patent-restricted codec?

Let’s go back a little. The whole saga starts from the HTML5 group. (Bear in mind that this effort started outside of the W3C, comprising mainly of browser-vendors including Apple and Microsoft.) I don’t have enough knowledge of the inside politics of this group. But what remains out of it is that one of the most discussed features of HTML5, the <video> element, is a failure.

Why HTML5 <video> has been a failure

Why’s that a failure? Because today, it seems that most of the time HTML5 videos are encoded solely using the restricted-by-patents AVC/H.264 format. That means that publication on the Web is now restricted by rules determined by a cartel of patent holders (The MPEG-LA has been under investigation by the US Department of Justice for anti-trust concerns since 2011.)

This is certainly not how the web was envisioned. The web was envisioned with freedom at its core. Just like Tim Berners-Lee didn’t have to ask anybody’s permission to make the Web work 22 years ago¹, nobody should have to ask anyone’s permission to publish something on the web.

Why HTML5 <video> is still a failure

Now the second attack against HTML5 <video> has come. We saw it coming, about a year ago. But nothing was done. It is only now that I see a reaction (BTW if you haven’t done yet, please sign now to stop Digital Restrictions Management (DRM) on the Web: defectivebydesign.org/no-drm-in-html5).

Make no mistake. These are concordant, and very important attacks. They will deeply change the Web if they succeed. Microsoft, Apple, Netflix and others want to control how one can make videos (through patents) and who can watch videos (through DRM).

The first part (patents) seems lost. We have to fight for the second part.

What we need: to weigh in the political process of shaping HTML5 and to fight FUD

Here I want to focus a little bit on how they achieved to control videos through patents and how this is related to what we’re witnessing with the proposal to include DRM in HTML.

These are some of the steps:

  1. Make a technical proposal to the HTML5 group.

    Oppose inclusion in the standard of Free Software and claim the reason is concerns around patents.

    In case opposition come from Free Software folks, claim there is no problem because your proposal can be included in hardware

  2. Spread FUD everywhere that Free Software implementations and technological alternatives are violating patents.²

    (Of course, hope that nobody sees how hypocrite you are, because the patent risks come from your own patents and from organisations like MPEG-LA, which you are a part of)

  3. Make vague threats of lawsuits and show your muscles.

    (I now regret having participated in this by publishing Steve Jobs’ answer to my open letter. I should have handled this more carefully and contacted other organsations like Xiph.Org… This could have been a nice opportunity to debunk FUD more efficiently.)

  4. Buy yourself time, continue spreading FUD

I think it’s time to realise that building web technologies is a process with political implications. They’re trying to change the web from a place where you’re free to express yourself without having to ask anybody’s permission or having to agree to a restricted-patent-license, into something where you cannot express freely without using proprietary technology and where DRM prevents you from doing legitimate things (like saving a private copy of online content, or watching a video using only Free Software, the only way to ensure your privacy).

Of course, people who are aware enough of these issues will still be able to publish using Free Software with webM and Theora, and the next open codecs. Surely, there will be ways to crack DRM.

But what about everyone else? Do we want to accept the Web as a fragmented place? No, we want to keep the Web as it is, universal.

IMHO, the only reason why things aren’t so bad is thanks to Mozilla. By building Firefox, maintaining an independent browser engine when everybody’s going WebKit, and getting involved in the whole HTML5 spec process, they’ve managed to hold back these attacks. But they haven’t succeeded entirely. How long before Mozilla suffers from these attacks and cannot be as competitive as other web browsers?

We all need each other here. And I think it’s time to bring some political weight to the HTML5 process to counterbalance this.


  1. Actually, TBL did have to ask someone’s permission: his employer, CERN. But it’s totally unrelated 😉

  2. Apple seems particularly good at this


Edit Source Link

Quelques notes sur la seconde licence publique Mozilla (MPL 2.0)

(A short post in French on the Mozilla Public License 2.0. If you want to know about it, you can read in English Luis Villa, who led the update process. Richard Fontana wrote an article (RedHat); and the FSF has lauded the compatibility with GNU licenses.)

Cette année, une petite nouvelle est arrivée dans le monde des licences de logiciel libre : la seconde version de la licence publique Mozilla (MPL 2.0). Elle n’est pas totalement nouvelle, car elle garde l’esprit général de la première version puisqu’il s’agit d’une licence de faible copyleft. C’est-à-dire que cette licence permet dans une certaine mesure — assez large — de combiner du code régi par la MPL avec du code sous une autre licence (y compris propriétaire). Pour autant, des modifications apportées aux fichiers du code MPL doivent être régies par les mêmes obligations : mise à disposition du code source, notifications des droits des utilisateurs (droits d’utiliser, de partager, d’étudier le fonctionnement et de publier des modifications — la définition d’un logiciel libre).

Ainsi, la MPL est un bon compromis, entre d’un côté les licences “académiques” (BSD, MIT) et de l’autre, les licences copyleft¹ fortes comme la licence publique générale GNU. Mais comme tout compromis, la MPL souffre des inconvénients incombant à chacun des deux modèles de licence.

Il y a cependant des qualités indéniables à la MPL 2.0, que j’ai voulues résumer ici […]

Lire Les qualités de la MPL 2.0.