One of the most interesting and unsurprising characteristics of conversations with organizations that have adopted one of the emerging hybrid or “non-compete” style of licenses is that they are universally insistent on being differentiated from one another. Which is understandable on the one hand, given that there are major structural differences between the Commons Clause and the SSPL, to pick two recent examples. Whether it’s reasonable to expect a market which by and large has little appetite for the nuances of different licensing approaches to care is, of course, a separate question.
What is perhaps more interesting, however, is a central, foundational assumption that every member of this category of licenses shares. On the surface, examples like the Business Source License, the Cockroach Community License, the Commons Clause, the Confluent Community License, the Fair Source License, the TimeScale license or the SSPL would seem to have little in common. Some have ambitions to be considered open source, some do not but invoke open source-like terminology, and some are unambiguously and unapologetically proprietary. Some merely require contributions back copyleft-style, some prohibit usage within prescribed business models (read: cloud) and others restrict business usage without distinction. And so on; while typically rolled up and discussed as a category, they are no more unified in their intent and purpose than open source licenses broadly.
The obvious differences notwithstanding, there is one important assumption upon which each of these licenses rests: that source code is inherently valuable in the commercial sense and therefore worth protecting. This is, of course, a decades old assumption that has led to the creation of the software industry as we know it today. It’s the core assumption behind the success of Microsoft’s Office and Windows franchises, Oracle’s database business and other immense revenue engines.
It is an assumption, however, that is facing increasing challenges.
As has been noted both briefly and at greater length, realizable revenue from traditional software models have been in decline for some time. This doesn’t mean that software can’t be a good business, but it does mean that it’s a more difficult business to execute in and that the returns will be lower than in the past.
One of the major challenges for traditional commercial software businesses, of course, has been the rise of open source. Open source is difficult to monetize but arguably harder to compete with, leaving commercial software authors facing the less than encouraging outlook described by Mike Olson in 2013: “You can no longer win with a closed-source platform, and you can’t build a successful stand-alone company purely on open source.”
This reality led initially to models that attempted to combine open and closed source business models – an approach commonly referred to as open core. It has also more recently led, perhaps inevitably, to the deliberate and ongoing blurring of the lines between open and closed source software manifested in the licenses mentioned above. In an attempt to protect – and thereby monetize – their source code, commercial authors are turning to licenses as a strategy.
This approach is problematic for many reasons, as has been discussed previously. But one of the more important concerns that original foundational assumption about the value of the source code. More specifically, what is the value of the code versus the API it creates?
In a piece entitled “Why your next open source project may only be an interface,” Eric Anderson argues:
With cloud offerings on the rise and the rate of complexity and innovation increasing, we are likely to see more open interfaces and metaframeworks emerge.
His primary examples are projects such as Apache Beam in the data processing space, which can serve as an interface for commercial products like Google Cloud Dataflow/IBM Stream or open source data engines such as Flink, Spark or Hadoop, and Keras in the AI category, which can front CNTK, MXNet and Tensorflow among others. These examples are notable because they were purpose-built as meta-interfaces – like the largely forgotten Delta Cloud, and to a lesser extent because they came out of Google in a similar timeframe.
But the question of API importance extends well beyond interfaces originally intended to abstract multiple underlying implementations. With the accelerating appetite for managed services in the cloud, APIs are becoming the new de facto standards much as open source was before it. All of the major cloud providers, for example, include MySQL and PostgreSQL offerings – but behind the scenes, their implementations may differ. Aurora, for example, is MySQL and PostgreSQL compatible, but the underlying implementation is Amazon-only. Google’s Cloud Memorystore exposes a Redis API, but is presumably not vanilla Redis. And most recently, MongoDB saw its API replicated by Amazon with the release of DocumentDB, which follows in the footsteps of Microsoft’s Cosmos DB. Both purport to offer MongoDB compatibility, neither are – it is assumed – based on MongoDB’s code.
All of which suggests three things.
First, that APIs are increasingly of greater importance than the code that instantiates them. Whether the interface is built for the purposes of being a standard or becomes one accidentally, in cloud environments moving forward decisions are more likely to be made on the basis of API compatibility and other ancillary factors such as networking and storage costs than on the quality of the underlying implementation.
Second, that as such all of the complicated machinations over source code and licensing may miss the point and be protecting the wrong asset. For all of the focus from commercial open source organizations on protecting particular features or capabilities – in a market in which “many can likely replicate others’ software in, at most, 1–2 years” – comparatively little attention has been paid to the interface to that software.
Lastly, this suggests, as Professor at Stanford Law School Mark Lemley has said, that calling the Google vs Oracle a copyright case of the decade understates its importance. If you believe that APIs are the new standards, nothing less than the future of the industry is at stake.
Disclosure: Amazon, Google, IBM, Microsoft, MongoDB, and Oracle are RedMonk clients.
