Over the last few years, there have been many calls to evolve the Open Source Definition (OSD) to fit the modern world. Some would like to see noncompetitive licenses such as the Server Side Public License (SSPL) or Elastic License considered open source. Others approach this by thinking about ethics and “using software for good and not evil.” Yet another group is so concerned about privacy that they think strong privacy protections need to be included in the open source definition as a standard.
What I get from all this discussion, though, is that what started decades ago as a small but united group of free and open source software enthusiasts has grown and evolved into multiple groups with different needs and different visions. The current discourse, which tries to split the whole software landscape into open source and proprietary software, is not helpful. Proponents of source-available licenses with ethical or non-compete restrictions rightfully do not see themselves as in the same group as hardcore proprietary software, where you do not have access to the source code and can be prevented from doing other things, too.
Additionally, open source itself has a lot of shades to it. There is a huge difference in what you can actually do with software that is licensed under the terms of BSD License compared to AGPL 3.0. Each of these licenses exists for a reason.
Why is this debate taking place?
Today, open source has become increasingly polarized. There are those committed to the OSD and projects that focus on community or foundation models, and there are single vendor-driven commercial open source projects that are increasingly bringing in non-OSD licenses to protect their positions and competitive advantage but still want to get the benefits that open source offers around the community, market reach, and developer access. Any market that gets broken up in this way will become less useful to the ultimate audience involved – developers. I think the best way to handle the situation is not to simply dig our heels arguing about getting a single modernized open source definition but to embrace variety and agree on how to describe the software licensing landscape, where there is a place for all kinds of licenses.
I have used this list to show where different licenses fall within the overall software license landscape:
A quick license primer
This is an intentionally simplified summary:
Classic proprietary covers software used for Windows, Mac OS, iOS and a lot of other software out there we use every day. All such software tends to have unique terms of use that you accept when you purchase or use it, which can be referred to as the End User License Agreement (EULA). Users of such software tend not to have access to its full source code.
Source available is a class of license that allows you to see the source code, but it does not give you the right to use that software in every way you see fit. For example, it may not allow you to use or re-distribute modified software in certain cases, so you do not have the freedoms expected from open source.
Open source copyleft covers open source software licenses such as GPL and AGPL, which require derived work to be distributed under the same license, hence, in theory, requiring the community to benefit from changes and improvements. On the other hand, this means this software can’t be embedded in any commercial software, which, in practice, reduces its adoption. Alongside this, a lot of software is not distributed but delivered as a service. These licenses often do not deliver on their original purpose of ensuring changes to the software are shared with the community.
Open source, permissive licenses such as BSD, MIT, MPL, and APL are open source, but unlike copyleft licenses, they generally allow software to be embedded in other software, even if it is proprietary.
Public domain means no one claims any intellectual property rights, and it can be used without any restrictions whatsoever. For example, some open source licenses ask you to retain copyright information, where there are no such restrictions in the public domain
This approach is single-dimensional and ranks licenses based on how many rights you reserve as the original developer or vendor compared to what rights you give to software users around the code and how they can use it. When you release software that gives the most freedom to its users, you enable them to use software for any purpose, including competing with you or using it for purposes that may not be in line with your ethics.
Each of those classes has some different complexity. Even what I call “classic proprietary” software can include software that you can use for free (as in beer) for development or noncommercial purposes. However, these licenses will be proprietary and paid for production deployments.
The area of source available software is where most discussion is taking place today. I like to break this area into the following sub-groups:
Ethical source are perhaps the best source available licenses, as they tend to focus on maximizing public good rather than ensuring one player gets to be in a privileged position. Even though this license is created with good intent, it can add a lot of impractical friction on controlling who is the software end user and what purpose the software is used for. In the effort to do good, it makes things harder in many circumstances.
Non-competitive licenses are the software licenses that are coming to the fore today. They are focused on making software and code available to groups like developers but also helping one vendor, typically the creator of an open source project, to reserve additional rights around who can use the software. This makes it easy for these vendors to monetize their software. On the other side, this market capture can lead to increased costs and restricted choices for companies or individuals that actually use the software. A lot of non-competitive licenses focus on cloud delivery these days (SSPL, Elastic 2.0).
In the past, we have seen licenses that look to prevent competition in support subscriptions and professional services, too. HashiCorp has taken this approach with its BSL license, which restricts any competitive use of the company’s software projects. The challenge here is who gets to decide what projects are ‘competitive’; without a strict definition in place, this can have a chilling effect on the wider market beyond what the original license was designed for.
Source for reference: While we do not see this kind of license much anymore, it was one of the first types of source-available licenses. Microsoft’s Shared Source license would allow you to see the source code as a customer, for example, to perform security reviews, but it did not provide much more.
Licenses in all of those groups can borrow ideas from copyleft or permissive open source licenses. For example, SSPL is based on AGPL and, as such, has a lot of similarities to open source copyleft licenses, whereas HashiCorp’s BSL variant is more similar to open source permissive licenses as long as you do not compete with HashiCorp.
Additionally, we can look at source-available licenses as permanently source-available or eventually open source. Permanently source available software is simple – it starts as source-available software, and it remains source-available software. Eventually open source licenses start as source available, and then make the source code for software available as open source after a given time. The most common timeframe is three to four years, based on the most recent examples. You can compare it to patents for intellectual property, which eventually expire and allow inventions to be used by everyone given enough time.
The Business Source License (BSL) is the only widely used license in this area. Note, though, unlike patents where good ideas tend to be good ideas 20 years later, by the time any code converts to an open source license, it tends to be outdated. Depending on the commitment of the vendor involved, this is likely to lead to unmaintained code that is full of security bugs, providing very little value to the user or to the community over time.
Why definitions matter
Software licensing goes back to the original decision to cover software by copyright back in the 1960s. Before that point, it was impossible to divide software from the hardware that it ran on, so the value was perceived to be in the hardware that was purchased. Today, the cloud is where software runs, and many—IT, developers, and business people alike—define the cloud as where the value comes from. It makes it easy to run software when you need it and for as long as required. This, too, ignores the value that comes from the software itself.
We need a variety of software licenses to cover the requirements that those developing software have around their code, from protecting their intellectual property to building sustainable businesses. All of these licenses are options. Proprietary and source-available software advocates will always argue that their approaches make it easier for businesses and developers.
The challenge is that for many developers, open source does not matter right up until things like source code availability and community control over projects really do count. Developers do want ease of use, ease of access, and software that responds to their needs. They got these due to Open Source, not cloud. Cloud could equally take them away under the guise of being easy.
To support open source and keep it vibrant in the future, we need to consider our options around software licensing and how we can cover the different needs of developers around software that they create, contribute to and use. However, as part of this, we also need to look at being more prescriptive about what open source means and what can be defined as open source. For those of us in the community, we also need to keep in mind why open source provides value to the community, as well as to the more commercial entities that are set up to support those projects and keep them viable over time.
About the Author
Peter ZaitsevPeter managed the High Performance Group within MySQL until 2006, when he founded Percona. Peter has a Master's Degree in Computer Science and is an expert in database kernels, computer hardware, and application scaling.
