logiciel libre

Free Software v. “Open Source” community?

Two days ago, Bjarni had a “minor epiphany” as he puts it. If I can summarize it briefly, he realized while looking at hadoop that although some software projects are technically, or legally speaking, Free Software; their goals, or the intent of the projects’ community seem far behind the goal of freedom of the users. Hence, he proposes two definitions:

The Free Software Community writes and shares software with an explicit intent to safeguard the rights and freedoms of its users by eliminating antifeatures and natural monopolies.

The Open Source Community writes and shares software with an explicit intent to advance the state of the art of computing through open collaboration and publication.

and goes along with examples:

Free Software: GNU, Firefox, LibreOffice, VLC, PageKite
Open Source: Apache, Android, Hadoop, Varnish, Linux

There is some truth in it, but I am afraid I strongly disagree with this assessment because I think it is false and also because I think it weakens the goal of Free Software. (On the other hand, I have to say that Bjarni’s project is really awesome. By the way, they now offer free accounts for Free Software web projects!)

Not distinctive communities

My first comment when you look closely at Bjarni’s proposed definitions is about the word “safeguard.” I think it is no accident that this word is here. In a way, this word conveys the idea that copyleft and Free Software are strongly linked together. This is true: the most important Free Software license today is the GNU GPLv2, a copyleft license. On the other hand, the GPL is the license of the GNU project, but also of the Linux kernel. And if you look at examples given above you’ll find that GNU is in the Free Software category, while Linux in the Open Source category. So why would the Linux hackers choose a Free Software license (per the definition given that Free Software means safeguarding rights and freedoms) if they are an “Open Source” project?

People in communities have things in common, they share values, practices, culture. If you look at both self-proclaimed Free Software and Open Source projects, they undeniably share something in common: software projects. And nearly all software projects technically under a Free Software license, are under an Open Source license. And that’s not an accident: after all, the Open Source Definition comes from the Debian Free Software Guidelines.

And because we all share the same software; it’s possible for the Debian community, undeniably a Free Software community, to integrate a lot of other projects which are proclaimed “Open Source.”

So, I think trying to identify two different communities: one Free Software, one Open Source; is identifying important parameters: which values are put forth, which license, which contribution model, and how they work with other projects or businesses. But none of these parameters, IMHO, are fundamentally inclusive or exclusive of one of the Free Software community, or of the Open Source community.

There are various smaller communities and varying degrees: it’s a complex community; but that’s one community.

I’ll take one other hypothesis that, I think, supports this assertion. Bjarni writes about removing antifeatures and monopolies for Free Software, while Open Source is about state-of-the-art coding and openness. But, these are two sides of the same coin. The art of coding, or hacking, is strongly against antifeatures, incompatible both in practice and in spirit. So, ultimately, whether the emphasized goal is state of the art or openness, it often leads to the same result: a Free Software license is chosen.

In the case of hadoop: while it’s true that in most cases, the companies that use hadoop are not Free Software companies because they clearly work against the freedom of the users; they are part of the Free Software community nevertheless, because they use and contribute to Free Software (whether we like it or not, they are free to do it). Of course, there are distinctions to be made: I’m not saying Facebook or Google, are part of the Free Software movement! But they are players and actors in the Free Software community (even if not exclusively). On the other hand, that’s the power of Free Software: I am quite sure that hadoop can be used for good or bad. Bjarni writes:

[Hadoop] is a cluster computing system which companies and scientists love, but individuals and consumers couldn’t care less about. It is based on ideas made popular (invented?) by Google, but Google kept their code to themselves, so the Hadoop project was created to advance the state of the art and bring MapReduce to the rest of the industry.

That would be like saying that MapReduce is a kind of technology fundamentally incompatible with freedom. I don’t think that’s true. The problem is when a company uses it to become the central point of control of the worlds’ data. The only difference is that MapReduce can be a more effective way of doing that; but that’s not relevant. What is relevant is that Hadoop is Free Software, so anyone has the freedom to use it and modify it for positive change in the world.¹

Advancing the goal of freedom

The final point is that from a purely technical or legal point of view, Free Software and Open Source designate the same category of software. Trying to make two distinctive categories weakens our position when we talk to corporations or public administrations because it’s divisive, or confusing at best (i.e. some people think that non-copyleft software is not Free Software²).

