Trust and legal
Adopting and Developing BSL Software
Frequently asked questions
Business Source License (BSL) was created by David Axmark and Michael Widenius to provide a mutually beneficial balance between the user benefits of true Open Source software that is free of cost and provides open access to all of the product code for modification, distribution, etc., and the sustainability needs of software developers to continue delivering product innovation and maintenance.
The BSL is structured to allow free and open usage for many use cases, and only requires a commercial license by those who make production use of the software, which is typically indicative of an environment that is delivering significant value to a business. It allows, and encourages, vendors to further relax restrictions on software use with an optional additional grant of right to make limited production use without payment.
BSL gives users complete access to the source code so users can modify, distribute and enhance it. It also guarantees a path for the software to become Open Source over time so that users will not become permanently locked into a single vendor. These features help preserve the critical freedom aspects of Open Source (as defined by the Open Source Initiative in the Open Source Definition) while enabling a viable business model for professional software developers.
This FAQ is designed to address questions for developers and companies interested in working on BSL software or adopting BSL for their own business
BSL is an alternative to closed source or open core licensing models. Under BSL, the source code is always publicly available. Non-production use of the code is always free, and the licensor can also make an Additional Use Grant allowing limited production use. Source code is guaranteed to become Open Source at a certain point in time. On the Change Date, or the fourth anniversary of the first publicly available distribution of the code under the BSL, whichever comes first, the code automatically becomes available under the Change License. The Change License is mandated to be GPL Version 2.0 or later or a compatible license (i.e., the Change License is always an Open Source license that enables use of the software in a GPL project).
To create a license that strikes a balance between being able to run a financially viable software company while still supporting the original tenets of Open Source, such as empowering all software developers to be part of the innovation cycle – giving them open access to the code so they can modify or distribute the software by making the entire source code available from the start. Ultimately, we hope that BSL will create more Open Source software.
The BSL does not meet the Open Source Definition (OSD) maintained by the Open Source Initiative (OSI). OSD does not allow limitations on specific kinds of such, such as production use. However, most of the OSD criteria are met. Most important, the source code is made available. The BSL allows for copying, modification, creation of derivative works, redistribution, and non-production use of the code. It allows for (and encourages) the licensor to define an Additional Use Grant (e.g., allowing for free use below a specified level, like in this example).
BSL version 1.0 is now deprecated. We have moved all our code from BSL 1.0 to BSL 1.1. The BSL has been reviewed and endorsed by Bruce Perens, the co-founder (together with Eric S. Raymond) of the Open Source Initiative. As a result of this review process, MariaDB introduced a number of changes together with Mr. Perens, to simplify the adoption of BSL by other vendors than MariaDB, by setting consistent user expectations of what BSL stands for. Specifically:
The BSL is not an Open Source license and we do not claim it to be one.
On the Change Date, or the fourth anniversary of the first publicly available distribution of the code under the BSL, whichever comes first, the code automatically becomes available under the Change License.
The Change License is mandated to be GPL Version 2.0 or later, or a compatible license (i.e., the Change License is always an Open Source license). Additional alternatives to the Change License may be offered by the licensor, but as a baseline, one must always be GPL or GPL compatible.
The term Usage Limitation (which in BSL 1.0 said when one could not use the software) is substituted by Additional Usage Grant (which says when you can use the software)
The word Software is substituted by Licensed Works, so BSL can be used for other types of work.
The license expressly mentions purchasing a commercial license from the licensor where the desired use of the Licensed Work is not allowed under BSL.
As recommended by Bruce Perens, the legal phrasing of the BSL has been reviewed and edited for consistency and simplicity by Heather Meeker of O’Melveny & Myers LLP. Author of Open (Source) For Business: A Practical Guide to Open Source Licensing, Heather has been a pro-bono counsel to the Mozilla, GNOME, and Python foundations.
Vendor lock-in occurs when users have only one vendor to go to for support, fixing bugs or getting new features added to the product. BSL avoids this in two ways. First, it allows inspection and modification of source code by any licensee. Second, when the license converts to the Change License, the software is free for anyone to use, change, and share under those terms.
No. The BSL specifically allows non-production use.
You only need a commercial license for any copies of the software that are running in production use.
The usage is limited to non-production use, or production use within the limits of the “Additional Use Grant” defined by the vendor using BSL and specific to each BSL product.
All source files under BSL have a Change Date and the name of an Open Source license in the header. The Change Date specifies when the source file changes from BSL to the specified Open Source license. On the Change Date, or the fourth anniversary of the first publicly available distribution of the code under the BSL, whichever comes first, the code automatically becomes available under the Change License (i.e., an Open Source license).
The answer depends on the company providing the BSL software. At MariaDB, the answer is no. Each new major version of the software will have its own Change Date.
Yes, for example the Fair Source License at https://fair.io/ and the Open Source Eventually License at https://github.com/ftrotter/OSE. The main difference is the usage framework, each of which works best with different classes of software. BSL was optimized for enterprise-class software. For a more detailed comparison of BSL with other Open Source licenses, please visit mariadb.com/bsl-faq-mariadb.
The answer depends on the company providing the BSL software. At MariaDB, it would be a version that does not only fix bugs but adds features.
Picking the right Change Date depends on how rapidly the software is changing. Bear in mind that, regardless of the Change Date, the Change License will take effect on the fourth anniversary of the first publicly available distribution of software under the BSL. For most software, the recommendation is four years, which is the BSL’s default position. For rapidly developing software, an earlier Change Date may help encourage community contributions.
A licensor may change the use limitation (i.e., by limiting or eliminating the Additional Use Grant) in the future, but users will always be able to use any previous version of the BSL software under its earlier limitations. In other words, the licensor’s edits would be forward-looking only and would not apply retroactively.
Contact the licensor. They may be able to partner with you to figure out what will work best for your company.
The Business Source License is trademarked. By using the BSL as a licensor, you covenant to follow the BSL wording and to only make changes that are allowed by the license. Review the BSL’s terms, particularly the “Covenants of Licensor” section, before modifying its language.
Until the Change Date (or the fourth anniversary of public distribution under the BSL), the final mixed code will be bound by the license of the BSL code and the license of the other code. So for example, mixing BSL code and GPL code before the Change Date might be difficult. After the Change Date, the final mixed code will be bound by at least the Change License (e.g., GPL Version 2.0), along with whatever licensing requirements are mandated by the other code’s license.
No. The BSL has a usage limitation that is not allowed with Open Source software. However, you can usually mix BSL, Open Source and closed source code within an application as long as you don’t release or distribute the code to third parties. You can eliminate the usage limitation by purchasing a software license for the BSL code.
Yes, but you must either purchase a commercial license for the BSL code or ensure that your product doesn’t exceed the BSL’s grant of rights. Use of in a close source product will usually be production use.
No. Your modified version consists of the original software (which is under the BSL) and your modifications, which together constitute a derivative work of the original software. The license does not grant you the right to redistribute under a permissive license like MIT.
Yes, as long as you don’t include any of the BSL code in the code for the software that’s being developed, and you do not make production use of the BSL code.
No, BSL and GPL are not compatible licenses. As such, both BSL and GPL can be combined with software under other licenses, but the requirements that they put on the surrounding software are incompatible. The BSL’s use grant is limited to non-production use, and this limitation is not allowed by GPL. GPL does not allow imposing any additional restrictions on the use of software licensed under GPL.
Yes, as long as you don’t include any of the BSL code in the code for the software that’s being developed, and you do not make production use of the BSL code.
License your code using the “new BSD” license or dedicate it to the public domain. Code contributions under “new BSD” is compatible with BSL. See BSD on Wikipedia.
No. In this circumstance, you would either violate the BSL licensor’s copyright by re-releasing the code under Open Source, or you would violate the Open Source project’s license by introducing incompatible BSL code (i.e., code subject to a use limitation not allowed by the Open Source project’s license).