For those who would develop software and sell it, open source is something of a conundrum. On the one hand, as Mike Olson has noted, you can’t win with a closed platform. On the other, it substantially complicates the sales process.
Before open source software entered the mainstream for enterprise technology usage, the commercialization of software was a straightforward affair. As the gatekeeper between proprietary code and an enterprise that wanted it to solve one problem or another, vendors were able to dictate terms to would be buyers. When that source code is made available publicly under an open source license, however, vendors must either persuade enterprises to pay a license for something they have free and unrestricted access to or find a different model to monetize their software development efforts.
This fundamental disruption of the traditional sales model has led the commercial open source community to experiment with a variety of business models, from support and service to dual licensing to open core. It has also, more recently, led to the release of the Commons Clause.
The Commons Clause, in the event that you are extremely fortunate and missed the eruption that followed the news that Redis Labs had applied it to several of its previously AGPL modules – although not, as was initially believed, core Redis itself – is essentially a license rider. For something that has generated this much controversy, the language itself is actually simple.
In short, as the documentation acknowledges, the Commons Clause turns open source software into non-open source software, according to the industry’s accepted definition of that term. Specifically it says that the terms of the original open source license notwithstanding, you may not sell software “whose value derives, entirely or substantially, from the functionality of the Software.” Lawyers and others with long term exposure to license issues will note the problem with the word “substantially” – what does that word mean in this context, precisely, and who gets to define it? It’s a bit odd, frankly, to see such a lack of precision in a document produced by Heather Meeker, a respected lawyer with long experience in licensing generally and the open source world specifically. It seems safe to assume that that language didn’t make the final draft without a fair amount of internal debate.
Perhaps the language will be reworked or redefined in future revisions. For now it’s enough to note that it’s an issue that, because they are paid to be conservative, most legal teams are likely to avoid by assuming that any value creation, however minor, triggers the clause.
Setting that aside for the present, then, there are several logical questions to explore regarding the Commons Clause. What are the drivers behind it? What does it mean for the companies that employ it and the wider industry? And lastly, is it a good idea?
The Driver
The answer to the first question is easy. While companies employing it will claim, with some justification, that the Commons Clause will lead to the source code of previously proprietary software being released – a debatable point, as we’ll come back to – this ultimately boils down to money. Creators of open source software want to protect their ability to monetize a given software asset.
Which is absolutely their right, to be clear. Whatever the wider implications of this license might be, it is important to note up front that those responsible for writing a given piece of software should get to determine how that asset is licensed and used. And if their desire is to improve their ability to monetize said asset, that is again absolutely within their rights.
But while it may be in their rights to do so, it’s also not surprising that the Commons Clause has triggered such antipathy amongst open source communities in such a short span.
As discussed at the top, open source software has always posed challenges to those who would monetize it. In a world with dozens of public technology companies valued in the billions of dollars, it’s notable that the only pure play open source vendor among them is Red Hat – the exception that proves the rule. This does not mean, as has been misunderstood many times over the years, that open source is somehow impossible to monetize – quite the contrary. But it is inarguably more difficult to sell than the traditional proprietary software models that preceded it or, more problematically, the as-a-Service (aaS) versions that present the fiercest competition for open source today. It is, in fact, that latter camp that is the real, primary driver for the Commons Clause.
At RedMonk, we have been arguing for years now that the real competition for most on premise providers is not, in fact, other on premise providers: it’s the cloud. These warnings, notably, came well before the release of products such as GKE On Prem which represent an entirely new class of threat. To add insult to injury, not only does the cloud represent a competitive threat, thanks to the nature of the licenses most commonly employed open source’s fiercest competitor is able in many cases to monetize the open source projects while contributing little or nothing back to their development.
Salil Deshpande, the architect of the Commons Clause intitative who is also a Managing Director at Bain Capital Ventures, acknowledges the threat that cloud providers play, citing Amazon’s behavior in particular as the impetus for gathering “CEOs or chief counsels of two dozen at-scale open-source companies, some of them public, to talk about what to do.” Indeed, by his account, the Commons Clause was and is a direct response to the commercial threat that cloud providers pose:
What Commons Clause prevents is the running of a commercial service with somebody else’s open-source software in the manner that cloud infrastructure providers do.
As stated above, then, the drivers here are for all of the controversy relatively straightforward. Commercial open source organizations using this clause want to prohibit others – and by others, read “cloud providers” – from selling their software.
One interesting question to ponder as an aside – while proponents of the clause claim that it is focused on cloud providers and that companies who don’t sell software in the traditional sense, such as General Motors or General Electric, are unaffected, how does the license read on internal scenarios involving chargebacks? If an individual business unit bills one another for services based on software licensed under the Commons Clause, does that count as a sale?
In any event, those who would employ the Commons Clause want to prevent those who don’t contribute to their work from being paid for it. What could be wrong with that?
To address that, let’s look at the second question posed above: what does the Commons Clause mean for the companies that employ it and the wider industry?
The Implications
In the abstract sense, it’s reasonable to hope that those who are responsible for a given software asset are the ones who profit from its sale. The problem is that the mechanism leveraged by the Commons Clause poses several major issues for open source broadly.
First, it’s necessary to understand why open source works at all. For developers, it’s simple: open source works because it imposes less friction than the alternative. But the reason open source works within the enterprise is an acquired acceptance of the model and an understanding of both the macro license types and micro-license implications.
What this means in practice is that the ability of the developers within a given enterprise to use and rely on open source at scale is dependent on its acceptance by that enterprise’s legal department. Which in turn implies that the legal department has had to learn, in many cases slowly and painfully, what open source is broadly and what the differences are between, as one example, permissive and reciprocal licenses. The end result is the policies which countless developers operate under today which specify which licenses are approved and which are not.
Implicit to this arrangement is stability and predictability to both the term open source and the licenses themselves, as well as a manageable scale of licenses and types.
Consider the latter issue. Lawyers can reasonably be expected to understand the half dozen to dozen most common licenses, but what if each commercial open source project had its own license? This would mean that every project would involve a one off license review, a process that cannot scale for most enterprise legal teams. Which in turn means that the friction to using open source would be unacceptable, which would depress usage. This potential threat was and is why the OSI and other open source communities fought the so-called vanity licensing practice by heavily restricting the list of approved licenses.
It is also why the OSI guards the term Open Source zealously. Today, enterprises can assume that any open source license – whether it’s permissive, reciprocal or somewhere in between – adheres to these ten principles. What if, however, that definition became blurry? Or what if well understood and vetted open source licenses began to be modified by riders with unclear implications? Either development would be enormously problematic for open source broadly.
Which brings us back to the Commons Clause. The problems it was created to solve have, in most cases, been solved before. Without turning this into a history lecture, here are a few examples.
- The AGPL, for example, was created to solve the problem of cloud businesses not contributing back to projects; its reciprocal provision, unlike the GPL’s, is triggered when a given software project is distributed in a network context. This means that companies that might resell Redis in a cloud context, for example, would be required to make any changes, fixes or updates available under the same terms if the project was licensed under the AGPL. MongoDB is perhaps the most notable at scale employer of this licensing approach.
-
Or there’s the oft-cited issue of wanting developers or others to have access to source code, but not wanting to make it available under an open source license – the model that purports to allow companies to make proprietary source code available publicly mentioned above. This escrow-type model, again, has been done many times over the years. The source code for one of the most important proprietary software assets of all time in Microsoft Windows was available on this basis; Microsoft later tried unsuccessfully to scale this with efforts like its Shared Source licensing approach. Current practitioners of this escrow approach include Elastic; see their license description here.
-
The restrictions on sales, likewise, have been done. Shareware, crippleware, trialware, nagware and so on are models with histories going back decades. More recently, Cockroach Labs, MariaDB, Sourcegraph and others have attempted to conflate open source and commercial models, the result of which are hybrids like MariaDB’s Business Source License or Cockroach’s Community License. Importantly, none of these lay claim to being open source.
The group behind the Commons Clause is presumably aware of this history, and if they were not Meeker most certainly is, and yet they chose none of these paths. Why?
In the case of the AGPL, there are specific objections regarding its patent clauses and its inability to solve the monetization problem. Companies considering the Commons Clause could choose to follow in the footsteps of a Cockroach Labs or MariaDB, which apply specifically non-open source licenses. Instead, the Commons Clause implicitly rather than explicitly conflates open source and proprietary licenses by combining a known and trusted open source license with an unknown proprietary alternative.
From an open source perspective, that is a clear and present danger. Open source, as discussed, is dependent on crystal clear and scrupulously maintained principles and definitions. Commons Clause projects invoke that – deliberately, one assumes – but then supersede those implied rights and privileges with a rider that is inarguably at odds with the core values espoused by open source communities regardless of where they sit on the licensing spectrum.
Because of this, you can expect the Commons Clause effort and its adherents to take heavy fire from open source advocates in a manner in which even Cockroach Labs and MariaDB have never had to. Moreover, it’s embedded in the model itself, and thus is not a fixable problem. Unless and until the Commons Clause becomes its own hybrid license class and actively and aggressively differentiates itself from OSI-approved open source, it will remain a threat to open source and its adoption.
Which brings us to the last question, independent of its wider implications for open source and the industry, is the Commons Clause a good idea?
The Merits
In the short term, at least, adherents are more or less guaranteed to face heavy negative feedback, both from open source advocates in their particular community as well as from a variety of unassociated groups with horizontal open source concerns. Which means that another way of asking that question is whether the benefits of employing the Commons Clause outweigh the real, observable short to medium term negatives in public perception and developer sentiment.
Each case will be different, of course, but on a high level the Commons Clause seems – like hybrid licensing – to be a misguided approach.
First, it is essentially built on a fundamental assumption that the value in software today is in the source code. This assumption, however, is contradicted by a host of available evidence from a wide variety of categories. As has been covered here and in more depth in The Software Paradox, the realizable commercial value of software has been on a trajectory opposite to that of its actual importance within organizations. One comment supporting the Commons Clause read, “it is difficult to sell open source infrastructure software today.” This is partially correct; it is, in fact, difficult to sell infrastructure software today, open source, proprietary or otherwise. Whatever the category, software is an asset that is worth substantially less than a comparable product would have been a decade prior. While commercial open vendors can employ the Commons Clause to ensure that cloud companies don’t sell their software, then, this is obviously not a guarantee that customers will buy it.
It seems improbable, certainly, that if suddenly confronted with Commons Clause licensed software, that cloud providers would universally pivot and license the software from the commercial open source providers that wrote it. It’s possible, in fact, that the application of the Commons Clause could backfire, making it more likely for cloud providers to try and poach key contributors or committers from companies that employ the license and forking projects either publicly or privately as a lower cost means of providing the necessary control over the software assets. Regardless, the question remains: if the Commons Clause isn’t likely to turn cloud providers into a major revenue source, where will the dollars come from?
Which brings us to the second point.
In June of 1999, Shawn Fanning and Sean Parker released a piece of software called Napster. Napster allowed those who had purchased a commercial CD and ripped it to the MP3 format to distribute their MP3s directly and efficiently to a worldwide audience via a P2P network, thereby depriving artists, rightsholders and distributors of potential revenue from additional sales.
Unsurprisingly, the record companies and their trade organization, the RIAA, were appalled at their products being shared user-to-user for free rather than purchased directly. In their eyes, their formerly paying customers were all thieves, not would be buyers who merely wanted a simpler, more convenient way to purchase music digitally. As a result, their response to this disruptive threat was not to offer users what they wanted: an online purchasing offering. Instead, they attempted to further restrict the digitization of physical media such as CDs, they employed advertising scare tactics and eventually litigation of their would be customers. They saw licensing and enforcement as the solution to a business model problem, in other words.
Commercial open source organizations who are considering licensing as a solution to their business problem, then, might want to focus not on whether Amazon is taking advantage of open source software, but why customers are flocking to Amazon and other cloud providers. Whether or not one believes that cloud providers can and should do more to support the open source projects – and the view here is that it is inarguably the case – is immaterial. Ultimately the problem faced by commercial open source organization is less the fact that the open source licenses they rely on are too liberal than the fact that customers want what many commercial open source organizations are unable or unwilling to provide: a managed service. Licensing cannot address that problem.
As has been said here before, licenses are always a tactic, but they’re rarely a strategy. If the Commons Clause is intended to “protect” open source but is both not open source itself and widely viewed as actively harmful to it, it’s not clear how much protection the industry needs.
Disclosure: Amazon, Elastic, Microsoft and MongoDB are RedMonk clients. MariaDB is not currently a RedMonk client. Cockroach Labs, Redis Labs and Sourcegraph are not RedMonk clients.
Update: This piece originally asserted that the Redis Labs modules released under the Commons Clause had previously been proprietary code. This was incorrect and has been corrected above, the modules in question had been AGPL.
