The HPCC Covenant by Mark Stone

October 2011. Bruce Perens has announced an innovative new approach to open source project governance and intellectual property, an approach to be used by LexisNexis for their data analytics engine, HPCC. Perens, author of "The Debian Social Contract", which ultimately served as the foundation for the Open Source Definition, has always been an innovative thinker when it comes to community management, governance, and open source. The problem he purports to solve with LexisNexis' newly announced "Covenant" has to do with a perceived asymmetry in dual-licensed software. While I applaud Perens for a genuinely useful innovation, there are some other perspectives to keep in mind when examining corporate-community partnerships around open source projects.

Let's look at the problem as Perens sees it. In a dual-licensing scenario, the intellectual property of a project is held by a company that releases it under an open source license for the community, and a commercial license for companies looking to include the software in their own product(s) without the "encumberance" of an open source license. In this scenario the open source license used is typically a so-called "restrictive" license like the GPL, which would prohibit creating derivative or combined works that are not also under the same open source license.

This approach creates a balanced market for users of the dual-licensed project. Open source developers can freely use the project in their own work, as long as they use a compatible open source license. Commercial companies whose business and licensing model is incompatible with open source can pay to opt out and instead use a commercial license.

The problematic asymmetry arises with open source developers who wish to contribute to the dual-licensed project. After all, the licenser must hold all the relevant intellectual property rights in order to distribute under two different licenses. As Perens says, "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." Open source developers must be willing to sign some sort of contribution agreement in order for the company to make use of their contributions. The end result is a company profiting from a commercial licensing business based on code that has been "gifted" to them by outside open source developers. This is bad for the open source developers, because they are giving away something for nothing. This is bad for the company, because developers are consequently reluctant to make contributions. Perens says, "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'." Perens then cites MySQL as just such a cautionary tale, suggesting that MySQL AB's acquisition by Sun, and their subsequent acquisition by Oracle, has left MySQL contributors in a very different position than they thought they were in when they originally made those contributions to MySQL and signed a contribution agreement with MySQL AB.

Without debating the facts of the MySQL - Oracle relationship, let's acknowledge what Perens gets right. It is indeed difficult for companies pursuing open source as part of their business, and open source developers in the community at large, to find common intellectual property ground on which to collaborate. Licensing terms too favorable to the company discourage contribution, which inhibits development and ultimately slows adoption. Licensing terms too favorable to the community leave the company exposed to the possibility of a competitive fork, meaning the company will be reluctant to invest significantly in open source. All of this Perens gets absolutely right.

And his proposed "covenant", the very approach LexisNexis is adopting, indeed offers a solution for some companies in some situations. Essentially the proposal is that the company reciprocate each contribution agreement with a covenant to that contributor that, in accepting their contribution, the company will maintain and support the project, and release an open source version, for at least three years. In other words, as long as there are active outside contributors, the code cannot be taken private for at least three years.

This is a step forward, and real innovation on a complicated intellectual property frontier. We should all applaud Perens for that. However, I suspect that the problem he is trying to solve is not as dire as he suggests, and the solution he proposes not as all-encompassing as he might hope.

First of all, the ultimate protection against taking code private always has been, and always will be forking the code. In the MySQL case this is precisely what Monte Widenius has done in one direction with MariaDB, and what Brian Aker has done in another direction with Drizzle. No matter what Oracle ultimately decides to do with MySQL, the open source community has some great open source choices to pick from. To me this doesn't sound like a broken model, but a model working exactly as it should.

Second, I'm skeptical that even Perens' "covenant" will completely relieve the discomfort open source developers may feel at gifting their intellectual property to a company. While it is a step in the right direction, at the end of the day developers are still granting the company a one-sided opportunity to profit from the work of others.

Finally, the "covenant" isn't going to solve all problems for all companies looking to engage in open source. Given the current state of patent law, for many companies being the holder of intellectual property to open source code they developed will be at best extremely risky, and at worst actively bad. One need look no further than the Google – Oracle dispute over Android to see the proof. Let's assume, for the moment, that Google is ultimately proved to be completely without fault – an outcome that is far from certain. Even in that hypothetical scenario, it will take Google years of effort and hundreds of millions, maybe even billions of dollars to see their way clear of the Android legal action. In this and other patent maneuvers in the mobile space developers and ultimately consumers are paying a huge "patent tax" as companies spend exorbitant amounts to protect themselves from exactly the sort of briar patch into which Google has been thrown ("Planet Money" says it best).

An alternative approach, pioneered by the Apache Software Foundation and now expanded on by other organizations like the Outer Curve Foundation, is to establish a neutral party as the "escrow house" for intellectual property. If the intellectual property owner is not a company, then developers should feel much more comfortable that the contribution agreement they sign is still resulting in a community contribution. And if the intellectual property owner is not a company, but a not for profit with no revenue and negligible assets, then such an entity is much less likely to be the target of legal action about said intellectual property.

My own work was with the planning and launch of the Outer Curve Foundation. It was very clear in the planning stages for the foundation that (a) developers at Microsoft were eager to have certain projects released as open source and continue contributing to those projects, and (b) while management at Microsoft understood the value of open source as a way of fostering the ecosystem around Microsoft technologies, they had no desire for Microsoft to deal with the entanglements of having actual intellectual property ownership of that open source code. The foundation provides a steward for these projects with which all parties are more comfortable.

Of course on this model there's no direct way to pursue a dual licensing model, since the company has divested itself of the intellectual property in question. But dual licensing is only one open source approach among many that companies might pursue. And with further innovation, there may yet be a way to accommodate dual licensing within the "escrow house" model. One of the great services Perens has done for us with the HPCC Covenant is to remind us that innovation is still possible on the intellectual property frontier of open source. Organizations like the Apache Software Foundation or the Outer Curve Foundation are pursuing innovation, and companies struggling to find the right open source engagement model would do well to heed what they have to offer.

Add / view comments.