That doesn’t mean however that terms like Free Software or Open Source should be used interchangeably. I think this is a mistake, because it is true that there are differences. When I say Free Software, I want to emphasis the freedom. Exactly like when I say GNU/Linux instead of “Linux” to name my operating system, I want to emphasis the role of the GNU project: although there was free software before GNU, the GNU project was really what started the Free Software movement. But I’ll also call the Linux kernel Free Software: because I want to thank them for developing it and giving me the ability to be in control of my computer!

Some people won’t agree with that, and they want to emphasis “openness” or whatever, because they are not interested in freedom, or they believe in another way to convince consumers or people to use their software, etc. After all, it is their choice and although I disagree with it, to me it does not mean they should feel excluded from the Free Software community.

What we should do is convince them that saying Freedom is important, it matters for everyone; we shouldn’t exclude them and create barriers to collaboration.

On this issue, you can read Georg Greve’s advice: It’s time for the community to take charge of its brand.


  1. For instance, hadoop could quite well play an important part in our goal for distributed systems in Free Software. []

  2. This diagram can help you get a good grasp at different licensing models and how they relate to what’s Free Software or not, technically/legally speaking. One thing: you’ll notice that the Open Source category there is almost completely the same as Free Software. The differences are very minor: a few licenses are accepted by the FSF while they are refused by the OSI, and vice versa. But that’s just a minor annoying detail of license proliferation and amateurism. []

FOSDEM 2012, table ronde sur les app stores ⚓

Pour la troisième année consécutive, j’irai au FOSDEM, l’évènement de la communauté européenne du logiciel libre le plus attendu, qui se tient à l’Université Libre de Bruxelles (quoi de mieux qu’une université libre au pays de la bière (pas gratuite !))

Cette année cependant, je ne serai pas juste là pour discuter aux stands et assister aux confs ; je participe également à la table-ronde sur les magasins d’applications (les « app stores » etc.) dans la DevRoom juridique, samedi après-midi, avec Giovanni Battista Gallus, Bradley M. Kuhn et Richard Fontana. Voici le résumé, en anglais :

So-called “app stores” are becoming a popular means of distributing software, particularly for mobile devices. However, the rise of app stores has been accompanied by tensions with free software/open source legal norms. Companies controlling official app distribution channels for their platforms typically place restrictive terms on both users and developers in ways that may be difficult or impossible to harmonize with requirements and expectations around FLOSS licensing. Moreover, there is a perception that noncompliance with FLOSS licenses is prevalent in app store distribution. This panel will explore some of the problems arising out of the intersection between app stores and FLOSS, under EU as well as US law, and will discuss possible solutions.

Donc si vous êtes intéressés, venez nous rejoindre à 17h30 salle AW1.125 ;!

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

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 :

La certitude d’une approche technique du copyleft plutôt que juridique

C’est la principale qualité du copyleft à la sauce Mozilla : la portée de celui-ci se limite aux « Modifications » telles que définies par la MPL 2.0, c’est-à-dire tout fichier originellement sous MPL qui a été modifié, et tout nouveau fichier qui contient du code originellement sous MPL. Pour faire simple : tant qu’on ne touche pas à un fichier du code sous MPL, on est en dehors du cadre d’application de son copyleft.

Cette façon de procéder contraste largement avec le fonctionnement des licences GNU dont la portée du copyleft s’apprécie juridiquement, car celui-ci s’applique aux œuvres dérivées (derivative works en copyright). Or pour déterminer s’il s’agit d’une œuvre dérivée ou non, il faut à la fois solliciter des approches juridiques et techniques. Ça ne veut pas dire pour autant que cette solution est plus compliquée, ni moins sûre (il y a consensus) mais il reste des zones à clarifier (on peut voir un essai de catégorisation de plusieurs cas de figure où le copyleft s’applique ou ne s’appliquerait pas).

