In an attempt to explain the periodic fluctuations in American history, the historian Arthur Schlesinger – the Schlesinger the Harvard library is named after, not his son Arthur Schlesinger Jr that worked in Kennedy’s administration – posited that history runs in cycles. Specifically, his cyclical theory argued that American history swung back and forth between periods of private and public interest, with transition periods in between. These transitions could be rough, and characterized by elevated economic, social and structural tensions.
This is a model that attempts to help understand both the past and the future of the United States. As is said in our industry, all models are wrong but some are useful. Schlesinger’s is no different, and is imperfect even while it provides a framework for understanding and providing context around historical developments. The model’s utility extends beyond American history, however, because as an analogy it may be applied – if loosely – to the defining product of the technology industry – the software that runs it.
In software, there are clear public and private interests. On the one hand, individual software authors have interests and incentives associated with their creations. On the other, the influence of what we now would refer to as open source but has a long history predating that term, is oriented more around the concept of a commons.
These private and public incentives have been waxing and waning in influence as long as there has been software. It’s easy to forget now, but the earliest days of software looked very much like what we would now refer to as open source. When software was a means rather than an end, as the history of the SHARE user group amply demonstrates, it was standard practice for users of software to collaborate with each other and the original authors to improve a given asset. That public model gave way, in time, to private interests in large part due to the meteoric rise of Microsoft and its unprecedented ability to monetize software.
The private model of software came with costs, however, both literal and figurative, which led to increased friction for developers. This friction, in turn, ushered in a public software renaissance – a renaissance that has continued into the present, a present in which open source is the default assumption for infrastructure software.
But history does have a tendency to be cyclical, which implies that our the current public cycle must eventually be eclipsed by a private model. Were this to occur, it would according to Schlesinger’s model be preceded by a transition period, a period of strife in which tensions between public and private interests rose to new heights and partisans on both sides took at aim at each other, and even themselves in a series of petty internecine squabbles.
A period of strife, in fact, that might look a lot like the current industry environment.
One year ago this past June, the prediction was made in this space that because of its obvious downsides that the trend of hybrid licenses would be more passing fad than market phenomenon. Recent history has proven that incorrect, laughably so in fact. In spite of the obvious overhead, commercial open source providers are pursuing incongruous combinations of open source and proprietary licenses at an accelerating rate, with each such effort seeming to provide cover for the next.
These inarguably have negative implications for the public good, as will be discussed, and are driven instead largely if not strictly by private interests. Bryan Cantrill has argued that “any perceived ‘danger’ to open source is overblown,” and he is correct – depending on what we’re talking about when we talk about open source. Open source as a development model will undoubtedly endure, if only because it’s the least bad model out of all of the others that have been tried and because the phenomenon of developer empowerment is unlikely to be reversed.
But in a world in which appetites for open source software commercially are under threat from – among other areas – proprietary cloud based offerings, it is certainly possible that industry appetites and support for open source could be slowed if public models give way to private alternatives.
Many of those that have resorted to problematic licenses, however, feel as if they’ve been left with little choice. In their view, they foot the bill for the majority of development on an open source asset, only to see a cloud provider pick up that code and offer it as a competitive service – often without so much as an acknowledgement of the open source codebase it’s derived from.
The question facing these providers, and the market as a whole, is not whether or not the typical commercial open source vs cloud provider dynamic is optimal – it is clear that, while improving, it is not. The question rather is whether or not a license is an appropriate remedy for the issue.
The view here has been, and remains, that licenses do not represent a solution. At best, they’re a band aid, and at worst they may achieve ends opposite of their original intent. There are many reasons to be critical of these controversial licensing approaches, here are ten of the most relevant.
- They Represent a Threat to Open Source
Again, not open source as a development methodology – that is here to stay. But if the development model is secure, the wider market context of open source as an approach that supports, among other things, commercial entities could be damaged by these new licenses that attempt to look like open source but are not. Which would be ironic indeed, because many of those embracing the hybrid licensing approach claim to be doing so in an effort to protect open source.But the fact is that efforts like the Commons Clause which deliberately blur the line between open and proprietary approaches and messaging so completely its difficult to determine where one starts and another begins can have negative ripple effects on open source projects. If one company is bitten by a BSD + Commons Clause combination, for example, some of the negative association bleeds into the open source license. That’s a problem.
Which has become obvious, because in the wake of the controversy following the introduction of the Commons Clause, many embracing a similar but more transparent hybrid licensing approach have sought to distance themselves from it. Of those that have found the Commons Clause implementation wanting but borrow from some of the same ideas, a common defense is that their particular license doesn’t have those problems and is therefore not an issue.
Even if we assume that these licenses don’t come with systemic structural issues – counterfactually as we’ll see later – a problem remains. Kant’s Categorical Imperative states that one should:
“Act only according to that maxim whereby you can at the same time will that it should become a universal law.”
Imagine a world, then, where every commercial OSS provider pursues a course of action which involves a unique, part open and part closed license – each with different language designed to lock AWS out of their business. What this means, effectively, is a world in which every question of product adoption because a one off license negotiation. It is a world suffering from what the OSI – which fought and won a pitched battle against it years ago – would term license proliferation.
Some of the licenses are intrinsically problematic, some may be less so, but in the aggregate they are all part of a problem.
-
They Will Be Fought by OSS Communities
Anything that represents a threat to open source, unsurprisingly, will be fought by communities that support open source. Which in turn implies that commercial open source providers that embrace controversial licensing tactics won’t have to contend with just their competition in the cloud, but potentially with their own and adjacent open source communities. In a few cases, this has led to preliminary planning to attack institutions that seek to protect open source, such as the OSI.Wherever a given community may sit on the ideological spectrum, an existential threat to one is a threat to all, which is why you see such aggressive discussion and the beginnings of mobilization around the issues relating to open source and its relationship with licensing. Commercial open source organizations contemplating license changes must contemplate, therefore, whether the perceived benefits of their approach outweigh the costs of antagonizing their supporters as well as their competitors.
And as an aside, the idea that the OSI cannot or will not evolve its definitions or principles – that it is a hidebound institution dedicated solely to protecting the past – is difficult to support. First, because the OSI is an elected body, not an appointed one. But more importantly, the idea of fundamentally redefining open source and its principles simply isn’t a realistic short term goal. If those principles need to be changed, they need to have a lengthy timeframe for consideration and debate, because the unintended consequences of major changes would be profound indeed. The fact that the OSI isn’t rushing to adapt and compromise its principles in service of the short term needs of investors, therefore, is a feature rather than a bug.
-
They Offer Minimal Gains Over Traditional Open Core
For years now, commercial open source organizations have found success pursuing so-called open core models, in which a functional open source foundation is complemented by a closed source, proprietary extension offering additional, paid-only features. While perhaps not the preferred approach of open source advocates, it is universally understood and accepted. It is also an approach which protects the commercial opportunities for software authors, both by offering would be users an incentive for purchasing the software in a traditional manner while also denying access by cloud providers to the premium source code and features.Hybrid licensing approaches typically, though not exclusively, leverage this approach except that they make source code available (good) under a opensource-but-not-really license (not good).
Vendors claim that the benefits to the available source code, ranging from the ability for customers to look under the hood, file bugs or even patch their own source code, outweigh the overhead of the unique (read: vanity) license. But in most cases, organizations pursuing this course develop the source code in question entirely by themselves. This means that the number of outside bugs, fixes and so on they actually receive from external parties – let alone that make their way back into the source code – is vanishingly small. In which case organizations would likely be better off not pursuing unique, exclusionary licenses but simply releasing their assets under a proprietary software license in a source-available model.
-
They Introduce Friction for Commercial Buyers
For reasons of scale, enterprises are not in favor of the practice of performing one off license reviews on each piece of software they adopt. The response from vendors embracing vanity, exclusionary licenses is that it’s a non-issue; enterprises purchasing the software buy their way out of the license, effectively.This is true for enterprises that are fully aware of every instance of a given piece of software running. The problem is that that doesn’t describe many enterprises. In multiple cases RedMonk is aware of since the introduction of these hybrid licenses, enterprises have forbidden their future usage in spite of being commercial licensees because of the possibility of unsanctioned instances creating potentially serious license issues.
-
They Don’t Solve the Business Problem
Commercial open source companies are attempting to solve the problem of cloud providers re-implementing their software, which is clearly an issue. But they have another, potentially larger problem: the commercial markets associated with stand alone, on premise software generally are in decline and have been for years.In some cases – Elastic or MongoDB, as two examples – the vendors have strong SaaS offerings of their own. But in several cases, these licenses are being employed by businesses that do not to offer their open source as a service. Which means, effectively, that commercial providers are not providing customers what they want while attempting to protect a market that is shrinking over time.
Making matters worse for companies that decline to pursue service-based models is that they are denying themselves access to the invaluable customer telemetry data AWS and others accumulate every second their workloads run.
-
The Assumptions Are Questionable
In 2016, Andrew Ng said:Among leading AI teams, many can likely replicate others’ software in, at most, 1–2 years.
Implicit in every one of the hybrid licenses is an assumption of value. Specifically, that some or all of the software is so unique that it requires special, industry-norm violating protections. Given that no one has expressed any expectation that these new licensing schemes will result in cloud providers commercially licensing the software, the implicit assumption therefore seems to be that the licensed software can’t be replicated by those it is protected from. Based on the demonstrated development velocity of players such as AWS, this seems like a questionable assumption.
It is also possible that in cases where an asset is popular enough, that the controversial practice of relicensing will result in users triggering their nuclear option: damaging forks of the code pre-license change.
-
The Licenses May Not Work
One of the questions concerning hybrid licenses is whether or not they are legally enforceable. Cantrill has argued that the licenses “are almost certainly asserting rights that the copyright holder doesn’t in fact have.” Tidelift founder and attorney Luis Villa is less convinced, saying: “I’m mostly agnostic on the [question] of whether or not these licenses are enforceable.”Given the downsides of the licensing approach, it would be ironic indeed if the licenses that caused so much damage proved to be unenforceable.
But even if we assume for the sake of argument that the licenses are enforceable, they have systemic structural issues. Attempting to simultaneously limit the scope of the license to cloud providers but provide enough ambiguity to cover the necessary range of potential service implementations is akin to threading a needle. Accordingly, the licenses employ less than precise language which is highly problematic in the context of a legal document such as a license.
MongoDB’s SSPL includes the phrase “value of which entirely or primarily derives from the value of the Program or modified version,” which is similar to the Commons Clause’s “whose value derives, entirely or substantially, from the functionality of the Software.” The issues there are clear: who decides what “primarily” or “substantially” mean?
Confluent’s Community License, for its part, includes an excluded purpose “other similar online service that competes with Confluent products or services that provide the Software.” How is competing defined, and who gets to define it? And what if the asset licensed evolves functionally such that it reshapes the definition of what it competes with?
Whether or not they’re enforceable, then, these new licenses are legally imprecise and therefore problematic. The question isn’t whether the current crop of licenses is well designed, then, but rather whether it is possible to design a license that achieves the desired ends without foundational structural issues. The available evidence – specifically the fact that the experienced legal teams involved have thus far been unable to design an adequate license that meets with general acceptance – suggest that it can’t be done.
-
They Create FUD Opportunities for Competitors
There is one constituency who does obviously benefit from these new hybrid licenses: competitors. By invoking hybrid licenses, organizations employing them are handing their competitors easy public relations wins.Competitors can and are asking questions like:
- You bought this because it was open source, but now it’s not. What else are they going to change on you?
- They claim that the license doesn’t apply to you? Will their acquirer believe that?
- Are you sure that your definition of value is the same as theirs? What if you’re wrong?
The degree to which companies employing these licenses are being dunked on in sales calls versus both open source and proprietary competition is startling.
-
They Face Increased Competition
One of the under-recognized problems with this licensing approach is the market context. In stark contrast to the world a decade or more ago, competition in the open source world – and therefore customer choice – is abundant. This means that a user in many cases can choose between a hybrid-licensed asset and several pure open source alternatives. Even if the functionality isn’t identical, the technical tradeoffs may be offset by the lack of legal overhead. -
They Can’t Be Combined With Other Open Source Software
One of the benefits of open source software from a developer standpoint – and one of the most common use cases – is the combination of various open source assets to form a new whole. This was such a fundamental use case, in fact, that it was a primary consideration during the revision of various licenses from the Apache Software License to the GPL.These hybrid licenses, by comparison, cannot reasonably be expected to interact well with existing open source licenses. This is something both authors and users should consider.
In some ways, these hybrid licenses are similar to debates around free speech. It is, inarguably, an author’s right to decide how and where their projects can be used – including whether to be a part of what Adam Jacob is terming “The Non-Compete Movement.” But just as no one is obligated to provide an audience to someone with views they find distasteful, nor is the market required to receive hybrid licenses warmly – even if the motivations behind them are understandable.
Whatever the relative merits or downsides to these new licenses, however, the market does appear to be shifting back towards the private interests and away from the public. Even for advocates of the hybrid license approach, it’s worth thinking carefully about what that means for the long term.
Disclosure: Amazon, Elastic, Microsoft and MongoDB are RedMonk customers.
