Salil Deshpande
More posts from Salil Deshpande
Amazon’s behavior toward open source combined with lack of leadership from industry associations such as the Open Source Initiative (OSI) will stifle open-source innovation and make commercial open source less viable.
The result will be more software becoming proprietary and closed-source to protect itself against AWS, widespread license proliferation (a dozen companies changed their licenses in 2018) and open-source licenses giving way to a new category of licenses, called source-available licenses.
Don’t get me wrong — there will still be open source, lots and lots of it. But authors of open-source infrastructure software will put their interesting features in their “enterprise” versions if we as an industry cannot solve the Amazon problem.
Unfortunately, the dark cloud on the horizon I wrote about back in November has drifted closer. Amazon has exhibited three particularly offensive and aggressive behaviors toward open source:
- It takes open-source code produced by others, runs it as a commercial service and gives nothing back to the commercial entity that produces and maintains the open source, thereby intercepting the monetization of the open source.
- It forks projects and forcibly wrestles control away from the commercial entity that produces and maintains the open-source projects, as it did in the case of Elasticsearch.
- It hijacks open-source APIs and places them on top of its own proprietary solutions, thereby siphoning off customers from the open-source project to its own proprietary solution, as it did with the MongoDB APIs.
Amazon’s behavior toward open source is self-interested and rational. Amazon is playing by the rules of what software licenses allow. But these behaviors and their undesirable results could be curbed if industry associations created standard open-source licenses that allowed authors of open-source software to express a simple concept:
“I do not want my open-source code run as a commercial service.”
Leadership often comes from unexpected sources.
But the OSI, an organization that opines on the open-sourceness of licenses, is an ineffective wonk tank that refuses to acknowledge the problem and insists that unless Amazon has the “freedom” to take your code, run it as a commercial service and give nothing back to you, your code is not “open source.” The OSI believes it owns the definition of open source and refuses to update the definition of open source, which is short-sighted and dangerous.
To illustrate: The Server Side Public License (SSPL) — the license proposal spearheaded by MongoDB — was patterned exactly after the Gnu General Public License (GPL) and the Affero General Public License (AGPL). SSPL is a perfectly serviceable open-source license, and like GPL and AGPL, rather than prohibit software from being run as a service, SSPL requires that you open-source all programs that you use to make the software available as a service.
A months-long comical debate ensued after SSPL was proposed as an open-source license candidate to OSI, after which OSI made its premeditated opinion official, that SSPL is not an open-source license, even though GPL and AGPL are open source. In its myopia, the OSI forgot to be consistent: If SSPL is not open source, then GPL and AGPL should not be either. MongoDB will continue to use SSPL anyway, but it just won’t be called “open source” because OSI says that it owns the definition of “open source” and it can’t be called that. Great.
Source-available licenses
Is it inevitable that the combination of Amazon’s behavior and this lack of industry leadership will stifle open-source innovation and make commercial open source less viable? Should we just live with either more software becoming proprietary and closed-source to protect itself against AWS, or with widespread license proliferation?
We’ve already seen plenty of license proliferation. MongoDB SSPL, Confluent Community License (CCL), Timescale License (TSL), Redis Source Available License (RSAL), Neo4J Commons Clause, Cockroach Community License (CCL), Dgraph (now using Cockroach Community License), Elastic License, Sourcegraph Fair SourceLicense, MariaDB Business Source License (BSL)… and many more.
The trend is toward “source-available” licensing rather than “open-source” licensing because source-available licenses, uncontaminated by the myopia of open source industry associations, do not require that Amazon have the “freedom” to take your code, run it as a commercial service and give nothing back to you.
To that end, a group of open-source lawyers led by Heather Meeker, a respected and undisputed leader on technology and open-source law who worked on both Commons Clause and SSPL, will soon open a suite of “source-available” licenses for community comment.
The suite of source-available licenses is expected to provide authors of open-source software with a number of methods to address the growing threat from cloud infrastructure providers. The suite will provide short plain-language source-available licenses; standardize patterns in recently adopted source-available licenses; and allow users and companies to mix and match limitations you want to impose (e.g. non-commercial use only, or value add only, or no SaaS use, or whatever else). I believe these frameworks will be a smart alternative to open source, as the OSI refuses to provide leadership in solving the Amazon problem.
AWS and anti-competitive behavior
More broadly, it is clear to most industry observers that AWS is using its market power to be anti-competitive. Unless something changes, calls for anti-trust action against both Amazon and AWS are inevitable, even if AWS is divested from Amazon. That issue is broader than just open source.
Amazon’s behavior toward open source is self-interested and rational.
Within open source, if Amazon isn’t breaking any laws today, then licenses to prevent or curb their behavior are critical. And lack of leadership from the open-source industry associations that squat on the term “open source” means that source-available licenses are the most viable solution to curb such behavior. It doesn’t have to be this way.
Leadership often comes from unexpected sources. There are promising signs that other cloud infrastructure providers are becoming true allies to the open-source community. Take Google, for example. The major announcements at Google Cloud Next in April 2019 were dramatic and encouraging. The company announced partnerships with Confluent, DataStax, Elastic, InfluxData, MongoDB, Neo4j and Redis Labs — companies most affected by Amazon’s behavior.
Google Cloud’s new CEO Thomas Kurian’s remarks echoed what I had been saying for the last year.
Frederic Lardinois of TechCrunch wrote:
Google is taking a very different approach to open source than some of its competitors, and especially AWS. … “The most important thing is that we believe that the platforms that win in the end are those that enable rather than destroy ecosystems. We really fundamentally believe that,” [Kurian] told me. “Any platform that wins in the end is always about fostering rather than shutting down an ecosystem. If you look at open-source companies, we think they work hard to build technology and enable developers to use it.”
It’s smart for Google to align with these commercial open-source players — AWS is beating Google in the cloud wars and giving best-of-breed commercial open-source products first-class status on Google’s cloud will help Google win more enterprise customers.
Perhaps more importantly, the stance and language on how ecosystems thrive is incredibly encouraging.
Disclosures: The author has invested in numerous open companies affected by the behavior of cloud infrastructure providers, indirectly owns shares of Amazon and, apart from any abuse of open source or anti-competitive behavior, is a big fan of Amazon.
Comment