POSS Chap 9 Part 10
Un article de Framalang Wiki.
[modifier] Dual Licensing Schemes / La double licence
Some projects try to fund themselves by using a dual licensing scheme, in which proprietary derivative
works may pay the copyright holder for the right to use the code, but the code still remains free for use
by Open Source projects. This tends to work better with code libraries than with standalone applications,
naturally. The exact terms differ from case to case. Often the license for the free side is the GNU GPL,
since it already bars others from incorporating the covered code into their proprietary product without
permission from the copyright holder, but sometimes it is a custom license that has the same effect. An
example of the former is the MySQL license, described at ht-
tp://www.mysql.com/company/legal/licensing/; an example of the latter is Sleepycat Software's licens-
ing strategy, described at http://www.sleepycat.com/download/licensinginfo.shtml.
You might be wondering: how can the copyright holder offer proprietary licensing for a mandatory fee if
the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The an-
swer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is
therefore free to decide not to apply those terms to itself. A good way to think of it is to imagine that the
copyright owner has an infinite number of copies of the software stored in a bucket. Each time it takes
one out of the bucket to send into the world, it can decide what license to put on it: GPL, proprietary, or
something else. Its right to do this is not tied to the GPL or any other Open Source license; it is simply a
power granted by copyright law.
The attractiveness of dual licensing is that, at its best, it provides a way for a free software project to get
a reliable income stream. Unfortunately, it can also interfere with the normal dynamics of Open Source
projects. The problem is that any volunteer who makes a code contribution is now contributing to two
distinct entities: the free version of the code and the proprietary version. While the contributor will be
comfortable contributing to the free version, since that's the norm in Open Source projects, she may feel
funny about contributing to someone else's semi-proprietary revenue stream. The awkwardness is ex-
acerbated by the fact that in dual licensing, the copyright owner really needs to gather formal, signed
copyright assignments from all contributors, in order to protect itself from a disgruntled contributor later
claiming a percentage of royalties from the proprietary stream. The process of collecting these assign-
ment papers means that contributors are starkly confronted with the fact that they are doing work that
makes money for someone else.
Not all volunteers will be bothered by this; after all, their contributions go into the Open Source edition
as well, and that may be where their main interest lies. Nevertheless, dual licensing is an instance of the
copyright holder assigning itself a special right that others in the project do not have, and is thus bound
to raise tensions at some point, at least with some volunteers.
What seems to happen in practice is that companies based on dual licensed software do not have truly
egalitarian development communities. They get small-scale bug fixes and cleanup patches from external
sources, but end up doing most of the hard work with internal resources. For example, Zack Urlocker,
vice president of marketing at MySQL, told me that the company generally ends up hiring the most act-
ive volunteers anyway. Thus, although the product itself is Open Source, licensed under the GPL, its de-
velopment is more or less controlled by the company, albeit with the (extremely unlikely) possibility
that someone truly dissatisfied with the company's handling of the software could fork the project. To
what degree this threat preëmptively shapes the company's policies I don't know, but at any rate,
MySQL does not seem to be having acceptance problems either in the Open Source world or beyond.Certains projets tentent de s'auto-financer en adoptant une double licence, c'est un système dans lequel toute société peut payer le détenteur des droits d'auteur pour obtenir son accord pour utiliser le code dans un programme propriétaire, mais le code reste libre pour les projets Open Source. Cela fonctionne mieux pour des librairies de code que pour des applications autonomes évidemment. Les termes exactes varient d'un cas à l'autre. La licence pour l'aspect libre est la GNU GPL, puisqu'elle empêche déjà n'importe qui d'ajouter le code protégé dans un produit propriétaire sans l'autorisation du détenteur des droits, mais parfois c'est une licence personnalisée ayant les mêmes effets. Ainsi la licence MySQL décrite à l'adresse http://www.mysql.com/company/legal/licensing/ utilise la licence GNU GPL et on peut citer comme exemple de licence personnalisée le système de licence de Sleepycat Software décrit à l'adresse http://www.sleepycat.com/download/licensinginfo.shtml.
Vous vous demandez sûrement comment le détenteur des droits peut proposer une licence propriétaire contre une rémunération si les termes de la GNU GPL stipulent que le code doit être mis à disposition sous des conditions moins restrictive. La réponse est que les termes de la GPL sont imposés par le détenteur des droits à tout le monde sauf aux logiciels propriétaires, l'auteur est libre de décider de ne pas appliquer les mêmes termes pour lui même. Une bonne représentation de cela est de s'imaginer que le détenteur des droits possède un nombre infini de copies du logiciel rangées dans un sceau. A chaque fois qu'il sort une copie du sceau pour la donner au monde il peut décider quelle licence il lui applique : GPL, propriétaire ou une autre encore. Son droit de faire cela n'est pas lié à la GPL ou à aucune autre licence Open Source, c'est simplement un pouvoir qui lui est accordé par les lois du droit d'auteur.
L'attrait de la double licence est que, dans le meilleur des cas, elle donne un moyen à un projet de logiciel libre d'avoir une source de revenue sure. Malheureusement, cela peut aussi interférer avec la dynamique normale d'un projet Open Source. Le problème est que chaque volontaire apportant sa contribution au code participe maintenant aux deux entités : à la fois à la version libre et à la version propriétaire du code. Alors que ça ne lui posera pas de problème de contribuer à la version libre, puisque c'est la norme dans les projets Open Source, il pourrait ne pas désirer contribuer aux revenus constants semi-propriétaires de quelqu'un d'autre. Ce côté étrange est exacerbé par le fait que pour une double licence, le détenteur des droits doit vraiment recevoir une déclaration officielle, signée de l'attribution des droits d'auteur par tous les participants afin de se protéger si plus tard un participant mécontent prétend à un pourcentage des droits des revenus propriétaires. Le processus de collecte des attributions signifie que les participants sont bien prévenus que le travail qu'ils produisent enrichira quelqu'un d'autre.
Tous les volontaires ne se soucieront pas de ça, après tout leur contribution participe également au développement de l'édition Open Source et c'est bien là leur intérêt. Néanmoins, la double licence est un exemple où le propriétaire des droits d'auteur se donne à lui même un droit particulier que les autres personnes dans le projet n'ont pas, ce qui conduira tôt ou tard à des tensions, au moins avec quelques volontaires.
En pratique il semble que les entreprises qui travaillent sur des logiciels à double licence n'ont pas une communauté de développement vraiment égalitaire. Ils profitent des correctifs de bogues mineurs ou des maintenances proposés par des sources externes, mais ils font le gros du travail en interne. Par exemple, Zack Urlocker, vice président du marketing chez MySQL, m'a dit que l'entreprise finit souvent pas employer les volontaires les plus actifs de toute façon. Ainsi, le produit en lui-même est Open Source, sous une licence GPL, son développement est plus ou moins contrôlé par une entreprise, même si la probabilité (extrêmement faible) que quelqu'un de vraiment insatisfait de la gestion du logiciel par l'entreprise fasse une fourche existe. Je ne sais pas à quel point cette menace entre en compte dans la politique de l'entreprise, mais en tout cas, MySQL ne semble pas avoir de problème d'acceptation, que ce soit dans le monde de l'Open Source ou ailleurs.
