When most people think about Free and Open Source Software they think about zero cost as the word “free” has two legitimate general meanings; it can refer either to freedom or to price. Free and Open Source Software is about freedom, not price (“free speech,” not “free beer.”). In fact, the Free Software Foundation encourages people who redistribute Free Software to charge as much as they wish or can.
Why Commercial companies go Open Source
For commercial companies, there are two primary motivations for releasing software under an open source license. Some companies believe in Free or Open Source Software philosophy and the value it creates for the company image (Free Software philosophy and Open Source philosophy are not exactly the same). Most commercial companies that release software as open source for the above reason do so for software that falls outside their core business, while retaining their primary software under a commercial license (e.g. Google, Microsoft, Meta). Others follow a more commercially oriented open source model, releasing their core software as open source while offering paid services or enhanced features on top of the open source software. In such cases, the main driver for going open source is the high adoption rate of “free” software in both its legitimate general meanings.
In certain industries, the open source model is notably prevalent, like in Blockchain and DataBase software. New entrants in these sectors often find it considerably challenging to establish a presence without adopting an open source approach.
Common Commercial Open Source models
Some companies develop and distribute software as open source software, relying on additional services, support and advanced features to generate revenue from the distributed software (e.g. HashiCorp, MongoDB, ElasticSearch). While third-party contributions are theoretically possible, in practice, the majority of the code is typically written by the company itself. This is quite understandable, as most individuals do not contribute to commercial entities.
However, not all commercial open source companies utilize homegrown software. Some leverage open source software created by third parties, often the open source community itself, such as Linux. These companies provide paid support and services on top of this open source software, like RedHat (the RedHat case is particularly intriguing due to its utilization of RedHat’s trademarks and logos in their software and EULA, but this is an issue for a separate article).
Choosing an Open Source License and CLA
If you plan to release your software under an open source license, you probably asked yourself which open source license to choose or whether to draft your own open source license. Although the exact number of open source licenses is unclear the SPDX project lists over 500 common open source licenses, which is hardly an exhaustive list. What is clear is that there are plenty of existing open source licenses to choose from and drafting your own open source license is rarely a good idea and should be done only in very specific circumstances and only by an open source expert.
Open Source licenses are typically classified as either restrictive (requiring derivative works to be released under an open source license, also known as Copyleft) or permissive (characterized by the absence of a Copyleft requirement). Restrictive licenses offer stronger protection for derivative works but often result in lower adoption rates. while permissive licenses enjoy broader adoption, at the expense of limited or no protection for derivative works. Although “derivative work protection” and “adoption rate” are the most prominent factors, they are certainly not the only factors, and other considerations may influence your choice of an open source license.
If the software you release under an open source license constitutes your core business, you should also contemplate the terms under which third-party contributions are accepted and consider implementing a contribution license agreement (“CLA”) as a prerequisite for third-party contributions. Without a CLA, making changes to the license in the future could be difficult and, in some instances, nearly impossible.
The chronicle of high adoption
If your objective is to achieve widespread product adoption, you would likely choose a well-known permissive open source license. However, once adoption rates are high, you will probably contemplate on changing the license to a more restrictive open source license or a commercial license (e.g. HashiCorp, MongoDB, ElasticSearch).
There are two primary reasons why successful open source commercial companies change their open source license:
- Competition + Research & Development (R&D) Costs. As mentioned, there are two primary commercial open source models – providing services and support on top of your own open source software, or offering services and support on top of a third-party open source software. Guess what? if your open source software is so great, competition is likely to emerge, and your competitors will not bear the burden of substantial R&D expenses. A shift to a more restrictive or a commercial license is inevitable (ElasticSearch – “why we had to change Elastic licensing”).
- Scalability + R&D costs. Did I mention R&D costs already? As your product evolves and becomes more complex the R&D expenses tend to What initially seemed like a commercially sound model encounters the “services and support” scalability limitations. You probably have acquired more clients but scaling up “services and support” relies primarily on human resources, which are a costly asset. On the other hand, scaling up software licensing requires minimal growth in human resources.
An open source model can wield significant power and make compelling commercial sense, especially for newcomers entering the market with a new product. However, adopting an open source commercial model must align with the long-term strategic vision. To avoid comment pitfalls it is advisable to seek guidance from an open source professional.
