The complexity of BUSL transformation

The Business Source License (BUSL) is a source-available license that "converts" to an open-source license after a period of time. In theory, this means that a few years after a version of a product is released under the BUSL, it becomes open source and is fair game for Linux distributions to package along with regular open-source projects. In practice, the license throws a few curveballs that require special consideration and caution, as the Fedora Project recently discussed.

The concept of proprietary-to-open has been around for quite some time. For example, Aladdin Enterprises developed Ghostscript under a similar scheme from 2000 to 2006. The company's proprietary version, Aladdin Ghostscript, was released under the source‑available (and misnamed) Aladdin Free Public License first and then later as Ghostscript under the GPLv2. That, however, was a two‑step process where the source release was performed under a different name and a clear change of license.

BUSL was, however, the first license to include a transformation clause rather than the licensor performing a separate release under the open-source license. It was introduced in the article "Introducing 'Business Source': The Future of Corporate Open Source Licensing?" by Michael (Monty) Widenius and Linus Nyman in 2013, and then applied in 2016 to MariaDB's database-proxy product, MaxScale.

The idea behind the license, according to the article, was to "harness the benefits of open source while generating sufficient income for the program's continued development". BUSL permits modification and redistribution of the code, but restricts "production use" of the software as long as the terms of the BUSL apply. After a period of time, generally four years, BUSL specifies that the code becomes available under the GPLv2 or later, or a compatible license.

Since the release of MaxScale under the license, a handful of other companies have adopted BUSL for some or all of their products as well. During its larval stage, BUSL-licensed software is a non-starter for inclusion in most Linux distributions. Now that some of the software is emerging from its non-free chrysalis, the question is whether and how it might be included as open-source software.

Transformation

Recently, Michal Schorm sought guidance about how to treat software once it had transformed to use a free license. Specifically, Shorm asked about the MaxScale 21.06 release on GitHub with a change date of June 3, 2024. He wanted to know how Fedora packagers should represent the license in the binary package, and if there were other special considerations for formerly BUSL software.

Neal Gompa wondered if the System Package Data Exchange (SPDX) format, which is what Fedora now uses in its packaging to identify licenses, should add a way to specify that a license had converted. "Non-free licenses converting to FOSS licenses have been a thing for a few years now. Now we're starting to see stuff 'convert', we probably want a way to express that?"

Richard Fontana, a member of Red Hat's legal team who advises Fedora on legal issues, said that the question of how to categorize software that had transitioned to a free license had not come up before. He said that it was "'fine' in theory, but somewhat risky" to package the software for Fedora:

I imagine that in some cases it won't be clear whether a particular version mixes BUSL (at various stages of the process towards the "change date") and post-BUSL licenses.

If it was clear that the change date had been reached, then it might require some further action to document that beyond the license tag in the RPM, Fontana said. But, he said, "we can cross the bridge when we come to it -- or have we come to it?" Daniel P. Berrangé said "Yes & no". The branch shared by Schorm had files with change dates that had not yet passed the change date, which was the risky scenario that Fontana worried about. "I presume this is because that branch will be getting [maintenance] bugfixes periodically and they'll be setting a new Change Date each time." But, if MariaDB had distributed a source tarball instead, it would be from a fixed point in time and easier to determine if the code was older than the change date.

Schorm followed up to say that he had been contacted by MariaDB and that it had indicated that they would like to see MaxScale adopted by Linux distributions since its oldest major version had just reached its transformation date.

With that information, Berrangé said that the company could take steps to make it simple by updating the branch for the old version and replacing the license and file headers with GPL instead of BUSL. Finally, the company should release an updated tarball with appropriate bug fixes to make the licensing entirely unambiguous, "and thus [trivially] accepted by any distro maintainers". If it is clear that software has passed its change date, Fontana said, then its BUSL heritage is not an obstacle to packaging in Fedora. Packagers should make it clear that the operative license is the one allowed for Fedora and use that license in the RPM spec file.

Vít Ondruch asked about security fixes. If a security vulnerability is discovered and fixed in a later version of the software, should that patch be reimplemented? Fontana said that might be an option, but Berrangé cautioned that it could be tricky if "the 'reimplemented' patch ends up being effectively (or actually) identical to the official patch".

Up in the air

The Fedora conversation trailed off without any concrete plan of action for handling security updates or other maintenance for ex‑BUSL software. It seems almost certain that packagers would be responsible for implementing their own bug and security fixes for any given release, effectively becoming a fork of the upstream. Then, when another version reaches its change date, the packagers would need to reconcile the homegrown fork with the next upstream release.

All of that, of course, could be avoided if companies chose open-source licenses in the first place. Failing that, they could take a cue from Aladdin's playbook and actively maintain open-source releases under a different name that don't have the same complexities of BUSL‑licensed software.