Quo Vadis Open Source Databases?

How open source license models might look in the future.

In the past few months, some open source software vendors in the database sector have decided to change their licensing policy and to introduce partly new but also more restrictive open source licensing models.

In this article, the background of these changes and the options for action of the participants will be examined using the examples of MongoDB, Redis and Neo4j. In addition, the extent to which the changes made are in line with the principles of the open source movement will be discussed.

License models

The aforementioned OSS database providers MongoDB, Redis and Neo4j made license changes from AGPLv3 to other license models in the course of 2018. In the current version these are now as follows:

• MongoDB Community Server: Complete change from AGPLv3 to SSPL (Server Side Public License = own variant of GPLv3) for all patch releases and versions from 16.10.2018. It is unclear and legally controversial whether the SSPL is still an OSS licence in so far as it requires disclosure of the additional tools of the cloud providers as a licence condition (paragraph 13). MongoDB has submitted a corresponding request to the OSI.
• Neo4j Enterprise Edition: Two-level switch from AGPLv3 to an open-core model. First change from AGPLv3 to AGPLv3 with Commons Clause. The latter is a commercial license which was initially offered in parallel (so-called "dual license" model). As of Neo4j 3.5, the entire source code is no longer public as before. All extensions that are part of the Enterprise version are no longer available on GitHub. Consequently, Neo4j 3.5 Enterprise is only available as a binary version under a commercial version. The Community Edition as the functional core is still available under GPLv3. This combination represents the so-called "open core" model with a distinction between open core and undisclosed source code for extensions.
• Redis Enterprise Add-ons: Change for some Enterprise Add-ons, like ReJSON, RediSearch and Redis Graph from APGLv3 to a combination of Apache Licence 2.0 with Commons Clause. Assuming that the Commons Clause is a non-open-source-compliant license condition, the result is an open core model in the variant of a fully disclosed source code.

Even though the OSS database providers have gone different ways, the problem they have to solve is the same. The OSS database providers see themselves and their commercial interests increasingly threatened by both the violation of rather implicit principles of Gift economy, as well as explicitly agreed licensing conditions within the open source communities by the increasing number and importance of the various cloud providers.

Role of Cloud Providers

Not only classic cloud providers, but also increasingly providers of serverless computing such as Tencent, Alibaba or Amazon, provide OSS databases as commercially oriented "as-a-service" services. They leave the database itself unchanged in order not to violate its license conditions.

However, they supplement these with powerful administration software, user interfaces and simplified APIs. This ranges up to the provision of DB abstraction layers, which sometimes represents a considerable added value compared to the pure database. Since these additional services are generally available without direct additional costs and embedded in other offers from cloud providers, they are gladly accepted, even if the database manufacturer's offers (which are subject to costs and licensing) are more extensive and of better quality.

As a consequence, cloud providers, as direct competitors, endanger one of the central monetization strategies of open source vendors: from the possibility of establishing their own customer relationships with OSS users and offering these users additional services such as installation, configuration or support in connection with OS software to customer-specific software development.

The OSS database manufacturers thus on the one hand enhance the entire range of services offered by cloud providers, but on the other hand are increasingly being undermined both as an independent product and with regard to their database-specific, complex features - they are becoming a partially invisible, exchangeable preliminary product. As a result, differentiation through independent product offerings with a more sophisticated range of functions as well as specialized service offerings tailored to the products become more difficult to perceive.

At the same time, individual customer problems in connection with the use of databases that could previously often be solved for a fee by the OSS database vendors themselves are eliminated. Even if the original manufacturers can implement this much higher complexity in the package (high availability, performance monitoring, load distribution, memory optimization, individual development, troubleshooting, scaling, etc.), the cloud providers are increasingly at an advantage due to their position in the value chain, their distribution, their pricing structure and their market power and can position themselves as direct competitors. Not to mention the fact that they are increasingly launching and aggressively marketing their own products.

This is a particular problem for small and medium-sized enterprises: Their services are marginalized by the massive scalability of cloud providers. The large providers are able to automate many functionalities and offer them as inclusive services at no additional cost. In this way, monetization potential for small and medium-sized providers of services in the cloud environment disappears without a return.

Is everything lost?

