Manche Projekte versuchen sich durch ein duales Lizenzmodell zu finanzieren, bei dem proprietäre Derivate dem Inhaber des Urheberrechts bezahlen können um den Code in ihre Projekte verwenden zu dürfen, der Code für andere Open-Source-Projekte aber unter einer frei bleibt. Das funktioniert natürlich meistens besser für Code-Bibliotheken als für einzelnen Anwendungen. Die genauen Bedingungen unterscheiden sich von Fall zu Fall. Oftmals ist die freie Lizenz die GNU GPL, da es bereits andere daran hindert, den davon abgedeckten Code in ihre Proprietären Anwendungen, ohne Erlaubnis des Urhebers zu benutzen, manchmal ist es jedoch eine eigens geschriebene Lizenz mit dem gleichen Effekt. Ein Beispiel für ersteres ist die hier beschriebene MySQL-Lizenz http://www.mysql.com/company/legal/licensing/; ein Beispiel für Letzteres ist die hier beschriebene Lizenzierung der Sleepycat Software http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html.

Sie mögen sich vielleicht fragen: Wie kann ein Urheber eine proprietäre Lizenz für eine Gebühr anbieten, wenn die Bedingungen der GNU GPL vorgibt, dass der Code unter keiner restriktiveren Lizenz verbreitet werden darf? Die Antwort darauf, ist dass die Bedingungen der GPL vom Urheber auf alle anderen auferlegt; es steht dem Urheber deshalb offen, sich selber diese Bedingungen nicht aufzuerlegen. Man kann sich das so vorstellen, dass der Urheber unendlich viele Kopien der Software in einem Eimer hat, es kann sich entscheiden welche Lizenz dafür gilt: GPL, proprietär, oder etwas anderes. Das Recht das zu machen ist nicht an die GPL oder irgend einer anderen Open-Source-Lizenz gebunden; es ist einfach ein durch das Urheberrecht gegebene Möglichkeit.

Duale Lizenzierung ist attraktiv, da es freie Software eine Möglichkeit bietet, eine verlässliche Einkommensquelle zu sichern. Leider, kann es auch die üblichen Abläufen von Open-Source-Projekte behindern. Das Problem, ist das jede Freiwillige die einen Beitrag macht, jetzt an zwei verschiedene Einheiten einen Beitrag macht: Der freien Version vom Code und der proprietären Version. Auch wenn die Freiwillige gerne zur freien Version etwas beiträgt, da es bei Open-Source-Projekten üblich ist, mag es ihr nicht ganz genehm sein, zum teils-proprietären Einkommen von jemand anderem etwas beizutragen. Dieses Unannehmlichkeit wird noch verschlimmert, da die duale Lizenzierung von dem Urheber erfordert, formale, unterschriebene Übertragungen der Urheberrechts einzusammeln, um sich vor einem aufgebrachten Freiwilligen zu schützen, der im Nachhinein einen Teil der Gebühren einfordert. Durch diesen Vorgang, werden freiwillige offenkundig, mit der Tatsache konfrontiert, dass sie Arbeit machen, die jemand anderem Geld einbringt.

Das wird nicht allen Freiwilligen stören; schließlich werden ihre Beiträge auch an die Open-Source-Version gehen, und dass mag ihr Hauptinteresse sein. Duale Lizenzierung ist trotzdem ein Fall bei dem der Urheber sich selber ein Recht zuspricht, die andere im Projekt nicht haben, und wird deshalb irgendwann garantiert Spannungen verursachen, zumindest bei manchen Freiwilligen.

In der Praxis scheinen Firmen die eine duales Lizenzmodell wählen keine wirklich gleichberechtigte Entwicklergemeinschaft aufzubauen. Sie bekommen von außen kleine Bugfixes und Patches gegen Unschönheiten, müssen jedoch die die meiste Arbeit intern erledigen. Zack Urlocker, der Vizepräsident für Marketing bei MySQL, sagte mir beispielsweise, dass die Firma aktive Entwickler im Allgemeinen sowieso einstellt. Die Entwicklung unterliegt deshalb, wenn auch unter der GPL lizenziert, im wesentlichen der Kontrolle der Firma, wenn auch mit der (äußerst unwahrscheinlichen) Möglichkeit, dass jemand der wirklich unzufrieden damit ist, wie die Firma mit dem Projekt umgeht, einen Fork von dem Projekt machen könnte. In welchem Maße diese Bedrohung, die Politik der Firma präventiv gestaltet, weiß ich nicht, in jedem Fall scheint MySQL jedoch keine Akzeptanzprobleme, in der Open-Source-Welt oder sonstwo zu haben.