Business Source License Adoption

by Adam Retter

I have been following the re-licensing upheaval which has been happening with Open Source database software over the last few years. Last year, I gave a couple of small talks on the subject at both, the London Open Source Databases Meetup (slides: Database Licensing Chaos), and at Declarative Amsterdam (slides: Are we still Open Source?).

The summary is that, many well-known databases that were previously Open Source have either moved to an Open-Core Model and/or changed to Source Available licensing. There are various reasons behind this including refinement of business models and protecting investment in intellectual property. I won't debate the motivations or merits of such approaches in this article, there are already many other articles out there which do! Instead I will look briefly at one such Source Available license, the Business Source License, and whom has adopted it and how.

The Business Source License

The Business Source License 1.1 (BSL) is a Source Available software license, which guarantees that the software's source code will become Open Source after a period of time (up to a maximum of 4 years).

The BSL was created by Michael Widenius and David Axmark and developed with Linus Nyman back in 2013 (see: Introducing “Business Source”: The Future of Corporate Open Source Licensing?). As you likely know, Michael and David have a long history and involvement in MySQL and MariaDB. Previously they had taken a Dual-Licensing approach with MySQL, however they felt that did not work well due to how customers wanted to use and deploy the software. As a response they developed the BSL for use with MariaDB products.

Finally, I hope that BSL will pave the way for a new business model that sustains software development without relying primarily on support.

Michael Widenius, 2016

The Business Source License was revised in version 1.1 with the help of Bruce Perens (a co-founder of the OSI, and creator of the OSD); Adjustments were made from BSL 1.0 to make it clearer to users what they get and when, to impose constraints on the licensor as to both, the period of the Change Date (a maximum of 4 years) and the choice of Change License (must be GPL 2 or later compatible).

BSL is a parameterised license, which allows the copyright holder some flexibility in how they apply it to their work. The three parameters are:

  1. Change License

    A license which is compatible with GPL version 2.0 or later, which the work becomes licensed under after the "Change Date".

  2. Change Date

    The date at which the work ceases to be licensed under BSL and instead becomes licensed under the "Change License".

  3. Additional Use Grant (Optional)

    The BSL by default prohibits production use of the software. This parameter can optionally be used to grant additional rights to the licensee by the licensor. For example, so that it may be used with various restrictions in some form of production environment. It cannot be used to limit the other rights granted by the license.

Who is using the BSL?

The obvious adopter of BSL is MariaDB, who are using it for their MaxScale, ColumnStore Backup Restore Tool, ColumnStore MaxScale CDC Data Adapter, and ColumnStore Kafka Data Adapter software products.

In addition to MariaDB, finding other software products that have adopted BSL has not been easy. Through Google, I was able to only identify four more products: CockroachDB, Sentry.io, Materialize, and ZeroTier. There are likely others, but even with relatively little effort I was surprised to find so few!

How is the BSL being Used?

I did a brief survey of how each of the adopters that I found are parameterizing the BSL for their needs...

Change License

  1. MaxScale: GPL Version 2 or later
  2. CockroachDB: Apache 2.0
  3. Sentry.io: Apache 2.0
  4. Materialize: Apache 2.0
  5. ZeroTier: Apache 2.0

The majority of those appear to be using Apache 2.0 as their Change License. BSL 1.1 states the following about the choice of Change License:

a license that is compatible with GPL Version 2.0 or a later version, where “compatible” means that software provided under the Change License can be included in a program with software provided under GPL Version 2.0 or a later version.

This is interesting because actually, the Apache License, Version 2.0 is not compatible with GPL Version 2. However, it is compatible with GPL Version 3 (see: Apache's GPL Compatibility), so I guess that the "or later version" text allows this to work.

(Period of) Change Date

  1. MaxScale: 4 Years
  2. CockroachDB: 3 Years
  3. Sentry.io: 3 Years
  4. Materialize: 4 Years
  5. ZeroTier: 3 Years, 4 Months *

* This seems an unusual period; it was calculated based on their commits and stated Change Date).

