Last week, yet another company — HashiCorp — announced they are changing the license for the majority of their software from an Open Source License (Mozilla Public License 2.0) to a Business Source License (BSL).
It is worth noting that, unlike licenses like GPL or even SSPL, BSL is not a specific license but more of a template, allowing for some wording to change. The HashiCorp variant specifies this as an “Additional Use Grant.” From HashiCorp’s website:
“You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp’s products.”
One thing you’ve got to give to HashiCorp is that they are very honest and clear about their intentions. They want to prevent any potential competition, both in terms of hosted delivery or from otherwise embedding it within a product.
I think this license change by Hashicorp is particularly important as, unlike MongoDB, which was seen as a “Reluctant Open Source Company” even before it went through with its license change, HashiCorp was one of the best examples of a commercially successful company that found a balance between its interests as a business and the interests of the community as a whole.
Yet, with profitability still elusive, there is no surprise that business interests in preventing competition and maximizing revenue won.
As we can see, some companies are already discussing the potential results of this fallout. Some HashiCorp competitors are making sure to showcase their OSS License as a competitive advantage, with developers and DevOps teams concerned about the change. There is even a fork of Terraform, though, at this point, this looks more like an individual initiative rather than more broad industry action, which happened in similar circumstances with OpenSearch.
There is another interesting quote in the HashiCorp Announcement:
“With this change we are following a path similar to other companies in recent years. These companies include Couchbase, Cockroach Labs, Sentry, and MariaDB, which developed this license in 2013. Companies including Confluent, MongoDB, Elastic, Redis Labs, and others have also adopted alternative licenses that include restrictions on commercial usage. In all these cases, the license enables the commercial sponsor to have more control around commercialization.”
What they basically claim is that changing licenses away from open source is an industry trend, if not the standard for public and venture-funded companies, and they have chosen to just go along with it. This may well be true, but as analysis shows, the community sees it as a hostile step.
Polarization
While HashiCorp and other companies in this group tend to proclaim this decision as the “new normal” for open source, and many even claim it makes things better for their community and customers, it is only one of the open paths.
Indeed, you should probably expect that if open source software is owned by a large, for-profit company, the company will work in the interest of its shareholders to maximize profitability and company value. A fully open source license, which is largely pro-consumer and aims to “level the playing field” for everyone, makes it easy for competition to enter the market. This is not aligned with maximizing profit.
In the early days, many commercial open source companies liked to play the “open source game” because it helps adoption, speeds up community formation, attracts contributions, etc. However, once market dominance is achieved, growing monetization becomes a priority for these companies, and the “Commitment to open source” goes out of the window.
Commercial open source is going to continue being less open source. Other companies will see the community response to HashiCorp and see more support for them as a business, compared to how previous companies saw huge volumes of negative responses and very little support. They may be tempted to try the same approach to capture market value and stop supporting open source earlier.
This is not the only path, though. We see a lot of very successful “non-commercial” open source projects as well. Take a look at the Apache Software Foundation and some of the most successful open source projects of the last few decades — Linux, PostgreSQL, Kubernetes. These projects are all driven by a non-commercial entity that acts in the interest of the industry and community as a whole rather than a single company.
What is interesting is the companies that take the most commercial value from those projects have changed over time. If you look at Linux, for example, commercial distribution vendors like RedHat captured most of the value in the early days. Now, much more value is captured by cloud vendors building their offerings on Linux.
Where for commercial open source, we see companies taking that protectionist path and adopting a non-open source, anti-competitive path, we see the opposite taking place in the “non-commercial” open source area. Permissive licenses that allow free embedding even in commercial software are on the rise, while copyleft licenses, which try to force open source, are in decline.
I expect this trend to continue with even more polarization in the coming years.
Project vs. Product
When we speak about non-commercial open source, it is important to understand the difference between Product vs Project. When it comes to non-commercial open source, the software you tend to get through those entities comes “as is with no warranty.” Similarly, these projects do not tend to have any commercial support with SLA available from that foundation. If you look at PostgreSQL, for example, you will see some options for community support “for community by community,” as well as ways to report bugs and security issues. If you’re looking for commercial support, you can pick one of many independent commercial companies. Percona is one of the companies which provide PostgreSQL support and professional services, but others are local to specific countries or regions, and others that support their own flavor of PostgreSQL.
As such, the PostgreSQL Organization is focused on the PostgreSQL Project, while many companies in the ecosystem can offer you commercial products around PostgreSQL. They can be either service based (i.e., training how to use PostgreSQL more effectively) or product based, with software derived from PostgreSQL: AWS RDS, EDB Postgres Advanced Server, Timescale, or Percona’s own Percona Distribution for PostgreSQL. This is better for customers as they can pick the company that best suits them rather than being tied to that specific provider, whether they like it or not.
You can find even more interesting setups with Linux, where you have a variety of commercial (i.e., RedHat Enterprise Linux) distributions aimed at businesses and noncommercial (i.e., Debian) distributions which end users tend to use.
As a contributing developer, you are more likely to be interested in how the Project is governed and what contribution policies it has, so you are more likely to be interested in Debian If you’re at a user organization, especially when you are running software in mission-critical environments, it is the Product that you’re likely to be interested in.
This is where the restriction of non-competitive licenses tends to come into play. Vendors want to ensure that if you’re going to seriously use a product and require commercial relationships, they are going to be the only choice. Instead of you having freedom from vendor lock-in, they want to ensure you are in a “Hostage Customer” situation. For all the discussion about open source preventing lock-in, these companies want to create that situation when it is to their advantage.
Terminology
One issue we have in the open source space is terminology. Because no one really “owns” the term “open source,” it can be casually used in reference to just about everything rather than only relating to software strictly following the Open Source Definition. Today, an increasing number of new-generation developers do not understand the difference between “real” open source providing all the values you would expect versus faux-open source, which is referred to as ’open source’ but does not really fit the definition.
You also have some “advocates” claiming that the original open source definition does not really matter anymore and that we should all just adopt the newer loose definition instead.
Embracing this approach with a new open source definition allows companies to have their cake and eat it too. This approach is loved by many commercial open source companies (especially those that have abandoned their Open Source Licenses) as it allows them to promote a disingenuous message that there is no real difference for a user between real open source and faux-open source licensed software. They can look to get all of the benefits of community, faster adoption, and scaling their projects into products with the help of contributors without returning as much of that value back to the community in the first place.
Open Source Initiative (OSI)
In my opinion, the Open Source Initiative has been way too passive in the last twelve months, allowing this redefinition to happen in the heads of the new generation. Where the OSI “defines” open source, they have no “teeth” in ensuring this definition is observed in practice and that any bad practice is called out. As a non-profit with a lot fewer resources or PR teams compared to those large public and venture-funded companies, they can hardly win this as an information war alone.
It would be great for OSI to recognize this polarization and set out to help the community as a whole. By this, I mean we should not only define open source but also “open source pretenders” and help unite the community regarding terminology. I also believe OSI should emphasize some form of certification, helping users understand which open source software is for real and which is not. Rather than just decrying those that misuse the term open source, we have to support and celebrate those following the definition’s letter.
Open source is not for everyone
Back in the 1990s, proprietary software was the dominant model, and open source software was for small groups of us who wanted something different in the relationship between vendor and user. Today, open source is the mainstream, but we have discovered that many open source users do not really care about open source values but only about convenience and not so much about its license, as Matt Asay notices in his article. It is true that many developers do not care about open source — they never really did — yet we should not yield to those folks to redefine something they do not care about nor understand as yet.
The challenge for open source is that many developers have not gone through the problems others faced. They have been used to the flexibility and control that open source provides them. The result is that it is too easy to overlook some of the value that open source has provided in the past and assume that it will always be there. As all the license changes we have seen have shown, this is not true. The one caveat here is that new companies will come along and use open source as their approach in order to compete against those that now have closed licenses. To avoid any problems here, the answer is to use your own judgment and not follow the herd.
What you can do
As this open source polarization continues, I would encourage you to pay close attention to the projects that choose to call themselves “open source” and what it actually means. Whether a truly important open source license is important for you or not is your choice, but be sure to make decisions with open eyes. If open source is important to you, consider software governed by a non-profit organization, where you have multiple commercial vendors you can pick. You should also consider giving back — whether it is your time or your money. While open source software is wonderful in providing tremendous value in allowing permissionless innovation, it is not immune to the freeloader problem – there will always be some that take more than they give back.
The more that individuals and businesses choose to contribute to open source fairly, there will be less temptation to abandon open source and adopt non-open source licenses. If we don’t understand what is taking place, then we run the risk of open source being unsustainable and making things more difficult for us all.