In the opinion of the open source database vendors, the cloud providers are violating basic rules of use of OSS, without which the open source universe cannot function. It is a fact that cloud providers do not reimburse or compensate the manufacturer community (here predominantly small or medium-sized enterprises) (so-called "contribution") in the form of contributions to the source code. In addition, there is no financial contribution, e.g. in the form of a revenue or market share in the revenues generated directly or indirectly by the cloud providers with the databases involved.

The OSS database providers did not feel sufficiently protected against such a violation of the rules of the game by the license models used so far. These did not ensure that the additional tools developed by the cloud providers had to be made available to the database provider again in the form of disclosed source code, nor could this form of commercialisation be prevented by the cloud providers.

The AGPLv3 explicitly deals with the provision of software as SaaS / ASP / Hosting ("...interacting with it remotely through a computer network..."), but it is only regulated here that these forms of provision also represent a case of the distribution of software. A statement as to whether, in the case of the use of additional tools by cloud providers, a "copy-left"-relevant connection of the additional tools with the database software is always mandatory (i.e. as a derived work or as a "modified version") cannot be found in the AGPL and must therefore be difficult to prove in individual cases. Moreover, even the existence of 'copy-left' would not lead to the desired shift of market shares in favour of open source database providers, due to the absolute dominance of cloud providers in the access markets.

It can be assumed that users would probably continue to use the database offerings of the cloud providers. The almost sole commercialisation of the software by the cloud providers would therefore not be prevented.

Possible solutions?

So what can you do to survive against the cloud providers in the long run? The chosen solution variants of the database providers differ from each other, especially in the scope of the source code affected by the license change (from parts to the entire source code) and the objective pursued with the license change (disclosure of the source code of DB add-on tools of the cloud providers up to the comprehensive prohibition of commercialization).

However, it is common to all variants that the distinguishing feature "OSS" as a strong brand component is not abandoned and the licence changes are intended to strengthen the OSS movement.

This is how MongoDB, particularly by means of Section 13 of its SSPL (Server Side Public License), aims at the return ("contribution") of source code to the community:

All companies offering MongoDB as a service are obliged to provide the additional tools used to offer the service (administration software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software) in such a way that a "user can execute an instance of the service with the source code provided".

Redis, on the other hand, wants to prevent commercialization by cloud providers at all: Redis uses the so-called Commons Clause (in conjunction with an Apache license) for its enterprise add-ons, which explicitly prohibits the sale of the affected add-ons by third parties if they are products / services of the third party, the value of which results in whole or in part from the functionality of the Redis software itself. Sale here means both provision for a fee and other consideration ("...including and without limitation, hosting fees...").

Of course, objections can be raised for each of the license changes made with regard to their "OSS purity" and compliance with the pure doctrine:

Is MongoDB's SSPL actually a violation of "Freedom 0" of the Free Software Foundation (FSF) because it may restrict the execution of the software for a particular purpose?

Or is it only a secondary condition for its execution (according to MongoDB and the author of this article)?

Is the Common Clause at any time and in any conceivable situation incompatible with OSS principles? Does the entire source code of a product always have to be published or is the software core of the product sufficient for this?

Some Linux distributions like Debian and Red Hat have at least in the case of MongoDB already decided the question of OSS purity for themselves and removed MongoDB from the distributions. Whether the draft of an SSPLv2 submitted by MongoDB will change the acceptance on the part of OSI and the distributions something is currently open.

However, if the discussion is not to be conducted solely for academic purposes, it seems more important to keep the following aspect in mind when evaluating license changes and their possible adaptation to drug-economic implications:

The rules of the game of OSS projects are put to the test more intensively by the cloud providers' actions and the survival of OSS companies is endangered more lastingly than by the described "cautious" license changes. At any rate, it is currently not clear that cloud providers actually have a vital interest in (OSS database) upstream suppliers who do not position themselves as a purely altruistic OSS community (and thus "community-driven"), but also as companies / "competitors".

In particular Amazon demonstrates what the future could look like: MongoDB is forged in the form of Amazon DocumentDB on the basis of an older version, whereby missing DB features are rebuilt at short notice and made available in the unchanged end customer relationship.

In view of this, the current license adjustments of Neo4j appear to be moderate, withdrawing parts of the software from the cloud providers' access. In our opinion, Neo4j has chosen the most appropriate, unambiguous and thus the easiest way to communicate the situation to the user, which we at Structr are happy to follow.