Additional Use Grant

  1. MaxScale

    Allows your application to use MaxScale up to and including two server instances for any purpose (e.g. production).

  2. CockroachDB

    Allows you to use CockroachDB for any purpose (e.g. production) as long as you are not offering it as a commercial DBaaS (Database as a Service). It seems likely that they are trying to head off large Cloud Providers (e.g. Amazon AWS) from monetizing their work for free.

  3. Sentry.io

    Their wording is almost identical to that used for CockroachDB. You can use Sentry for any purpose (e.g. production) as long as you are not offering is as a commercial SaaS (Software as a Service). Likewise, I suspect they also wanted to inhibit Cloud Providers from monetizing their work for free.

  4. Materialize

    Allows you to use as many non-clustered isolated server instances of Materialize as you want for any purpose (e.g. production) as long as you are not offering it as a commercial DBaaS.

  5. ZeroTier

    Their Additional Use Grant is the most complicated of the adopters that I looked at. In summary I interpret it as allowing you to use ZeroTier (e.g. in production), providing you are not:
    1. offering a commercial service e.g. ZeroTier SaaS
    2. creating a non-open source commercial derivative work
    3. using it within Government, unless for physical or mental health care, family and social services, social welfare, senior care, child care, and the care of persons with disabilities.

Applying the BSL to Software

MariaDB provide guidance on adopting the BSL in the form of an FAQ, however the details of how to correctly apply the BSL to your software are not crystal clear. In some places MariaDB also appear to offer contradictory advice.

Consider the following statement from https://mariadb.com/bsl-faq-adopting/#future:

Q: How far in the future is the recommended Change Date?
A: At most five years from the initial alpha release of your BSL software. Picking the Change Date depends on how rapidly the software is changing. For most software, the recommendation is four years.

This seems to directly conflict with the following statement from the BSL 1.1 itself:

Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first

If the maximum period is the Change Date or the fourth anniversary, then what would be the purpose of the Change Date being "At most five years". The period of limitation is presumably 4 years maximum?

Likewise, consider the following statement from the BSL Adopting FAQ on Change Date expiry:

All source files under BSL have a Change Date and the name of an Open Source license in the header.

This advice seems to vary from https://mariadb.com/bsl-faq-mariadb/, which by my interpretation, seems to imply that the Change Date need only appear in the BSL license file:

To convert your software to BSL, you have to add the BSL header to all your software files and include the BSL license file in your software distribution. In addition, you have to add the usage limits and Change Date that suits your software in the header of the BSL license file.

I have yet to find an explicit definition of what the "BSL header" is. In my opinion, understanding clearly how to apply the BSL to your software is at the moment difficult. Conversely, most Open Source licenses make this easy by having an explicit section with instructions on how to apply the license to your software, and often include a template header which can be copied and pasted into each source file. Similar explicit and precise instructions for BSL would be welcome.

How has BSL been applied so far?

Looking at each of the adopters that I previously identified, between them there seem to have been two distinct approaches taken to applying the BSL to their software:

  1. Maintaining the Change Date in both, a central license file, and also within a license header at the top of each source code file.
    This is the approach taken by both, MaxScale (LICENSE.TXT / server.cc), and ZeroTier (LICENSE.txt / Node.cc).
  2. Maintaining the Change Date only in a central license file, the license header at the top of each source code file then references the central license file. This is the approach taken by both: CockroachDB (BSL.txt / server.go), and Materialize (LICENSE / server.rs). Sentry.io also takes a similar approach (LICENSE), but unusually (at least in my experience) does not include any license header or copyright notice at the top of their source files.

The advantage of approach (2) for the developer/publisher is that they only have to update their licenses Change Date in a single place. This removes any opportunity for inconsistency across multiple files.

However, from a user/developer (or even archivist) perspective I think there are advantages to approach (1), in so far as, if I am viewing the source code files individually, perhaps because they had been distributed individually or separately to the main body of work, then the Change Date is immediately apparent.

Which approach is correct? I don't know! It could be one or the other, both, or neither.

Regardless, at present there is no evidence of a consistent approach. I believe it is likely that this may have been caused by a lack of explicit and precise guidance on how to apply the BSL to your software.

Personally, I rather like the BSL for the purpose that it serves, and hope for clarification on how it should be applied in the near-future.