Earlier this year, Elastic reignited the open-source licensing debate when it announced it would be changing its license model to better protect its open-source code. 

Over the last couple of years, a number of companies have been switching their open-source licenses to avoid what they call “the big code robbery,” where cloud providers like Amazon take their successful open-source project, adopt and profit off it as a cloud service without giving back to the community.  CloudBees’ co-founder and chief strategy officer Sacha Labourey commented:

“Cloud vendors do not care about monetizing FOSS projects, they are about getting more workloads running on their infrastructure — hence, to be the preferred destination for such workloads.”

Confluent created a new community license, and MongoDB announced its Server Side Public License to combat cloud providers. In January, Elastic announced it would move its Kibana and Elasticsearch open-source projects to a dual license under the Elastic License v2 and SSPL. However, these new licenses that companies are switching to are not considered open source by the Open Source Initiative’s standard, leaving many in the industry to wonder where these companies now stand with open source.

According to Stephen O’Grady, principal analyst and co-founder of the developer analyst firm RedMonk, while it can be upsetting, the cloud providers are not actually abusing open-source projects if they are still abiding by the rules of the open-source license.

MongoDB argues that under SPPL, developers are still able to access, use, modify and redistribute its code. Dev Ittycheria, CEO and president of MongoDB, noted:

“We adopted the SSPL license to protect our right to build an innovative business in the Cloud era. We wanted to counter the threat of hyperscale cloud vendors taking our free product and offering it as a service without giving anything back.”

Tomer Levy, CEO of Logz.io, a cloud observability platform provider, argues that changing licenses shake the entire foundation of the open-source philosophy and shows that those in control of popular projects have the ability to take these projects away from the community at any time. He added:

“We were disappointed to hear about Elastic’s decision to change to a license which is not truly open source. This is a slap in the face to the engineers that helped build the community and make open-source software the staple that it is today.”

Elastic made the decision to no longer refer to Elasticsearch or Kibana as open-source and instead refer to the project’s as free and open. The company explained:

“While we have chosen to avoid confusion by not using the term open source to refer to these products, we will continue to use the word ‘Open’ and ‘Free and Open.’ These are simple ways to describe the fact that the product is free to use, the source code is available, and also applies to our open and collaborative engagement model in GitHub. We remain committed to the principles of open-source — transparency, collaboration, and community.”

Some ways to combat the cloud providers, other than changing your software licensing model, is to form innovative partnerships with the cloud vendor so there’s a window where they can’t just steal your functionality and hopefully, during that window, the project innovates and moves past the threat.

Drupal’s Bryon thinks creating a form of Creative Commons for open source could help categorize open-source projects into projects that are free to use, projects that require attribution and so on and so forth. She also suggested creating social pressures on these companies to do better.

Additionally, New Relic recently contributed Pixie, the open-source project for Kubernetes-native observability, to the Cloud Native Computing Foundation, and expanded its relationship with Amazon to run Pixie on AWS.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Nikoleta Yanakieva Editor at DevStyleR International