Introduction
Open Source Software (OSS) is everywhere and has become indispensable for modern software development. Open Source is driven by communities: the projects, which make their source code freely available, are either kept alive by individual developers, or supported by a broad community, or managed by individual companies as a business model. Even in case of a larger project community, some projects are mainly funded and maintained by commercial organizations.
Open Source does not mean that the use of the code is allowed without any restriction: The use is subject to conditions which are formulated by the author (copyright holder) in a form of license. The most business permissive form of usage is called Public Domain – this is when the author of the software gives away the copyright as well as any other legal restrictions and makes it belong to the public. The first BITKOM guide on Open Source Software gives the following clarification about usage of Open Source: “Usage, duplication and processing are not permitted without conditions, because in the case of open source software the granting of rights of use is often made dependent on certain conditions…”.
When commercial organizations Open Source their code, this is usually driven by business reasons rather than altruistic behavior. For example: to increase the market footprint by simplifying access to software, to sell additional services, or to upsell additional features only available in commercial version of the software.
What happened?
Recently, we have observed some Open Source projects maintained by commercial companies have changed their license conditions from a rather business friendly i.e. with very few (if any) obligations, to a more restrictive licenses in newer versions of the software. Elastic (a real-time search server based on Apache Licene), Redis (an in-memory database), MongoDB (database) or Grafana (graphical representation of data) should be mentioned here. All of them adapted their licensing models to more restrictive licenses. The reasons for that appear to be similar: to force current users, especially non-paying businesses to purchase commercial licenses of those OSS products.
Why the change?
fair question you may ask is “why didn’t those owner companies have allowed the use of business-friendly licenses on the first place?” There are several reasons for that. Number one is that most of the projects they own were started by private individuals and making money for these was not the main purpose why they created those projects. The second reason is adoption – if OSS licenses were too restrictive it would be harder to convince developers to use the software in their code. Finally, it was not until late 2020’s when enterprise software started to heavily migrate into the cloud and hence most licenses from earlier times did not have covenants regulating the use via network or as software as a service.
Even today the vast majority of OSS licenses are not putting any significant restrictions on the use of software in a cloud, however it is pretty clear that today most applications are running as services and can greatly benefit from the software under those older licenses.
In addition to the commercial reasons there is one more important aspect – free to use OSS did not motivate companies to contribute back to the OSS they were using, and hence they had become free riders on a train where some passengers paid a lot and some paid nothing at all neglecting the basic principle of Open Source is based on mutual exchange. In it’s statement, Redis said, “Cloud vendors contribute very little (if anything) to such Open Source projects. In contrast, they would generate hundreds of millions of dollars in revenue from them, causing harm to the Open-Source community and even driving some companies out of the market.”
Redis had first switched some modules to a Common Clauses licensing model, but a short time later the company introduced the Redis Source Available License (RSAL). MongoDB also decided to switch to the Server Side Public License (SSPL). Elastic also moved from the Apache 2 to the SSPL.
What are the implications for end users?
These changes have generated a lot of friction between existing users of the software and current OSS maintainers. In case of Redis the main reason for the stir was that Redis disallowed commercial distribution of the software using Redis even it was created by a third party through this license change. In other words if your cloud provider allowed you to use Redis and you have built your application around it, after that license change you were now required to pay Redis for the commercial use of their software.
What do other OSS vendors who made the change say?
Another reason for a license change is provided by Grafana, which switched from Apache to the AGPL: According to the company, the license change is intended to ensure fair use of the Open Source software. The AGPL still allows the free use and further development of the product. Compared to the GPL, it closes the so-called ASP loophole, through which companies would not have to release the source code for purely hosted versions of the software.
Anaconda also recently introduced a commercial license for those users who use the software “very intensively”. This refers to those users who mirror the repository on a large scale or whose CI/CD and deployment systems regularly makes thousands of package download requests to the repository. Anaconda Co-founder Peter Wang said: “At this point, Anaconda alone is bearing the costs of packaging, testing, and monthly bandwidth costs in the petabyte range. I trust that our commercial users understand that it is no longer reasonable for us to offer this service at zero cost.”
What should you do and what you should pay attention to?
What are the implications of this for you as the user of Open Source software? When selecting an Open Source package, we recommend paying attention to not only richness of functional perimeter, and how actively it is maintained (A good metric is average commits per month and average time to remediation of issues filed by users). Also, what is the community which is maintaining the project. If an Open Source project depends on only one or a few developers, or is mainly driven by a single company, the risk of an unexpected license change with some effects on your business interests is much higher than if a broad community supports the project.
Another good way to assess if a project is a good fit for your business is to evaluate if you or your company can get involved in the community and actively support those projects that are relevant to you, thus trying to secure a certain influence on the project.