Ở Vn chắc các viện nghiên cứu và cả doanh nghiệp đều cần.
http://hpccsystems.com/community/white-papers/the_covenant_bperens
By Bruce Perens
How can a company profit from their product while being fair to their Open Source development partners? After decades of corporate participation in Open Source, this question is still debated. HPCC Systems is taking a new approach.
Dual-licensing is a common paradigm for producing a profit from Open Source, but not a problem-free one. It was made famous by MySQL, who distributed a version of their database under the GPL as their Open Source license, and also sold commercial licenses to the same software. The GPL is a reciprocal license: modifications of a program that is licensed under the GPL must themselves be made available under the GPL terms, which include distributing source-code to the public. Companies that made use of MySQL's application libraries in their proprietary products were happy to pay for a commercial license and avoid the GPL terms. Dual-licensing was successful for MySQL, and the relatively small company sold for USD $1 Billion1 9 years after it was founded.
Dual-licensed products use an Open Source license that discourages proprietary software that is a derivative work of the platform, while allowing Open Source development to proceed unabated. The GPL is effective in this, because of its requirement that modifications be distributed in source-code form with rights to use, further modify, and redistribute. Producers of proprietary applications generally need total control of the distribution of their products, and use that control to monetize the product. To be sure of maintaining that control in the face of the potential that their work could be derivative of the platform and subject to GPL requirements, they must purchase a proprietary license.
It might seem ironic that the GPL, a license designed to give everyone the freedom to use, modify, and redistribute software without charge, becomes an effective capitalist tool when used in the context of dual licensing. Companies will pay to avoid granting the GPL's freedoms. But even in this context, the GPL achieves its own goal of maximizing the creation of Free Software: it separates those who wish to participate on its terms from those who won't. Those who accept the GPL are rewarded with gratis software and a broad set of rights, while those who eschew the GPL must pay for the right to develop commercial derivative works, and must pay more for the right to re-distribute the licensed software. Much of this payment goes to support development of software that – in the dual licensing paradigm – is released under the GPL.
Dual licensing is potentially fair for both Open Source and proprietary users, and both commercial users and Open Source developers potentially benefit from each other's participation. However, the way most dual-licensing companies handle contributions from Open Source developers breaks this balance.
When dual-licensing, it is necessary for the company to own the entire copyright of that product, or to obtain from every contributor the right to apply a commercial license to their portion of the work. Companies that dual-license must not accept modifications from the Open Source community without one of these things, or they will be unable to commercially license their product. In general, companies implement this by refusing to accept modifications to Open Source projects that they operate until developers agree, in writing, to assign the copyright of that modification to the company.
Open Source developers, however, have historically been reluctant to give away their copyrights, even though they are happy to "give away" substantial rights to their programs, under the governance of an Open Source license. The license enforces that the software will remain Open Source. Copyright assignment, in contrast, does not. As implemented by most dual-licensing companies, copyright assignment is an unconditional gift to the company with no quid-pro-quo for the Open Source developer.
The reluctance of Open Source developers to grant such a gift has, historically, been justified. The companies that have required copyright assignment from developers have made no guarantee that they will refrain from "taking the project private". An Open Source project would be taken private if the company failed to license its further work as Open Source, and continued development as a proprietary product while abandoning the users and developers in the Open Source community. It is the lack of any form of assurance of the subsequent handling of the contribution after a developer assigns their copyright that makes copyright assignment intolerable to many Open Source developers.
The threat that a company would take an existing Open Source project private has been realized a number of times2, most recently when Oracle discontinued Open Source releases for a number of Sun Microsystems' products. Oracle's control of MySQL is seen as a continuing threat. So, Open Source developers who are asked to contribute copyrights have an accurate perception that their contributions may eventually be taken private, and may end up belonging to a proprietary competitor of the Open project. Given the negative history around copyright assignment, a developer who obtains no quid-pro-quo for a copyright assignment, and has no promise of any governance over the contribution that will prevent the work from being taken private, is like an unpaid employee. This is demotivating for the developer, and it's no surprise that Open Source developers find something else to work upon. Projects that have required copyright assignment have not, historically, gained a large developer community. Thus, a company that wishes to build a fair and working partnership with the Open Source community while using dual licensing for monetization should consider how it can improve upon the history of such operations.
This is a concern for HPCC Systems, because the company's product is the result of more than a decade of work and a very large investment. For this exact reason, the decision to release the HPCC platform as Open Source needs to be justifiable through a sound business plan. The goals of this plan are to capitalize on the innovation and new ideas that come with an Open Source community, develop new use cases from the Open Source users, continue and increase the relevancy of the product by keeping up with Open Source development, and collect direct revenue from the product – not just revenue from ancillary products like support and training. Dual-licensing has become a key component of the business plan, and it has become critical to overcome the problems of dual-licensing and its copyright assignment requirement.
MySQL was inadvertently fair to developers. Working on flawed legal advice3, their policy was to refuse to accept contributions from the community at all!4 Instead, they hired the good developers from the community, and thus owned the copyright of their product as a work-for-hire. So we establish one fair quid-pro-quo for Open Source developers who assign their copyrights: pay for the work.
But how would we determine what to pay for each modification? It's easy to price the work of a full-time employee, but difficult and costly to arrive at a fair price for work, done unsolicited, by strangers a hemisphere away. A metric that attempts to pay per line of code would ignore the real cost of the work to the developer, which is strongly influenced by the complexity, or lack thereof, of the project and the contribution. A fair measure of those costs can't come from a machine, it's the domain of expensive experts and will always be subject to argument. Auction and bounty systems have been tried, most infamously by SourceXchange. That effort, operated by venture-funded CollabNet with HP as its founding sponsor, is said to have only achieved the completion of a single bounty project.
An easier approach than paying for contributions is to offer a quid-pro-quo to the developer that is not based upon any factor of the individual contribution, and thus avoids the need for cost-evaluation of individual modifications. Is it possible for a company to offer something valuable in exchange for the participation of their entire external developer community? It would have to be something that benefits all of them, and which none of them could use to the exclusion of others. And it would have to provide each new contributor with an incentive, although it's already been offered to the rest of the community. So, the value would have to change in some way with each new contribution, but not in a way that is based upon the cost of the contribution. It turns out that there is something of value that fits these requirements and can be offered to the entire Open Source community.
A company can covenant, to each contributor of a copyright, to continue to support and maintain a project as Open Source, for a fixed period after a particular contribution - or to remove the contribution from their product if they cannot continue to Open Source their work. In this way, the Open Source developer would be assured of the continuing labor of paid developers on the project in exchange for his contribution, and thus the continued improvement of the program that he uses gratis as a community participant. By making the promise in exchange for the participation of the entire Open Source community, the company will have a better idea of the value it is expending and the value it receives than if it attempted to pay piecemeal for modifications. This covenant is renewed each time there is a new copyright assignment, in that the three-year counter starts anew every time the company receives a contribution from a developer. Thus, developers continue to be encouraged to contribute their copyrights to the company. This seems more workable5.
And this is what we have arrived at for HPCC Systems: the product is to be dual-licensed under the Affero GPL 3.06 and a commercial license. In exchange for each copyright assignment from an Open Source developer, the company will covenant to continue to support and maintain the Open Source version of their product for a period of three years – they won't take it private during that time. The three-year clock will start anew every time there's another copyright contribution. If the company cannot continue to support and maintain the product as Open Source, HPCC systems promises either to contribute the product to a non-profit under permissive licensing like BSD, or to remove the developer's contribution, and all others for which the three-year clock is still running, from the product. Thus, the Open Source developer is assured that the work won't be taken private for a significant amount of time after his/her contribution, and the continued participation of Open Source developers provides a strong incentive for the company to never take the product private.
This covenant will apply to the HPCC software, such that a running HPCC system results from the Open Source release. It will not apply to the ECL programs that HPCC Systems develops to run on the HPCC software. Many of these are custom applications that are developed for proprietary customers. It will not apply to the various data collections that HPCC Systems and its parent companies produce with the use of the HPCC software.
By use of the covenant, HPCC Systems will achieve the best solution for the Open Source community, the company, and the company's commercial customers. Open Source developers will "pay" for their use of the product with source code, commercial users will pay with money, and HPCC systems will "pay" the Open Source developers in the currency they're used to: the source code and support that are promised through the covenant. Open Source developers and commercial customers will benefit from the participation of each other, as the full-time developers at HPCC systems and the Open Source developer community both increase the system's capabilities.
Through the covenant, their use of dual-licensing, and their innovative software, HPCC Systems will gain broad acceptance of their product and will profit from its software and services. I'm proud to have been a part of the development of this strategy.
Bruce Perens is one of the founders of the Open Source movement in software, and a strategic consultant to companies and governments on the issues of Open Source. There's more information on him at perens.com
Disclaimer: This article is commentary upon a legal strategy. The actual licenses and covenants discussed are the only promise from HPCC Systems, and this article should not be considered to create any promise or estoppel. You are encouraged to consult your contracted attorney, who is the only person allowed to provide you with legal advice, regarding this article and the licenses and covenants.
1 MySQL was not the only company to make use of dual-licensing. Sleepycat Software (also purchased by Oracle) made use of it before MySQL adopted the paradigm, and there are no doubt others.
2 Although not always in conjunction with a copyright assignment requirement.
3 We know it was flawed because the advice became a subject of public debate when MySQL co-founder Monty Wirzenius challenged Oracle's purchase of Sun. The EU government's review of the issue found the advice given to MySQL to be incorrect and thus Monty's arguments to be specious.
4 MySQL did license their database server product as Open Source even though it was not community developed. The magic of Open Source, for MySQL, was that their database was configured as the default database of almost all Open Source applications that could use a database. So, MySQL was "pre-sold" to companies, in that they were likely to start using it for mission-critical applications before they acquired a commercial version.
5 I first proposed this idea to the OpenOffice project, in 1999. This was during a phone call to brief me on Sun's initiation of the project, which would require copyright assignment. My idea wasn't implemented. OpenOffice did suffer from very poor developer participation for a decade.
6 Affero GPL 3.0 is a modern version of the GPL with the addition of an "Affero" feature that requires that source be made available if a program is performed online. GPL only required that source code be made available if the software was distributed, which may never happen in the case of software-as-a-service. The license is accepted by the Open Source Initiative and (of course) the Free Software Foundation (which produced it).