Compatibilité avec les autres licences libres importantes.

  • Licence Apache 2.0 : les conditions de respect des obligations de la MPL 2.0 relatives aux brevets ont été calquées sur celles de la licence Apache, de telle façon que la satisfaction des conditions de la MPL 2.0 satisfait celles de la licence Apache 2.0. En d’autres termes : incorporez du code Apache 2.0 dans du code MPL 2.0, tenez-vous aux obligations de la MPL 2.0 et vous aurez de facto respecté celles de l’Apache 2.0.

  • Licences GNU GPL, AGPL, LGPL versions 2 ou ultérieures : cette compatibilité est rendue difficile par les différences d’appréciations de la portée du copyleft. Auparavant, Mozilla avait recours pour cela au double-licenciement; les logiciels étaient à la fois publiés sous les termes de la MPL 1.1 et de la GNU GPL par exemple. Cela menait à des bifurcations, puis à des incompatibilités.

    La MPL 2.0 a adopté une meilleure solution, qui déclare explicitement la compatibilité avec les licences GNU². On peut donc incorporer du code MPL 2.0 à du code GPL 3.0 par exemple, et distribuer le tout sous licence GPL 3.0 — tout en donnant la possibilité à celui qui reçoit l’ensemble de continuer à bénéficier de la portion du code MPL 2.0 sous cette licence.

Du côté des projets et des distributeurs de logiciels en aval, cette compatibilité simplifie grandement l’analyse du jeu de licences et leur travail de documentation, etc.

Changement de la clause de défense contre les brevets.

À l’heure où la guerre nucléaire sur les brevets est déclarée, on sait l’importance de ces clauses anti-brevets dans les licences de logiciels libres qui se sont développées depuis la version 1.1 de la MPL (1998). On peut dire en quelque sorte que ces clauses sont à la guerre des brevets, ce que les traités SALT sont aux armes nucléaires : des accords mutuels de non-agression.

Le licencié d’un logiciel sous MPL bénéficie de droits accordés par ses contributeurs. Si celui-ci engage des poursuites contre quiconque pour violation de brevets par le logiciel sous MPL, alors il perd tous les droits (droits d’auteur et droits sur les brevets des contributeurs) dont il avait bénéficié jusqu’alors grâce à la MPL.

Cette clause de défense contre les attaques pour violation de brevets (attaques souvent abusives, sur des brevets parfois invalides ou fantasques) est une avancée majeure par rapport à la version 1.1 de la MPL — laquelle avait une clause à la fois bien trop large puisqu’elle se déclenchait pour toutes poursuites de violation de brevets, y compris les brevets qui n’avaient rien à voir avec le logiciel sous MPL ; et à la fois bien trop restreinte puisqu’elle ne concernait que la poursuite d’ayant-droits du logiciel sous MPL, laissant les autres sans protections.

Dans l’ensemble, il faut saluer le travail de Mozilla qui a conduit la rédaction de cette version de la MPL. Il s’agit sensiblement d’une amélioration, qui a su garder les qualités inhérentes à la MPL tout en corrigeant les problèmes pratiques et en s’adaptant aux problématiques d’aujourd’hui notamment dans cette lutte contre les brevets qui, chaque jour, menacent les développeurs de logiciel.

Lire aussi  La nouvelle version 2 de la Mozilla Public License tend vers l’unité, Framablog, 22 janvier

En anglais : Articles de Luis Villa, qui a mené ce travail de rédaction de la MPL 2.0 ; Un article de Richard Fontana (RedHat) ; Communiqué de la FSF ; et enfin, le texte de la licence.


  1. La question s’est reposée récemment sur la liste de traduction April : comment traduire copyleft ? Difficile de garder l’élégance et la signification du jeu de mot. Certains traduisent par la (voire le) « gauche d’auteur » et d’autres par « copie laissée ». Je suis partisan de laisser le mot tel quel, en anglais (on parle suffisamment de copyright en français de toute façon) mais si l’on recherche absolument un adjectif pour qualifier ces licences, je pense que « héréditaire » est une bonne solution (merci Luis)  en tout cas, c’est certainement mieux que « virale » ou « contagieuse » qui nous viennent directement du vocable Microsoft. []

  2. Cette compatibilité explicite est cependant optionnelle. Un donneur de licence qui a contribué peut inclure une notice excluant celle-ci. En tout cas, il est intéressant de voir ce procédé se développer. On l’avait déjà vu avec les licences françaises CeCILL, ou avec la licence développée par l’Union Européenne (EUPL). []