The Business Source License (BSL) is a middle ground of sorts between open source and end-user licenses. The BSL (also sometimes abbreviated as BUSL) is considered a source-available license in that anyone can view or use the licensed code for internal or testing purposes, but there are limitations on commercial use.
Unlike open source licenses, the BSL prohibits the licensed code from being used in production — without explicit approval from the licensor.
But, similar to open source licenses, BSL-licensed source code is publicly available, and anyone is free to use, modify, and/or copy it for non-production purposes.
Additionally, after a set period of time, either four years or an earlier period set by the licensor, the BSL automatically converts to an open source license of the licensor's choosing. However, the open source license must be compatible with GPL, and it usually applies only to specific software versions on a rolling basis, based on the date of release.
Note: Two versions of the BSL have been released: the original 1.0 and the current 1.1. Assume all references in this blog are to the current BSL 1.1 unless otherwise stated.
Business Source License Requirements and Provisions
The Business Source License has provisions in common with both open source and end-user licenses. It also has a few non-standard clauses that are important to understand. Here’s a look at the license’s key requirements, provisions, and exceptions.
Required Change from BSL to Open Source License
Software licensed under the BSL will not stay under the BSL forever. This is because of a provision that requires software under the BSL to convert to an open source license within four years after its release date. This is sometimes called a “springing license.”
It’s important to note that this requirement applies to specific software versions. If you release v1.0 of your software under the BSL on January 1, 2025, v1.0 must convert to a GPL-compatible license by January 1, 2029. But the four-year clock won’t begin for subsequent versions until the “first publicly available distribution of a specific version.”
Within those general constraints, the licensor has the freedom to decide exactly when the license change will happen (“Change Date”) and what the new license will be (“Change License”).
- Change Date: The licensor can specify a date for the license change as long as that date is within four years of the software version’s release. If no date is specified, the change will automatically happen four years after the software is released under the BSL
- Change License: The Change License must be GPL v2 (or later), or a license compatible with GPL
Using BSL-Licensed Software in Production
The BSL doesn’t allow licensed code to be used in production unless the licensor uses the “Additional Use Grant” mechanism. The Additional Use Grant allows the licensor to identify specific circumstances where licensed code can be used commercially.
The BSL does not define “production” use. Many licensors use Additional Use Grants to clarify the definition or to broaden the rights granted.
For example, Hashicorp’s BSL implementation (which made headlines when the company announced its change from the Mozilla Public License) includes an Additional Use Grant that does allow for production use — except in products that are competitive with Hashicorp’s. Sentry (an application monitoring platform) uses a similar Additional Use Grant to prohibit competitors from using its BSL-licensed code in production.
MariaDB, the license author, takes a different approach. Its Additional Use Grant allows commercial use only if “your application uses the Licensed Work with a total of less than three server instances in production.”
In situations where you want to use BSL-licensed code — but your production use case isn’t covered by an Additional Use Grant — the license states that “You must purchase a commercial license from the Licensor, its affiliated entities, or authorized resellers, or you must refrain from using the Licensed Work.”
Other BSL Provisions
As mentioned, anyone is free to use, redistribute, copy, modify, and create derivative works of BSL-licensed code for non-production purposes. Additionally, you are required to include a copy of the BSL text in any copy or modification of a BSL-licensed work.
History of the Business Source License
In 2016, MariaDB (a cloud database company founded by members of the core MySQL team) released v1.0 of the Business Source License. MariaDB CTO Michael 'Monty' Widenius explained the rationale for creating the license in a ZDNet interview a few years prior. Widenius said, in part:
“You can get access to all the source. You can use it in any way but the source has a comment that says you can use it freely except in these circumstances when you have to pay… Because you have the code, you know that if the vendor does something stupid, somebody else can give you the support for it. So you get all the benefits of open source except that a small portion of users has to pay. As long as you continue to develop the project, each version still gets a new timeline…"
In 2017, MariaDB released its first (and to date only) new version of the license, BSL 1.1. The BSL 1.1 was created with input from Heather Meeker (a leading IP attorney and open source licensing expert) and Bruce Perens (co-founder of the Open Source Initiative).
The essence of the two versions is similar, but there were several notable differences, including:
- In v1.1, the “Change License” (e.g. the open source licenses that the BSL eventually converts into) must be GPL compatible. There was no such requirement in v1.0.
- In v1.1, the “Change Date” (e.g. the date on which the BSL converts to an open source license) must be within four years of the software release date. This time constraint didn’t exist in v1.0.
- While v1.0 allowed the licensor to specify situations where the licensed software could not be used (“Usage Limitation”), v1.1 takes the opposite approach. It introduces “Additional Use Grants,” which the licensor can use to communicate circumstances where the licensed code can be used in production.
Additional Software Licensing Resources
For more information on software licensing, consider checking out the following articles from leading IP attorney Heather Meeker:
- Heather Meeker on the AGPL: Heather analyzes the AGPL (a network copyleft license), including its source code disclosure provision
- Heather Meeker on Open Source License Notices and Automation: Heather discusses open source license notices (including how they differ from copyright notices) and the role of automation in simplifying notice creation
- Heather Meeker on Open Source License Compliance Tools: Heather shares guidance on evaluating license compliance technologies and strategies for getting more value from existing tools