Some successful open-source companies are using a dual-licensing scheme. In short, software is released both through an open source version (e.g. licensed under the GNU GPL) and through a proprietary license usually reserved to paying customers. It’s great for attracting OEM vendors since they can integrate the dual-licensed software into their proprietary application without fear of contamination. FUD is apparently good for business.
But this approach has important drawbacks (some of them nicely developed by Glyn Moody a few years ago and also discussed here by Lajos Moczar) that make it question whether a dual-licensing model is really fair to the community and its developers.
Indeed, regular open source community developers are usually:
- Free to exert their IP (copy)rights at any time, any way they want
- Free to offer contributions approved by the community
- Free to fork new versions
- Overall free to produce work in the best interest of the community
In current dual-licensed models, none of these basic open source freedoms can be easily –if at all- exercised. Icing on the cake, the open source company is not forced to contribute back to the community.
By controlling IP rights Dual-Licensing (DL) companies are controlling your contribution to other open source projects
In a dual model, all external contributors are required to re-assign their copyrights (and sometimes all of their IP rights) to the open source company.
Assume a contributor releases his/her rights for a piece of code P to MyCompany.
Later on, a famous open source project is approaching the developer: we’d like to use this P code you wrote but it has been released under the GPL which is not compatible with XXX, our project license. Can you release it under another open source license?
The answer is: sorry guys, I’d love to but I can’t, you’ve got to ask MyCompany. To which MyCompany will likely answer: sorry it’s not our policy to release our code under license XXX.
By controlling the source tree DL companies are controlling the directions, the maturity and the crippleware-level of the code
Of course a contributing developer could refuse to sign any IP assignment. But then MyCompany would refuse to integrate the contributed code in the source tree. And it works because no developer is going to fork a new project just to incorporate his/her patch.
In the same vain, certain DL companies are often releasing patches to the proprietary version before releasing them to the open source community. Good for business (see we are the only professionaluntil it was reminded their duties by the community. version) bad for the community. Ghostcript for instance didn't level both releases
By controlling the right to fork DL companies are also depriving developers of their right to choose
You cannot fork: Dual licensing is about exerting a very tight control over the community. That’s why in this model, most key and/or respected developers are usually paid or employed by the company: a very strong disincentive to fork.
To realize the extent of the influence and control of companies over open source project, think about this: Sr. VP and former MySQL CEO Mårten Mickos is now the boss (at SUN) of PostgreSQL core developer Josh Berkus .
The company can fork but you cannot choose: Any addition of proprietary code to the dual licensed code (and distributed through the proprietary license) is a de facto fork. In the open source world when such fork happens, you can always choose which one suits your need. In the dual-licensed world, you cannot.
By controlling the key developers DL companies are diverting key resources from the open source community: dual-licensing is a road to one-way schemes
When distributing the code under the proprietary license MyCompany is never forced to contribute to the community while the open source community is always forced to contribute to both licenses (remember the IP assignment).
The more proprietary code is included, the more difficult it is for MyCompany to release patches that are compatible with both the proprietary version and the open source version.
As time goes by, MyCompany will release more and more patches of no-use to the community.
And who is working on those patches? Well, the key developers who have been so wisely hijacked by the company and who are now prevented to really contribute to the community. Business is business after all.
For all of the reasons above, many developers are not keen to the idea of dual licensing. They don’t like the idea of their contribution released as proprietary, nor are they found of this idea of given up all of their IP rights. MySQL for instance has a much less thriving community than that of PostgeSQL.
Is there a solution for dual-licensing companies that would bring more fairness and more freedom to the model and as such foster more community involvement?
PS: We will discuss a few possible directions in a forthcoming post. And if you're here, maybe you want to register to the feed.
Update: Many detailed comments! Answers to those comments have been made available here.
- Dual-licensing: revoking the GPL
- A company turns the Microsoft-Novell case into an open source business model
- One million dollars for a T-shirt
This post is cited or quoted by: