Is AWS Turning Open Source into Proprietary? The Open Distro and SSPL Debate

Two months ago AWS launched Open Distro for Elasticsearch, claiming it is an enhanced distribution of Elasticsearch and not a fork, and that they will continue contributing upstream.

Nevertheless, many view AWS's move as a split of Elasticsearch and of open source itself.

Critics argue that Amazon's approach to open source, combined with the lack of leadership from industry bodies such as the OSI, stifles innovation and makes commercializing open source less viable.

This leads to more open‑source projects becoming proprietary or “source‑available” as companies resist AWS‑style “predation” (dozens of firms changed their licenses in 2018) or switch to licenses like SSPL.

The shift to closed source mainly concerns infrastructure software. If cloud providers and open‑source projects cannot resolve the “giving back” issue, open‑source vendors may reserve richer features for enterprise editions.

Examples of what critics call Amazon’s aggressive open‑source behavior include:

Using open‑source projects as commercial services without rewarding the entities that created and maintain them, hindering project development.

Forking open‑source projects and forcibly steering them away from their original maintainers, as with Elasticsearch.

Hijacking open‑source APIs and placing them under proprietary solutions, exemplified by AWS’s Document database that is compatible with MongoDB’s API to bypass its new license.

From Amazon’s perspective these actions are permissible under existing licenses and may even be optimal, but many believe new open‑source license standards are needed to balance the interests of authors and vendors.

One quoted concern is “not wanting one’s open‑source code to run as a commercial service.”

When MongoDB submitted its Server Side Public License (SSPL) to the OSI, the community questioned whether SSPL violates the essence of open source, because open source’s value lies in allowing anyone to use the software within the license terms.

The SSPL requires cloud providers hosting MongoDB instances to either obtain a commercial license from MongoDB or open‑source their service‑side code.

MongoDB maintains that SSPL meets open‑source approval criteria.

If industry bodies do not recognize such licenses, vendors may resort to changing licensing models or even closing their software.

Without constraints on the “abuse” of open source, contributors, users, and the market could suffer significant harm.