Introducing the Functional Source License: Freedom without Free-riding

Sentry started life in 2008 as an unlicensed, 71-line Django plugin. The next year we began publishing it under BSD-3, and ten years later we switched to the Business Source License (BSL or BUSL). Last year we purchased Codecov, and a few months ago we published it under BSL/BUSL as well. That led to some vigorous debate because of our use of the term “Open Source” to describe Codecov, from which emerged this helpful suggestion from Adam Jacob, co-founder of Chef:

I think the way forward here is to make what I suspect is a loose confederation of folks using non-compete licenses to actually get together and draft their own set of values. To then brand that. And stand behind it proudly.

We took him up on it by articulating our values and inviting input. Today we’re taking another step by relicensing both Sentry and Codecov under a new license we’ve written called the Functional Source License (FSL). FSL is an evolution of BSL that deepens our commitment to balancing user freedom and developer sustainability. We think it is a compelling option for Open Source-minded SaaS companies such as ourselves who wish to grant freedom without harmful free-riding.

We developed FSL openly over the past two months. Thank you to everyone who weighed in on X/Twitter and Hacker News, and especially those who participated on GitHub (* = Sentry employee): djc, ljharb, kemitchell, gauthamcs*, mitsuhiko*, augb, benvinegar*, dcramer*, ezekg, and ssdanbrown. Special thanks to Gavin Zee* and Virginia Badenhope* for doing the bulk of the drafting, and Heather Meeker for participating in several real-time drafting sessions.

BSL: Pretty Good, but Too Complex and Too Long to Wait

The Business Source License (BSL or BUSL) is a source-available, non-compete license with a twist: it reverts to an Open Source license after a number of years. Whereas open core limits in space (as it were), BSL limits in time. There is one edition of the software with all features included, but the software can’t be used to economically undermine the producer of the software. BSL is an example of “delayed open source publication” (DOSP), and Sentry is sponsoring research into the history of DOSP by the Open Source Initiative.

BSL has worked well for us. We like the simplicity compared to open core. We never have to waste time on internal conversations, “Should this feature go in the community or enterprise edition?” It feels more honestly aligned with Open Source values to have all features immediately available and eventually Open Source.

But BSL has two major flaws. First, the default non-compete time period is four years, which is a really long time in the software world. This can make it feel like the eventual change to Open Source is only a token effort. It almost might as well be 100 years. For Sentry we chose to tighten to three years, but even that is probably too long.

The more serious flaw is that BSL has too many parameters: the change date, the change license, and the Additional Use Grant. The Additional Use Grant is the biggest problem. It is a giant fill-in-the-blank that effectively means that every BSL is a different license.

The variability in the BSL, especially with the Additional Use Grant, makes it difficult for compliance departments to approve use of BSL software since they can’t adopt a blanket rule, they must review each case individually. It also makes it difficult for companies to adopt BSL for their own products, because they need to make decisions and write custom language for it. We want to widely promote the values that led us to BSL, and to that end we want to fix the friction, with FSL.

FSL: Streamlined for SaaS Companies

The Functional Source License (FSL) makes opinionated decisions about the variables in BSL, so that it is easier to reason about for both potential producers and consumers of FSL software. FSL is tuned for SaaS companies such as Sentry. It is not ideal for companies that depend on other business models, such as charging for on-premise use or library embedding.

The change date is two years. This is half the BSL default, which we arrived at after discussing a range of options. For companies using FSL, two years provides protection against competition, but also acts as an incentive to continue innovating. For the user community, two years provides meaningful protection in the event the driving company drops the ball.

The change license is Apache 2.0 or MIT. We looked at all popular licenses according to OSI and GitHub. Copyleft doesn’t fit our values, and BSD/ISC don’t offer anything over MIT. That left us with Apache 2.0 (with its patent grant) and MIT.

There is no additional use grant. Instead, FSL defines Permitted Purpose: “any purpose other than a Competing Use. A Competing Use means use of the Software in or for a commercial product or service that competes with the Software or any other product or service we offer using the Software as of the date we make the Software available.” We provide specific examples of both Competing Use and Permitted Purpose based on our history of fielding licensing questions. The goal is to avoid having to ask in almost all cases.

In plain language, you can do anything with FSL software except economically undermine its producer through harmful free-riding. You can read it, learn from it, run it internally, modify it, and propose improvements back to the producer. To apply FSL to your project, copy the FSL-1.0-Apache-2.0 or FSL-1.0-MIT template as LICENSE.md in your project, and fill in the copyright notice. That’s it.

Why? Freedom without Harmful Free-riding

We value user freedom and developer sustainability. Free and Open Source Software (FOSS) values user freedom exclusively. That is the source of its success, and the source of the free-rider problem that occasionally boils over into a full-blown tragedy of the commons, such as Heartbleed and Log4Shell. The strength of Open Source is also its greatest weakness.

We want to do something about harmful free-riding by prioritizing developer sustainability—for ourselves and others—in addition to user freedom. By prioritizing sustainability for ourselves through licensing, we are able to prioritize sustainability for others within the wider Open Source community by allocating significant funds every year and encouraging other companies to join us.

FSL is not the perfect license for everyone who shares our values of user freedom and developer sustainability. But for Open Source-minded SaaS companies such as ours, we think it’s a strong option. It is less restrictive than copyleft, and more open than open core. FSL is simple, straightforward, and codifies what has worked well for us at Sentry for several years now.

Visit fsl.software to learn more, and talk to your lawyer about whether FSL is right for you. If you decide to adopt FSL or you have questions, let us know on X/Twitter, Discord, or GitHub.