Over the last few years, many Commercial Open Source Companies have changed their licenses for some of their software projects from Open Source to some form of non-competitive Source Available License. The most recent example is HashiCorp adopting the Business Source License (BSL) for a wide variety of its software tools, instead of the Open Source Mozilla Public License 2.0 (MPL 2.0) that it previously used.
While companies like HashiCorp are within their legal rights to make this kind of change, it very much goes against the principles of Open Source around Collaboration. The principles are pretty much like this:
Contributors help projects to succeed by contributing code, helping to test software, writing documentation, manning forums and otherwise providing “community support,” as well as giving back by spreading the word about the project. In return, they have free (as in beer) access to the software they helped to create.
You may notice this is especially important in the early stage of the product, where an individual founder or small company has very little resources to achieve traction without that community help. As the company grows and becomes successful, two things happen. First it reaches a saturation point. For example, how many people in the addressable market are not aware of Terraform today? This tool is ubiquitous for Infrastructure as Code and managing cloud resources, in large part due to the fact that it was open source. Second, the company has the money to buy many of those things contributors provided.This means not just development for the project, which engineers like to focus on, but also all the rest of things the community would provide.
When “Community Love” gets devalued like this, and your Sales team and Shareholders are complaining how you’re losing the deals to your “competition”, how do you think about your principles around Open Source? Are you going to stick to such a silly thing as staying with an Open Source License, when so many of your compatriots are also making that shift from Open to Closed approaches? What else would you expect?
I expect this will continue to happen as more Open Source companies face challenges to pay back their investors. However, there is one element that has not been considered here - the code provided by the community contributors and how this is handled over time. This is a topic where some companies have put a lot of time and thought, and where others have not planned ahead.
Contributor Protection
As a contributor to an Open Source project, you want to improve what is in front of you. However, why should you offer your time and your code if someone can take that work and re-badge it under ‘their’ license in the future. You will likely wonder how you ensure your interests are protected. At the very least, I assume you will want to understand the risks of you no longer having real access to something you helped to create.
To break this down, you need to think about Ownership and Governance of the following items: Source Code, Data and Related assets required for software operation, Trademarks, and Software and Information Distribution channels.
Ownership and Governance
Ownership and Governance is about who owns the Intellectual Property (IP), including your contributions. Typically, Non-Profit organizations or Public Domain bodies (
It is also important to look at what happens if something unforeseen takes place. For example, what happens when the corporation gets into trouble? Founders and CEOs may make promises, but these can be unreliable as businesses can be bought or go through bankruptcy. Similarly, Founders and CEOs can step down or be forced out. In the case of Non-Profit ownership, Governance becomes critical as this is how you ensure the organization really acts in a way that is aligned with contributor interests. I would specifically consider how the Board operates at any organization, particularly Non Profit ones. Questions to ask include, Are board members elected? By whom? How do we ensure that commercial entities do not achieve dominance and end up guiding the projects to protect their commercial interests, rather than serving the interests of the project community as a whole?
I think the
Source Code and Beyond
One common argument for changing licenses around Commercial Open Source projects is that the vast majority of contributions come from one vendor, so that one vendor changing the license does not make much difference. Indeed, some companies claim that it was all their own effort, so the community should not have a say in what takes place. However, this is rarely the case in practice. Even projects that are majority supported by one vendor will have contributions from other providers in them, particularly when they come from customers using a project that need specific support and are willing to provide that code too. A vendor is much more likely to accept change requests when it is a customer that is providing the code.
Alongside this, when a vendor is providing the majority of the code, they may actually rule out community suggestions or contributions. This does not incentivize customers, partners or competitors from making code contributions as they will get rejected out of hand. This approach is ‘Open Source In Name Only’ as it rejects the whole reason to collaborate. This is actually a leading indicator that a project will change from Open Source to Closed Source, so be aware of when companies state that they are responsible for the vast majority of code commits. This is not a sign that a project is healthy from an Open Source perspective, even when adoption and use is high.
Also pay attention to what is required to contribute source code to a project - some entities will require Contributor License Agreement (CLA) While such agreements differ, they usually grant the governing entity to right to do whatever it sees fits, including changing the license. Developer Certificate of Origin (DCA) though is simply states you have the right to contribute the code you’re contributing and you’re contributing it under existing open source license. This technically means that your permission will be required for license change, in practice though this only applies to copyleft licenses, such as GPL, as permissive licenses tend to already allow you to re-license of modified work under different licenses, including proprietary ones. For more information about DCA and CLA
Alongside the software source code you should look at how the project handles all the material required to run a project. For instance, you should see whether documentation, data and all other assets required to build and implement the software involved are also available under an
Note, you should not just think about the license but also access to the source code without any restrictions. For example, Red Hat has recently
Similarly, while Red Hat’s software license does not prevent other companies from re-distributing RHEL code, Red Hat’s subscription agreement would be void if they did share the code out. Similarly, MariaDB Corporation actually followed this approach with the MariaDB Server product for years. Because MariaDB Server is based on MySQL, the company can’t use the
Trademark
While it is very important, software source code is not enough on its own. When a vendor changes the license for an existing Open Source project, they can’t really change the license for code which is already included. Instead, vendors will basically “fork” the code under a new license. Because the vendor owns the Trademark they can choose to call this new and very differently licensed thing the old name for the project, which is very important.
MariaDB teaches us an interesting example in this regard. The original MySQL Founder, Michael “Monty” Widenious, did not like where Sun and later Oracle were taking MySQL, so he exercised his right to fork and created MariaDB. He was able to use the source code under the terms of the GPLv2 license, but not the name of the product itself.
What the MariaDB team did that was very clever is that they convinced many Linux distributions to provide you with MariaDB for any options where you had the choice to use MySQL. As a user, when you were asked to install “mysql” MariaDB Server was there as an option. In initial versions, any MySQL tools using command line names - “mysql”, “mysqldump,” “mysqladmin” et cetera - were all supported, so users often would not even know they were running MariaDB rather than MySQL. Even though the new project could offer compatibility with MySQL on the write protocol and command line level and actually, initially had little difference from MySQL, it could not be called MySQL. This differentiated the two projects, even when the code base was identical.
For a project, this can be an essential element in all the work that the community has done around raising awareness, so any fork can face an uphill battle in raising awareness or letting people know that alternatives exist. For those that have contributed code to previous projects, the choice of whether to carry on making those contributions or supporting code that has been donated in the past can be a tricky one.
Software and Information Distribution Channels
When it comes to the software, what is PostgreSQL? For many developers, it will be whatever Google says it is or whatever is located at
I already wrote about how MariaDB was successful in replacing MySQL as the database of choice within some communities,
The interesting thing about Software Information and Distribution is that it is not based on IP ownership alone, though IP ownership really helps. People can choose where they get the information about software as well as download software itself, and it requires hard work by the community to remain the leader in this space compared to any commercial organizations that are involved in supporting the projects.
Summary
If you're an Open Source Contributor, I hope this will help you to understand the issues around software ownership, licensing and changes in approach. When companies make decisions to change their licenses, they are not taken lightly, but they often overlook the contributors and community involved beyond the initial pushback or risk of a fork taking place.
For Open Source contributors, you should continue getting access to fruits of your labor. For the open source project community, you should maintain thought leadership and develop content in the project space. If you’re an Open Source minded Founder, this also may serve as a roadmap for how to set up your project, so you yourself can’t hurt the community you created in the moment of weakness of greed.