Do We Need a Covenant for Open Source Businesses?

It's no secret that businesses built around open source tend to favour one model in particular - that involving dual licensing. The basic idea is simple. A company acquires the copyright of the main codebase, which might begin life as a...

Share

It's no secret that businesses built around open source tend to favour one model in particular – that involving dual licensing. The basic idea is simple.

A company acquires the copyright of the main codebase, which might begin life as a small-scale, single-coder project, and is then "taken commercial" thanks to a little greasing of palms (providing a well-earned payback for all those hours of lonely coding.)

The company continues to release the code under an open source licence, typically the GNU GPL, in order to tap into all the good things that free software can provide – user feedback, bug fixes, code suggestions etc. But as the copyright holder, it is also able to release the same, or similar, code under a non-open licence. This might be so that third parties can include the software in their closed-source products without triggering the GPL, or simply because customers' lawyers are uncomfortable with open source licences (although it's hard to believe many can be so clueless these days....)

To make that possible, the company will routinely ask open source coders to transfer copyright in their submissions. Although this has become the accepted route for companies based around open source, it's problematic for a number of reasons.

It introduces an asymmetry into the relationship. The company can offer the code as free software or under a closed-source licence. Although coders can take the code and fork it, they can only offer it under the open source licence chosen by the company. Then there is the issue of enclosure: once the copyright has been assigned, there is nothing to prevent the company from closing down the code for future versions (older versions will, of course, still be available under the original open source licence.)

My preferred solution to this is to move towards a foundation model. Here, open source coders would transfer their rights in the code to an independent foundation that would be tasked with ensuring it thrives. Any company could use that code as the basis of its business, but it would not be able to enclose it or offer it on preferential terms. Openness and symmetry would be preserved.

This approach is already employed: for example, the copyright for code in GNU projects is assigned to the Free Software Foundation, and other open source projects use foundations in similar ways. But there is a certain resistance among companies to take this route, since they see themselves as losing the obvious – and probably easiest – way of making money from the open code.

So, the question is: can the dual-licensing model be adapted in some way so as to address the concerns of coders, but without removing the commercial advantages? Until now, that's been a thorny problem that no one has really managed to solve. But maybe one of the key people in the early years of open source, Bruce Perens, has done just that.

For those of you unfamiliar with his not inconsiderable achievements, here's part of his biography:

Perens is probably best known as the creator of the Open Source Definition, which is both the manifesto of the Open Source movement in software and the specification for its licensing. Perens was the person who announced Open Source to the world, and co-founded the Open Source Initiative. He is the founder of the Linux Standard Base, the main standards project for Linux; and Software in the Public Interest.

And this is his cool idea - that companies employing a dual-licensing approach should pay the open source coders when they assign the copyright of their work, but in a rather unusual way:

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 workable.

This is very clever: I don't think I've come across this kind of lateral thinking before. My only concern was what might happen if the company in question went bankrupt, but Perens has addressed that too in the implementation he came up with for the HPCC (High Performance Computing Cluster) project, "a massive parallel-processing computing platform that solves Big Data problems". This was recently released as open source by LexisNexis Risk Solutions, part of Reed Elsevier (disclosure: I used to work for these people 20 years ago...). Here's what the deal is there:

the product is to be dual-licensed under the Affero GPL 3.0 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.

Here's the key section of that HPCC covenant [pdf]:

HPCC Systems' Open Source Covenant. HPCC Systems supports open source technology and the availability of the Community Edition source code. To that end, HPCC Systems will support and maintain an open source edition (now known as the Community Edition) of the HPCC Systems platform source code ("OSS Edition") for at least three (3) years after accepting and including specific
Source Code from You; provided that, if HPCC Systems desires to discontinue supporting and maintaining the OSS Edition prior to that, HPCC Systems may donate the then-current version of the OSS Edition to the open source community (i.e. a not-for-profit or non-commercial organization managed primarily by persons or entities not employed or owned by HPCC Systems) to support and manage the OSS Edition under a permissive open source license (for example, the MIT License) without violating this obligation. If HPCC Systems fails to maintain this obligation for any of Your applicable Source Code, Your remedy will be that HPCC Systems will remove such Source Code, upon request and identification, from the then-current versions of the Application and not include it going forward.

Interesting to see that the fall-back position in the event of the company being unable to support and maintain an open source version is that it is given to a foundation....

So what's your view? Has Perens squared the open source licensing circle, offering businesses a way to make money, and providing assurances to coders that companies won't rip them off? Or can you spot some fatal flaw in the scheme that dooms it to history's dustbin? All comments welcomed....

Follow me @glynmoody on Twitter or identi.ca, and on Google+

"Recommended For You"

The 5 key forces driving open source today Licence to Kill